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).
10 comments
[ 2.6 ms ] story [ 37.1 ms ] threadTry 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.
"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 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.