Hacker News new | past | comments | ask | show | jobs | submit login

A very similar scenario is described in the fictional work, "The Phoenix Project", is it not? There is a smart character who handles every escalation, but nothing is documented, he was the bottleneck, and his stress level was high.

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?




The One-Minute Manager is a general book on how to appropriately manage people.

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...


Yup, very similar scenario in The Phoenix Project.

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 :)


It's simple to avoid:

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.


I can sympathise. I've basically been brought in to take over from someone who was the technical bottleneck for the company I now work for so that he can get on with being CTO. For a while I was necessarily working alone, but now I've hired a team and am in the process of eliminating myself as the bottleneck: by the time I go on holiday at the end of this week I want to be off the critical path and never find myself on it again.


Are you me? :)

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.


When I was reading "The Phoenix Project" I thought that the outcome there was going to be the same as in the original article this post is responding to. The "hotshot" developer would be fired and everyone would live happily ever after without addressing the reason things got so bad.

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.


Can I ask what you're hoping to get out of a book?

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!)




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: