I had a similar brilliant engineer with odd working hours at one point. I also had the same problem with other engineers requesting the same odd hours, with equally negative results.
In my case, I eventually learned that the odd hours weren't the key to his perceived success. Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation, because no one else was awake or online at the same time to discuss them.
Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions. Everyone else was forced to work around his code. If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor and waste time updating their PRs to match his work.
Worse yet, having someone like that on the team drives away other great employees. Eventually everyone else will get sick of accommodating the architects isolated schedule. If they have other opportunities, they'll leave.
> I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.
It's not on you. Brilliance and individual productivity aren't everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It's painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run.
In my case, I eventually learned that the odd hours weren't the key to his perceived success. Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation, because no one else was awake or online at the same time to discuss them.
Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions. Everyone else was forced to work around his code. If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor and waste time updating their PRs to match his work.
Worse yet, having someone like that on the team drives away other great employees. Eventually everyone else will get sick of accommodating the architects isolated schedule. If they have other opportunities, they'll leave.
> I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.
It's not on you. Brilliance and individual productivity aren't everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It's painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run.