[dfsegoat]

> I was the happiest boss when I could let people just do their thing and come back with great results

This is decentralized command, and really the best place to be. That's why I believe being a leader in software dev. is really about serving the ppl under you - not the opposite.

I think it's about balance:

I will micromanage new hires initially, so that I can ensure they are sticking to SOPs, code standards etc. and developing the habits we need to be successful.

After awhile, the training wheels can come off and you can give them ownership of larger and larger stakes in projects. They'll stumble once in awhile, but chances are that goes back to something you (leader) left as ambiguous - or that they genuinely didn't know.

[chriskanan]

This is the same way I treat PhD students. A lot of micromanagement early on, and then I progressively try to step back. That said, it is always a big concern if they stumble for a considerable amount of time (a year) or are not capable of being independent as they approach graduation, even if they can deliver very effectively when being micromanaged.

[brailsafe]

Do you find you get a lot of negative feedback or churn during that period? Seems like it would be an awful first impression, but maybe not if you communicate things well.

[dfsegoat]

You mean during the intro / "more hands on period"?

I've not heard any negative feedback, but I think it requires a 'fine touch' - or you risk drowning people in information / tedium. If they get things the first time, I won't be prone to checking up on them as much.

[brailsafe]

Ya, that's what I meant. If I started at a company and my manager micromanaged me—especially with no clear reason why—I'd feel like this company isn't for me. No negative feedback isn't terribly surprising given that I don't know anyone besides myself inclined to actually say anything about an issue. Out of curiosity though, have you ever received negative feedback about anything, or given it yourself explicity before being more "hands-on"?

[dfsegoat]

I totally get where you are coming from. I should clarify that historically, all of my new hires were pretty much fresh out of school, or transitioning to software dev from other roles.

If I hired a dev with significant experience, I don't think I would use the same process, aside from knowledge gaps.

I definitely have received negative feedback on processes that are in place, and I welcome that, because if something can be done better, or more efficiently - then we should change it. Flexibility is key.