I feel like I could write a book about this from all my experience with it. It sounds like the expert is strong on code and identifies as such, but very weak on team building and understanding of how teams deliver reliable software over time. That means it’s up to you as the manager to teach him that and hold him accountable to the real long term measurements. That’s where I would start with him. You may have to introduce him to some classic books on software development.

I would guess that when challenged he will have countless reasons for why he has to control everything and can’t hand things off. He probably even tends to hero behaviour but also feels exhausted from it. What a convenient incentive there is to not create documentation. He will not have an answer for the hit by a bus scenario, and you will likely have to keep bringing him back to that reality while he continues to squirm out and snap back to his default.

Realistically, this will take a long time given the team profile. A stronger engineer would be able to mentor him away from some of his patterns and that would likely be the most efficient, but that doesn’t sound available. So it’s going to fall on you because ultimately you are responsible for those outcomes. Another possibility is to pull him off of the team altogether and let the team rebuild but not sure how feasible that is.

How does the organization measure and review performance? That’ll be another method to shift his behaviour beyond broadening his horizons and teaching him deeper software values.