Protect the bottleneck

11 Sep 2024 . efficiency . Comments #management #improvement

Mark Rendell in his blog about the Phoenix Project listed in what they actually did #8 Protected the bottleneck. Brent was the single point of failure on the IT team, both the go to person for everyone’s questions, and also the one who struggled to make others like him. How did the book solve that problem?

Mark’s list continues with #9 Captured how to replicate the work done by the bottleneck and #10 Identify the constraint and exploit it i.e have it work on only the most important thing. See the whole list

Once an individual demonstrates to others how to do the work, it is not up to the bottleneck to replicate the work done. Instead the bottleneck must focus on only the most important thing. How does a team identify their bottleneck, replicate the work it does so that it may focus on only the most important thing?

Modern Bottlenecks in Software Development Process

There tends to be individuals who, similar to The Phoenix Project’s Brent, is expected to perform duties rather than replicate them. It is only when their coworkers who used to come to him for everything experience the management intervention protecting the most important thing that the bottleneck replicates.

Combatting this knowledge or domain sink hole is important to maintain healthy teams. Documentation is helpful, but only in the same way that specs can help describe how code works. It is a one-way communication meant for a wide audience. A better way to set up success is with pairing.

Simple ways to improve this culture of sharing is to perform a code review over zoom rather than only on Github. Interaction is pretty important to understanding quickly. Having the developer who doesn’t understand a domain use the keyboard to enter the code is the most effective way to replicate the work done. A humble navigator tends to be more effective at encouraging this most effective position.

Exploit the constraint

In software development it is difficult to exploit the constraint, at least not reliably. More often than not, engineers use shared knowledge and synchronous pairing to avoid having to be Jack-of-all-trades with zero specialty. Unless time zones, meetings, moods, and breaks line up there’s very little left in the day to exploit the constraint.

We’ve used a few tools to try and improve this concept. Meetings are clustered all before lunch so the people on other teams with the specialty knowledge have long block of time later in the day. Additionally, a day is designated as free of meetings. Finally, we’ve set up 6 hour blocks of time on two separate days as a lounge where team members optionally drop in to work.

Usually the constraint is a moving target. In order to exploit it, you need to know what it is, get on the same page, then work only on what is the most important.

Replicate the work

The very tactics employers use to squeeze productivity out of their workforce like making competitions out of performance, conducting reviews (especially onymous feedback), and layoffs makes it difficult for top performers to focus on enablement of their colleagues.

Rather than leaving those who are best suited to instruct in an approachable position, these games tend to put distance between colleagues and a few things happen. First, when work is distilled down to any metric that produces ranking everyone focuses on a metric rather than work. The collaboration that results in more skilled individuals is demotivated.

What tends to happen long term is everyone is left comparing themselves with someone else rather than themselves a year ago. What we should be comparing is the whole team a year ago. And the best way to get there is not through ranking. It is by sharing.