How do you solve bottleneck engineers?

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.

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.

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.

Read The Phoenix Project - you are describing a “Brent.”

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.

You relieve them of any tasks except for documenting the code/protocol.