How to handle Brent in The Phoenix Project

I got stuck at home with a dreadful cough and sinus dysfunction this last week. As a result I spent some time re-reading The Phoenix Project. I really wanted to try to have another run at understanding Erik’s examples from the Theory of Constraints side of things. Particularly, I wanted to appreciate the “ringer” situation that Brent has created around himself.

Brent is a problem. I think first and foremost every organization has a Brent. Theres the guy that knows how to do everything, is responsive to everyone, and generally the most helpful fella in the room. As a result Brent becomes a bottleneck for all work endeavors. He begins to thrash cycles as he is overwhelmed with requests, meetings, and generally refocused on the less productive social aspects of development work.

I think its key that Brent situations occur in the context of an “easier to do it than explain it or teach it” situation. I think an organization needs to identify Brents and begin to introduce some professionally essential development paths for Brent so that the situation where Brent knows and holds up every workflow in the enterprise.  First is to get Brent in a hand-on teacher mentality. Make sure your ringer starts couplings requests for their time come with a training session. If someone needs Brent to copy a database table from one environment to the next, make sure that Brent is teaching that individual how to do it themselves and that they are able to react the procedure after they are done.

In this way, asking Brent means you are accepting a piece of work for which you can no longer request of Brent. Its a one-time shot kind of thing.

Secondly, I think if Brent is in work churn you need to bring in an architect level individual to study Brent’s workstream for automation opportunities. Usually, folks like Brent know tons of places where his job could be easier if he just wrote a script or process to handle it. For example, in one of my past Brent roles, bringing up WordPress environments for SEO managers was a huge component. Often, when in the depth of work churn, its difficult for individuals to see this opportunity for automation and take action on it.  An architect level observer will see these opportunties and have the specific task of making them happen.

Ideally you want someone studying exactly what Brent is doing and developing tools specifically for him to make his throughput and productivity even more amazing. If you take lengthy operations for him, reduce them to highly automated processes, then Brent is able to take more requests and the actual work performed is easier for Brent to teach others.