[bertr4nd]

I’ve only once worked under a manager who also coded, and I had extremely mixed feelings. On the one hand, he was a brilliant engineer who I learned a ton from, and who set a really solid technical direction for the team.

On the other hand, I was personally unhappy a lot of the time. On one occasion he pretty much tore apart one of my designs and I felt fairly humiliated (with reason, as a few other senior engineers confirmed in private conversations).

Did my design deserve to die horribly? I don’t know. The PR had already been accepted, but maybe the accepter was wrong. In any case it felt really crappy to be criticized so heavily by someone who in theory supports me.

[arpa]

You know, it's easy to be an asshole when you're brilliant. But that's why soft skills are important, especially in leadership roles.

I tried my best to be a supporting lead, everywhere i was in that role. I believe in leading by example, but i recognize the necessity to _let_ people do things themselves and not just hog power because "i know best". Let people implement imperfect designs. They'll own it, learn, and fix them in time. Your job is to lead, to give direction and not let total crap be put into prod, not keep people under your "benevolent dictator" heel.

[jeromenerf]

I tend to disagree with the "live and let die" approach. Delegating responsibilities isn’t abandoning responsibilities and when deviation happens, getting hands dirty is good stewardship to me.

The main factor to me is the team size and subsequently the organization of said responsibilities delegation. My personal context sweet spot is around a 50 persons team.

[ritchiea]

There's also good and bad ways to give feedback. It's important to find ways to give honest feedback that isn't crushing your reports's confidence. It's more of a question of when to step in with an important critique that whether to at all. There are some pieces of code and systems that aren't critical enough or won't be stressed by a junior learning through a bad design decision. And critical system where you absolutely have to step in and make sure everything is in the best shape possible.

[arpa]

50 persons is a small organization, not a team!!

I agree about responsibilities part, however, if you don't let your people grow by simply vetoing the ideas, they won't grow. Discussing and openness to your subordinates' ideas is not a bad thing in my opinion. Letting people make proof-of-concepts and fail is not abandonment of responsibilities. Letting people implement their bad ideas in production is.

[jeromenerf]

> 50 persons is a small organization, not a team!!

Well, I refer to the whole company as a team. This may be my SME bias :)

[arpa]

That's a sign of a good CxO, IMHO - thinking of the whole org as a team. Respect :)