TBM 266: Human Load Balancers, Renegades, Insiders, and Platform Saviors (Part 4)

This is the fourth post in my series on dependencies in faster-growing companies. Read Part 1, Part 2, and Part 3 if you like, but this post stands alone if you are short on time.

Today's question:

How can the dependency challenge get so bad before companies do something about it? Why does it creep up as a problem?

Let's explore this question by discussing four archetypes:

• Human Load Balancers

• Renegades

• Insiders

• Platform Saviors

Note: This is not an effort to blame people. These archetypes are typically behaving rationally given the situation.

Human Load Balancers

One way to address dependencies is to throw people at the problem. I refer to this as the human load balancer approach. The general idea here is that you can preserve some level of independence on the team level if you hire people to coordinate dependencies. The independence is real at first—but over time becomes more illusory, held in place by the heroics of the HLB.

Human load balancers create a fascinating dynamic. A good human load balancer (and humans in general) runs in "degraded mode" quite well. Efforts don't suddenly take twice as long; it's a slow increase. The effects of premature convergence and Tetris playing can take years to materialize in terms of reduced business outcomes and customer outcomes. Employees who are super sensitive about autonomy leave if they can. Loyal employees try to stick it out and solve the problem. 

As the team gets slower and slower, there are repeated efforts to try to fix things with processes, practices, and systems. If trust in the human load balancer drops too far, they get replaced. It must have been a management problem! People get fired and replaced if faith in the team drops too far. It must have been a motivation or skills problem! 

Ironically, the better the human load balancer is at their job, the longer they can prolong having to face the dependency issue (until it is too late). Once the human load balancer self-identifies with dependency management, Tetris playing, and influencing others as their job, they will inadvertently do things that perpetuate the problem. And even if they are fully aware of the problem and want to change it, they'll push themselves to the limit—trying harder and harder to protect the team—and eventually burn out, become ineffective, and leave or get fired.

I've observed the human load balancer problem persist for years in organizations, spawning additional layers of hierarchy in management and even becoming a core part of the management culture and what defines doing a good job.

Isn’t being a human load balancer just being a manager?

Topic for another post. It really depends on the management culture in an org. Yes in some places. A definitive No in others. What I have noticed is that in many cultures the first group to blame is the front-line managers for not “working it out.”

Renegades

The next thing that mutes the impact of a growing dependency problem is that humans are extremely creative at working around dependencies. Or at least some humans are. 

If just enough people in an organization can move quickly, no matter what it takes, that is the reference point for what is possible. So you'll start to see leadership teams say things like, "Well, if that team can move so quickly, why can't the other teams move so quickly?" If, when faced with a dependency, a team opts instead to build their way around the problem, they can move quickly. Of course, the proliferation of all these workarounds makes other people's lives very difficult. Still, many companies reward people who effectively circumvent the system when it comes to promo season. 

It doesn't take many Renegades—especially if they focus on high-profile initiatives—to mute the growing impact of dependencies. When Renegades ascend the organization because of their successes, this reinforces the perception that things aren't bad. It can also stigmatize talking about stuff like debt and dependencies overall. If they aren't complaining, is it even okay to mention the problem?

Insiders

Insiders aren't as bold as Renegades, but their knowledge of how to effectively get things done even when the rest of the organization is mired in a bureaucratic mess also sways perceptions. 

People who understand the architecture, who influence who, and who can barter favors with other groups can remain effective for much longer. They also tend to have more influence in the organization overall, so their perspective of the situation often carries much weight. These are people who don't need to file a ticket (“we didn’t do that back in the day when people just got stuff done!”). They're valuable due to their contextual understanding, so they build a fair amount of social capital (though sometimes they can dismiss newcomers.) They simply don't know or understand the experience of arriving as a fresh set of eyes and trying to make sense of the organization, its architecture, and how things get done.

Platform Saviors

When dependencies accumulate, someone will understand that you can use platforms to limit the number of dependencies. And you can, in certain cases. But often, these efforts fail to produce the desired impacts. These platforms are left in nascent, un-evolved states. Teams still have to collaborate heavily to make things happen, and there is no continued investment in ensuring these platforms are useful and self-service. The problem is that this cycle can take years. So, as dependencies are accumulating, people point to these platform efforts as potential saviors. "We're doing something about it!" But the benefits never really materialize.

Side-note (and kind of funny): A friend calls himself “The Platform Surfer”, and prides himself on surfing different big tech companies and pitching a two year long big platform effort. “It’s great,” he says “because they always deprioritize it just when it starts getting boring and frustrating, and it is a fun way to explore new tech and get stock options!”

There are other contributing factors:

• Changing the org-chart is hard and is always delayed. Same with prioritization.

• Issues don't manifest immediately when teams skimp on quality to move faster and “keep pace.”

• As long as something is moving quickly to distract people, they're less likely to notice the accumulation of dependency issues.

• You have natural spectrums in terms of skills. If you hire less experienced people as you grow, skill-based challenges will exceed the challenges that dependencies present. This makes the issue harder to detect.

• Over time, you get a normalization of deviance. These things don't come in like a lion. It's an accumulation of small inconveniences multiplied over time.

• The problem gets muted as it moves up the org hierarchy.

Combined, this is why you can have a highly delayed response to an accumulation of dependencies in a company. Even when those dependencies are doubling or tripling the time it takes to get things done (or worse), many illusions get in the way of assessing the problem and doing something about it.

Some questions:

• What early signals do you look for to let you know that dependencies are increasing at a dangerous rate?

• How can you create more situational awareness about the pain the front line feels related to dependencies?

• Great human load balancers can move mountains. But should they? How do you prevent your most talented human load balancers from getting into a self-reinforcing loop?

• Find a reference feature from a couple of years ago. How long does it take you to finish a similar feature right now?

• How are you effectively balancing the rewards you give the Renegades with the teams that have to work through the muck?

• How can you limit the scope of your platform efforts so that you can get something off the ground quickly but then sustain development to realize the promise of the platform effort truly? If you can't do that, is it even worth it?

• How can you engage your insiders in sharing their institutional knowledge with others? How can you position them to have more empathy for what it's like to join the company right now?

• Are you seeing signs of premature convergence and Tetris playing? What impact does that have on customer outcomes, cycle, and lead times?

Want more in this series? See Part 1 | Part 2 | Part 3 | Part 4