Where Information Goes To Die
We’ve all been in jobs where there is “the guy” (I should really say “the person”, but that just doesn’t ring as colloquially true) who know how everything works and ties together. Maybe she’s been there a while, maybe she’s just REALLY smart, but in any case, she is the person who knows how all the pieces tie together. Maybe it’s you!
This person is usually a dedicated worker who is very often savvy and held in high regard by his coworkers. This person is often the one that problems are escalated to or is the person that rides to the rescue during an outage.
In one of my favorite books, the Phoenix Project, the authors create a character that embodies “that guy” - Brent.
<div class="productDetails center">
<a href="http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592%3FSubscriptionId%3D0ENGV10E9K9QDNSJ5C82%26tag%3Dinvestipendin-20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D0988262592" target="new" class="product-title title">The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win</a>
<div class="product-author author">By Gene Kim, Kevin Behr, George Spafford</div>
</div>
Without giving away too much of the book, Brent finds himself in the path of just about every critical workflow in the company. He’s not malicious, he’s trying to be efficient and solve business problems (as he sees them). The problem is that every time Brent solves a problem, he gets a bit smarter about how those systems work together, but no one else on the team does. This compounds the reliance on Brent.
I keep listening as Patty continues, “Someone else said that she couldn’t implement her change because there was an outage in progress. And a bunch of other people said, um…” She looks uncomfortable, so I prompt her to continue. “Well, they said they needed Brent for a portion of their changes, and he wasn’t available,” she says reluctantly. “In some cases, Brent’s involvement was planned. But in other cases, they discovered they needed his help only after they started implementing and had to abort when Brent wasn’t available.
Distribute the Goods
In order to deal with guys (or women) who are becoming (or are already) a bottleneck of information in your organization, we need to pull that information out of them - gently if possible. That is the type of information you want to persist in co-workers, documentation, runbooks, monitoring systems and scripts.
It will be painful.
Responses to critical issues will be slower at first. There will be lots of “Well, I’ll just do it this way once and I’ll script it or show you next time, when it’s not as critical.” It’s ALWAYS that critical. There is NEVER more time.
That knowledge and process needs to be captured, as soon as possible.
There may be hurt feelings.
If you call someone a bottleneck, that implies that they can’t keep up with the workload. Your Brent may feeling like things are being “taken away” from him. Nothing makes you feel valued like being told that you are indispensable.
If you single out someone as having all the knowledge, you are also telling everyone else in the organization that they don’t know something critical to there environment and that they are not as good as “Brent”.
It will benefit everyone.
If that knowledge is distributed and captured, the pressure on “Brent” will drop.
“My God,” Wes continues, shaking his head. “I don’t think Brent’s even been able to take a day off without a pager in about three years. You know, he’ll burst into tears when we offer that to him.”
Since work isn’t being blocked by “Brent” anymore, the amount of projects and changes that can be completed improve.
IF you are “Brent” or think you might become “Brent”,
- focus building documentation or tooling to help your team do what you can
- help embed your intuition in your monitoring system with contextual checks
- pair with a team member and let them drive the console or code editor, so they understand what’s going on
Do you have any other suggestions?