> We both knew the reality: you can't be an effective Engineering Manager and spend 50% of your time in the codebase. The role demands full attention to your people, to strategy, to communication.
I take issue with the way this is posited as being obviously true…
Personal experience N=1 and all that, by my previous manager stepped up from engineer to manager and kept doing about 50% coding. Not only was it completely viable, but he did an even better job than our previous (also great) manager who was doing 0% coding.
Though it sounds like your company is even worse with meetings than ours was, so may legitimately not viable for you there. I still would have gone for Staff though as another commenter explained in detail.
Yep, It really depends on the company. I still code probably 75% of the time and have two devs report to me and a few contractors, so 1 on 1s, coaching, Work Day stuff, invoicing, etc.
I don't do a lot of meetings, probably an hour tops most days. Maybe that is the key?
I think the staff role varies a lot between companies- so take this with a grain of salt.
> Because I've been out of the daily coding game for three years. I know what I don't know. I need time to rebuild those muscles - to remember what it's like to be in the weeds of production incidents at 2am, to own features end-to-end, to debug race conditions that only show up under load.
I think you’ll find that your management skills transfer easily to the staff role. Staff, at least in my org, has a lot of cross over between management.
Maybe you are given a large ambiguous task and it’s up to you to solve it. You don’t have a team, but you can gather requirements- scope out the work and depending on timelines, you’ll get people assigned. Lots of project management aspects.
Or maybe a project already in progress is going off the rails and you get thrown in the mix to get things back on track. You need to identity why things aren’t going as expected. Is it scope creep? Was it bad estimates? Is the design not working out? Maybe the team just doesn’t have the necessary skills? These are all things that I would expect a staff engineer to be able to identify. It’s a nice option for leadership to be able to add a peer to an engineering manager into a team to get another viewpoint. It would certainly be awkward to add another EM to a team, but a staff can provide assistance without the awkwardness.
> And honestly? I want something to work toward over the next three years while my kids are young.
Well, I have young kids and I can’t say I disagree with you there. I’ve been on this horrible project the past 3 months and I’ve found myself daydreaming of going back to Senior - or just switching companies all together.
Anyways, staff role varies a lot. From my viewpoint if you are a half decent EM, then those skills should transfer just fine for you to be a half decent staff engineer.
I realize how crazy this looks at first glance, but have you considered paying people to work on your side projects for you? I have tried it and it is rewarding.
Most people I know who take on side projects do them because they enjoy solving problems. They find them enjoyable, and to many, side projects are like taking a vacation. I wouldn't pay someone to take a vacation for me, that's nonsensical and defeats the purpose of the vacation.
Why would you pay someone to do something you enjoy doing, so you don't have to do (any/some/all) of it? What kind of side projects are we talking about here?
In my case I wanted a particular piece of software that I had visualized. I found someone and agreed on a price, and provided what we needed to collaborate, and watched the progress. He accepted critical feedback and did a good job. That software has been adapted and ported to more platforms since. The effect was to compress my time and energy invested, and I paid with money earned from my full time job.
I’m still glad I did it. It’s okay to farm out the intensive work and savor the fun bits yourself. There are people waiting to do this for cash.
There are two sorts of projects (or in general, people): artisans, and entrepreneurs. The latter see code as a means to an end, possibly monetized, and the former see code as the end in itself.
I’ve gone the other way recently, from a senior programming position to management temporarily. Not just of developers but operations management.
I do miss the coding, the building of things and saying “I did that”.
But there is satisfaction to be gained from getting projects started, motivating people, planning and monitoring.
I didn’t enjoy laying off people after senior staff left before they could do it. Finding out your upper management were out of their depth and sinking the company was frightening.
Before you take that management promotion, be aware that everything you guessed about the C suite being incompetent boobs is likely true. And you’ll be expected to fix it.
> We both knew the reality: you can't be an effective Engineering Manager and spend 50% of your time in the codebase. The role demands full attention to your people, to strategy, to communication.
I take issue with the way this is posited as being obviously true…
Personal experience N=1 and all that, by my previous manager stepped up from engineer to manager and kept doing about 50% coding. Not only was it completely viable, but he did an even better job than our previous (also great) manager who was doing 0% coding.
Though it sounds like your company is even worse with meetings than ours was, so may legitimately not viable for you there. I still would have gone for Staff though as another commenter explained in detail.
Yep, It really depends on the company. I still code probably 75% of the time and have two devs report to me and a few contractors, so 1 on 1s, coaching, Work Day stuff, invoicing, etc.
I don't do a lot of meetings, probably an hour tops most days. Maybe that is the key?
I think the staff role varies a lot between companies- so take this with a grain of salt.
> Because I've been out of the daily coding game for three years. I know what I don't know. I need time to rebuild those muscles - to remember what it's like to be in the weeds of production incidents at 2am, to own features end-to-end, to debug race conditions that only show up under load.
I think you’ll find that your management skills transfer easily to the staff role. Staff, at least in my org, has a lot of cross over between management.
Maybe you are given a large ambiguous task and it’s up to you to solve it. You don’t have a team, but you can gather requirements- scope out the work and depending on timelines, you’ll get people assigned. Lots of project management aspects.
Or maybe a project already in progress is going off the rails and you get thrown in the mix to get things back on track. You need to identity why things aren’t going as expected. Is it scope creep? Was it bad estimates? Is the design not working out? Maybe the team just doesn’t have the necessary skills? These are all things that I would expect a staff engineer to be able to identify. It’s a nice option for leadership to be able to add a peer to an engineering manager into a team to get another viewpoint. It would certainly be awkward to add another EM to a team, but a staff can provide assistance without the awkwardness.
> And honestly? I want something to work toward over the next three years while my kids are young.
Well, I have young kids and I can’t say I disagree with you there. I’ve been on this horrible project the past 3 months and I’ve found myself daydreaming of going back to Senior - or just switching companies all together.
Anyways, staff role varies a lot. From my viewpoint if you are a half decent EM, then those skills should transfer just fine for you to be a half decent staff engineer.
I realize how crazy this looks at first glance, but have you considered paying people to work on your side projects for you? I have tried it and it is rewarding.
Most people I know who take on side projects do them because they enjoy solving problems. They find them enjoyable, and to many, side projects are like taking a vacation. I wouldn't pay someone to take a vacation for me, that's nonsensical and defeats the purpose of the vacation.
Why would you pay someone to do something you enjoy doing, so you don't have to do (any/some/all) of it? What kind of side projects are we talking about here?
In my case I wanted a particular piece of software that I had visualized. I found someone and agreed on a price, and provided what we needed to collaborate, and watched the progress. He accepted critical feedback and did a good job. That software has been adapted and ported to more platforms since. The effect was to compress my time and energy invested, and I paid with money earned from my full time job.
I’m still glad I did it. It’s okay to farm out the intensive work and savor the fun bits yourself. There are people waiting to do this for cash.
There are two sorts of projects (or in general, people): artisans, and entrepreneurs. The latter see code as a means to an end, possibly monetized, and the former see code as the end in itself.
I’ve gone the other way recently, from a senior programming position to management temporarily. Not just of developers but operations management.
I do miss the coding, the building of things and saying “I did that”.
But there is satisfaction to be gained from getting projects started, motivating people, planning and monitoring.
I didn’t enjoy laying off people after senior staff left before they could do it. Finding out your upper management were out of their depth and sinking the company was frightening.
Before you take that management promotion, be aware that everything you guessed about the C suite being incompetent boobs is likely true. And you’ll be expected to fix it.