One strategy, multiple realities

A solutions architect and a senior engineer sit in the same meeting. They're discussing the same product, the same customers, the same codebase. They both want the company to succeed. And yet, three weeks later, one of them is building separate product branches for each customer implementation, while the other is tightening controls on the mainline to prevent exactly that. Not because anyone disagreed. Because the same business goal, filtered through two different roles, arrived as two opposite technical priorities.

Refraction across domains

In a previous article, I described how strategy refracts as it travels down through an organization. A CEO's decision looks different to a VP, different again to a manager, and barely recognizable by the time it reaches the team doing the work. Each level translates the message for the level below, and each translation shifts the emphasis.

But that's only one dimension. Real organizations don't just have levels. They have domains: engineering, sales, marketing, finance, operations. Each domain has its own language, its own priorities, its own definition of what "good work" looks like.

When top-level guidance travels down, it doesn't follow a single path. It enters each domain separately and refracts independently. The CTO translates strategy for engineering. The CCO translates the same strategy for the commercial side. By the time those translations reach the execution level, each domain has arrived at its own internally coherent interpretation. And here's the problem: within each domain, it feels like the organization has aligned. The refraction is invisible from inside.

How the same guidance splits

Consider a company that builds a complex product. As it grows, customers need customizations: specific configurations, integrations, sometimes entire features built for a single use case. Leadership's goal is straightforward: serve more customers, faster, without breaking what already works.

Two people own different parts of that goal.

The solutions architect, Lisa, works closely with customers and reports into the commercial side of the organization. She translates the goal as: "We need to deliver customizations quickly. Each customer implementation should have its own branch so we can move fast without stepping on each other."

The senior engineer, Marco, owns the long-term health of the codebase and reports into engineering. He translates the same goal as: "We need to keep everything in the mainline branch. Every customer fork is technical debt. The only sustainable path is a stable core with a clean extension model."

Both translations are correct. Both serve the business goal. Both people are probably even thinking about the same metrics: delivery speed, customer satisfaction, engineering capacity. But they've arrived at opposite conclusions, because the same guidance refracted differently through their respective domains.

And neither of them knows it. Each one believes the organization has reached consensus. Lisa sees agreement within the commercial side. Marco sees agreement within engineering. From inside either domain, the picture looks complete. What neither can see is that they're each working from a different version of the same guidance.

The further down, the harder to bridge

This is where cross-domain communication becomes expensive. Not because people are bad at communicating, but because the shared context they need lives above them. Any two people in different domains share a common point somewhere higher in the organization where their guidance was still unified. For a CTO and a CCO, that point is close, and the gap is small enough to reconcile over a conversation. For their direct reports, it's one level up. Still bridgeable.

But for Lisa and Marco in our example, the point where their guidance was still the same sits some levels above them. To discover their misalignment, one of them would need to reconstruct the full chain of translations that happened in the other's domain. That's not a conversation. That's an archaeology project.

The further down you go in the organization, and the more the guidance has refracted through each domain, the more effort it takes to communicate across those domains. Not because of how far apart they sit on the org chart, but because the amount of divergent context between them has accumulated with every translation step.

This is why the misalignment goes undetected. The cost of discovering it is higher than either person realizes, because from inside their own domain, everything looks resolved.

"I thought we were done"

At one point in this story, Lisa asked Marco to document the discussion from a neutral perspective, because she didn't trust herself to be unbiased. Days later, she asked for the document. The response: it wasn't ready yet, because the discussion on the engineering side was still ongoing. Her reaction: "Oh, I thought the discussion was concluded."

She wasn't being dismissive. From her vantage point, the discussion genuinely was concluded. Her domain had processed the guidance, arrived at an answer, and moved on. The fact that the other domain had arrived at a completely different answer, and that the two answers were incompatible, was invisible to her.

This is what organizational refraction looks like in practice. Not loud disagreements. Not obvious conflict. Just two parts of the organization quietly executing on different versions of reality, each convinced they're aligned.

The bridge role

So who catches this?

In this case, it was a more senior engineer, David. Someone operating at a higher level in the organization, with enough altitude to see both domains' interpretations side by side. He looked at the branching debate and saw something neither Lisa nor Marco could see from their positions: the disagreement wasn't about branches. It was about a business decision that nobody had explicitly made:

Do we want to deliver customizations quickly as separate products that happen to share a common base? Or do we want a stable base product with extensions on top for each implementation?

Both choices are valid. But until that decision is made at the right level, Lisa and Marco will keep optimizing for different answers to a question nobody asked.

This is what a bridge role does. Not mediate. Not split the difference. But use their altitude to see the common nexus and their domain fluency to trace refracted guidance back to where it was still unified. Once the refraction is visible, it's solvable.

What to do about it

Refraction across domains is structural. You can't eliminate it. But you can make it visible and manage it.

Recognize that domain alignment is not organizational alignment. When your engineering team agrees on an approach, that's one domain's interpretation of the guidance. Check whether the commercial side, or operations, or product has arrived at the same interpretation, or a compatible one.

Build bridge roles at the divergence points. Where two domains need to coordinate at lower levels, don't rely on the execution layer to discover the gap on their own.

Check for refraction explicitly. After translating a strategic decision downward, ask the receiving teams in different domains to describe what they think changed. If Lisa says "we're setting up per-customer branches" and Marco says "we're building an extension framework," you've caught the refraction before it becomes a three-week argument.

Name the decision that's missing. When two competent people in different domains can't agree, the disagreement often lives one level above where they're looking. The branching debate was never going to resolve itself, because it was a proxy for a product strategy question that nobody had answered. Find that level and make the decision there.

Lisa thought the discussion was over. Marco thought everyone agreed with him. David was the one who saw that neither was true. Who in your organization is your David?

Ivo Timmermans is the founder of Sparqpath, where he works as a fractional CTO and strategic technology advisor, helping companies build the translation layers between business strategy and engineering execution.