Invite an engineer to your strategy meeting

The fastest way to predict what your product will look like in six months is to look at how your teams talk to each other. Not the org chart. The actual conversations. What flows between domains ends up in the product. What gets stuck at a boundary ends up as friction your customers feel. Here's what you can do about it.

You may already know what Conway's Law describes, even if you've never heard the name: teams that don't talk enough build components that don't integrate. Leave two groups alone long enough and the product starts to feel like two products. The org chart leaks into the user experience. This is not news to anyone who has shipped software with more than one team.

But do you know how far this effect extends? It doesn't stop at the product. The same organizational friction that creates inconsistent user experience also shapes how sales talks about the product, how support handles escalations, how finance structures pricing. The customer doesn't experience your product in isolation. They experience your organization. And when internal alignment breaks down, the customer can feel it.

The problem is structural, not personal

In a previous article, I described how strategy refracts as it passes through an organization. The same guidance enters different domains, and by the time it reaches execution, each domain has arrived at its own internally coherent interpretation. Engineering hears "scale" and builds for extensibility. Sales hears "scale" and optimizes for faster delivery. Both are right within their context. The product absorbs both interpretations.

This is organizational friction. Not the kind caused by bad people or poor decisions, but the kind that emerges naturally when a message has to travel across domains and down through levels of abstraction. The further the distance between the source of intent and the point of execution, the more room there is for the signal to shift.

This is a solved problem in many organizations. Not by eliminating friction entirely, but by understanding where it occurs and putting mechanisms in place to counteract it.

Mechanisms to align the organization

When organizations successfully prevent their product (and broader customer experience) from fragmenting, two patterns consistently show up.

1. A sharp, concrete vision

The first mechanism is a vision so clear that people can translate it to their own work without being told how. Not a mission statement pinned to the wall. Not a slide deck from an all-hands. Something concrete enough that a person in any role can look at what they're doing and ask: does this move us toward that? The power is in the focus. When the vision is sharp, it gives everyone permission to connect the dots themselves.

History is full of examples. The NASA janitor who, when asked what he did, answered that he was helping put a man on the moon. Alan Mulally, on arriving at Ford, cutting the company's sprawling brand portfolio back to a single name so the entire organization could rally around "One Ford." In both cases, the vision wasn't abstract. It was sharp enough that a janitor, an engineer, a designer, and a salesperson could each see their own work as a contribution to it.

A clear vision produces something valuable as a side effect: an unbroken line from strategy to execution. When everyone can connect their work to the same concrete target, there are no layers where the message gets stuck, distorted, or quietly reinterpreted. Domain-specific interpretations still happen, but they converge rather than diverge. The continuum holds together not because leadership is constantly re-communicating, but because the vision does the alignment work on its own.

Most vision failures are not a lack of effort. They are a lack of sharpness.

A vision that tries to cover everything ends up guiding nothing. Focus is what lets people align the work they already do.

2. Intentional bridges between domains

The second mechanism is people who actively connect different domains. Product managers are the most obvious example, but not the only one. What matters is that someone holds the full picture across team boundaries and has the authority and context to flag when interpretations diverge.

I've worked with a product manager who was exactly this. He knew the product inside out, not just the features his team was building, but how customers actually used the product across all of its capabilities. When one team's roadmap started drifting from the overall product direction, he caught it. Not because he was micromanaging, but because he held a mental model of the whole customer experience that no individual team could hold on its own.

I've also seen variations on a simpler pattern: making developer exchange an explicit mechanism. A developer embedded in another team for a day a week, or for the duration of a project. Engineers rotating through support, through operations, through whichever domain produces the friction they rarely see up close. Not as a one-off favor, but as an intentional expectation built into how projects are run. The effect is consistent: engineers come back with a sharper sense of how their work actually lands, and the receiving team gets a direct line into the development process. Users' paper cuts get fixed faster, and the friction between domains becomes a shared problem rather than someone else's.

These are bridge roles. They create the lateral connections between domains that a purely hierarchical structure can't maintain. In a small enough company, some of this happens organically through hallway conversations and shared lunches. Once the company outgrows that, the informal bridges stop being enough, and you need to design them intentionally.

Exposure is sought. Leadership has to provide it.

Here's what many managers miss: the people worth investing in are actively looking for exposure. They want to understand how decisions get made at the level above them. They want to see what other domains worry about. They want to know how their work fits into the larger picture. They just don't know how to ask for it, and they don't know it's available. Junior and medior individuals especially often don't realize that the meeting they're wondering about is something they could reasonably attend, or that the context they're craving is sitting in a weekly management review they've never heard of.

This is where leadership earns its keep. Exposure is not something individuals can arrange for themselves. It has to be provided, and it has to be deliberate.

The good news: this doesn't require big structural change. The lightest-weight version costs almost nothing. Invite a senior engineer to sit in on a weekly management review. Share the agenda and notes from a cross-domain sync with the people whose work it touches. Bring a product manager into a finance planning session once a quarter. Encourage people to attend the all-hands Q&A with a specific question in mind. These are small, concrete acts that give curious individuals a window into higher-level thinking and adjacent domains without asking them to take any personal risk.

Coaching matters too. Sometimes the right intervention is as simple as telling someone: "You should talk to X about this. I'll introduce you." Leaders have networks that individual contributors don't, and a single introduction can create a lasting cross-domain connection. Encouraging internal networking, explicitly, by name, with follow-up, is one of the highest-leverage things a manager can do, and it shows up on no project plan.

The two objections, and why they're usually wrong

Objection one: "these are unfinished ideas, people shouldn't see them until we've decided." When people only see the final decision, they fill in the missing reasoning themselves, usually wrongly. Exposing the thinking, the dead ends, the trade-offs, the disagreements, is what builds judgment. Hiding it doesn't protect people. It keeps them shallow.

Objection two: "some of this is sensitive." Genuinely private topics exist. Specific performance conversations, for instance. They should be handled separately. But "sensitive" is rarely the real reason. Revenue numbers are sensitive because the company decided they are. Plenty of organizations run open books without the sky falling. When "sensitive" becomes a blanket justification, it's almost always convenience dressed up as principle.

Neither objection survives much scrutiny, but both get used reflexively, and the cost of that reflex is invisible. Senior individuals stay shallow, the bridges never form, and trust quietly flows in one direction only.

Your burden is to justify exclusion, not inclusion.

If you're a leader, start from open, and carve out exceptions with specific reasons. Not the other way around.

Over time, consistent exposure is what produces the bridges the organization needs. Not through lateral moves or formal rotations, but through a steady drip of cross-domain context delivered to the people who are hungry for it. The effect compounds. People who were junior a year ago start showing up with sharper questions, broader context, and a better instinct for how their work fits the whole.

Your product is still a mirror

Your product reflects your organization. So does your sales process, your support experience, and every other touchpoint where a customer meets your company. The question is not whether organizational friction exists. It does, always. The question is whether you understand where it occurs and whether you've put mechanisms in place to manage it.

Two things make the difference: a sharp vision that people can translate for themselves, and deliberate exposure that turns curious individuals into cross-domain bridges. When both are in place, organizational friction becomes visible and manageable. When either is missing, your product starts telling a story your organization didn't intend.

What information is inaccessible to your people, but doesn't have to be?

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.