PAPER
Alignment Isn't Enough. The Model Has to Be Right.
Teams often struggle because they do not share a mental model. But there is a second failure mode that is harder to see.
Teams can align around the same model and still build the wrong system.
Alignment does not guarantee correctness.
It amplifies whatever model is already in place.
The Common Explanation
When teams are not aligned, the symptoms are obvious. Debates repeat. Decisions are inconsistent. Ownership is unclear. Work gets redone.
This is usually explained as a communication problem. The solution becomes alignment. Get everyone on the same page, define the model, move forward.
That helps. But it is incomplete.
The Hidden Failure Mode
Alignment feels like progress. Everyone agrees, decisions move faster, work accelerates.
But a team can share the same assumptions and still be wrong.
When that happens, the system does not fail immediately. It appears to work. Endpoints respond. Data flows. Features ship. The failure shows up later, when boundaries begin to blur, responsibilities overlap, and behavior becomes harder to reason about. Changes become more expensive. Edge cases expose inconsistencies that were always there.
The system was never correct. It was only consistent.
What the Model Actually Is
A mental model is not just how the system looks. It is how the system behaves.
Where state lives. Who owns it. How information moves. What triggers change. How failure is handled.
If those things are wrong, everything built on top of them inherits that error. Alignment does not fix that. It amplifies it.
Why This Happens
Most teams do not explicitly define their model. They start building. The model emerges through implementation.
At first this feels efficient. Progress is visible. Code accumulates. Behavior becomes observable. What is actually happening is that the system is being designed implicitly, through code and correction. That works until the system grows. Then the lack of clarity becomes friction.
Two Ways Systems Get Built
There are two patterns that show up consistently.
In the first, implementation comes before architecture. Teams start coding early, discover the system while building, and adapt as new cases appear. The model emerges over time. It is reactive by nature.
In the second, architecture comes first. Boundaries are defined before implementation begins. Ownership is explicit. The flow of information is intentional. Implementation follows the model rather than producing it.
The difference is not speed. It is whether the model is discovered or intentionally designed.
Where Alignment Breaks Down
In implementation-first environments, alignment happens around what exists. The team agrees on the current shape of the system. But that shape may not be correct. Alignment reinforces the existing structure even when it should change.
In architecture-first environments, alignment happens around intent. The team agrees on what the system should be. That creates a reference point that implementation follows rather than invents.
One creates consistency. The other creates correctness.
The Cost of a Wrong Model
A wrong model does not stop progress. It redirects it.
The system grows in a direction that feels coherent but becomes harder to maintain. The cost accumulates as complexity increases, changes slow down, integrations become fragile, and ownership becomes unclear. At that point the team is not just fixing code. They are correcting the model.
That is significantly more expensive than defining it correctly at the start.
Why This Matters More Now
With AI, this distinction becomes more important.
AI can generate code quickly. It can implement patterns, wire services, and fill in structure. But it does not understand the model. It will execute whatever assumptions it is given.
If the model is wrong, AI will help you build the wrong system faster. Alignment will not save you. It will only make the outcome more consistent.
The Correct Focus
The goal is not alignment. The goal is alignment around a correct model.
That requires clear boundaries, explicit ownership, intentional flow of information, and an understanding of failure modes. These are design decisions. They do not emerge reliably from implementation. They have to be defined.
What Defining the Model Looks Like
Before implementation begins, three questions need answers.
What is the system responsible for, and what is explicitly outside its scope. This is the boundary question. Most teams skip it because it feels abstract. It becomes concrete the first time a feature request lands in an ambiguous zone and nobody knows who owns it.
Who owns each piece of state, and what are the rules for changing it. Shared ownership is not ownership. When two services can both modify the same data, neither is accountable for its correctness. Ownership has to be assigned, not assumed.
How does the system behave when something goes wrong. Not as an edge case, but as an expected condition. The failure model shapes the implementation more than the happy path does. Teams that define it early build systems that are easier to operate. Teams that discover it later build systems that require intervention to keep running.
These are not architecture diagrams. They are decisions. The difference is that decisions can be wrong, which means they can be corrected. Undocumented assumptions cannot be corrected because they cannot be found.
The Bottom Line
Teams do not break down only because they disagree. They also break down when they agree on the wrong abstraction.
Alignment is necessary. It is not sufficient.
The model has to be right.
Continue reading
Papers