I have experienced this from the management perspective and it resonates strongly with experiences I have had. Some of the hardest employees to manage are those that are both talented and heavily invested, but unable to accept what their role actually is. When you have someone like that doing things that aren't in alignment with the technical vision - whether its right or wrong - they rapidly diverge towards having negative value.

- Micromanaging and "make them accept their role" is how you make them unproductive. Smart/talented people can tell if the manager doesn't care. They know if they are being forced to be a cog in the machine. They either become frustrated and quit, or resigned into doing just enough work 9-5.

- Having talented and invested folks voicing ideas that aren't in alignment with the current technical vision is a critical signal you should take note. That may mean you don't have a good Tech Lead that can convince those folks why the current approach is good. It's not the job of those folks to "align" with the Tech Lead. It's the Tech Lead job to convince those folks that the approach is correct.

- Everyone requires a different way to lead/manage. But in general, the more talented a person is, the more autonomy they would expect. To get the best out of them, assume good faith, and trust their autonomy.

That's a really interesting observation. If this thread was about the opposite - what mistakes did you make later in your career - one of my responses would be the above - because its exactly what I did and it turned out badly. I recognized talented people, seeing in them earlier versions of myself, and I gave them lots of autonomy. And they took it, and I got back amazing works of art that created all kinds of discordance with our longer term architecture and vision. I regret now that I didn't intervene more strongly at that point. Instead, those people have left and I now have years of technical debt to fix. Meanwhile the less talented but more aligned folk are chugging away and creating more value longer term. It's tortoise and the hare.

> "And they took it, and I got back amazing works of art that created all kinds of discordance with our longer term architecture and vision"

I interpreted this part as you attributing the cause to the talented folks creating the discordance in your team.

For me, it's the reverse. That shows insufficient technical leadership from the top. It's the job of the Tech Lead to convince and ensure good architecture. If the Tech Lead get "amazing works" that are "all kinds of discordance", it's the failure of the Tech Lead. People don't believe in the architecture/design. They see flaws. As I mentioned above, it's the signal that you may have a weak TL. I would focus on improving that aspect first.

However your assumption that people can all be convinced to agree on the technical architecture is part of the problem here. There are so many areas of software engineering where "reasonable experts" can disagree. Static vs dynamic typing, functional vs object oriented, loose coupled messaging based flows vs tightly coupled APIs etc. Successful systems can be built in all these ways as long as one is chosen and there is some consistency. But it is hard to be successful if they are built in all different ways at the same time.

So inherent in this picture is that you will have people with irreconcilable differences about how things should work at a fairly deep level.

Acknowledging your point however - part of what I say my mistake was in not "intervening" was to do more of this advocacy proactively, and flush out earlier on - can these individuals be convinced or is the difference irreconcilable.

An example, if it helps, is in one instance one of the team was tasked to implement a particular feature, and they found that the implementation was too slow when written in Python. So without consulting they selected a different language that is not in use or understood by anybody on the team at all, and then developed this whole critical subsystem in this language. Meanwhile there were many alternatives within the team's chosen tech stack that could capably solve this problem with adequate performance (even Python if properly utilized). The solution was an amazing work of art (although quite buggy as it turned out). But it was a disaster for the project and actually sank the delivery of it.

It sounds like you might have a team of talented and enthusiastic junior/mid-career engineers who lacked the experience and vision to see the bigger picture and long term future of their work.

In all seriousness, seems odd that they were able to go so far down this road without anyone throwing up red flags.

Leaving is not always the answer, keeping your head low and surviving is modus operandi for a lot of people.

Perhaps I’ve been lucky though. I’ve worked at places with potential to move internally which has kept things fresh and allowed me to grow expertise on the same larger team without losing tribal product knowledge altogether.

I’ve only switched companies once and it had more to do with curiosity than bad management.