Management had to figure out they needed to handle the escalations, prioritize, reduce the bottleneck, document the solutions, and teach others to fish.
This article seems to be addressing the same issue, albeit a bit more confrontationally. Anyone have recommendations for a non-fictional book on how managers can identify these problems and implement people-centric solutions?
How to Win Friends and Influence People is a fantastic book on people in general.
Influence is a great book for managing up, or understanding why your people react the way that they do.
The basics for any manager are the following:
1. Know what you're solving for, know what your people are solving for. Make sure that they are in alignment.
2. Invest in your people. Time, money, etc. Not just technical skills, but soft skills. A smile and remembering someone's name go a long way.
3. Keep everything that isn't their job, out of their job. If someone is a bottleneck then there needs to be a defined point in time every week where they do documentation and/or training until they are no longer the bottleneck. Assume it will take other people longer to do the same task at first and accept it, make sure that they understand this is normal.
Edit: I'd also include this blog post in your reading: http://firstround.com/review/this-90-day-plan-turns-engineer...
And thank you for the reminder of that. It occurred to me reading the original article and this reply to it that I may be somewhat putting myself in a Rick situation right now.
I don't have any good book recommendations, but I'd be delighted if anyone else did :)
1) don't work more than 45 hours a week, ever.
2) if you are forced to work any saturday or sunday, you take one day off in the following week.
3) don't work when you are outside of work. no remote access, no email, no slack, no app on your phone, don't accept calls from work.
That's probably the solution: find at least one other person for this team. The CTO was amazingly taking care of all of the infrastructure himself, I came in to lighten his load, and I feel like we could use another person or two to bring it down to a manageable level.
I was pleasantly surprised when they acknowledged this is largely a management issue and worked to fix the underlying causes instead of using the developer as a scapegoat.
You already seem aware of and thoughtful about the issue. (To the point you could identify a similar one in fiction.)
I'm always loathe to recommend books about techniques -- almost invariably, they're used in a process-as-proxy way. (If I had one piece of advice of managers, it would be that -- don't manage by proxy!)