Building on a framework from Ken Rubin. Link to his original at the bottom.
Every scaling class I teach gets to the same moment. Somebody raises a hand and asks how to handle dependencies across teams, and before I can answer, three other people jump in with their own version of the same pain. The platform team. The data team. The architecture review board. The one guy who owns the deployment pipeline and is on vacation until the 14th.
Then we talk about what they’ve built to cope with it. Dependency boards. A weekly cross-team sync. A RAID log somebody updates every Friday. A Scrum of Scrums where twelve people take turns naming blockers.
And I ask the question that usually changes the room: has any of that made the waiting shorter?
Usually, no. It made the waiting more visible. Those are not the same thing, and organizations confuse them constantly.
First, the number that gets people’s attention
Flow efficiency is the ratio of value-adding time to total elapsed time. When organizations actually measure it, they typically find 10% or less.
A feature that took fifteen weeks to deliver got about a week and a half of real work. The other thirteen and a half weeks, it sat blocked, waiting on someone else.
In my classes I get one of two reactions to that stat. Either people don’t believe it, or they go very quiet because they already suspected it.
So let’s do the arithmetic, because the number only becomes useful when you turn it into weeks.
Fifteen-week work item at 10% flow efficiency. That’s 1.5 weeks of value-add and 13.5 weeks of idle. Now go after the idle time and remove just 15% of it. Not the work. The waiting.
You get back a little over two weeks. The item ships in 13 weeks instead of 15.
Notice that flow efficiency itself only moved from 10% to about 11.6%, which sounds like nothing. Ignore that number and look at the other one. You just took 13.5% off your time to market, across the portfolio, and nobody worked faster, worked longer, or got asked to commit harder in quarterly planning.
Now the real question. Where is all that idle time coming from?
Dependencies. And here is where I think most organizations aim at the wrong target.
Two kinds of dependencies
Ken Rubin, who wrote Essential Scrum, draws a distinction here that I now use in every scaling conversation I have. I’m going to use his language because I haven’t found clearer.
A structural dependency is one baked into how you’ve organized. If UX design is always done by the UX team, and your team has to go to the UX team every single time it needs a design, that relationship is a permanent feature of the org chart. Nobody decides on it each time. It’s just there.
An instantiated dependency is one specific occurrence of that relationship. “We need a design for the new sign-up screen.” That’s one instance.
If you have a technical background, Ken’s analogy lands immediately. The structural dependency is the class. Each instantiated dependency is an object of that class.
Make fifty design requests over a year and you have one structural dependency and fifty instantiated ones.
Now go back to that list at the top of this post. The dependency board, the sync, the RAID log, the Scrum of Scrums. Every single one of those manages instantiated dependencies. You are processing instances, one at a time, forever, while the class that keeps generating them sits untouched.
Move UX skills onto the team and the structural dependency is gone. So are those fifty instances, plus every instance next year and the year after that.
As Ken puts it, “the easiest dependency to manage is the one you don’t have.”
That’s the leverage. One structural change eliminates an unbounded number of future waits. A better-run dependency board eliminates exactly zero of them.
Ken’s seven strategies
Ken has developed a structural dependency improvement framework across his work with large clients. Seven strategies in four categories. Here’s the short version.
Reducers cut the number of structural dependencies outright.
- Create feature teams. Move the missing skills onto the team. This is the one everybody reaches for first.
- Organize into coordinated ecosystems. Ken defines these as an encapsulated, cross-organizational set of aligned resources built around a durable product, value stream, business capability, or customer journey. One product owner, aligned resources, far fewer boundaries to cross.
- Architect for self-service. Your team publishes the mechanism, my team uses it without asking. Build-using instead of build-together.
Enablers make the reducers practically and politically possible.
- Cross-functional and T-shaped skills. A prerequisite for feature teams, and it makes a team resilient when someone is out.
- Communities of practice. Also called chapters, guilds, or centers of excellence. These answer the objection you will absolutely hear: if we scatter the designers, we lose conceptual integrity and shared craft.
A coordinator handles what you can’t eliminate.
- Team-to-team working agreements. Pre-negotiate intake, decision rights, interaction model, cycle-time expectations, and what “done” looks like.
A simplifier reduces how many dependencies are live at once.
- Balance system and portfolio WIP. Stop starting things. Fewer items in progress means fewer simultaneous dependencies of fewer distinct types.
Where I’d sequence this differently
Ken uses all seven with his clients, and so do we. But I want to push back on the order most organizations pick.
They start at number one. Feature teams. Reorganizing feels like decisive leadership, and it is also the slowest and most expensive strategy on the list. Six months later they’re still negotiating reporting lines and nothing has shipped faster.
I tell my clients to start at number seven.
Balancing WIP costs you no reorg, no headcount, and no HR conversation, and you can do it inside one planning cycle. It produces the fastest visible improvement, and that improvement is exactly the political capital you’ll need when you do ask for the reorganization.
Then move to number six, working agreements. They’re cheap, and they surface which structural dependencies actually hurt. Teams will tell you.
Only then go after feature teams and ecosystems, because now you have evidence about which ones to build first instead of a whiteboard guess.
What my Wall Street learners push back with
I spent three decades in financial services before this, so I get two objections in almost every class and both are good ones.
“Some of our dependencies are controls, not defects.” Correct. The team that builds a pricing model cannot be the team that independently validates it. That’s separation of duties, and a regulator will explain it to you if you forget. Before you eliminate a structural dependency, make sure it isn’t load-bearing. Those get strategy six, not strategy one.
“Feature teams just move the cost.” Also fair. Break up a UX group of six and spread them across twelve teams and you have not created twelve designers. You have created twelve teams with partial design coverage and possibly twelve different design languages. That’s what strategy five exists to fix, and communities of practice only work if somebody funds the time for them. On paper they’re free. In practice they’re the first thing cut when the delivery pressure shows up.
Neither objection kills the argument. Both should change how you sequence it.
Try this on Monday
Pick one recurring wait your teams complain about. Count how many times it happened last quarter. That count is your instance rate, and it is the real size of the prize.
Then ask a better question than “how do we coordinate this better?”
Ask what would have to be true for this dependency to not exist at all.
Sometimes the answer is a hire. Sometimes it’s an API. Sometimes it’s a regulator, and you go build a working agreement instead.
But ask it, because that coordination meeting is going to run every week until somebody does.
In an upcoming post I’ll walk through how we actually measure flow efficiency with clients, since “10% or less” is a lot more convincing when it’s your own number.
I’d really appreciate your comments and feedback on this one.
Credit where it’s due. The structural versus instantiated distinction and the seven-strategy improvement framework are Ken Rubin’s, developed and evolved through his work with large clients. Ken is the author of Essential Scrum. The sequencing argument and the objections in this post are mine, and so are any errors in them. Read Ken’s original here: https://www.linkedin.com/pulse/dependencies-killing-your-agile-flow-scale-mountain-goat-software/
