7 ms·

The slow death of the hands-on engineering manager

100 points by Liriel 2y ago

deleted 2y ago
[deleted]
willvarfar 2y ago
Thinking of lots of EMs I've known or worked with who used to code, across quite a few companies, its really a factor of their tenure in role. At first a bright young engineer IC taking the EM track will try to keep being an engineer and keep coding. But with time they get bored with this and realise it has no correlation with how their manager measures their success etc, and they get over that fad and coast. YMMV.
- cube00 2y ago
  I used to think I had low quality EMs because they didn't have an IT background. However I started coming across EMs with IT backgrounds that had completely checked out of anything technical. They'd let their source control licence lapse giving them an excuse to not get involved in shutting down long running PR debates, suggest they can only get involved in a discussion if we were still using XYZ dead language/stack from two decades ago.
matsemann 2y ago
If you're not touching code you're not an engineering manager. You're a manager that happens to oversee engineers. I might be a bit jaded, but I don't feel like I've seen an implementation of EMs I actually feel work well, at least from an IC perspective. The EM often ends up being a mix of both tech lead and all HR stuff, being overworked and unavailable, or neglecting one of the tasks. I've actually preferred when my "EM" is on a different team than me. Can then speak freely to the person about issues in my team etc.
- ricardobeat 2y ago
  Your first statement certainly attracted some downvotes, but I can't disagree. Engineering Management is supposed to be a support role, working from the sidelines on enabling engineers to deliver, manage career progression, and sometimes help untangle actual technical problems - but not act as a tech lead. My experience echoes yours: EMs serving multiple teams can do that most effectively without the role getting muddled. It was meant to replace non-technical project management, and gives space for product to become a non-management role. If the EMs stop being technical, what's the point?
  - matsemann 2y ago
    I deserved the votes jo-jo-ing up and down, as I didn't manage to put my thoughts down as eloquently as you and it came out a bit harsh. Probably because of my recent bad experience before summer. I was tech lead at a small 3 dev team (including me). Then we got an EM assigned working full time in the team. Somehow nothing changed, I still did all the technical leadership, contributed code and talked with the stakeholders. While he was just always "busy" going to some meeting, and never could contribute. But those meetings didn't exist before he joined, and no one really knew where his time went or what he did, even had PMs asking me. And upper management expected more output now that we were one engineer more, and I had to explain I hadn't seen him work in weeks. Of course, this is a singular bad EM, but made me question the role even more. Not the first time I've seen EMs slowly fading, getting away with doing very little except busy work.
    - calderwoodra 2y ago
      A team of 3 doesn't need an EM. A team of 7 probably does.
- krisoft 2y ago
  > If you're not touching code you're not an engineering manager Surprise: Not all engineering is software engineering.
  - isaacremuant 2y ago
    The tweet article talks about writing code.
    - krisoft 2y ago
      Context doesn't make a false statement true.
      - matsemann 2y ago
        From the guidelines: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. So, yeah, the context should make it obvious what I'm referring to here.
tagyro 2y ago
As a leader/manager it is essential to spend your time on the right thing. Sometimes that might be coding, most of the time though, it is not. Mike Michalowicz's Clockwork has a really nice framework, called 4D: - Do - the least important type of action a leader can do and where they should spend as little time as possible - Decide - a level higher, but still not the core activity for leaders. Being the decision makes means that they have to be informed about everything. - Delegate - this is an important skill for leaders, assigning who is responsible for which outcome - Design - the most important type of action: designing the organization of the future and creating the right conditions for that organization to emerge; Put differently, this is truly working ON the business rather than IN the business.
- grecy 2y ago
  > Sometimes that might be coding, most of the time though, it is not. I agree 100%, though I will add it is important to have a manager who can do, so that at the very least they can have technical conversations. Nothing worse than a manager who has no concept of what the doing even is.
  - willvarfar 2y ago
    For a good IC it might feel important that the manager understands engineering and has domain knowledge, but for the organisation it is import that the manager understands engineering and has domain knowledge so they can work out which ICs are good.
- alxlaz 2y ago
  That's a cool conceptual framework but like all conceptual frameworks it's meant as a simple, immediate rule of thumb, not a theory of how engineering management works. In practice, the last three Ds depend heavily on familiarity with the first one, as they ultimately boil down to steering it at (team) scale. Without it, you're going to decide the wrong thing for what your team needs to do, delegate the wrong things to people who can't do them, and ultimately design an organisation that can't do shit. Actually doing it isn't the only way to attain that sort of familiarity but for lots of people it's the only one that works. For them it's anything but the least important type of action a leader can do. Once they stop doing it at all, the clock of knowledge obsolescence starts ticking and all the other Ds atrite, as they inevitably end up deciding, delegating and designing based on yesterday's realities.
nextworddev 2y ago
The trend is to cut down on these non hands on managers. If you are one of those, hold onto that job with dear life since they are disappearing
- carnewal 2y ago
  My experience: I lived every day in agony knowing there's nothing of value I'm contributing to this company and everyone around me knows. I was turbo depressed. If this is you I'd advise you to leave that job as soon as possible and take matter into your own hands. I became an individual contributor at a different company after being in this non-hands-on manager role for just about 2 years. What followed was a sense of accomplishment, being a happier person overall and earning way more money.
  - nextworddev 2y ago
    Agreed. Good on you to make that decision. If only the vast majority of other middle managers had that much integrity
    - Clubber 2y ago
      >If only the vast majority of other middle managers had that much integrity I would argue the vast majority of other middle managers can't code, so play manager is all they can do.
- Cumpiler69 2y ago
  >The trend is to cut down on these non hands on managers. If only. A lot of them have embedded themselves deeply in the org to make themselves feel indispensable to the upper echelons. So even though they are dispensable, as long as those at the top don't know that, they're not going anywhere.
  - nextworddev 2y ago
    I agree and let me explain that we are actually talking about the same thing. Basically senior managers are offering less senior managers as sacrifice to embed themselves deeper. But that shtick doesn’t last forever I can promise
submeta 2y ago
I am an IT project manager at a company with 750 employees. In my role, I coordinate various teams – both internal and external. My work requires me to quickly grasp complex IT systems and rapidly acquire domain knowledge. While programming is not part of my core responsibilities, my ability to write, deploy, and test code allows me to communicate effectively with engineers and better understand technical challenges. So yes, being able to work in terminal, to write code, to run it, play with it, to review code is very helpful for me.
woadwarrior01 2y ago
As a long time IC turned EM; in my experience non-technical EMs are alright, technical EMs are great, but pseudo-technical are the most dangerous both to the company and their direct reports. It's like the midwit meme, but in real life. Perhaps the belief is somewhat self serving, but I've seen dozens of examples of good non-technical EMs and good technical EMs, but never a good pseudo-technical EM. The pseudo-technical ones are so jaded with technical work that's palpable. Also, reminds me of the famous Elon Musk quote[1]: > Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse! [1]: https://x.com/elonmusk/status/1522609829553971200 https://x.com/elonmusk/status/1522609829553971200
- ricardobeat 2y ago
  "Non-technical EM" is an oxymoron and should have never existed. The role itself was meant to replace non-technical project managers with people who had a better grasp of the engineering challenges.
- blitzar 2y ago
  Now I want everyone to print out all the code they have worked on for the last month and bring it to my office for review.
- intelVISA 2y ago
  Wonder how far a corp borrowing USMC "everyone is a rifleman" but applied to tech would get We've such crazy margins that we can support too many "i'm not technical hehe" managers than should really be feasible
t43562 2y ago
I am a combination Tech Lead/Line Manager. I'm at a lower position than an Engineering Manager but the problems don't seem that different. I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. I need to know how difficult it's getting to write tests and get features done if I'm to make decisions about how to simplify everything for other developers. I have to understand what's possible. I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, we can't do this like this.....!!" So the decision part of management is just not possible without some time programming. I like to do refactoring - esp of tests and bits of code where I know that people have been in a rush and done a bit too much copy/pasting. I try to make log messages more useful, simplify things that I realise can be simplified. I write scripts to make annoying bits of work trivial so other developers have an easier time. I try to punch through problems with debugging or development. Some management tasks soak up energy: * hiring is one. I'm new to it and I am only beginning to have ideas about how to do it more efficiently. I wanted to get my team to help choose people but this ends up taking far too long to arrange. I realise I need to man up and do more of the initial choosing and present them with a limited choice at the end - I want people who will work well with everyone else. No arseholes, however good they might be. * helping people get their tickets done - which is good work and always worthwhile but to do it well you do need to understand the codebase a bit. * meetings about future features...which are incredibly inefficient because they're about getting everyone to understand what is wanted and trying to imagine an acceptably rapid way of doing it that will also fit in with other plans. This is very inefficient because people talk a great length then forget and have to understand it all again weeks later. On the other hand, doing work where everyone has a different understanding of what's needed is a deadly problem, so the horrendous hashing-things-out sessions generally pay off in the end. I just wish there was a better way.
- applied_heat 2y ago
  For your feature meetings the recipe for success is the same as any meetings, have an agenda and other materials people need to review before the meeting to be prepared to contribute without wasting everyone’s time, and take minutes and distribute them after the meeting, the minutes document the decisions made so they don’t need to be rehashed on the next meeting, and the minutes feed in to the preparation package for the next meeting. It is a lot of work to prepare these meetings and keep them on track, on the agenda items, so that the required decisions get made.
Insanity 2y ago
Here are my two cents. I understand that there are coding things which I could do as an EM. And I can find time for it if I want to. But .. at any given time when I want to I have to decide if it is the most important thing I can do with my time. Sadly, the answer usually is “no”. That did shift over time, I now manage teams maintaining three distinct products - and between managing the people and the products, setting the vision, dealing with customers.. there is just never any time for coding which isn’t taking away from the time I could better spent doing something else.
cheema33 2y ago
I was an engineering manager, but I am now more of a co-manager, because I suck at managing difficult engineers. Our business is small and we asked our product manager to help manage engineers too. She is not technical, but is great at managing people. I now write software, assign tasks, hire and sometimes fire people too. But I don't do the hard stuff of managing people, doing their reviews, encouraging and coaching them and giving them a shoulder to cry on. I know my limits. I love this arrangement. Sharing a role works well if you can find someone who is good at what you suck at.
- gabeidx 2y ago
  That sounds like more of a tech lead role than EM. Nothing wrong with that, it's good that you found a way to balance it. If you want to continue on the manager path, I'd suggest leaning into that area of weakness and trying to improve it as much as you can. At Director+ levels, these skills are non-negotiable.
bstar77 2y ago
This article is pretty on point with my experience. I'm a "senior technical" manager (of about 60 engineers) and with that comes a ton of responsibility that pulls me away from coding at every turn. I have to be in every call, I have to know everything that's going on and I have to be able to be able to communicate all of this in ways that advocate for the team but also navigate the politics of the organization. All that said, I often get criticism that I should not be picking up coding tasks every sprint. There seems to be some unwritten rule that remaining a coder is a net negative when you start tickling the upper management ranks. On the one hand I'm told that I need to train the other managers to be more like me and then on the other hand I'm told that I code too much, I'm going to burn out and need to find ways have others do the work. I personally think being able to do all kinds of coding tasks (prototyping, bug fixes, major time sensitive features, etc) does a lot for me as a manager... the team respects me, I stay close to the code so I can speak about it as well as anyone can and I can contribute to just about anything if the need arises. If I ever get promoted to Director level then I probably will have to step away from coding as an official duty, but I'll happily keep enjoying that part of my job for now.
- pnut 2y ago
  What is the source of work for these 60 people? Who is keeping them fed? That is beyond a full time job, and if your cup isn't full today, staying aligned with the product requirements and architectural implications, you need to let go and focus on that.
  - bstar77 2y ago
    I'm the senior manager, I have about 5 managers under me so I don't have 60 reportees.
- WesleyJohnson 2y ago
  60!? I struggle with ~10. Teach me, Yoda. On a more serious note, 100% agree. I'm asked to delegate more, but I don't want my skills to atrophy and, I'm happy when I'm coding. If I had to JUST manage, I wouldn't survive, figuratively speaking.
jweatherby 2y ago
Better than rolling out an AI to hopefully find the docs you're looking for, it would be better to create an actual framework for the docs. This would remove uncertainty about where docs live and improve discoverability to peruse as needed. AI and search is only as helpful as the content provided, and most applicable to those already familiar with the existing domain.
throw742809 2y ago
Throwaway because market is too bad to say the truth. Managers who code learn they are inviting political suicide. 1. Managers need to navigate office politics - a full time and full energy job. 2. Other teams will use lack of 8 hours of "coding output" as a weapon to prove that manager is not working. Putting more political pressure on them and their team.
ChrisMarshallNY 2y ago
I was a "first-line" manager, for over 25 years. I managed a small, high-functioning team of experienced and mature C++ image pipeline engineers. I chose not to go higher, because I felt that I was being most productive, where I was, and because, quite frankly, I didn't trust anyone else to do the job right (I still believe that this was a correct assumption). I had absolutely no stomach, whatsoever, for the political games, "above" my level, and was making enough to keep me satisfied. When I first became a manager, I continued to code, but, as time went on, I hired people who were better at it than I was (I was pretty good, but they were better), and also, I couldn't be reliable enough to be in a "critical path," so I worked on tools and experimental projects that didn't have deadlines. My managers did not want me coding. They actively discouraged me from it. Eventually, I stopped coding for the company (but kept coding on my own). I feel that continuing to code on my own, made me a much better manager. I think my bosses were dead wrong to discourage me from being technical. It was a cultural thing; not a practical one. I feel that "first-line" managers should still be very technical. Maybe they shouldn't have "critical path" responsibilities, but I believe that they should be absolutely conversant with the latest technologies and techniques, as well as be extremely sympathetic to the challenges faced by their employees. I believe that the rules are different for higher-level managers. BTW: I hated every minute of my work as a manager. I don't regret it, but I was glad to see the back of it.
isaacremuant 2y ago
Today in HN: catchy title to drive clicks to RAG tutorial. Tweet like quality.
throwaway984393 2y ago
[dead]
hiyer 2y ago
I've seen organizations go in the opposite direction now with the hands-off individual contributor. Their only job seems to be to attend meetings and pass on the minutes to others.
WesleyJohnson 2y ago
I feel more at home as a Senior Dev, or maybe a Tech Lead/Mentor, but here I am in management for the last 7 years. The article definitely resonates with me, as do many of the comments. I miss coding, deeply. I try to pick up the occasional project at work, but too often I have to turn it over due to lack of time. Sometimes I do not turn it over and it ends up taking far, far longer than it should have. I know I sometimes hold things too close to the chest. Delegating is not my strong suit but, in my mid 40's, I'm getting better. Whatever I'm doing, imposter syndrome be damned, seems to work. My team always look to me for help and plead with me to never leave; though I'm sure they'd find their way. I do find it difficult to keep up with all the projects going on at times, which complicates ongoing project discussions Especially when the developer isn't the best at communicating effectively and I need to be the liaison between them and upper management. Trying to keep up with all of that is really what limits my time as a developer. I was pleasantly surprised that the article linked a write-up on building an internal ChatBot. We're been looking at doing the same through Elastic AI but scratching that itch myself seems fun. I just wonder how long it'll be before I have to hand it over to someone else...
black_13 2y ago
[dead]

100 points by Liriel 2y ago

deleted 2y ago

[deleted]

Thinking of lots of EMs I've known or worked with who used to code, across quite a few companies, its really a factor of their tenure in role. At first a bright young engineer IC taking the EM track will try to keep being an engineer and keep coding. But with time they get bored with this and realise it has no correlation with how their manager measures their success etc, and they get over that fad and coast. YMMV.

cube00 2y ago
I used to think I had low quality EMs because they didn't have an IT background. However I started coming across EMs with IT backgrounds that had completely checked out of anything technical. They'd let their source control licence lapse giving them an excuse to not get involved in shutting down long running PR debates, suggest they can only get involved in a discussion if we were still using XYZ dead language/stack from two decades ago.

matsemann 2y ago

If you're not touching code you're not an engineering manager. You're a manager that happens to oversee engineers. I might be a bit jaded, but I don't feel like I've seen an implementation of EMs I actually feel work well, at least from an IC perspective. The EM often ends up being a mix of both tech lead and all HR stuff, being overworked and unavailable, or neglecting one of the tasks. I've actually preferred when my "EM" is on a different team than me. Can then speak freely to the person about issues in my team etc.

ricardobeat 2y ago
Your first statement certainly attracted some downvotes, but I can't disagree. Engineering Management is supposed to be a support role, working from the sidelines on enabling engineers to deliver, manage career progression, and sometimes help untangle actual technical problems - but not act as a tech lead. My experience echoes yours: EMs serving multiple teams can do that most effectively without the role getting muddled. It was meant to replace non-technical project management, and gives space for product to become a non-management role. If the EMs stop being technical, what's the point?
- matsemann 2y ago
  I deserved the votes jo-jo-ing up and down, as I didn't manage to put my thoughts down as eloquently as you and it came out a bit harsh. Probably because of my recent bad experience before summer. I was tech lead at a small 3 dev team (including me). Then we got an EM assigned working full time in the team. Somehow nothing changed, I still did all the technical leadership, contributed code and talked with the stakeholders. While he was just always "busy" going to some meeting, and never could contribute. But those meetings didn't exist before he joined, and no one really knew where his time went or what he did, even had PMs asking me. And upper management expected more output now that we were one engineer more, and I had to explain I hadn't seen him work in weeks. Of course, this is a singular bad EM, but made me question the role even more. Not the first time I've seen EMs slowly fading, getting away with doing very little except busy work.
  - calderwoodra 2y ago
    A team of 3 doesn't need an EM. A team of 7 probably does.
krisoft 2y ago
> If you're not touching code you're not an engineering manager Surprise: Not all engineering is software engineering.
- isaacremuant 2y ago
  The tweet article talks about writing code.
  - krisoft 2y ago
    Context doesn't make a false statement true.
    - matsemann 2y ago
      From the guidelines: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. So, yeah, the context should make it obvious what I'm referring to here.

tagyro 2y ago

As a leader/manager it is essential to spend your time on the right thing. Sometimes that might be coding, most of the time though, it is not. Mike Michalowicz's Clockwork has a really nice framework, called 4D: - Do - the least important type of action a leader can do and where they should spend as little time as possible - Decide - a level higher, but still not the core activity for leaders. Being the decision makes means that they have to be informed about everything. - Delegate - this is an important skill for leaders, assigning who is responsible for which outcome - Design - the most important type of action: designing the organization of the future and creating the right conditions for that organization to emerge; Put differently, this is truly working ON the business rather than IN the business.

grecy 2y ago
> Sometimes that might be coding, most of the time though, it is not. I agree 100%, though I will add it is important to have a manager who can do, so that at the very least they can have technical conversations. Nothing worse than a manager who has no concept of what the doing even is.
- willvarfar 2y ago
  For a good IC it might feel important that the manager understands engineering and has domain knowledge, but for the organisation it is import that the manager understands engineering and has domain knowledge so they can work out which ICs are good.
alxlaz 2y ago
That's a cool conceptual framework but like all conceptual frameworks it's meant as a simple, immediate rule of thumb, not a theory of how engineering management works. In practice, the last three Ds depend heavily on familiarity with the first one, as they ultimately boil down to steering it at (team) scale. Without it, you're going to decide the wrong thing for what your team needs to do, delegate the wrong things to people who can't do them, and ultimately design an organisation that can't do shit. Actually doing it isn't the only way to attain that sort of familiarity but for lots of people it's the only one that works. For them it's anything but the least important type of action a leader can do. Once they stop doing it at all, the clock of knowledge obsolescence starts ticking and all the other Ds atrite, as they inevitably end up deciding, delegating and designing based on yesterday's realities.

nextworddev 2y ago

The trend is to cut down on these non hands on managers. If you are one of those, hold onto that job with dear life since they are disappearing

carnewal 2y ago
My experience: I lived every day in agony knowing there's nothing of value I'm contributing to this company and everyone around me knows. I was turbo depressed. If this is you I'd advise you to leave that job as soon as possible and take matter into your own hands. I became an individual contributor at a different company after being in this non-hands-on manager role for just about 2 years. What followed was a sense of accomplishment, being a happier person overall and earning way more money.
- nextworddev 2y ago
  Agreed. Good on you to make that decision. If only the vast majority of other middle managers had that much integrity
  - Clubber 2y ago
    >If only the vast majority of other middle managers had that much integrity I would argue the vast majority of other middle managers can't code, so play manager is all they can do.
Cumpiler69 2y ago
>The trend is to cut down on these non hands on managers. If only. A lot of them have embedded themselves deeply in the org to make themselves feel indispensable to the upper echelons. So even though they are dispensable, as long as those at the top don't know that, they're not going anywhere.
- nextworddev 2y ago
  I agree and let me explain that we are actually talking about the same thing. Basically senior managers are offering less senior managers as sacrifice to embed themselves deeper. But that shtick doesn’t last forever I can promise

submeta 2y ago

I am an IT project manager at a company with 750 employees. In my role, I coordinate various teams – both internal and external. My work requires me to quickly grasp complex IT systems and rapidly acquire domain knowledge. While programming is not part of my core responsibilities, my ability to write, deploy, and test code allows me to communicate effectively with engineers and better understand technical challenges. So yes, being able to work in terminal, to write code, to run it, play with it, to review code is very helpful for me.

woadwarrior01 2y ago

As a long time IC turned EM; in my experience non-technical EMs are alright, technical EMs are great, but pseudo-technical are the most dangerous both to the company and their direct reports. It's like the midwit meme, but in real life. Perhaps the belief is somewhat self serving, but I've seen dozens of examples of good non-technical EMs and good technical EMs, but never a good pseudo-technical EM. The pseudo-technical ones are so jaded with technical work that's palpable. Also, reminds me of the famous Elon Musk quote[1]: > Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse! [1]: https://x.com/elonmusk/status/1522609829553971200 https://x.com/elonmusk/status/1522609829553971200

ricardobeat 2y ago
"Non-technical EM" is an oxymoron and should have never existed. The role itself was meant to replace non-technical project managers with people who had a better grasp of the engineering challenges.
blitzar 2y ago
Now I want everyone to print out all the code they have worked on for the last month and bring it to my office for review.
intelVISA 2y ago
Wonder how far a corp borrowing USMC "everyone is a rifleman" but applied to tech would get We've such crazy margins that we can support too many "i'm not technical hehe" managers than should really be feasible

t43562 2y ago

I am a combination Tech Lead/Line Manager. I'm at a lower position than an Engineering Manager but the problems don't seem that different. I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. I need to know how difficult it's getting to write tests and get features done if I'm to make decisions about how to simplify everything for other developers. I have to understand what's possible. I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, we can't do this like this.....!!" So the decision part of management is just not possible without some time programming. I like to do refactoring - esp of tests and bits of code where I know that people have been in a rush and done a bit too much copy/pasting. I try to make log messages more useful, simplify things that I realise can be simplified. I write scripts to make annoying bits of work trivial so other developers have an easier time. I try to punch through problems with debugging or development. Some management tasks soak up energy: * hiring is one. I'm new to it and I am only beginning to have ideas about how to do it more efficiently. I wanted to get my team to help choose people but this ends up taking far too long to arrange. I realise I need to man up and do more of the initial choosing and present them with a limited choice at the end - I want people who will work well with everyone else. No arseholes, however good they might be. * helping people get their tickets done - which is good work and always worthwhile but to do it well you do need to understand the codebase a bit. * meetings about future features...which are incredibly inefficient because they're about getting everyone to understand what is wanted and trying to imagine an acceptably rapid way of doing it that will also fit in with other plans. This is very inefficient because people talk a great length then forget and have to understand it all again weeks later. On the other hand, doing work where everyone has a different understanding of what's needed is a deadly problem, so the horrendous hashing-things-out sessions generally pay off in the end. I just wish there was a better way.

applied_heat 2y ago
For your feature meetings the recipe for success is the same as any meetings, have an agenda and other materials people need to review before the meeting to be prepared to contribute without wasting everyone’s time, and take minutes and distribute them after the meeting, the minutes document the decisions made so they don’t need to be rehashed on the next meeting, and the minutes feed in to the preparation package for the next meeting. It is a lot of work to prepare these meetings and keep them on track, on the agenda items, so that the required decisions get made.

Insanity 2y ago

Here are my two cents. I understand that there are coding things which I could do as an EM. And I can find time for it if I want to. But .. at any given time when I want to I have to decide if it is the most important thing I can do with my time. Sadly, the answer usually is “no”. That did shift over time, I now manage teams maintaining three distinct products - and between managing the people and the products, setting the vision, dealing with customers.. there is just never any time for coding which isn’t taking away from the time I could better spent doing something else.

cheema33 2y ago

I was an engineering manager, but I am now more of a co-manager, because I suck at managing difficult engineers. Our business is small and we asked our product manager to help manage engineers too. She is not technical, but is great at managing people. I now write software, assign tasks, hire and sometimes fire people too. But I don't do the hard stuff of managing people, doing their reviews, encouraging and coaching them and giving them a shoulder to cry on. I know my limits. I love this arrangement. Sharing a role works well if you can find someone who is good at what you suck at.

gabeidx 2y ago
That sounds like more of a tech lead role than EM. Nothing wrong with that, it's good that you found a way to balance it. If you want to continue on the manager path, I'd suggest leaning into that area of weakness and trying to improve it as much as you can. At Director+ levels, these skills are non-negotiable.

bstar77 2y ago

This article is pretty on point with my experience. I'm a "senior technical" manager (of about 60 engineers) and with that comes a ton of responsibility that pulls me away from coding at every turn. I have to be in every call, I have to know everything that's going on and I have to be able to be able to communicate all of this in ways that advocate for the team but also navigate the politics of the organization. All that said, I often get criticism that I should not be picking up coding tasks every sprint. There seems to be some unwritten rule that remaining a coder is a net negative when you start tickling the upper management ranks. On the one hand I'm told that I need to train the other managers to be more like me and then on the other hand I'm told that I code too much, I'm going to burn out and need to find ways have others do the work. I personally think being able to do all kinds of coding tasks (prototyping, bug fixes, major time sensitive features, etc) does a lot for me as a manager... the team respects me, I stay close to the code so I can speak about it as well as anyone can and I can contribute to just about anything if the need arises. If I ever get promoted to Director level then I probably will have to step away from coding as an official duty, but I'll happily keep enjoying that part of my job for now.

pnut 2y ago
What is the source of work for these 60 people? Who is keeping them fed? That is beyond a full time job, and if your cup isn't full today, staying aligned with the product requirements and architectural implications, you need to let go and focus on that.
- bstar77 2y ago
  I'm the senior manager, I have about 5 managers under me so I don't have 60 reportees.
WesleyJohnson 2y ago
60!? I struggle with ~10. Teach me, Yoda. On a more serious note, 100% agree. I'm asked to delegate more, but I don't want my skills to atrophy and, I'm happy when I'm coding. If I had to JUST manage, I wouldn't survive, figuratively speaking.

jweatherby 2y ago

Better than rolling out an AI to hopefully find the docs you're looking for, it would be better to create an actual framework for the docs. This would remove uncertainty about where docs live and improve discoverability to peruse as needed. AI and search is only as helpful as the content provided, and most applicable to those already familiar with the existing domain.

throw742809 2y ago

Throwaway because market is too bad to say the truth. Managers who code learn they are inviting political suicide. 1. Managers need to navigate office politics - a full time and full energy job. 2. Other teams will use lack of 8 hours of "coding output" as a weapon to prove that manager is not working. Putting more political pressure on them and their team.

ChrisMarshallNY 2y ago

I was a "first-line" manager, for over 25 years. I managed a small, high-functioning team of experienced and mature C++ image pipeline engineers. I chose not to go higher, because I felt that I was being most productive, where I was, and because, quite frankly, I didn't trust anyone else to do the job right (I still believe that this was a correct assumption). I had absolutely no stomach, whatsoever, for the political games, "above" my level, and was making enough to keep me satisfied. When I first became a manager, I continued to code, but, as time went on, I hired people who were better at it than I was (I was pretty good, but they were better), and also, I couldn't be reliable enough to be in a "critical path," so I worked on tools and experimental projects that didn't have deadlines. My managers did not want me coding. They actively discouraged me from it. Eventually, I stopped coding for the company (but kept coding on my own). I feel that continuing to code on my own, made me a much better manager. I think my bosses were dead wrong to discourage me from being technical. It was a cultural thing; not a practical one. I feel that "first-line" managers should still be very technical. Maybe they shouldn't have "critical path" responsibilities, but I believe that they should be absolutely conversant with the latest technologies and techniques, as well as be extremely sympathetic to the challenges faced by their employees. I believe that the rules are different for higher-level managers. BTW: I hated every minute of my work as a manager. I don't regret it, but I was glad to see the back of it.

isaacremuant 2y ago

Today in HN: catchy title to drive clicks to RAG tutorial. Tweet like quality.

throwaway984393 2y ago

[dead]

hiyer 2y ago

I've seen organizations go in the opposite direction now with the hands-off individual contributor. Their only job seems to be to attend meetings and pass on the minutes to others.

WesleyJohnson 2y ago

I feel more at home as a Senior Dev, or maybe a Tech Lead/Mentor, but here I am in management for the last 7 years. The article definitely resonates with me, as do many of the comments. I miss coding, deeply. I try to pick up the occasional project at work, but too often I have to turn it over due to lack of time. Sometimes I do not turn it over and it ends up taking far, far longer than it should have. I know I sometimes hold things too close to the chest. Delegating is not my strong suit but, in my mid 40's, I'm getting better. Whatever I'm doing, imposter syndrome be damned, seems to work. My team always look to me for help and plead with me to never leave; though I'm sure they'd find their way. I do find it difficult to keep up with all the projects going on at times, which complicates ongoing project discussions Especially when the developer isn't the best at communicating effectively and I need to be the liaison between them and upper management. Trying to keep up with all of that is really what limits my time as a developer. I was pleasantly surprised that the article linked a write-up on building an internal ChatBot. We're been looking at doing the same through Elastic AI but scratching that itch myself seems fun. I just wonder how long it'll be before I have to hand it over to someone else...

black_13 2y ago

[dead]