Why organisation almost always wins over architecture

On Conway’s Law, friction, and leadership trade-offs

Conway’s Law is often quoted, but rarely taken fully seriously. It describes how organisations tend to design systems that mirror their communication structures. In other words, architecture becomes a reflection of how we organise ourselves and work together.

It sounds simple. But in practice, it explains very precisely why architectures become complex, tightly coupled, and hard to change, even when the original intention was something quite different.

Over many years, I have found that architecture rarely fails for technical reasons. It fails because the organisation is pulling in another direction. When teams are organised around systems, technologies, or functions, the architecture will, over time, become divided in the same way. When responsibility is fragmented, interfaces become unclear. And when coordination across boundaries is expensive, solutions emerge that make local sense but, taken together, make the organisation slower.

And yet I often come across the wish to “fix” the architecture first and the organisation afterwards. The idea is to design the right architecture and then adapt teams and responsibilities to match it. The problem is that, in practice, this is almost never possible.

Most organisations already have more than enough to do:

• deliver on the roadmap
• keep operations stable
• deal with existing technical and organisational debt

There is rarely enough slack to split systems apart, establish new interfaces, and prepare a reorganisation that matches the future architecture all at the same time. The result is often that the organisation remains stuck in a kind of halfway state, where everyone knows something needs to change, but no one can quite see how to get there without losing momentum along the way.

This is where I believe we need to shift perspective. Instead of trying to remove all friction, leaders should ask themselves:

• how much friction can we handle?
• where is friction most usefully placed?
• and where does it become directly harmful?

I remember a conversation very clearly with a CIO in a large Danish company, whom I was advising. The ambition was to organise value stream teams close to the customer and deliver all the way from need to solution. In the middle of the discussion, he stopped and pointed out that if you really want to deliver end to end, it would involve 12 different systems, 12 technologies, and a corresponding number of competencies.

With a desired team size of five to nine people, which we felt gave a sensible balance between overhead, collaboration, and productivity, it was obviously impossible to bring the entire architectural stack into a single team. Either you would create unreasonable demands on the breadth of competence within the teams, or you would end up with massive dependencies between teams.

So the choice was not between a perfect solution and a bad one. It was between doing nothing and remaining in a classic system-based organisation with long distance to the end user and countless dependencies, or deliberately stretching the elastic.

We chose the latter.

The organisation was changed into five customer-facing teams, each covering three to five architectural layers. The remaining parts were grouped into component teams. It created friction, but it reduced coordination significantly compared to the previous setup. More importantly, it created movement. More decoupling. Stronger customer focus. And a new, temporary friction until organisation and architecture found a new balance.

It is a pattern I have seen again and again. And every time I speak with CIOs or CTOs about Conway’s Law, there is never any real disagreement. Everyone knows that organisation plays a decisive role in the architecture you end up building. The challenge is not the insight. The challenge is acting on it in an everyday reality shaped by high speed and tight deadlines.

To me, experience suggests that the way forward requires a long-term target picture, where leadership aligns on a few basic questions:

• What is the business ambition?
• What kind of systemic support does it require?
• What should the architectural landscape look like over time?

And then accepts that the path there will not be frictionless.

You have to choose your starting point. Reorganise in a way that supports movement. Take some steps. Follow closely how it affects collaboration, decisions, and delivery. Adjust along the way as you learn more. And then take the next step. Until, gradually, you are left with a more loosely coupled architecture that actually supports the business agility you are aiming for.