Ask HN: How do you solve bottleneck engineers?
What happens when whole companies end up stuck due to bottleneck engineers? By that I mean an engineer that knows the code/protocol (because they wrote it most likely) but did not document it. Hence, other engineers are often stuck for weeks/months working on it unless they can obtain answers from a single engineer, who most often does not respond or respond by just doing the work in place of the other engineers (rainchecking the problem).
6 comments
Unspicy take:
Try to take a blameless post-mortem approach rather than blaming your "bottleneck" engineer, this is ultimately an organisational failure.
Get people together, go through the RCA process. Use some representative blockers.
When you take a wider look at what's going on, be open to more complex explanations than might be immediately apparent.
Ask whether the organisation prioritises documentation, how time is allocated for it and how that work is checked. Ask why multiple people weren't across core work that is critical to the business. If there was a team, why did the others leave? What is your onboarding process and is it giving people enough information and access to do their jobs? Does your now "bottleneck" engineer's workload permit time to answer the questions they get? And so on.
I do find it surprising that engineers would wait weeks or months for an answer instead of reading code or writing a test. Why aren't the engineers engineering, it seems like a major problem? You're either talking about really subtle and deep systems here, or the code/infra is super bad, or people don't have the access (to code, or systems or test infra) they need to do their jobs, or you have major skill gaps in your team, or some combination of all these factors.
Try to take a blameless post-mortem approach rather than blaming your "bottleneck" engineer, this is ultimately an organisational failure.
Get people together, go through the RCA process. Use some representative blockers.
When you take a wider look at what's going on, be open to more complex explanations than might be immediately apparent.
Ask whether the organisation prioritises documentation, how time is allocated for it and how that work is checked. Ask why multiple people weren't across core work that is critical to the business. If there was a team, why did the others leave? What is your onboarding process and is it giving people enough information and access to do their jobs? Does your now "bottleneck" engineer's workload permit time to answer the questions they get? And so on.
I do find it surprising that engineers would wait weeks or months for an answer instead of reading code or writing a test. Why aren't the engineers engineering, it seems like a major problem? You're either talking about really subtle and deep systems here, or the code/infra is super bad, or people don't have the access (to code, or systems or test infra) they need to do their jobs, or you have major skill gaps in your team, or some combination of all these factors.
Rule of three: if someone asks the same question or protocols three times, then they should document it.
"often does not respond or respond by just doing the work in place of the other engineers (rainchecking the problem)."
This suggests that the documentation takes longer to write than the solution.
Documentation isn't always as helpful as many people think. It gets out of date unless maintained and can be worse than reading the code. Someone can sit and think for three hours how to explain it to someone else. Or they can just change code in a bunch of places
The solution we use is that everyone is expected to read the code. We ask when something can't be found, or ask the why. It's usually easy to say "oh that code is in the X module, not Y" rather than dig up actual specs and making sure it's correct.
If it's something like an API guy blocking a FE guy, FE should start reading API code.
If this is a recurring problem, hire a systems analyst, whose dedicated role is to answer such questions, handle code reviews, be mentally up to date with all changes and basically act as living documentation.
"often does not respond or respond by just doing the work in place of the other engineers (rainchecking the problem)."
This suggests that the documentation takes longer to write than the solution.
Documentation isn't always as helpful as many people think. It gets out of date unless maintained and can be worse than reading the code. Someone can sit and think for three hours how to explain it to someone else. Or they can just change code in a bunch of places
The solution we use is that everyone is expected to read the code. We ask when something can't be found, or ask the why. It's usually easy to say "oh that code is in the X module, not Y" rather than dig up actual specs and making sure it's correct.
If it's something like an API guy blocking a FE guy, FE should start reading API code.
If this is a recurring problem, hire a systems analyst, whose dedicated role is to answer such questions, handle code reviews, be mentally up to date with all changes and basically act as living documentation.
The whole framing is wrong to call this person a "bottleneck engineer". This is not the issue of the engineer but a failure of management. Dedicate another engineer or two to learn from and document what this person knows. And give the bottleneck engineer a raise.
I had to solve a similar issue in two teams. I'm not against documentation, but this wouldn't have solved the issue in my case. Documentation was available, but you couldn't clearly know if it's still up-to-date or which use case would be the right one.
The solution was to dissolve head monopolies. The best developer in the team was very supportive and tried to solve all problems himself instead of involving his colleagues to make them more independent from him. This was not malicious intent, but just helpfulness oriented to short-term solutions.
So it was a structural cause that could only be solved from outside the team.
The solution was to dissolve head monopolies. The best developer in the team was very supportive and tried to solve all problems himself instead of involving his colleagues to make them more independent from him. This was not malicious intent, but just helpfulness oriented to short-term solutions.
So it was a structural cause that could only be solved from outside the team.
You relieve them of any tasks except for documenting the code/protocol.
Read The Phoenix Project - you are describing a “Brent.”
This book has been recommended to me a number of times! And I have it on my desk as I'm typing this comment :) Do you remember how they fixed the problem without annoying the Brent too much? (if Brent quits it's not good)
Maybe you can pick up the book and read it since it's next to you.
what a condescending comment
More or less condescending than "Oh you mean I have a book right there next to me that contains the information I want? well I would rather you - random on the internet - to take time out of your day to summarize for me what I could find out by myself - ok thanks bye!"?