Pull up your IT org chart and read the box names. If you are like most shops, they name technologies. Network. Storage. Database. End-user computing. Security. Maybe a cloud team, maybe a data team. Each box is a tower, each tower is a specialty, and each specialty has a leader, a budget, and an SLA it defends.
Now trace one thing the business actually asked for across that chart — onboard one more institution, ship one more decisioning feature. It does not live in a box. It crosses them. It starts as a request to one tower, becomes a ticket to the next, waits in a queue, gets handed to a third, and somewhere in the crossing the context leaks and the clock runs. The chart optimized every tower. Nobody on it owns the thing the customer was waiting for.
That is the quiet defect in most IT operating models. The chart is a map of specialties, not a map of how value reaches a customer. It answers "who reports to whom." The business was asking "how does work get to me." Those are different questions, and the second one is the one that pays the bills.
I want to make the case for redrawing the function around that second question — around business capabilities and the value streams that deliver them, not around the technology towers we happen to staff. And I want to be honest about where I am standing when I say it. I do not own the whole IT org chart. I own one function, security and DevOps, that I built on purpose against the tower grain, and I report its return to a board. That is one data point, not a mandate. But it is a data point I ran deliberately, and it taught me the mechanism.
Towers optimize the layer, not the outcome
Towers are not stupid. They exist for real reasons — specialization, vendor management, a control surface an auditor can find, a career ladder a network engineer can climb. Organizing by discipline was rational when the discipline was the scarce thing. The trouble is what the structure does to the work that has to cross it.
Melvin Conway named this in 1968, and it has aged into a law because it keeps being true: a system's structure ends up mirroring the communication structure of the organization that built it. Staff by tower and you get an architecture stitched together at tower seams, with a handoff living at every seam. The handoff is where the latency hides. Lean people have a tool for seeing it — value stream mapping — and the first thing it shows every time is that the wait between steps dwarfs the work inside them. Your request is not slow because any tower is slow. It is slow because it spent most of its life in a queue at a boundary, waiting for the next specialty to pick it up.
Each tower is measured on its own SLA, and it can hit that SLA all day while the end-to-end capability crawls, because the thing that is slow — the crossing — is nobody's number. A tower is a fine unit for attributing a cost. It is a terrible unit for organizing a team, because the value the customer bought never lived inside one.
I already ran this experiment at n=2
I have written before about putting security and DevOps under one roof and refusing to apologize for it. The org-chart version of that argument is simpler than the culture version. When security and delivery sit in separate towers, the space between "the people who ship" and "the people who protect" is a handoff, and a handoff is a queue. Collapse the two into one function and the queue does not get shorter. It disappears. What used to be a ticket crossing a boundary becomes a tradeoff managed inside one team.
The result was not looser control. It was the opposite — control designed into the pipeline instead of inspected at a gate the work had to stop and pass through. That is the whole move, run at the smallest scale where it is interesting: n=2. Take two towers, remove the boundary, and the cost that lived at the boundary goes with it.
This essay is that move reasoned up a level. If collapsing one boundary bought that much flow, what happens if the collapse is the design principle rather than the exception? I am not going to pretend a two-tower merge proves an enterprise reorg — two is not forty, and the second-order effects at forty are real. But the mechanism does not care about the count. Every boundary you draw is a queue you are choosing to own. The question a CIO is actually answering when they draw the chart is which boundaries are worth the queue.
Organize around capabilities, not technologies
If the tower is the wrong spine, what is the right one? The most stable structure a business has is its list of capabilities — the things it does, stated as verbs. Onboard an institution. Decision a request. Serve an account. Close the books. Business architects call this a capability model, and its virtue is durability. Processes change constantly, org units churn with every reorg, but the set of things a company fundamentally does barely moves in a decade. Build the chart on the capabilities and you are building on the one layer that holds still.
The team shape that follows is what Team Topologies, from Matthew Skelton and Manuel Pais, calls a stream-aligned team: a team that owns a slice of value end to end, from a change to production, for a single capability. The value chain becomes the org chart. And because Conway's law runs in both directions, you can use it on purpose — the inverse Conway maneuver, deliberately shaping the teams to grow the architecture you want, instead of letting an accidental org shape you an accidental system.
The tell that you have it right is the set of questions the structure can suddenly answer:
- What is the end-to-end lead time for this capability? A stream-aligned team can tell you. A collection of towers can only report their individual pieces and shrug at the seams.
- Who owns the outcome when it breaks? A name, not a routing table that hands the incident from tower to tower until it lands on whoever is least able to refuse it.
- What does it cost to serve one more unit of this? The capability is the unit the rest of the business already prices its work in, and now IT can answer in the same currency.
The platform is the shared spine, not another tower
There is an obvious way to get this wrong, and it is worth naming because it is the failure mode that scares every infrastructure leader out of trying. Reorganize into value streams naively and each stream rebuilds its own plumbing — its own pipelines, its own identity glue, its own logging. You trade a handoff problem for a duplication problem, and forty private stacks is not progress.
The answer is a thin platform beneath the streams: identity, logging, pipelines, the paved road, consumed as self-service rather than requested as a ticket. That last clause is the entire difference between a platform and a tower. A tower hands you a ticket and a wait. A platform hands you a capability and gets out of the way. If your platform team behaves like a tower — gates, queues, mandates — you have not built a platform. You have renamed the silo.
This is the shape we built AgentOS into. It is a governed internal agent platform, which means the control plane — identity, the action boundary, per-agent logging — sits beneath the teams. A stream that wants to ship a safe agent pulls the guardrails off the platform instead of standing up its own, so the governance travels with the platform and the capability travels with the stream. The streams stay fast because they are not each reinventing the plumbing, and the plumbing stays consistent because it lives in one place that everyone consumes and nobody has to petition.
What you keep, and what the examiner still wants
None of this dissolves deep expertise; it changes the shape expertise takes. Team Topologies is honest about this — alongside the stream-aligned teams it keeps two other shapes. Enabling teams, which coach the streams and then leave. Complicated-subsystem teams, which own the genuinely hard specialty that no single stream should have to carry. The database expert and the network engineer do not vanish in this model. They stop being a tower everyone has to visit and become expertise the streams can pull in when they need it.
Some things also stay centralized on purpose, because they are genuinely cross-cutting and, in my world, non-negotiable. The identity model, encryption, the control plane, the examiner-facing evidence — those are the high curbs, and streams do not defect from them. Serving more than 1,500 financial institutions means an examiner will still ask, in plain language, who owns a given control. "The value stream" is not an acceptable answer if it turns out to mean no one. So the move is not to abolish ownership of controls. It is to make the control travel embedded with the stream instead of sitting in a tower the stream has to stop and cross — a named owner inside the flow, not a checkpoint at its edge.
And I will not oversell it, because Conway's law cuts both ways. A value-stream reorg done badly just relabels the towers, adds a coordination tax, and calls the disruption transformation. If you draw the streams around the current org chart instead of around the actual path value takes to a customer, you will get all the churn and none of the flow. The map you draw first is the whole ballgame. Draw it wrong and the new boxes are the old boxes with better branding.
Draw the value chain first
If you own the chart, or you are reasoning toward the seat that does, a few moves carry most of the weight. Draw the value chain before you draw the boxes — map how a real request reaches a real customer, count the handoffs, and put a team on the flow instead of on the layer. Collapse the boundary where the handoff hurts most, and treat security and delivery under one roof as the template rather than the exception. Back the streams with a thin platform, not another tower, so the shared spine is self-service and never a ticket. Keep the high curbs centralized and the specialties on tap, and make every control travel with a named owner inside the stream.
I have run this at n=2 and I am reasoning openly toward the seat that owns the whole chart. If you have run a value-stream reorg at real scale — or watched one quietly relabel the towers and ship a slide about it — I want to hear which one you got. Tell me in the comments where the model held and where it broke, and whether the examiner in your world ever accepted "the stream owns it" as an answer.
