Comment by thanhhaimai | Hacker News Reader

Comment by thanhhaimai | Hacker News Reader

Parent Full thread

I also had experience leading both talented and heavily invested teams. Differently from your experience, we were able to get the team hyper productive and accomplished a lot of good things together. A couple lessons I learned:

- 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.

> 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.

That's where we differ on the cause.

> "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.

I think you're probably right and that's definitely part of the issue.

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.

If a piece of work is buggy, hard to maintain AND failed to deliver, I'm not sure if it can be described as amazing engineering.

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.

Don’t be afraid to say it, the language was Rust wasn’t it? Although Rust usually replaces C or C++, so maybe in your case Go is more likely.

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

Reply on news.ycombinator.com