Robust Theme
Dec 09, 2019 2020-04-08 7:40Robust Theme
The Seam Is the Bottleneck: Why the Coordination Layer Survives the Reorg
By: Kumar Dattatreyan
Every reorg makes the same promise. Break the big thing into small things and watch it move. The small things do move. The company does not. You drew new lines to create focus, and now every piece of work has to cross more of them than it did before. A line on an org chart is a seam in the delivery. A seam nobody owns is where the work stops. You didn't remove the bottleneck. You relocated it to the space between the boxes, the one place your reorg deck never showed.
The promise is real and it's incomplete
Smaller units, clearer ownership, faster decisions. The first part of that pitch holds up. A team of eight that owns its own outcome will outrun a department of eighty, and I've never seen it go the other way. The deck is right about that, and the deck is usually beautiful, and the arrows all point right.
The trouble starts with the work that doesn't sit inside any one unit, which is most valuable work. It starts in one box, needs something from a second and finishes in a third. Every transition is a seam. Before the reorg you had a handful of them buried inside a slow structure, so nobody counted them. Now you have many and they're load-bearing.
Nawaz Butt made the de-scaling case on Episode 175, and he's right about what all that structure costs. He traced it back to Conway's law and to what happens as organizations grow: they add layers, and layers mean hierarchies, approvals and handoffs. His words for the result: "this whole coordination effort becomes a huge undertaking." His prescription follows from the diagnosis. As he put it, "the aim has to be not to have more teams but to have less number of teams in the organization."
I agree with the direction and I'd go further with it. Fewer units, more autonomy, decisions pushed to where the work happens. That's a real cut in the coordination tax.
Cutting a tax isn't the same as removing the work. The remaining seams still have to be crossed, and the fewer of them there are, the more each one carries. You didn't delete the coordination. You concentrated it, then took the coordinators off the payroll and called it a saving.
The objection I'd raise if I were reading this
The sharpest pushback comes from the Team Topologies school, and it's worth stating in the terms its own believers use.
Their argument: if you need a coordinator to make your split work, you drew the split wrong. Stream-aligned teams own a slice of value end to end. Platform teams expose self-service capability so nobody files a request and waits. Interaction modes get defined up front. Design the coordination out instead of staffing it, because a coordination role institutionalizes the dependency you should have deleted.
That critique is right about the failure mode, and I've seen enough of it to take it seriously. A coordinator with no decision rights becomes a status reporter. They collect updates, publish a RAG chart and add a wait state to the thing they were hired to speed up. The chart is always amber, because amber is the color of nobody's fault. If that's what giving the seam an owner means, don't do it.
Here's where I go the other way. Designing coordination down is not the same as designing it away, and the people who wrote that playbook know it. Their own guidance describes managed dependencies rather than total autonomy, and it treats the platform as a product with a team accountable for the experience of using it. That's an owned interface. The disagreement isn't about whether the seam needs an owner. It's about what the owner is called and where they sit.
Conway's law cuts the same way. If your communication structure shapes your system, then the split you just performed has already written the seams into the architecture. You can move them and you can reduce their number. You can't wish them out of existence, and pretending otherwise is how they end up unowned.
There's a real risk buried in that objection. Route every crossing through one person and every crossing queues at one desk, and once that desk is past about eighty percent booked, wait times don't rise gently, they go vertical. Congratulations, you've built a roundabout with a toll booth.
The fix isn't to leave the seam unowned. It's to keep the owner out of the transaction. Their job is to make the crossing work when they're on vacation, by fixing the interface, retiring the gate and settling the standing argument once instead of every sprint.
What actually sits in the seam
Three things collect there, and none of them show up on the new org chart.
The handoff. Liam O'Neill has spent his career inside business process work, which is the part of the org most people walk past on the way to the interesting problems. On Episode 140 he identified the place momentum dies: "These team handover points, things get lost. Things fall down and things slow down." His example was specific. A change program with a clear target got to the transition point and stalled, because, in his words, "the handover to the PMO team slowed everything down." Different expectations on both sides of one line, and nobody who owned the line.
The sediment. In a conversation on SAFe's revised Principle Six, Chris Daily put the legacy policy problem at the front of the flow work. His description of what greets you when you stand up a new structure: "we still have all this crap that hangs around from the way we did things for the last 150 years and a lot of it doesn't apply." Policy outlives the structure that produced it. Redraw the boxes and the old approval gate stays exactly where it was, now governing a flow it was never written to serve. Nobody remembers why it exists. The person who wrote it took early retirement and the gate got tenure.
The delay. Chris also pinpointed the compounding cost, and it's the one leaders underestimate: "you've got eight or nine teams team one may not get any feedback from production for six months to a year." A team can be fast, engaged and completely wrong for two quarters, because the signal has to cross every seam on the way back. The news arrives at the retro, where somebody writes it on a sticky note under "things we can't control."

Each of these lives between units, not inside them. Every unit passes its own health check while the flow across all of them degrades, which is why the reorg reads as a success internally and as a slowdown to the customer.
Giving the seam an owner without rebuilding the layer
Liam's fix wasn't a coordinator. It was authority attached to accountability: "You're holding people to account for how this process works. They need to approve the changes. They need to be empowered to make those." He was blunt about the alternative. Run every change through a head of function or a CXO and you've built the queue back.

That's the design constraint. The seam owner needs the right to change how the crossing works, or the role is theater with a calendar invite.
If you want a job description that already exists, look at the Release Train Engineer. Chris Daily wrote up the RTE skill set for us back in 2023, and the substance holds up with the framework vocabulary stripped out. The RTE isn't a manager of people. It's an assigned accountability for flow across teams, with standing to remove what's blocking it. Strip the framework vocabulary and you're left with the general answer: somebody owns the space between the boxes, and that somebody can act.
This is where I part company with the flattening instinct. I've argued before that removing layers won't save you, and this is the sharper version of that claim. The coordination layer is the one you can't cut, because cutting it doesn't remove the coordination. It just makes the coordination invisible and unassigned, which is worse than having it on the payroll, because now it's being done at 11pm by whoever cares most and has the least authority.
The distinction that matters: a layer sits above the work and grants permission. An owner sits across the work and clears the path. Same headcount, opposite effect on lead time.
The argument found me before I wrote it
Glenn Marshall said this to me on the show two years ago and I filed it under interesting rather than under important. We were working through the last of the XSCALE ecosystem thinking principles, which are built as parallels to the twelve principles of permaculture, and he was explaining why self-organizing teams don't finish the job:
"they're kind of the leafs of the of the organizational tree if you will what we need is the the nodes up from the teams to also embrace change and adapt and pivot"
Leaves adapt. That's the whole job of a leaf, and it's why team-level transformation always produces early wins that everybody can point at. The branch doesn't adapt. The nodes between the leaf and the trunk hold their shape through every season, and those nodes are exactly where work crosses from one part of the tree to another.
He was describing a seam. Neither of us had the word for it at the time, and I spent the two years since watching reorgs prove him right.

Three moves for the quarter after the reorg
Count the crossings. Trace your two or three highest-value flows across the new structure and mark every point where the work changes hands. This takes an afternoon and no software. If the number went up after the reorg, you bought focus and sold speed, and you want to know that now rather than in the board pack next February.
Give each crossing an owner and a mandate. Not a coordinator. Someone with the standing to change the interface, retire the approval gate that no longer applies and settle a dispute between two units without escalating. Write down what they can decide alone. If the list is empty, you've created a status reporter.
Measure wait, not utilization. Instrument the time work spends between units, not the time people spend busy inside them. Utilization inside a unit will look excellent while the flow across them dies. A dashboard of busy people is the most reassuring useless artifact in the building, and somebody is paying a license fee for it. Wait time at the seam is the only number that tells you whether the split paid off.
The same move works in a single room, which is where you can test it this week. Put two units in a meeting to resolve a crossing and the loudest function converges the group inside ten minutes, everyone nods, and the disagreement goes underground until it reappears as a missed handoff. Structure it so each side develops its position before anyone converges, and you get the real conflict while it's still cheap.
Related Podcast Episodes
Episode 175, Bloated Teams, Broken Delivery: The Case for De-Scaling, with Nawaz Butt. Nawaz makes the split-side argument better than anyone I've had on, and he grounds it in Conway's law rather than in framework preference. Listen to this one alongside this article and you'll hear where we agree and where I push further. He wants the coordination load smaller. I want what's left of it owned.
Episode 140, From Red Tape to Innovation Engine: Disrupting Business Process Management, with Liam O'Neill. Liam works with organizations that most people assume are drowning in process, and his diagnosis is about the handover, not the paperwork. His condition for fixing it, real delegated authority for whoever owns the process, is the mechanism behind everything in this piece.
Unlocking Flow: SAFe's Revised Principle Six, with Chris Daily (Agile Meridian YouTube, SAFe principles series). Chris and I recorded this after Scaled Agile rewrote Principle Six on us, and the conversation went straight past the diagram to what actually clogs a crossing. His observation about legacy policy outliving the structure it governed is the sediment I describe above, and his eight-or-nine-teams example is where the feedback delay comes from. Watch it for the flow accelerators we skipped as much as the two we chewed on.
Episode 86, Ecosystem Thinking for Innovation, with Glenn Marshall. The last episode of our run through the twelve ecosystem thinking principles, argued through soil, wolves and spiders rather than through frameworks. It's where the leaves-and-nodes line above comes from, and it holds up better than most of what I've recorded since.
Where to take this next
If you're a quarter or two into a split and the units feel faster while the customer doesn't, the seam is where to look. The Disruptor Method™ starts by finding where value actually stalls rather than where the org chart says it should flow, and the space between your new units is usually the first thing it surfaces.
Take the assessment at https://www.thedisruptormethod.com/quiz, or book a 30-minute conversation and bring one flow you've traced across the new structure: https://tidycal.com/coachkumar/30-minute-meeting
We'll count the crossings together.