Engineering management lessons (2014)
defmacro.org
Engineering management lessons (2014)
1–10 of 112 posts
Re: Engineering management lessons (2014)
#2Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
Re: Engineering management lessons (2014)
#3[deleted]
Re: Engineering management lessons (2014)
#4Number 11: you are probably talking about authoritativeness and not authority
Re: Engineering management lessons (2014)
#5Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
Where does it tell to not code?
Re: Engineering management lessons (2014)
#6"Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own."
Spot on, a good leader does not make all the decisions. It is counter-intuitive to popular culture, but this is stop on.
I would go on to say minimising your decisions, also helps to spend more time on a key decision when it is really necessary.
Re: Engineering management lessons (2014)
#7Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself)
Then about the 5% - this is high prio, high visibility fixes where you bring in your extraordinary expertise in some domain. Believe me, that's enough to stay respected. Your time is much better spent at sparring systems architecture & high level design, hiring and building well-oiled teams and discussing the business needs with the rest of the company.
Isn't as fun, Doesn't feel as good, but it helps most the long run. The alternative is a high performance coding monkey that gets a tiny area of the company right - and the rest of IT goes wild and rewrites core APIs in the latest three hype language because "we needed to get rid of technical debt".
The 44 lessons of the OP are distilled gold from years of experience, I rehearse them every year and can recommend them to any aspiring tech lead.
Re: Engineering management lessons (2014)
#8Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
I'd rather a manager who seems to care about me. Someone who is fair to the team, and shields us from the executive pressure. Someone that gives me challenging work which I could fail at, and recognises that I can fail and that it's ok if I do. Most of all, someone who dispays real appreciation for the value I add to the team.
I honestly don't care if they code or not.
Re: Engineering management lessons (2014)
#9Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
Engineering managers that also code a lot usually fall short on the managing part, at least in my experience. Imo it's better if they focus on building a great team, guiding the team in the right direction by doing code reviews and making the hard decisions and be somewhat of a shield between the devs and other internal or external stake holders. Sounds boring, but provides more value as a whole imo. It's also why i opted to not be a manager right now so that i can still code full time.
This does not apply if you are a <10 people company though.
Re: Engineering management lessons (2014)
#10"Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own." Spot on, a good leader does not make all the decisions. It is counter-intuitive to popular culture, but this is stop on. I would go on to say minimising your decisions, also helps to spend more time on a key decision when it is really necessary.
A variation on this is not swoop in and make discoveries that the team is very close to finding - let them enjoy the thrill (even if you have to nudge them a bit in the right direction).