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.
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.
I tried to do the same thing too. Here's what I learned.
The people who are "managers" are also splitting their time. They only need to spend maybe 20% of their time in actual supervisory work. The rest of their time is spent on tasks that are delegated to them by their higher-ups. These tasks are largely forms of information processing: Gathering, analyzing, and communicating. Excel and PowerPoint. But they are typically one-time tasks that are not worth automating.
I was happy with the 20% supervision, no problem. But the 80% information processing tasks just weren't interesting to me.
When they finally posted an opening for my old job, I went to the boss and asked: "What do you want me to be, a mediocre manager or a great engineer?" Oddly enough, moving me back to engineering resulted in a second promotion on top of the first. Meanwhile, I did enjoy receiving a fair amount of management training and insider understanding about how the business works.
>(least known and most annoying is managing UPwards)
Boy if that ain't the most true statement about moving from engineering into management, I don't know what is. I was so exceptionally bad and unprepared for this when I tried my hand at management.
I was on the same boat, went back to senior dev but found myself missing the leadership side of the job (improve engineering process, cross team architecture etc) so I'm moving to principal SWE which seems to be the sweet spot in my current company.
The amount of time management takes depends on the size of your team. I've done 80% engineering and 20% management with small teams for more than a decade of my career. It's not for everyone, certainly.
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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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."
I used to be dislike the idea of being an engineering manager and wanted to stay in the code. Interestingly enough, having children completely changed my perspective on management. Some important management skills - e.g. patience, delegation (babysitters!), investing in someone's overall productivity and long-term success (Schools! Extracurriculars! College!), prioritization (family comes first!), sometimes cleaning up after someone else's messes (with kids, literally!) - come from being a parent.
I'm half joking, but only half! I believe part of being a good engineering manager is having had hands-on software development experience so as to better keep a check on velocity, code quality, and overall tech decision-making. Much in the same way, I feel like I can be a good parent and can teach my kids how to process their world because I've lived it before.
Having a kid during my transition to management (in the absence of existing management) brought me to the exact same thought process, and it's a dead-on observation I live every day six years later. It becomes much less about the executional skill, and much more about the aspects you listed above. The skills involved in parenting and managing are one big feedback loop of sorts.
Having someone that can see the forest for the trees and chart/change course as a team is, additionally, crucial. It's just that, at home, it's not just me.
That is an interesting connection. I've always been interested in growing into an engineering manager, especially at places where there is a distinction between managers and leads. I've also always been enthusiastic about having kids (particularly compared to my same-age peers). I guess I just naturally value investing in other people's success and easing the path for people to learn lessons that I might have learned the hard way.
I wonder whether interest in / enjoyment of parenting is correlated with feeling likewise about people management.
I've noticed this as well. Running a home together with a partner, especially with children in the picture, is an organizational challenge not unlike any other. It involves a lot of listening, acting, planning, budgeting, and keeping calm in the face of (neverending) problems. When I show up to work, it's more of the same.
I always make sure I can still compile and execute the code. If I can't, I get someone to update the README files so that I can. That also helps me make sure new members can be onboarded.
I also do off-critical-path features and bug fixes. That said, I did write a fair bit of the code base before taking a more managerial role, and I contribute to discussions about what will make the thing faster.
Compiling and running your team's code could be the most powerful excercise to stay connected with the engineering part. Way too often I would discover that some functionality declared as 'done' cannot be demonstrated in any way, and such discoveries initiate discussions leading to meaningful decisions.
Yeah exactly. I see it as a form of QA. It's not serious if discovered early, but I've come across times when there was some new dependency I didn't have, forcing me to google how to install it. So then I tell the team and someone will update the docs.
Basically, if only the people who wrote something can compile/execute it, it isn't done.
I've worked in organizations that promoted engineers into management, rather than bringing in outside managers or managers without engineering backgrounds. For highly engineering-driven orgs this can make a lot of sense, and depending on how it's done and the people involved, it can produce great results.
However: when those managers hold on to their engineering responsibilities, their teams suffer for it. There's a negative stereotype among engineers that managers don't do anything anyway, so maybe the team just needs a designated engineer to play manager in order to go to meetings, approve days off, etc.- the bookkeeping parts of management, but not the managing parts of management. There's a perception that the other engineers on the team are super self sufficient, what do they need a manager for anyway?
Often these managers would be allowed to continue doing engineering as a motivator- they didn't really want to be managers in the first place, let's just let them keep doing their thing and throw some more money at them and everybody will be happy. But it really feels like an antipattern.
Working on different teams where managers didn't do any coding was a breath of fresh air. I didn't know what I was missing. Managers can do the most good by focusing on things that allow their engineers to be as focused on their work as possible, and as unblocked and undistracted as possible. It makes a huge difference. It doesn't matter how incredibly self-sufficient an engineer is...if they get stuck doing a bunch of extra non-engineering stuff because their manager doesn't manage, their work and happiness will suffer for it.
So, at least based on my own experiences, I've come to see teams where the manager still has engineering responsibilities on their own team as a red flag. Anecdotal and highly contextual to where I've worked, but that's been my experience.
I've talked with several companies in the past 6-8 months where this tenure-based model of elevating engineers to management positions has broken down quite a bit.
What generally happens is, once in management, they end up on a track of being more business-facing and the breadth of their role continues to expand (while reducing hands-on code time) to the point where the organization has to relent and hire from the outside anyhow when the promoted manager finally admits they'd have rather remained hands-on.
I try to identify engineers on my team with an interest and early aptitude for management early-on, and mentor in that direction while mentoring those who wish to remain hands-on in the other. I always need a right-hand person to handle the higher-order organizational aspects while I'm away, and likewise, I need a left-hand person to lead the day to day technical execution. So usually I'm not lacking for support while at the same time elevating them to the next level (and without needing to hire someone from the outside).
Can you provide specific examples of things that you found the most useful when you finally had a full-time/non-coding manager? Having somewhat recently transitioned into an engineering management role, I'm curious if there's anything (or situation) in particular you'd highlight.
This is all in the context of large tech companies, so YMMV. Things like, going to high level meetings so engineers don't have to, and making an effort to keep engineers from getting sucked in to too many meetings period (at least, ones where their presence isn't critical).
Helping with bug management and task prioritization, minimizing engineers' multitasking to maximize productivity, and guiding the team towards long term goals. Engineers tend to be super focused on their immediate and short term tasks- what they're supposed to be doing right now. That can make it hard for a team to collectively maintain trajectories towards long term goals over the course of months and years. IMO a good manager will be the ultimate maintainer of the long term goals, and can helpfully keep everyone on track as they individually focus on shorter term stuff.
Also, enabling their engineers' professional development. Many engineers really thrive when they're tasked with something that involves learning and using some technology that they don't know, but are curious and excited about. As much as possible, if it aligns with team goals of course, it's great if people get a steady trickle of these kinds of tasks. Only if they'd want them, of course. It feeds their curiosity and creativity, and helps the whole team keep their technical edge. But these things are unlikely to happen unless the manager picks up on the interest and potential, and explicitly tasks someone to do it.
Finally, it might sound silly, but making a point to do pleasant team building stuff like bringing in bagels or donuts for everyone once in a while, or having the occasional team lunch at a cool restaurant (assuming there are cool places nearby). Also t-shirts. :) Quality t-shirts provide a surprising amount of bang for the buck in terms of goodwill, at least in large tech companies.
We don't let managers code where I work. We also don't let them do anything technical besides match employees to work they want to do. Your manager is just there to make sure you can focus as much as your time as possible being productive.
I really like this approach, it's extremely bottom up. It's not that I think our managers don't have technical skills. They all have impressive backgrounds as SWEs etc, but this setup is for the best. The alternative at other companies I've worked for ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions, and managers who intertwined their management success with the product and drove it to ruin because they weren't making the best technical decisions for the product.
So please, if you're a manager, stop coding. Manage people, unblock them, make sure they are happy. Empower them to do the coding for you.
"...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"
There's a connection here. A technical manager can't make reasonable tech decisions unless they do some tech work, but perhaps we just need to be more clear that what you want is a pure project manager to check off boxes.
I think a good tech manager still respects a bottom up approach most of the time, but should have enough experience to push back when the group is steering in the wrong direction. A generic project manager isn't going to do that.
I've had a primarily technical career so far and am working on switching to engineering management in the foreseeable future.
Once I'm done with that switch, I don't want to be frequently making technical decisions, rational or otherwise - that should be the job of the tech lead on my team, with input from everyone else.
I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say. I'll also need my team to respect my credibility enough to know that I relate to what they're dealing with, and to be able to effectively keep them unblocked.
But none of this requires sustaining continued technical contributions within my day job past the initial transition period, at least not once the company is above a certain size.
One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.
When have you ever heard of a large org making a re-org to solve real problems after substantial consultation and with anything close to universal buy-in? She managed that, and well enough that she correctly used arguments from the rank and file to explain the re-org to other parts of the company.
That's the kind of mentor I'll want to learn from as a manager.
That leads exactly to the situation you described below.
> "...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"
I recently left my job at a respected social network over my new manager lacking the proper technical skills yet not accepting more reasonable solutions.
Case in point: imagine you have an API endpoint you normally hit with your service, periodically. We make a GET request to this endpoint but it also supports POST. The parameter sent is q=<some_long_string>.
It comes to my attention that this long string can get over 1MB long, at which point it causes issues with our service.
I bring up in a meeting that we should just POST to this endpoint instead of doing GET at all times because the data could be larger than 1MB at times. Makes sense, right? Well, my manager without the proper technical awareness basically pushed for us to check if the query is larger than 1MB and POST if and only if it is larger than 1MB.
I gave my two weeks a week after that and made it very clear to the upper management that this manager was the reason I was leaving and I felt like I was being stifled by having a manager like this.
We don't want managers steering anything. That's either the job of the group or the tech lead. The manager is supposed to manage the team the same way a managers manages a baseball team. You get the right people, give them the right tools, and let them play the game.
The role of a project manager is to have someone who can represent the user. The project manager should be talking to users, soliciting product feedback, getting bugs filed, and feeding this to the team.
The role of a manager is to manage the people on the team. That means helping them grow their careers, help them switch teams if they find something that would be a better fit, promote the teams work, unblock people, give feedback on how team members are communicating, manage meetings and fill in for team members so they can spend more time coding that sitting in meetings.
Basically a people manager is like a boxing manager. He gets the champ into shape, puts him in to the ring, and cheers him on. When the champs not fighting he makes sure the champ can focus 100% on training.
Not a fan of this advice at all. My best managers were also fantastic engineers that actively contributed to the project. They were better at handling escalations, better at making technical decisions, got more respect from their reports, and were fantastic for team morale.
If you have a bad manager, it's not because they're coding, or too technical, it's because they aren't good managers. Good managers also know how to motivate, delegate, support, and lead. They know when to get their hands dirty, and when to let their teams fail and learn. And most importantly, they understand engineering tradeoffs, and when to make them.
Most top tech companies have very technical managers, and even though they're not always great, I'd take a random tech manager over a random non-tech one any day.
They're not supposed to make technical decisions. What you're talking about is one person wearing multiple hats. Sure, some people can do that. But the end goal is to have a manager that manages as his sole job. Getting your hands dirty is a bad thing. That means your spending that time doing technical work when you could be reducing friction for the team and promoting their work.
How big are your teams? This probably makes sense for a larger team where the person is less technical and more people focused. In most small companies, this would not cut it.
I worked with another team (6 people, 1 manager.) Their manager did NOT code and he was not well respected at all. It caused a ton of morale problems, complaints, etc.
That's about the maximum number of people a manager should be managing.
The biggest issue I see is managers who don't code making technical decisions. Like I said in my OP, managers are supposed to unblock people. The team or a tech lead should be making the technical decisions.
That makes sense too - as I see it depends a lot on how big the team is that an engineering manager works with, as well as if the team is a product or a platform team, among other factors.
Our teams have a hard size limit, after that we split and get a manager for the other team. If a manager is managing more than a handful of people, he can no longer give members the attention they need.
Fossilizations happen more so because companies treat manager as a promotion rather than a separate track for engineers who want to focus on people. You have managers who are used to solving problems with a skillset that's probably been outdated by the pace of technology, who no longer have the time to invest in keeping current since they're essentially wearing two hats now and they have more going on in their lives.
We have an EM who took on grunt work (but critical) so the team could focus on tasks on the charter of the team. Personally I really appreciated that because otherwise the team would have had to spend a few sprints doing the grunt work. His rationale was "You guys are doing great work and your momentum is great. I don't want this stuff to slow you guys down. I'll take it on" +100 for that attitude.
We have some managers that help in reproducing bugs. For me as a dev this is super valuable and saves me a lot of time I can spend on looking at the code.
I'm a CTO (of a company quite a bit smaller than Uber) and I do basically everything in this article.
One thing missed here (or that is out of scope of the article) which I think is actually very important is that engineering managers should get involved in QA. It's not glamorous but running through a couple of manual test scripts yourself gives you insight into features you might not know too well (if the product is very large) and also to personally assure yourself of the product's quality.
I find myself incrementally tweaking the QA test script every now and again when I do this, it's a great way to continuously improve the process.
I think people should be able to swing back and forth; manager for a year or two, engineer for a year or two. I don't believe everyone can be happy with a prescriptive path to follow -- I can't only be one or the other for the rest of my life. I like leading, mentoring, and developing teams. I also have strong inclinations towards inventing solutions and developing the future generation of technology.
I think businesses need to be able to adapt people to different roles and be comfortable moving people around and let them change over time. Otherwise we'll have people hopping off to new companies every few years as we tend to and taking all of their domain knowledge with them.
Readit News
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.
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.
The people who are "managers" are also splitting their time. They only need to spend maybe 20% of their time in actual supervisory work. The rest of their time is spent on tasks that are delegated to them by their higher-ups. These tasks are largely forms of information processing: Gathering, analyzing, and communicating. Excel and PowerPoint. But they are typically one-time tasks that are not worth automating.
I was happy with the 20% supervision, no problem. But the 80% information processing tasks just weren't interesting to me.
When they finally posted an opening for my old job, I went to the boss and asked: "What do you want me to be, a mediocre manager or a great engineer?" Oddly enough, moving me back to engineering resulted in a second promotion on top of the first. Meanwhile, I did enjoy receiving a fair amount of management training and insider understanding about how the business works.
Boy if that ain't the most true statement about moving from engineering into management, I don't know what is. I was so exceptionally bad and unprepared for this when I tried my hand at management.
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.
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.
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.
> 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.
One pattern that seems to work is to write the code if it's easier to explain it in code (& tests!) than in words.
That's a good rule of thumb too – haven't heard that before.
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.
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.
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."
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.
I'm half joking, but only half! I believe part of being a good engineering manager is having had hands-on software development experience so as to better keep a check on velocity, code quality, and overall tech decision-making. Much in the same way, I feel like I can be a good parent and can teach my kids how to process their world because I've lived it before.
Having someone that can see the forest for the trees and chart/change course as a team is, additionally, crucial. It's just that, at home, it's not just me.
I wonder whether interest in / enjoyment of parenting is correlated with feeling likewise about people management.
I also do off-critical-path features and bug fixes. That said, I did write a fair bit of the code base before taking a more managerial role, and I contribute to discussions about what will make the thing faster.
Basically, if only the people who wrote something can compile/execute it, it isn't done.
However: when those managers hold on to their engineering responsibilities, their teams suffer for it. There's a negative stereotype among engineers that managers don't do anything anyway, so maybe the team just needs a designated engineer to play manager in order to go to meetings, approve days off, etc.- the bookkeeping parts of management, but not the managing parts of management. There's a perception that the other engineers on the team are super self sufficient, what do they need a manager for anyway?
Often these managers would be allowed to continue doing engineering as a motivator- they didn't really want to be managers in the first place, let's just let them keep doing their thing and throw some more money at them and everybody will be happy. But it really feels like an antipattern.
Working on different teams where managers didn't do any coding was a breath of fresh air. I didn't know what I was missing. Managers can do the most good by focusing on things that allow their engineers to be as focused on their work as possible, and as unblocked and undistracted as possible. It makes a huge difference. It doesn't matter how incredibly self-sufficient an engineer is...if they get stuck doing a bunch of extra non-engineering stuff because their manager doesn't manage, their work and happiness will suffer for it.
So, at least based on my own experiences, I've come to see teams where the manager still has engineering responsibilities on their own team as a red flag. Anecdotal and highly contextual to where I've worked, but that's been my experience.
What generally happens is, once in management, they end up on a track of being more business-facing and the breadth of their role continues to expand (while reducing hands-on code time) to the point where the organization has to relent and hire from the outside anyhow when the promoted manager finally admits they'd have rather remained hands-on.
I try to identify engineers on my team with an interest and early aptitude for management early-on, and mentor in that direction while mentoring those who wish to remain hands-on in the other. I always need a right-hand person to handle the higher-order organizational aspects while I'm away, and likewise, I need a left-hand person to lead the day to day technical execution. So usually I'm not lacking for support while at the same time elevating them to the next level (and without needing to hire someone from the outside).
Helping with bug management and task prioritization, minimizing engineers' multitasking to maximize productivity, and guiding the team towards long term goals. Engineers tend to be super focused on their immediate and short term tasks- what they're supposed to be doing right now. That can make it hard for a team to collectively maintain trajectories towards long term goals over the course of months and years. IMO a good manager will be the ultimate maintainer of the long term goals, and can helpfully keep everyone on track as they individually focus on shorter term stuff.
Also, enabling their engineers' professional development. Many engineers really thrive when they're tasked with something that involves learning and using some technology that they don't know, but are curious and excited about. As much as possible, if it aligns with team goals of course, it's great if people get a steady trickle of these kinds of tasks. Only if they'd want them, of course. It feeds their curiosity and creativity, and helps the whole team keep their technical edge. But these things are unlikely to happen unless the manager picks up on the interest and potential, and explicitly tasks someone to do it.
Finally, it might sound silly, but making a point to do pleasant team building stuff like bringing in bagels or donuts for everyone once in a while, or having the occasional team lunch at a cool restaurant (assuming there are cool places nearby). Also t-shirts. :) Quality t-shirts provide a surprising amount of bang for the buck in terms of goodwill, at least in large tech companies.
I really like this approach, it's extremely bottom up. It's not that I think our managers don't have technical skills. They all have impressive backgrounds as SWEs etc, but this setup is for the best. The alternative at other companies I've worked for ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions, and managers who intertwined their management success with the product and drove it to ruin because they weren't making the best technical decisions for the product.
So please, if you're a manager, stop coding. Manage people, unblock them, make sure they are happy. Empower them to do the coding for you.
"...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"
There's a connection here. A technical manager can't make reasonable tech decisions unless they do some tech work, but perhaps we just need to be more clear that what you want is a pure project manager to check off boxes.
I think a good tech manager still respects a bottom up approach most of the time, but should have enough experience to push back when the group is steering in the wrong direction. A generic project manager isn't going to do that.
Once I'm done with that switch, I don't want to be frequently making technical decisions, rational or otherwise - that should be the job of the tech lead on my team, with input from everyone else.
I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say. I'll also need my team to respect my credibility enough to know that I relate to what they're dealing with, and to be able to effectively keep them unblocked.
But none of this requires sustaining continued technical contributions within my day job past the initial transition period, at least not once the company is above a certain size.
One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.
When have you ever heard of a large org making a re-org to solve real problems after substantial consultation and with anything close to universal buy-in? She managed that, and well enough that she correctly used arguments from the rank and file to explain the re-org to other parts of the company.
That's the kind of mentor I'll want to learn from as a manager.
That leads exactly to the situation you described below.
> "...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"
I recently left my job at a respected social network over my new manager lacking the proper technical skills yet not accepting more reasonable solutions.
Case in point: imagine you have an API endpoint you normally hit with your service, periodically. We make a GET request to this endpoint but it also supports POST. The parameter sent is q=<some_long_string>.
It comes to my attention that this long string can get over 1MB long, at which point it causes issues with our service.
I bring up in a meeting that we should just POST to this endpoint instead of doing GET at all times because the data could be larger than 1MB at times. Makes sense, right? Well, my manager without the proper technical awareness basically pushed for us to check if the query is larger than 1MB and POST if and only if it is larger than 1MB.
I gave my two weeks a week after that and made it very clear to the upper management that this manager was the reason I was leaving and I felt like I was being stifled by having a manager like this.
The role of a manager is to manage the people on the team. That means helping them grow their careers, help them switch teams if they find something that would be a better fit, promote the teams work, unblock people, give feedback on how team members are communicating, manage meetings and fill in for team members so they can spend more time coding that sitting in meetings.
Basically a people manager is like a boxing manager. He gets the champ into shape, puts him in to the ring, and cheers him on. When the champs not fighting he makes sure the champ can focus 100% on training.
Not a fan of this advice at all. My best managers were also fantastic engineers that actively contributed to the project. They were better at handling escalations, better at making technical decisions, got more respect from their reports, and were fantastic for team morale.
If you have a bad manager, it's not because they're coding, or too technical, it's because they aren't good managers. Good managers also know how to motivate, delegate, support, and lead. They know when to get their hands dirty, and when to let their teams fail and learn. And most importantly, they understand engineering tradeoffs, and when to make them.
Most top tech companies have very technical managers, and even though they're not always great, I'd take a random tech manager over a random non-tech one any day.
I worked with another team (6 people, 1 manager.) Their manager did NOT code and he was not well respected at all. It caused a ton of morale problems, complaints, etc.
The biggest issue I see is managers who don't code making technical decisions. Like I said in my OP, managers are supposed to unblock people. The team or a tech lead should be making the technical decisions.
There's lots of coding work that is easy to drop at a moment's notice and not mess up other work, schedules, etc.
Tooling is another one. Find processes that could use a nicer tool.
One thing missed here (or that is out of scope of the article) which I think is actually very important is that engineering managers should get involved in QA. It's not glamorous but running through a couple of manual test scripts yourself gives you insight into features you might not know too well (if the product is very large) and also to personally assure yourself of the product's quality.
I find myself incrementally tweaking the QA test script every now and again when I do this, it's a great way to continuously improve the process.
I think businesses need to be able to adapt people to different roles and be comfortable moving people around and let them change over time. Otherwise we'll have people hopping off to new companies every few years as we tend to and taking all of their domain knowledge with them.