TBM 370: Dependencies Aren't Your Problem

Thought experiment.

Save The Company

You have a critical, high-priority initiative that involves fifteen teams from across your organization. It is company-saving. If the effort fails, everyone’s RSU will be worthless, customers will churn en masse, and layoffs will be imminent. Everyone knows it. Everyone feels it.

Question: Does anyone complain about dependencies?

No. Because there is an implicit (and likely explicit) agreement that teams MUST focus on that initiative. They may complain a bit about having to coordinate across time zones and attend larger-than-usual meetings. The effort will also involve coordination friction, which will likely slow progress. But I doubt the next retro will be all about the evils of dependencies. If the company survives, everyone will rejoice.

The Overwhelmed Platform Team

Now contrast this with the situation in most companies.

A platform team is juggling six things at once. They participated in an elaborate “dependency management” exercise and made “high integrity commitments” to various teams. The roadmap timeline view for the quarter looks like an elaborate FTE capacity Tetris game.

One of those things is the thing that theoretically will make other teams less dependent on the platform team. The big unblocker. But it is playing the 6th fiddle to the myriad of ad hoc, external requests.

“We need to be more proactive here in Platform,” said their VP the other day, so there is little appetite for pushing back or asking too many questions. Little do they know, but one of those external requests will earn the company a maximum of $ 50,000 per month in cost savings (if the stars align), while another work item is blocking a massively important $1,000,000/mo, super high-critical, and high-value confidence initiative. The other external items trend on the lower side of value. But they don’t know any of this, because “It is all requests to us. They were all listed as P0s and P1s in the spreadsheet!”

Why?

How did they get into this mess?

Because it is easier to let this situation predominate than to have the hard discussions about priorities and making the right investments to reduce the number of dependencies. No one wants to own the fallout of saying “not now” or “we need to double investment in that team and do some re-orging to make that dependency go away.”

Visualizing dependencies is not enough. Instead, you need a visualization that shows each team’s competing priorities, highlights the value gap between those priorities, and measures the drag caused by multitasking.

Instead, most of these systems reduce work to colored bars in a matrix, incentivizing teams to play scheduling Tetris just to turn cells green. It becomes a “figure out how to make it work” conversation rather than a “what SHOULD we be focusing on?” discussion.

Dependency problems are frequently boiled down to discussions about estimation and commitment, when the real conversation should be about priorities and actual outcomes. In the current economic climate, teams are too gun‑shy to escalate issues, so you’ll hear a lot of talk about the evils of dependencies but very few concrete examples.

Companies that establish elaborate dependency‑tracking systems rarely, rarely calculate the “cost” of those dependencies—in terms of displaced priorities or the value of partnering on the work. Instead, these systems foster the wrong habits, including high WIP, premature convergence, and short-termism.

However, when you peel away the layers, you find that while dependencies are a problem, the much bigger issue is the incentives to overcommit and be overly proactive, along with a lack of shared priorities.

To fix this, you need a shift in perspective.

The focus needs to shift from merely “managing” dependencies to thinking about allocating capacity in the most economically sensible way given today’s conditions, while also deciding where to invest capital to untangle the issues that are gumming up the works.

Managing dependencies --> "Value" throughput. Shift the goal from managing dependencies, to focusing on the throughput of potentially value-creating activities

(I'd love to show you how we're addressing this with Dotwork. Drop some time on my cal if you're interested.)