5 ms·

Strongly 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

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

manojlds 9y ago
Where does it tell to not code?
- mpweiher 9y ago
  In fact: "You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end." Just not "Personally fix bugs and ship features."
endymi0n 9y ago
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.
- watwut 9y ago
  Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
  - valuearb 9y ago
    Why did you code it that way? How hard is it to answer that question?
    - NortySpock 9y ago
      "It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
      - mncharity 9y ago
        > I still need to apologise for that one. Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for? The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?
  - sanderjd 9y ago
    It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.
    - Spooky23 9y ago
didibus 9y ago
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.
- freekh 9y ago
  Second this a lot. In fact I am gonna steel exactly this and feed it back to my org
kayoone 9y ago
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.
- kochthesecond 9y ago
  I recently quit a job where I was in practice the tech lead. I did probably 60% code reviews, and made sure the architecture as a whole kept moving towards a coherent view and quality. But it was boring as I don't particularly enjoy teaching new developers basics of coding production ready systems every few months, especially when tied down as a consultant for a government organization. I ultimately had very little to say in what tech we could deploy. I therefore decided to go somewhere I might get more freedom to build quality with a bit less politics.
- TH3R3LL1K 9y ago
  I'm currently working for a company where the our manager holds a tight grip against the code we write, but he doesn't seem to guide us in the correct direction.
samlittlewood 9y ago
A recipe for disaster is for a manager's code to wind up on the critical path, then become a blocker - bad code & bad management. A possibly better approach is for managers to have a few side proejcts, scouting out potential risk reducing things, at a higher temperature, away from the main project. Great if one of them lands - no added problems if not. Also, if they land in the project, they are no longer the responsibility of the manager.
pjmlp 9y ago
I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. Have good social skills and specially important, how to raise morale in darker times. Knowing to code is irrelevant.
- kochthesecond 9y ago
  I agree, having good social skills and being good at moving things forward (often in a political landscape) is more important than coding skills.
- hoschicz 9y ago
  Where have you worked during your 30 years of experience? Big/small companies? What sector?
  - pjmlp 9y ago
    Education, Research (CERN), Shipping (Harbour IT), Telecommunications (CRM, Mobile Operators, OEMs), Life Sciences, Manufacturing. Mostly enterprise size companies.
watwut 9y ago
I had great managers who did not coded and had respect. They managed politics out of department, managed to find good trade off between autonomy and controll, made decisions where the team could not.
tootie 9y ago
I'm currently managing projects on tech stacks I have no experience with. It's definitely a handicap but I can still do 90% of my job pretty effectively. I just felt on my team more. One big thing I've learned is the manager should never take on big pieces of development. The other demands on your time mean that every task will take longer and you'll end up being a bottleneck.
xborns 9y ago
Actually I somewhat disagree with that. I think they should code to some extent, but it doesn't scale in my experience. I lean to say #7 is a good point. If the manager is required to complete the feature their "free" time is't the same as an engineer - read meetings/discussions. I manage two teams and when I first became a manager my instinct was to take tickets along with the team. Yet my other responsibilities came in play and made it harder for me to finish tickets I assigned to myself and others on the team waited. I still code review and partake in high level design and some scripts here or there etc. but not mainline code that another engineer will depend on to be completed by xyz date. The goal of a manager is to ensure the work pipeline and project trajectory are on path with the company needs while still taking time to learn new tech and skill-sets of the team. Of course most importantly protecting their time from distractions. To move from manager upwards, building a great team that trusts each other and follows and ensures the team standards is crucial. If I am required for every decision or code review, then I become the bottleneck. Empowering other people and trusting their judgement was one of the harder leanings growing from manager upward.
ransom1538 9y ago
Couldn't agree more. Engineering managers that have removed themselves from the ability to contribute will also lose touch with: design, build systems, architecture, qa, etc. At that point they are just a bad PM. When I was a vp eng. what helped me the most was having ONE feature that I owned. I was forced to use the build system, go through qa, fight with design. It was never something massive, or hindered other groups, but if someone on the team bitched: "this framework sucks because.." -- I was able to jump in.
curun1r 9y ago
It's not that you don't code...you need to code to stay relevant. It's that you shouldn't code serious production features/issues. As a manager, you're context switching constantly and it's very difficult to achieve the necessary quality. You'll never get the uninterrupted time necessary to do anything big. 5-10 min fixes are good targets for a manager, as are projects that would otherwise distract the team, like spikes on potential new technology. You should use your coding to further your overall goal of keeping your team focused and you should limit your coding so that all the major accomplishments of the team belong to the team members and not the manager.

manojlds 9y ago

Where does it tell to not code?

mpweiher 9y ago
In fact: "You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end." Just not "Personally fix bugs and ship features."

endymi0n 9y ago

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.

watwut 9y ago
Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
- valuearb 9y ago
  Why did you code it that way? How hard is it to answer that question?
  - NortySpock 9y ago
    "It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
    - mncharity 9y ago
      > I still need to apologise for that one. Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for? The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?
- sanderjd 9y ago
  It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.
  - Spooky23 9y ago

didibus 9y ago

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.

freekh 9y ago
Second this a lot. In fact I am gonna steel exactly this and feed it back to my org

kayoone 9y ago

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.

kochthesecond 9y ago
I recently quit a job where I was in practice the tech lead. I did probably 60% code reviews, and made sure the architecture as a whole kept moving towards a coherent view and quality. But it was boring as I don't particularly enjoy teaching new developers basics of coding production ready systems every few months, especially when tied down as a consultant for a government organization. I ultimately had very little to say in what tech we could deploy. I therefore decided to go somewhere I might get more freedom to build quality with a bit less politics.
TH3R3LL1K 9y ago
I'm currently working for a company where the our manager holds a tight grip against the code we write, but he doesn't seem to guide us in the correct direction.

samlittlewood 9y ago

A recipe for disaster is for a manager's code to wind up on the critical path, then become a blocker - bad code & bad management. A possibly better approach is for managers to have a few side proejcts, scouting out potential risk reducing things, at a higher temperature, away from the main project. Great if one of them lands - no added problems if not. Also, if they land in the project, they are no longer the responsibility of the manager.

pjmlp 9y ago

I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. Have good social skills and specially important, how to raise morale in darker times. Knowing to code is irrelevant.

kochthesecond 9y ago
I agree, having good social skills and being good at moving things forward (often in a political landscape) is more important than coding skills.
hoschicz 9y ago
Where have you worked during your 30 years of experience? Big/small companies? What sector?
- pjmlp 9y ago
  Education, Research (CERN), Shipping (Harbour IT), Telecommunications (CRM, Mobile Operators, OEMs), Life Sciences, Manufacturing. Mostly enterprise size companies.

watwut 9y ago

I had great managers who did not coded and had respect. They managed politics out of department, managed to find good trade off between autonomy and controll, made decisions where the team could not.

tootie 9y ago

I'm currently managing projects on tech stacks I have no experience with. It's definitely a handicap but I can still do 90% of my job pretty effectively. I just felt on my team more. One big thing I've learned is the manager should never take on big pieces of development. The other demands on your time mean that every task will take longer and you'll end up being a bottleneck.

xborns 9y ago

Actually I somewhat disagree with that. I think they should code to some extent, but it doesn't scale in my experience. I lean to say #7 is a good point. If the manager is required to complete the feature their "free" time is't the same as an engineer - read meetings/discussions. I manage two teams and when I first became a manager my instinct was to take tickets along with the team. Yet my other responsibilities came in play and made it harder for me to finish tickets I assigned to myself and others on the team waited. I still code review and partake in high level design and some scripts here or there etc. but not mainline code that another engineer will depend on to be completed by xyz date. The goal of a manager is to ensure the work pipeline and project trajectory are on path with the company needs while still taking time to learn new tech and skill-sets of the team. Of course most importantly protecting their time from distractions. To move from manager upwards, building a great team that trusts each other and follows and ensures the team standards is crucial. If I am required for every decision or code review, then I become the bottleneck. Empowering other people and trusting their judgement was one of the harder leanings growing from manager upward.

ransom1538 9y ago

Couldn't agree more. Engineering managers that have removed themselves from the ability to contribute will also lose touch with: design, build systems, architecture, qa, etc. At that point they are just a bad PM. When I was a vp eng. what helped me the most was having ONE feature that I owned. I was forced to use the build system, go through qa, fight with design. It was never something massive, or hindered other groups, but if someone on the team bitched: "this framework sucks because.." -- I was able to jump in.

curun1r 9y ago

It's not that you don't code...you need to code to stay relevant. It's that you shouldn't code serious production features/issues. As a manager, you're context switching constantly and it's very difficult to achieve the necessary quality. You'll never get the uninterrupted time necessary to do anything big. 5-10 min fixes are good targets for a manager, as are projects that would otherwise distract the team, like spikes on potential new technology. You should use your coding to further your overall goal of keeping your team focused and you should limit your coding so that all the major accomplishments of the team belong to the team members and not the manager.