TBM 261: Dependencies In Fast(er) Growing Companies (Part 1)
Part 1 | Part 2 | Part 3 | Part 4
We often hear about dependencies in the context of large, slow-moving, and slow-growing companies. The reality, however, is that dependencies are challenging in companies of all sizes and growth rates. Ironically, in faster-growing companies—due to scaling and other factors—the problems are even more acute AND the appetite for solving those problems is lower.
In this multi-part series I’ll tackle the dependency problem, with a specific focus on faster growing companies.
Note: When I discuss "dependencies" in this post, I specifically discuss work-related, ad-hoc dependencies. Specifically, I am talking about the "bad kind" that increases cognitive load, requires attention and coordination, and generally acts as limiting constraints. Ideally, they wouldn't exist. I'm not covering the "good kind" teams rely on to do great work and deliver customer value. Also, remember I’ve had exposure to lots of companies. Any resemblance to my current full-time job is coincidental. These are universal problems.
When a company is small, dependencies can be dealt with locally, without undue drag. A startup would be crazy to over-process dependency resolution because the ratio of cognitive load to productive work is still heavily skewed towards being productive. You're one hop from everyone else. If they are overwhelmed, you'll know. If you have a question, you'll get an answer quickly.
Additionally, a startup has one singular goal: surviving. There aren't 'departments' or 'products'—just the overarching aim of surviving to thrive. You can keep this informal approach going for a long time provided that:
Your goals/incentives stay focused.
Teams are empowered to say 'not now.'
Teams run their intake processes.
Work-in-progress (WIP) limits are kept relatively low, and the work stays flowing.
The problems start as the void between the people doing the work and the people funding the work (or setting competing goals) widens.
The ratio of cognitive load to productive work starts to skew towards cognitive load.
First is the obvious issue of a gap in the hands-on context involved in doing the work and the details in the work. Without everyone in the room, making real decisions is difficult. Next, there will be a tendency for leaders to avoid between-leader conflicts and to push the conflict down onto their teams to deal with. Surely, if teams planned better, it would be possible to fit it all in. The people with the formal authority to make decisions have limited time, and dependencies add inherent complexity, increasing the likelihood that details will get watered down. Whereas before, you had people directly working things out, now you have to navigate a tree of competing priorities, and at each level in the hierarchy, the time available to absorb the actual issues drops.
Meanwhile, as information travels longer distances, you get all the normal information loss problems coupled with the biases at each hop. 'I don't want it to seem like we're raising too much of a fuss,' says the middle manager. 'I think we need to be more pragmatic,' says the VP (who doesn't need to do any of that pragmatic work). When leaders finally get frustrated enough to dig into the details, they are horrified to see how hard it is to get actual work done and quickly close up that box ('Come on, we need to simplify! It can’t be this hard!').
The folks on the front lines will do anything at this point to spend less time in soul-sucking meetings. So they often just throw up their hands and say 'Yes' without knowing what they've said yes to and knowing that the details will almost certainly change, and timelines outside their control will slip so that they will be off the hook anyway. Once you lengthen the planning horizon, things become even more complex and harder to wrap your head around. This reality increases the likelihood that people will do whatever it takes to make the meeting end and will be even more confident that things will change.
It becomes a game of agreeing to things with no real ramifications and avoiding the actual time it would take to get aligned (even temporarily).
In big bureaucratic companies, the tendency at this point is to regiment the whole process and set up elaborate gates and huge meetings, get the tickets 'locked in,' etc. In faster-moving, faster-growing companies, that doesn't happen. First, there are bigger incentives to keep things moving quickly. People's promotions are on the line! There is also a bias against heavy processes and a strong desire (to believe, at least) that things can be dealt with informally by all the smart people you have around. It is easier to rationalize calling it out when everything is going slowly. However, when some things are moving incredibly quickly, and teams are, in fact, in a position to do things independently if they want, there is much more pressure and inertia just to keep things rolling and deal with dependencies informally. Those (high dependency) efforts will drag and go incredibly slow, but it isn't like ALL the work is going slow.
Big enterprises pondering a "transformation" are fine doing SaFE because they have nothing to lose. The rapidly growing company wants to hold on to the illusion that it is nimble and people are independent, sentient beings instead of cogs.
The net effect here is that:
In high-growth companies, you tend to observe far more dependencies than you expect when you get into the details, but the 'cost' of those dependencies tends to be muted and opaque.
'It's the dependencies' becomes like blaming tech-debt. It is almost certainly true, but no one wants to get into all the details because that worsens the situation and drains your soul. The further you are away from the work, the more it seems like an excuse. The closer you are to the work, the more it looks like a reality you're tired of describing and explaining.
Because there is no real forcing function (and the strong inertia), dependencies proliferate despite the organization's structure. Front-line folks resign themselves to figuring it out.
As opacity increases, trust drops. Are the dependencies actually that bad? Things are getting slower and slower, but what is REALLY behind that? We used to be able to figure this out informally, and now we can't. What changed? Unfortunately, this can trigger efforts at premature convergence, further exacerbating the problem.
Problem Statement
How do you manage dependencies in environments where there is a premium on speed and growth AND you’re experiencing fairly rapid change? How do you avoid causing premature convergence, chasing high utilization, increasing work in progress, lengthening lead times, and exacerbating trust issues and the information gap between the front-lines and senior executives? How can we avoid the “just make this meeting stop” syndrome the eats away at team morale?
Dependencies are a fact of life. In fact, if they didn’t exist, that would probably mean a business wasn’t growing. How do we deal with them?
Continued in Part 2
Another tune of well struck notes, John. Complexity is the stuff of madness unless one learns to listen to the music of their organization.