It starts with a one-degree deviation.
A standup becomes a status report. A retro surfaces the same theme for the third quarter running. A weekly sync gets added because teams aren’t aligned, and six months later, a second sync gets added because the first one stopped working. Nobody asks why. They just add another meeting.
The routine creeps in. Not because anyone chose it. Because nobody noticed the moment when the process stopped serving the work and the work started serving the process. The scaffold became the building.
Every team I’ve worked with could show me what they shipped last quarter. Burndown charts, velocity numbers, sprint reports: artifacts that look like measurement. Almost none could tell me why it mattered to a customer. PMI reports organizations waste $109 million for every $1 billion spent on projects (2014). Only 46% of employees feel clear about what’s expected at work, down from 56% in 2020. The numbers said on track. The direction was missing.
This is what I call proxy collapse: when the measurement replaces the thing it was supposed to measure. Velocity becomes the goal instead of customer value. Green status becomes the goal instead of actual progress. “We communicated” becomes the goal instead of shared understanding.
The team isn’t failing. It’s optimizing (precisely, rationally, intelligently) for the wrong thing. The process provides sensing without actuation. You can see the problem. You can route it to the right inbox. But nobody corrects course without scheduling a meeting first, and by then the deviation has compounded.
Most of what organizations call “control” is actually visibility. And visibility without the ability to correct is the illusion of control.
The Guidance System
In aerospace, a guidance system does three things: it senses where the vehicle is, it interprets what that position means relative to the mission, and it corrects before the deviation compounds. The best guidance systems are the ones you don’t notice. They correct continuously, invisibly. The moment you need manual intervention, the moment you need a meeting to check alignment, the system has already partially failed.
Wait. You have just been pooh-poohing Agile practices, with their story points and metrics dashboards. And now you’re reaching for rocket science? The field where every bolt is counted and measured?
Sharp observation. But the aerospace metaphor isn’t about vanity metrics, it’s about timing and embedding. Rockets don’t wait until they miss the orbit to check that they’re on course. They’re constantly sensing, interpreting the gap, and adjusting before errors compound. We don’t need more meetings to check how things are going. We need continuous sensing embedded in the work itself.
Software teams need the same three capacities. Not processes. Not ceremonies. Capacities:
Shared Interpretation. Not communication. The capacity for people to construct the same meaning from the same information.
Living Context. Not documentation. The capacity for an organization to know what it knows, and to know what that knowledge means right now.
Collective Judgment. Not culture. The capacity to make the right call without deliberating, because the team has made enough decisions together that their mental models overlap.
The first two are scaffolding for the third.
Shared Interpretation
You held the all-hands. You sent the strategy email. You posted the decision in Slack. You did the thing everyone calls “communication.”
Three weeks later, Team B is building against an assumption that Team A invalidated in week one.
The reflex: “We need to communicate better.” Nobody asks what “better” means because everyone assumes they already know: more updates, more channels, more frequency.
But the problem isn’t that the message wasn’t sent. It was sent. The problem is that meaning isn’t in the message. It’s constructed by each person who reads it.
When the VP writes “we’re pivoting to enterprise,” the engineering director reads “my roadmap is about to change.” The IC reads “my project might get cut.” The PM reads “I need to adjust priorities immediately.” The new hire reads “I don’t know what any of this means yet.”
Same text. Five constructions. Not because the VP wrote badly, but because each reader interprets through their own context: their fears, their incentives, their experience with previous “pivots.”
No amount of clearer writing fixes this. The ambiguity doesn’t live in the words. It lives in the gap between each person’s framework.
More communication can make it worse. Sharing partially formed information at the wrong moment can lock a team into a worse understanding than they’d have reached on their own. Research on high-performing navigation teams found that strict protocols (specific timing, standardized formats, selective sharing) outperformed open information flow.
On the best teams I’ve worked with, people filled in the gaps correctly. They knew what the VP meant even when the email was vague. Why? Because they had enough shared experience to construct similar meanings. They’d made enough decisions together that their frameworks overlapped. They’d become fluent readers of each other’s shorthand.
The test: Not “did we send the information?” but “did the person who received it understand what we meant, including what we didn’t say?”
- Was the information that could have prevented the last cross-team surprise documented somewhere? (It usually was. That’s not a context problem. It’s a routing problem.)
- How many degrees of separation exist between the decision-maker and the person affected? Each degree is a point where the signal can drop.
- Does your status report get read by the three people who most need it? Have you verified this, or are you assuming?
- When a team changes an API contract, who finds out? Is there a mechanism, or does it depend on someone remembering to mention it?
- If you removed one person from the organization, would information flow between two teams break?
- Ask any team member to present the vision for the project and how their work fits the big picture. If they can’t, the signal was broadcast but never routed.
Living Context
Your team documented everything. The wiki is thorough. The ADRs are up to date. The onboarding guide exists.
Six months later, a new engineer joins. They read the wiki. They study the ADRs. They go through the onboarding guide. And then they make a decision that anyone with three months on the team would have known was wrong.
Not because the information wasn’t there. But because the knowledge they needed wasn’t the kind that lives in documents.
There’s formal knowledge: documented, transferable, searchable. And there’s practical wisdom, the instinct that fires when someone proposes an architecture the team tried and abandoned eighteen months ago. Not a written record. A reflex. You can only develop it by inhabiting the practice.
When workers follow only the official procedures (only what’s written down) production grinds to a halt. The formal system functions only because people constantly improvise around it. Documentation is formal knowledge. What makes a team effective is practical wisdom. Build a documentation system and you’re building the formal part, hoping it produces the practical part. More often, it produces the illusion of shared understanding. Everyone read the same wiki, everyone passed the onboarding quiz, nobody developed the judgment the documents were supposed to transfer.
Velocity is the same proxy collapse: a number that’s comparable whether the sprint was greenfield features or untangling three-year-old tech debt. The number is comparable. The meaning is completely different.
Documentation works when it’s infrastructure maintained by people who already have the judgment to know what matters. DORA’s research confirms this: documentation quality is the single largest factor in their AI impact prediction model.
The test: Not “is the documentation complete?” but “does what exists accelerate judgment for someone new?”
- Pick a non-trivial decision from the last quarter. Can you find why it was made, not just what was decided, but what alternatives were rejected and what constraints drove the choice?
- Can a new hire find this in under 10 minutes without asking someone?
- When was the last time a document was deleted because it was stale? If the answer is never, your context system is accumulating debt, not building infrastructure.
- Ask two engineers independently: “What does [your most ambiguous domain term] mean?” Do the definitions match?
- When did you last discover during integration that another team had made a decision you didn’t know about? How long ago was that decision made?
Collective Judgment
You run standups. You hold retros. You do team-building offsites. You have a “culture” section in the company handbook. You did the thing everyone calls “building culture.”
The standup: everyone reports their status. Nobody reacts to what anyone else says. Each person presents an acceptable version of reality while the real problems live in DMs, hallway conversations, and private complaints. The retro: someone writes “communication” as an improvement area. Everyone nods. An action item gets assigned. Nothing changes. Next quarter, someone writes “communication” again.
The mechanism is simple: speaking up is effortful, benefits the organization after delay with low certainty. Staying silent is instinctive, benefits you immediately with high certainty. Eighty-five percent of people reported at least one occasion when they felt unable to raise a concern. “No one was ever fired for silence.” The absence of disagreement is mistaken for agreement.
Organizations develop what amount to immune systems against honest inquiry. Policies and practices that protect people from embarrassment, but prevent the organization from learning. Everyone knows the retro doesn’t surface real issues. Discussing that fact is the real issue. And discussing that it’s undiscussable is doubly taboo.
The most insidious version: the weekly sync that gets added to fix the problem that the first weekly sync was supposed to fix. Nobody asks why the first one stopped working. The scaffold became the building.
On the best teams I’ve worked with, people took the right initiative without being asked. They predicted each other’s reactions. They made judgment calls that turned out to be what the team needed. What those teams had wasn’t “good culture” in the handbook sense. It was recognition trained through experience: expert decision-makers don’t compare options, they recognize the situation pattern and act. The team literally thinks in ways no individual can: memory, error detection, course correction emerge from interactions between people, not from any single person’s ability.
“Reliability is a dynamic non-event. When systems operate reliably, nothing appears to be happening, but in reality there is constant mutual adjustment.” That’s actual control. Not the standup. Not the dashboard. Invisible, continuous adaptation by people who trust each other’s judgment. And in those environments, authority migrates to whoever has the most relevant knowledge, regardless of hierarchy.
The diagnostic: Can team members predict each other’s reactions? If yes, you have collective judgment. If no, you have smart individuals who share a Slack workspace. No ceremony will fix that.
- Can anyone on the team say “Maria would push back on this API design”? If nobody can anticipate anyone else’s objections, you have individuals, not a team.
- Are code review iterations declining over time? When shared judgment develops, people write code that passes review faster, not because standards drop, but because they’ve internalized each other’s expectations.
- When someone says “this feels off,” can they articulate what specifically feels off? The ability to name the pattern is calibration.
- How do you handle disagreement? If people say yes in the meeting and complain in DMs, you have compliance, not culture. If disagreement is visible and productive, culture is working.
- How many of the team members who were here a year ago are still here? If less than half, your culture is perpetually restarting.
If your team is aligned on paper but keeps surprising each other in practice, the formal system is working but the tacit system isn’t. No process fixes this. Only shared decisions over time.
Why This Matters Now
AI is making building cheap. A developer with a coding assistant can generate a well-architected service in an afternoon. But “well-architected” and “strategically right” are different questions. The code can be locally correct (passes its tests, follows patterns, implements the spec) and globally misaligned. It solves a problem nobody has. It contradicts a decision another team made yesterday.
This is proxy collapse applied to code. The AI optimizes for what it’s given: the spec, the tests, the context. If the specification is wrong, the AI produces perfectly aligned output to the wrong objective. And better models make this worse, not better, because the output looks more convincing.
The numbers confirm the structural problem. DORA’s 2024 report found that AI adoption decreased delivery stability by 7.2% and throughput by 1.5%, for the second year running. Code review time increased 91% (DORA 2025). A randomized controlled trial found that developers predicted AI would make them 24% faster. The actual measurement: 19% slower. The perception of acceleration masks actual drift.
Three structural patterns persist regardless of how capable AI becomes:
The specification gap. No matter how capable the AI, it optimizes for what it’s told. The gap between what humans can formally express and what they actually mean doesn’t shrink with better technology.
The supervision asymmetry. Reviewing AI output requires more expertise than producing it. A junior developer can generate a service. Evaluating whether that service should exist requires senior judgment.
Local correct, global misaligned. Each developer-with-agent produces correct output within their scope. Collectively, the outputs can be incoherent. This gets worse with speed.
The role of the person who ensures alignment (who senses, interprets, and corrects) doesn’t get automated. It becomes the scarce resource. When production is fast and cheap, judgment about whether the right thing is being built is what matters.
Someone must be accountable for alignment. Not the person who makes every decision, but the person who ensures the right information reaches the right people before decisions are made. Not someone whose authority depends on being the bottleneck, but someone whose credibility is earned by consistently driving clarity.
A metric can’t tell you it’s being gamed. A process can’t tell you it’s become theater. A dashboard can’t tell you the numbers are right but the direction is wrong. Only a person with judgment, someone who understands the intent, not just the measurement, can sense when the proxy has diverged from the thing it represents.
If you recognized any of these patterns, that’s where the conversation starts.