Where the system begins.
In 1943, with the House of Commons still in ruins from the Blitz, Winston Churchill argued against rebuilding it any larger. The chamber had never been big enough to seat every member; its benches sat close and face-to-face, government and opposition a sword’s length apart. That, he said, was exactly why it worked. Widen the room and scatter the seats, and you would change the way the country argued with itself. We shape our buildings, he told them, and afterwards our buildings shape us.
He was talking about a room. But the same holds for a team, and for an organization. The shape of a room decides how people deliberate; the shape of a team decides how decisions travel; the shape of an organization decides what it can build. We set the structure; the structure sets us.
The arranging itself — the org chart, the decision rights, the team boundaries — usually gets treated as administration: scaffolding around the real work, not the work itself. That belief has not survived the evidence. A decade of DORA research — one of the largest studies of software delivery ever run — has been steadily taking it apart. The teams that perform best are not merely better at execution; they operate inside structures where ownership is clear, boundaries are intentional, and authority sits close enough to the work to matter. Throughput and stability, the things we were sure were purely technical, turn out to depend on the shape of the room.
The most consequential architecture an engineering leader designs is never in the codebase. Like Churchill’s chamber, it shapes everything built within it — often before anyone thinks to question how the room was built.
The room behind the code
Earlier in my career, I worked at close range on a platform being pulled out of its monolith and rebuilt as microservices, one module at a time. A migration like that is never the clean break the slides promise; it is an excavation. Dig into a freshly built service and you keep finding the old system inside it — an endpoint still returning a boolean and a list, the relic of two controls on a web page that had never been told they were now one; a database table that had never learned to forget, still adding strata release after release. The strange part is that the fossils from the monolith era were still load-bearing. We weren’t studying the old civilization — we were living by its traditions.
I understand how this happens, mechanically. A migration doesn’t dissolve the weight of the past; it relocates it — forward, into the new system’s contracts and schemas — because that is the least contested place to set it down. Friction moves, gets redistributed, but never fully disappears. Yet that logic only accounts for the universal case — every migration drags a little of the old system along. It doesn’t explain why the new system drew its lines in recognizably the same way. For that you have to look somewhere the diagram doesn’t reach.
New ownership arrived — product and business leadership, capable and clear about what needed to be built. The technical room was largely the same. What emerged from the migration was real: a genuine constellation of microservices, built by people who worked hard to get there. And threaded through it, wherever the same judgment still held, the familiar architecture of the system it was meant to replace. Architecture doesn’t follow who owns the product. It follows who decides how to build it.
This is what took me too long to put into words: a codebase is a cast of the judgment that made it. Not the effort, not the intention — the judgment. What an organization is willing to risk, what it refuses to reopen, whose hesitation is enough to change course. Migrate the technology and leave the judgment untouched, and you will faithfully rebuild what you already had — only now it builds faster, ships in smaller pieces, and fails more gracefully. Every system runs on two architectures: the one in the repository, and the one in the room that preceded it.
So the deepest way to change an architecture is to change that room first — decision rights, risk appetite, and intellectual closure — and let the system redraw itself. Doing it deliberately has a name: the inverse Conway maneuver. It is rarely the first move — not because it is hard to explain, but because it asks a leader to accept something both humbling and freeing: that the most powerful architectural tool on the table was never a technical one. It is who you put in the room, and how you let them build.
Before it was anyone’s job
The announcement that we were moving to a new delivery model arrived without a schedule — a direction confirmed, a destination named, no date attached. There was a gap between that signal and the distance it implied. I needed answers about what the change would actually take. I didn’t want to lose that time.
I put the harder questions to the team: what this new delivery model would really demand of the deployment workflow, the versioning and branching strategy, the test surface. Working through them early, before anyone had been told to, meant answers were already in the room — the thinking well underway before the frame had set.
That space — between relaying a change and building the conditions for one — is where most of the work actually lives, and it is wider than it looks. You can mandate compliance; you cannot mandate ownership. Learning, judgment, the willingness to pick up a problem that isn’t yet yours — none of it answers to instruction. It answers to conditions — and those are built quietly, ahead of the order.
The most useful question I know is not the one the role trains you toward. The natural instinct is to ask what should the team be doing, as though effort were the scarce input. It rarely is. The sharper question runs the other way — what am I preventing them from doing? The approval they wait on, the context missing from the handoff, the decision they are asked to carry without seeing how it fits. More often than I’d like to admit, the highest-leverage move I had was not to add a plan, but to change what stood between the team and the work.
None of this is a matter of personality. Leadership can take many forms, but one distinction has mattered more than most: some leaders guard the standard; others change the conditions under which it becomes reachable. The labels are familiar — transactional and transformational — but the experience is older than the vocabulary. Most of us have worked for both, and know, without much reflection, which one made our best work possible. That leadership does not show up in a commit. It shows up in what the team can still do on the morning no one is there to tell them.
What echoes further than trust
If architecture is leadership written into the structure, culture is leadership written into the air between people — harder to point at, and unmistakable the moment you walk into it.
There is a way to read an organization that is worth more than any values statement. Watch what happens the moment someone close to the work sees something is wrong. Sometimes the problem travels — quickly, intact, to someone who can act on it. Other times it gets heard, acknowledged, and goes no further — not out of indifference, but because people have learned what it cost. Both are cultural facts, and the distance between them is most of what separates one engineering organization from another.
Ron Westrum had been studying exactly that distance — not in software, but in places where catching a problem in time was everything: hospitals, flight decks — and found that the strongest predictor of whether failures surfaced before they compounded was neither talent nor process, but whether people could carry bad news upward without it costing them. He called the healthy kind generative, and the DORA research has since put numbers to it: where information moves freely, teams perform better and burn out less. It is not only the more humane arrangement; it is the more effective one. How far bad news travels is not a property of the work. It is a property of the room.
I have seen it travel, and I have seen it stop — sometimes in the same place. I have watched trust compound: I gave engineers latitude to own their work and raise concerns directly, and each time it held, they went a little further — until a little more openness became ordinary. And I have watched it stall. A manager asked for feedback on a change still ahead of the team. An engineer answered carefully — concerns about the execution, not the decision itself. The response made clear how little the concern could shape what followed. Afterward, the engineer told the team they had felt disregarded.
The engineer had not simply been overruled. They had been invited to contribute without fully understanding the boundaries of that invitation. The dynamic was not necessarily careless or malicious. Leadership often has to choose despite disagreement. But when the line between consultation and decision remains unclear, even sincerely requested input can leave people uncertain about what their candor was meant to influence.
A team reads more than the exchange in front of it. It reads how decisions are framed, which parts remain open to influence, and what happens when someone speaks plainly. Trust can be strong between individuals and still be bounded by the architecture around them. People calibrate to that architecture: to what leaders leave open, what they close, and what the systems they shape allow candor to change.
Which is the uncomfortable and clarifying part: culture does not move because the values were rewritten or the poster reframed. It moves when the incentives move, and incentives are not democratic — the higher up they are set, the more of the organization inherits them. A manager can decide to reward candor on their own team. Whether that decision survives contact with the rest of the company is not theirs to decide; it is written at a level above them, by people who may never meet the person who spoke up. That is why the shift is slow and largely invisible, and why it is precisely the work: it has to be won again at every level, not just declared at one. Culture is not something a team has. It is something leadership builds, or fails to.
It comes due either way
Seeing the architecture is one skill. Choosing it is another. That is where judgment takes over from cleverness, because there is no clean structure waiting to be found — only structures that decide where the friction will live. Centralize, and you purchase coherence at the cost of responsiveness. Distribute, and you purchase speed at the cost of consistency. Every arrangement carries an invoice. The question is not whether the cost exists, but whether leadership has the discipline to name it before the organization pays it in hidden places. As Will Larson has argued, organizational design does not remove friction so much as relocate it. Judgment begins when the tradeoff is stated without pretending it is free.
Architecture is never one conversation. It is four at once, pulling against each other — what is elegant, what the business needs, what the team in front of you can sustain, and what will still be true on the morning the system breaks. The elegant answer is often the undeliverable one; the fastest answer reliably mortgages the risk. Most bad architecture isn’t a failure of intelligence. It’s someone optimizing the conversation they understand best to the floor while the other three quietly mail the invoice.
The hardest cost to price is the one attached to a person: someone on the team is not carrying the work, and no one will say so. Pressure runs toward silence — naming it is disruptive; silence passes for discretion. So the honest read gets deferred, gently, until patience becomes the story the organization tells itself about avoidance. But the cost does not wait while we do. The team pays it in momentum and in work that quietly comes out worse; the company pays it in the months it takes to admit what everyone had been working around; and the person pays most of all, because what they were owed was an honest signal early, while it could still change something — not a verdict at the end, when it can change nothing.
That is the part sentiment gets backwards: the silence that feels like care is the crueler thing, only postponed. Across teams and years, I have given people a real chance — the kind a person could pass, not staged to fail — and watched the cost mount when the chance changed nothing and no one would name it, though the person, more often than not, already knew. The decision was never mine alone, but it turned on the read I made, and I learned not to soften it to make the moment easier. The pressure was always to price what it costs to act. The judgment lay in pricing what the waiting had already cost.
The same discipline surfaces somewhere far quieter: in how a team is allowed to spend its weeks. There is a constant, reasonable pressure to turn every available hour into new features — features are what lands on a roadmap, and the easiest thing to ask for. But a team that never repairs what it has built loses, slowly, the ability to build anything quickly; the debt compounds until the speed everyone was protecting finally gives way beneath it. I kept a steady share of every release for repair, and — harder still — defended that share out loud. Not by pleading for it, but by making the compounding visible: showing the people waiting on features that the work we were protecting this quarter was the very thing that would let us move faster the next. You do not get to make that tension disappear. You only get to decide, deliberately, how much of it to settle now so that it does not all come due at once, later. Judgment is not the choosing. It is the honesty to name what a choice will cost.
One argument, three doorways
I realize now that I have been circling a single idea for years without naming it. I first wrote the idea as an equation — a way to make a team’s velocity legible, with trust, clarity, and autonomy carrying the numerator, and friction, ego, and burnout dragging beneath. Momentum, I was arguing, is not motion. It is a relationship between forces, most of them invisible.
I wrote it again as craft: that integrity is not a value a team declares, but an architecture it builds into the work — into the specification, into the room, into the moment before the decision sets. And I wrote it a third time as culture: the architecture an organization encodes whether it means to or not — prone to drift by accumulation, but capable of coherence by design.
Three subjects, apparently. One argument, seen through three doorways.
Momentum, craft, and culture all depend on the same hidden structure: the human system beneath the technical one. It decides whether effort becomes movement or drag, whether standards become habits or slogans, whether truth travels far enough to matter. Three times I had walked through a different door, certain each opened on a new room — when it had been one room all along. I had named everything it did, and never what it was. It is not only technical. It is judgment made structural — the most consequential work leadership does, in a material that never appears in a commit.
The present moment does not change that argument; it makes the stakes clearer. AI does not repair that structure. It amplifies it. Where judgment is distributed and truth moves freely, it compounds that strength. Where judgment remains concentrated and information stalls, it can scale dysfunction and let the result pass for productivity: shipping what no one weighed — fast, and looking finished. The amplifier was never the signal. The architecture is — and the architecture, still, is something a person decides.
So when I am asked now about the most consequential thing I have built, I no longer reach for something I can show you. The architecture I am most sure of left no diagram behind. It was who got to speak, and who was trusted to act without first asking. It was which decisions were made in daylight, and which ones were quietly kept. It was what I took off people’s plates so they could carry what mattered — and what became possible because I refused to stand in front of it.
We draw those lines early, usually before we know we are drawing anything at all: a reporting line here, a withheld decision there, a problem we let travel or let die. And then, exactly as Churchill warned the Commons, the room turns and, in its turn, shapes the people inside it.
The people who come through our rooms carry a grain of it onward — into what they dare, and make, and become, in rooms we may never see.
The architecture outlasts the architect.