8 ms·

I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very diff

I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very different jobs with very different modes of working. As soon as you start taking on managerial work, your development productivity starts to fall rapidly. I've never found a happy medium, nor have I seen others achieve it. People who try to do both quickly settle on ~80% of one and ~20% of the other. Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it. As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path. Nobody wants to hold up a release because you were working on an important part of it and you've been constantly interrupted all week with managerial work and meetings. Instead, pick things that are either tiny or decoupled from the release process. Things like refactoring, non-critical bug fixes, documentation, tests, spikes. These are the kinds of things that won't fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again. As an engineering manager, you're interrupt-driven which is incredibly disruptive for focus. If you do write code, then it has to be the code that works within those constraints, or you'll end up being a blocker for the rest of the team and your managerial work will suffer as well.

nodefortytwo 8y ago
For me I have always found the best projects to work on are Developer Experience projects. In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i'm delayed it doesn't really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.
- jon-wood 8y ago
  This is exactly what I do, currently my main coding project at work is a library to improve our tracking of system level metrics across applications. If I get some time I can add a few more things that suddenly get tracked across multiple projects, making debugging easier in the future, and if I don't nobody really notices.
  - WrtCdEvrydy 8y ago
    If you can hook into one of your upstream, this becomes even easier. We call this the '@companynamespace' layer, includes wrappers for internal APIs, and additional sugar we use everywhere (AWS, status, metrics)
    - jon-wood 8y ago
      That's much what I'm doing, a standard set of utilities that any service can depend on and use without thinking too much about it.
- khalilravanna 8y ago
  Ditto on this. I've been doing this by doing things like updating our libraries to be more secure, implementing lazy-loading, speeding up our build times, etc. Things that all increase engineering productivity and happiness and simultaneously aren't necessarily things that would be prioritized to be worked on normally. And of course as you point out, they're all things that can be worked on without blocking anyone while I get pulled away from code for sometimes days at a time.
- basilgohar 8y ago
  I apologize for not having a lot to add, but I had to upvote and reply for this phrase alone: > make their lives easier (the (almost) entire point of being a manager) I am glad I am not alone in this, and sadly, I feel that way most of the time.
- hinkley 8y ago
  In a lot of organizations a Lead Dev is still a coder, but keeping an eye on the long game. Personally, I think that the sort of code you're talking about here is a big part of the mix of things that a Lead should be working on, or at least championing. You don't actually want these people to have too much code with their name on it for the same reason you don't want Managers to do it: It gets treated as a sacred cow whether you want it to or not. For myself, I'd estimate it's about a 40-40-20 split between DevEx code, the most safety-critical functions in libraries, and example code respectively. But, I'd aspire to flip the last two numbers (on a high functioning team I should be able to trust other people to do bits I barely trust myself to get right). And unless you enjoy bottlenecks (some people do because it makes them feel special), you should be trying to get most of the code written by people of average skill (the peak of your employee bell curve). So if I'm writing even half as much code as they are, things aren't going well at all. You want a light touch.
  - ArcticCelt 8y ago
    >DevEx code I am trying to understand the meaning of this word through context and/or through Google but I only get some social media platform. What is DevEx.
    - JimDabell 8y ago
      Developer experience. In other words, improving the tools your developers rely upon to do their job. It's like UX, but for the development process.
      - walshemj 8y ago
        IBM called this role the toolsmith in a chief programmer team, a 1970's development paradime. I have worked in an early web dev team that sort of worked like that at BT I was the backup/toolsmith.
        hinkley 8y ago
        Ive been called a toolsmith before, but I fear that label misses the mark. I do what I consider to be the barest minimum of user studies (approximately what I don’t think my boss will notice) and I don’t observe others putting half as much effort or empathy into it as I do. I don’t know if I’m crazy or living in the future, but it’s definitely frustrating and a little alienating.
- ojn 8y ago
  As others, I 100% agree with this and it's what I've also been focusing on as a manager. Someone told me: Once you have 10 people on your team, if you spend 100% time coding, you increase amount of coding by 10%. Instead, either spend time finding that next hire (increase by 10%), or work on other things that improves the team's productivity even more. For me, the hard part is when the team size is ~5-8 people. Too big for me to be 80% technical, but usually not quite such that managing is 80% either. This is when it's easy to sign up for critical tasks and get interrupted due to manager stuff, and as a result work 160% total. Once the team grows it usually gets easier.
shados 8y ago
> Instead, pick things that are either tiny or decoupled from the release process Totally agree. What I've seen work is when engineering managers work on non-critical (but high impact) improvements, on initial prototypes (so that they can have a good idea of challenges when they allocate resources), bug fixes, getting involved in outage remediation, etc.
deanCommie 8y ago
Agreed with everything you said, and will add 2 major points: 1) God help you if you choose 80% coding and 20% management. Your team will be very unhappy. Maybe you'll take care of the HR/Admin work that noone else can, but their career growth will stagnate, and morale will be low. 2) If you do pick 80% management, and 20% engineering, understand that your growth as an engineer will completely plateau. Yes, you can still participate in design reviews, even weigh in on code reviews, and ship the occasional bug fix/perf improvement/nice-to-have feature or some operational tool that will save your team a bunch of time and make your oncall happy. But without hands on struggle with a new paradigm or scaling challenge, you won't grow. And given the choice between improving as a manager or improving as a hands on techie, you have to make the choice to work to improve as a manager, and start doing all the invisible things you never realized a manager does (least known and most annoying is managing UPwards) SOURCE: Just spent a year stepping into a vacant engineering manager role on my team, tried to do the 80-20, didn't love the management role, am back to a full time senior engineer, and am frustrated with my skills that appear to have atrophied.
- cyrux004 8y ago
  what kind of managing do you do ? I dont spend more than 1 hour a week with my manager, so I am not sure where your time goes ?
  - lbotos 8y ago
    Current Manager. It's "Support Engineering" but currently: - Metrics for the business to understand what our pain points are - 1:1 Prep and post 1:1 vision planning ("Is everyone aligned?") - Performance review prep (time of year) - Chasing down other managers to try and get problems fixed that were surfaced in 1:1s - a "net" above the team, to filter out any business side bs that would go their way that would be a distraction. (The team has to trust that I have their best interest in mind. That's why a net, I let them know, and they can see) - Capacity Planning (Do we have enough people for the growth plan? Oh, did the growth plan get updated? Lemme take another look...) - Hiring - Reviewing Resumes - Are our policies up to date? - Process thinking (usually surfaced by pain points from 1:1s) It's a lot of meta thinking
kemiller2002 8y ago
This is ultimately drove me to leave my last job. The company believed the word "manager" meant, "do everything that needs to be done." You're the senior developer? We need this fixed. No, I'm the manager. I manage people. What about the project? You're going to run it right? Is the project a person? No. What was really sad is that I had to abandon the management portion to do everything else. They were completely dumbfounded as to why there was no professional development going on in the entire company.
ultrasaurus 8y ago
It's been interesting to watch how we handle it here at Sentry (75 people) -- my manager, the CEO, still codes every day and a lot of it is non-trivial: https://github.com/getsentry/sentry/graphs/contributors https://github.com/getsentry/sentry/graphs/contributors One pattern that seems to work is to write the code if it's easier to explain it in code (& tests!) than in words.
- awad 8y ago
  To be honest, as a customer, this terrifies me if I take you at face value re: 'codes every day'
  - marsrover 8y ago
    Why?
  - ultrasaurus 8y ago
    FWIW: as the head of product, I code a few times a week but mine is all sample code for our customers or demos. We are a developer focused company so your mileage may vary.
- JimDabell 8y ago
  That's interesting! I think he's definitely an outlier though. He must have a good executive team under him to lean on so that he can focus some time every day on development. That's a good rule of thumb too – haven't heard that before.
pmart123 8y ago
This is very well said. Do you think when a manager jumps into critical parts of the codebase, it also causes an over-reliance on that person? i.e. Something is behind, the manager takes the wheel, and finishes it off over the weekend due to their experience. Now, the junior developers feel like they "don't own" that component?
- JimDabell 8y ago
  I've seen similar things happen, where there are certain areas that can only be worked on by the lead dev / manager because it's complicated and undocumented. It's usually because the codebase started out as a one-man job and the developer stuck with the company long enough to go into management but never got the code into a good enough state for others to work on it effectively. It's a business risk in lots of ways, including causing morale issues as you suggest. I think a lot of developers who become more senior also really struggle with delegation. We're that used to dealing with every tiny detail that taking our hands off the wheel feels unnatural. We're that used to solving technical problems, that when somebody has a technical problem, our instinct is to solve the problem for them instead of pointing them in the right direction so they can solve it for themselves. But that doesn't scale and doesn't help more junior developers grow. Teach a man to fish and all that.
rukuu001 8y ago
Ay, I'm just discovering this now. It's hard to give up my identity as a dev. Especially since I've been working as a solo freelance dev and moving into managing teams feels like I'm leaving my main monetizable skill behind.
augbog 8y ago
Thank you so much for talking about critical path -- I think that is the biggest takeaway. As someone who had a manager who was very hands on... it was frustrating. The code he wrote was brilliant, but it was hard to review against him. Furthermore, when bugs came up, it was always "hey guys I don't have time for it, please fix it."
kingkongjaffa 8y ago
For those who don't know a wonderful resource for this is https://www.manager-tools.com/ https://www.manager-tools.com/

nodefortytwo 8y ago

For me I have always found the best projects to work on are Developer Experience projects. In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i'm delayed it doesn't really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.

jon-wood 8y ago
This is exactly what I do, currently my main coding project at work is a library to improve our tracking of system level metrics across applications. If I get some time I can add a few more things that suddenly get tracked across multiple projects, making debugging easier in the future, and if I don't nobody really notices.
- WrtCdEvrydy 8y ago
  If you can hook into one of your upstream, this becomes even easier. We call this the '@companynamespace' layer, includes wrappers for internal APIs, and additional sugar we use everywhere (AWS, status, metrics)
  - jon-wood 8y ago
    That's much what I'm doing, a standard set of utilities that any service can depend on and use without thinking too much about it.
khalilravanna 8y ago
Ditto on this. I've been doing this by doing things like updating our libraries to be more secure, implementing lazy-loading, speeding up our build times, etc. Things that all increase engineering productivity and happiness and simultaneously aren't necessarily things that would be prioritized to be worked on normally. And of course as you point out, they're all things that can be worked on without blocking anyone while I get pulled away from code for sometimes days at a time.
basilgohar 8y ago
I apologize for not having a lot to add, but I had to upvote and reply for this phrase alone: > make their lives easier (the (almost) entire point of being a manager) I am glad I am not alone in this, and sadly, I feel that way most of the time.
hinkley 8y ago
In a lot of organizations a Lead Dev is still a coder, but keeping an eye on the long game. Personally, I think that the sort of code you're talking about here is a big part of the mix of things that a Lead should be working on, or at least championing. You don't actually want these people to have too much code with their name on it for the same reason you don't want Managers to do it: It gets treated as a sacred cow whether you want it to or not. For myself, I'd estimate it's about a 40-40-20 split between DevEx code, the most safety-critical functions in libraries, and example code respectively. But, I'd aspire to flip the last two numbers (on a high functioning team I should be able to trust other people to do bits I barely trust myself to get right). And unless you enjoy bottlenecks (some people do because it makes them feel special), you should be trying to get most of the code written by people of average skill (the peak of your employee bell curve). So if I'm writing even half as much code as they are, things aren't going well at all. You want a light touch.
- ArcticCelt 8y ago
  >DevEx code I am trying to understand the meaning of this word through context and/or through Google but I only get some social media platform. What is DevEx.
  - JimDabell 8y ago
    Developer experience. In other words, improving the tools your developers rely upon to do their job. It's like UX, but for the development process.
    - walshemj 8y ago
      IBM called this role the toolsmith in a chief programmer team, a 1970's development paradime. I have worked in an early web dev team that sort of worked like that at BT I was the backup/toolsmith.
      - hinkley 8y ago
        Ive been called a toolsmith before, but I fear that label misses the mark. I do what I consider to be the barest minimum of user studies (approximately what I don’t think my boss will notice) and I don’t observe others putting half as much effort or empathy into it as I do. I don’t know if I’m crazy or living in the future, but it’s definitely frustrating and a little alienating.
ojn 8y ago
As others, I 100% agree with this and it's what I've also been focusing on as a manager. Someone told me: Once you have 10 people on your team, if you spend 100% time coding, you increase amount of coding by 10%. Instead, either spend time finding that next hire (increase by 10%), or work on other things that improves the team's productivity even more. For me, the hard part is when the team size is ~5-8 people. Too big for me to be 80% technical, but usually not quite such that managing is 80% either. This is when it's easy to sign up for critical tasks and get interrupted due to manager stuff, and as a result work 160% total. Once the team grows it usually gets easier.

shados 8y ago

> Instead, pick things that are either tiny or decoupled from the release process Totally agree. What I've seen work is when engineering managers work on non-critical (but high impact) improvements, on initial prototypes (so that they can have a good idea of challenges when they allocate resources), bug fixes, getting involved in outage remediation, etc.

deanCommie 8y ago

Agreed with everything you said, and will add 2 major points: 1) God help you if you choose 80% coding and 20% management. Your team will be very unhappy. Maybe you'll take care of the HR/Admin work that noone else can, but their career growth will stagnate, and morale will be low. 2) If you do pick 80% management, and 20% engineering, understand that your growth as an engineer will completely plateau. Yes, you can still participate in design reviews, even weigh in on code reviews, and ship the occasional bug fix/perf improvement/nice-to-have feature or some operational tool that will save your team a bunch of time and make your oncall happy. But without hands on struggle with a new paradigm or scaling challenge, you won't grow. And given the choice between improving as a manager or improving as a hands on techie, you have to make the choice to work to improve as a manager, and start doing all the invisible things you never realized a manager does (least known and most annoying is managing UPwards) SOURCE: Just spent a year stepping into a vacant engineering manager role on my team, tried to do the 80-20, didn't love the management role, am back to a full time senior engineer, and am frustrated with my skills that appear to have atrophied.

cyrux004 8y ago
what kind of managing do you do ? I dont spend more than 1 hour a week with my manager, so I am not sure where your time goes ?
- lbotos 8y ago
  Current Manager. It's "Support Engineering" but currently: - Metrics for the business to understand what our pain points are - 1:1 Prep and post 1:1 vision planning ("Is everyone aligned?") - Performance review prep (time of year) - Chasing down other managers to try and get problems fixed that were surfaced in 1:1s - a "net" above the team, to filter out any business side bs that would go their way that would be a distraction. (The team has to trust that I have their best interest in mind. That's why a net, I let them know, and they can see) - Capacity Planning (Do we have enough people for the growth plan? Oh, did the growth plan get updated? Lemme take another look...) - Hiring - Reviewing Resumes - Are our policies up to date? - Process thinking (usually surfaced by pain points from 1:1s) It's a lot of meta thinking

kemiller2002 8y ago

This is ultimately drove me to leave my last job. The company believed the word "manager" meant, "do everything that needs to be done." You're the senior developer? We need this fixed. No, I'm the manager. I manage people. What about the project? You're going to run it right? Is the project a person? No. What was really sad is that I had to abandon the management portion to do everything else. They were completely dumbfounded as to why there was no professional development going on in the entire company.

ultrasaurus 8y ago

It's been interesting to watch how we handle it here at Sentry (75 people) -- my manager, the CEO, still codes every day and a lot of it is non-trivial: https://github.com/getsentry/sentry/graphs/contributors https://github.com/getsentry/sentry/graphs/contributors One pattern that seems to work is to write the code if it's easier to explain it in code (& tests!) than in words.

awad 8y ago
To be honest, as a customer, this terrifies me if I take you at face value re: 'codes every day'
- marsrover 8y ago
  Why?
- ultrasaurus 8y ago
  FWIW: as the head of product, I code a few times a week but mine is all sample code for our customers or demos. We are a developer focused company so your mileage may vary.
JimDabell 8y ago
That's interesting! I think he's definitely an outlier though. He must have a good executive team under him to lean on so that he can focus some time every day on development. That's a good rule of thumb too – haven't heard that before.

pmart123 8y ago

This is very well said. Do you think when a manager jumps into critical parts of the codebase, it also causes an over-reliance on that person? i.e. Something is behind, the manager takes the wheel, and finishes it off over the weekend due to their experience. Now, the junior developers feel like they "don't own" that component?

JimDabell 8y ago
I've seen similar things happen, where there are certain areas that can only be worked on by the lead dev / manager because it's complicated and undocumented. It's usually because the codebase started out as a one-man job and the developer stuck with the company long enough to go into management but never got the code into a good enough state for others to work on it effectively. It's a business risk in lots of ways, including causing morale issues as you suggest. I think a lot of developers who become more senior also really struggle with delegation. We're that used to dealing with every tiny detail that taking our hands off the wheel feels unnatural. We're that used to solving technical problems, that when somebody has a technical problem, our instinct is to solve the problem for them instead of pointing them in the right direction so they can solve it for themselves. But that doesn't scale and doesn't help more junior developers grow. Teach a man to fish and all that.

rukuu001 8y ago

Ay, I'm just discovering this now. It's hard to give up my identity as a dev. Especially since I've been working as a solo freelance dev and moving into managing teams feels like I'm leaving my main monetizable skill behind.

augbog 8y ago

Thank you so much for talking about critical path -- I think that is the biggest takeaway. As someone who had a manager who was very hands on... it was frustrating. The code he wrote was brilliant, but it was hard to review against him. Furthermore, when bugs came up, it was always "hey guys I don't have time for it, please fix it."

kingkongjaffa 8y ago

For those who don't know a wonderful resource for this is https://www.manager-tools.com/ https://www.manager-tools.com/