19 ms·

Coding as an Engineering Manager

307 points by gergelyke 8y ago

Waterluvian 8y ago
I really like the "work on bugfixes and small features". 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.
- maxxxxx 8y ago
  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.
  - gergelyke 8y ago
    Oh that's a great! Are you okay with me adding it to the article?
    - maxxxxx 8y ago
      Sure. The good thing about this is that they were often very good devs so their insights are really good.
- palakchokshi 8y ago
  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.
CardenB 8y ago
I find the bit about mentoring people outside your org interesting. I'm interested in mentorship myself. Does anyone know if there are actually rewarding mentorship programs on websites like meetup.com? Has anyone else done this?
- hodgesrm 8y ago
  Check with your local university or community college for mentoring opportunities. For example, the University of California at Davis has a senior design class in their computer science program. You can submit a proposal for a project; if it's accepted you become the mentor and work with the students a couple hours a week over 4 to 5 months. I did this last year and found it extremely rewarding. Edit: fixed typo
  - tudelo 8y ago
    Did you have to pay money to do this?
    - hodgesrm 8y ago
      No, it was more like just write a good proposal. There was a problem related to Swagger API specs that had been bugging me for a while, so I wrote it up and sent it in. I was delighted when it was accepted. I'm planning to submit another project this year. Working with students is fun. p.s., The class is ECS 193AB in case any folks living near Davis are interested.
- mkirklions 8y ago
  What do you have to offer? Im an ambitious person with credentials, but programming is not my day job and Ive made marketing mistakes on my popular website.
  - CardenB 8y ago
    Definitely technical mentorship- especially in robotics. Also great career advice for people starting out in their career (in university for CS or graduating soon/just graduated, picking between entry level offers) up to 2 years into career. Or grad school advice.
    - mkirklions 8y ago
      Id be looking for web programming and business savvy skills. Btw, Ive recently fell in-love with embedded systems. Ive built a dishwasher that sets your dinnertable. But the issue is the business, not the tech.
iaresee 8y ago
I like writing metrics-related code as an EM. It’s valuable for me to be able to understand our data that’s tracking our KRs and informing our KPIs. And I get to stay sharp on some frameworks we use here for surfacing metrics to the company.
gtsteve 8y ago
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.
- zandl 8y ago
  Totally agree on the QA side, you need to see first hand what’s coming out of your team to understand where your team is at.
bojo 8y ago
This article is pretty close to my own situation. I’ve found that the worst thing I can do is work on features that could potentially block everyone, and the best I can do is grease our code ecosystem by updating libraries, compiler versions, and low level code which doesn’t affect business logic.
segmondy 8y ago
I swing back and forth. I go for months without touching the code, then I go for months where I stay in touch. It's easy to think a code base is decent when you stay close to it. Diving into a new code and unfamiliar code base allows me to see how new engineers will approach the code base, what's the onboarding/setup docs? Is it automated? install.sh or containeriazed? Are there tests? FAQ? user documentation, maintenance document? architectural documentations? If I can jump in the code fast and get moving, it's great. If not, I know the team is slacking and I figure out why and cover that area. If pressed for time, then I might do the test/bugfixes cycle. I code multiple times a week at home, so I'm not really pressed to program at work
ilovecaching 8y ago
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.
- gergelyke 8y ago
  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.
  - ilovecaching 8y ago
    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.
    - seabrookmx 8y ago
      A lot of companies do not have the foresight or resources to simply split a team though. There's lots of way to organize teams as well. At previous companies we've organized yes around products, or around skillsets, for instance.
- jimejim 8y ago
  "We don't let managers code where I work." "...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.
lordnacho 8y ago
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.
- ansgri 8y ago
  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.
  - lordnacho 8y ago
    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.
azhenley 8y ago
As a new professor it seems I am supposed to act more like a manager and do less of the research/coding/data analysis myself. But I love to code! My goal is to keep a small project for myself that I work on when I don't have impending deadlines (basically never?).
purple_ducks 8y ago
> Work on Bug Fixes / Small Features With this, I disagree for 2 reasons: 1) If your devs had to prove themselves technically via hiring process and you didn't, then your technical chops are potentially not up to scratch and devs have to tolerate inferior noise. Ditto with architecture input. 2) The easiest fix isn't always correct. Not having day to day knowledge of the code base means you're more likely to implement something substandard.
mwfunk 8y ago
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.
- vanadium 8y ago
  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).
bwanab 8y ago
Exactly why I quit managing altogether. One can code or one can manage, but doing both means both are compromised.
agentultra 8y ago
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.
- timtyrrell 8y ago
  Great article on that here: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
- maxxxxx 8y ago
  I like the idea but in most companies the salary structure doesn't allow it.
alexchamberlain 8y ago
What do we mean by manager in this situation? Is the first level "team leader" a people manager that engineers, or are we talking higher level managers?
news_to_me 8y ago
> In the past four years, I’ve been working as an engineering manager. First, as the co-founder of RisingStack, then Godaddy and now Uber. Wow GoDaddy and Uber? I guess for some people a company is just a paycheck.
sharadov 8y ago
I guess am going down that path, am on the database side though. It terrifies me to be a people's manager, approving timesheets and crap.. I would love the mentoring part, but I'd rather skip and go straight to being the strategy guy.
leothekim 8y ago
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.
- ummonk 8y ago
  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.
- vanadium 8y ago
  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.
- drewr 8y ago
  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.
JimDabell 8y ago
I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very different jobs with very different modes of working. As soon as you start taking on managerial work, your development productivity starts to fall rapidly. I've never found a happy medium, nor have I seen others achieve it. People who try to do both quickly settle on ~80% of one and ~20% of the other. Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it. As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path. Nobody wants to hold up a release because you were working on an important part of it and you've been constantly interrupted all week with managerial work and meetings. Instead, pick things that are either tiny or decoupled from the release process. Things like refactoring, non-critical bug fixes, documentation, tests, spikes. These are the kinds of things that won't fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again. As an engineering manager, you're interrupt-driven which is incredibly disruptive for focus. If you do write code, then it has to be the code that works within those constraints, or you'll end up being a blocker for the rest of the team and your managerial work will suffer as well.
- nodefortytwo 8y ago
  For me I have always found the best projects to work on are Developer Experience projects. In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i'm delayed it doesn't really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.
  - jon-wood 8y ago
    This is exactly what I do, currently my main coding project at work is a library to improve our tracking of system level metrics across applications. If I get some time I can add a few more things that suddenly get tracked across multiple projects, making debugging easier in the future, and if I don't nobody really notices.
ElBarto 8y ago
"Work on Bug Fixes / Small Features" That's terrible advice, in my view. In your job you should always do what is the most useful and productive use of your time. As a tech lead/manager your role is to manage/lead and your time is extremely valuable. In addition, your job as a manager is to allocate resources efficiently. A small feature is a good task for a junior engineer. It helps them grow and their time costs less than yours. Bug fixes should be the job of whoever knows the relevant part of the code best, which is unlikely to be you if you're a manager but even if it is you should aim to train and mentor others to acquire the technical expertise.
- ummonk 8y ago
  Having first hand knowledge about the state of the codebase is helpful to doing your job as a tech lead / manager. Doing bug fixes / small features is a productive way to gain and maintain this knowledge.
  - ElBarto 8y ago
    You can/should have visibility of the code base through design specs and code reviews. There is absolutely no need to do a (potentially junior) engineer's job. It might be 'productive' but it's not the best use of your time or your role, and thus it is in fact a waste of time and money.
    - bearforcenine 8y ago
      If you only have 20% of your time available to write code, then I would much rather you do not review code in which the person who wrote it had 90% or more of their time to write code. The review will be less thorough, correct, and timely than if someone else who regularly spends more time in the code. These 'junior engineer' tasks are attractive for a manager who still wants to be in the code. They are non-critical and small. Perfect for someone with an unpredictable schedule. However, they also provide an opportunity for the manager to have a better, but still imperfect sense of the codebase and technology.
shados 8y ago
Lots of anecdotes here...I'll add more. I worked primarily in 2 type of companies as far as this topic goes. The first (and in my sample, more common) kind was engineering managers as pure managers. You had tech leads which were really DRIs on technical projects, but very much software engineers in their day to day roles, and Engineering Managers which handled money, people issues, and made sure the tech leads did their jobs. At some companies, teams have both. Often each team has one TL and an engineering manager may look over multiple teams. Not always though. That works, but there's a bit of a disconnect. The person who decides if you should get promoted or get a raise (or fired!) very much relies almost exclusively on second hand information. They may have been an engineer in the past, but they're not anymore, and may only have a loose understanding of what is truly happening. They're usually a bit better at handling people issues though. The other kind is the "your boss should generally be able to do your job. Maybe not as well, definitely not as fast, but in a pinch, given enough time, they could". So engineering managers are just a higher form of tech leads that ALSO have the whole people/money/management responsibilities. They code (a little...maybe 5-20% of the time max) and can fully understand the problem the people they manage are dealing with (not just because they did it 5 years ago, but because they deal with them too in the present). That's a lot of work. Much, much fewer people are qualified to do this so to scale, you either have to be a very competitive organization, or actively train/manage/promote engineers into those roles (or steal people from the rest of the organization and train them as engineers. That works too!). I personally much prefer the later (even though another post mentions it as being a potential trap, I saw it work very well when handled properly). It's infuriating to have to explain to a manager that the company's darling engineer actually suck, but the managers only see the end result (without what happened to get there or without being able to analyze the cost) and have significant decisions be made around it. But again, it's very hard to build an organization that way.
- opportune 8y ago
  >It's infuriating to have to explain to a manager that the company's darling engineer actually suck Holy crap, yes. Well it’s not always that the darling TL sucks but often that they themselves are in a role where they aren’t familiar with some of the tech the people working in their team are working on, so they don’t know how to properly make the large scale time estimates that get reported to the manager (and why would you ever ask the people actually working on specific tasks how long something would take? That makes too much sense and they might not tell you what you want to hear). But when they’re the darling and you’re working to meet the darling’s time estimates that were never realistic in the first place, you get thrown under the bus to the manager when time estimates fail. This actually just happened to me today. This power structure also allows the manager/TL to play good cop bad cop on their employees where all bad news/orders from manager to employee goes through the TL but all good news/orders goes directly through the manager. You can’t really win in a finger pointing game like this. The only fix is to just leave
ducklingslicks 8y ago
That would be great.
encoderer 8y ago
Here's how I do it: 1) I manage a team of fullstack engineers where I do very few coding tasks but also can sometimes chip in on large efforts or when senior people are out of the office. 2) Code liberally on weekends and on my bus ride in the morning on OSS and a SaaS I've built over many years. Staying engaged technically makes me unquestionably a better manager, but I will impede my team's development if I take tasks in the team sprint.
deleted 8y ago
[deleted]
keephere 8y ago
I run an org of 20ish at a FANGish company. I have mgrs and a team of ICs reporting to me. Myself and my managers are on the oncall rotation along with ICs and we do light coding activities. Pros- team morale, better tech decisions, skills stay up to date, oncall is quiet Cons- more time consuming, develops bias against other mgrs that do not code To each his own...
known 8y ago
As Engineering Manager I was doing Code reviews of my team;
Dawny33 8y ago
What is the difference between a tech lead and an engineering manager?
purplezooey 8y ago
If you choose non critical bugs to work on, your managers will say wtf is he working on that, and your next performance review will say "needs better judgement on priority of tasks" and you'll be let go in the next round.
deleted 8y ago
[deleted]
drej 8y ago
This is the worst class of managers I have ever experiences: engineering managers with little dev experience. They rose quickly and became managers fairly early on in their career. They got excited by the opportunity, but then realised early on that they mostly attend meetings and write e-mails. They miss coding, so they try and code between meetings, but without knowing our engineering practices, code reviews, agile methodology, ...
Hippocrates 8y ago
Good perspective. In my experience an engineering manager must be flexible. An engineering manager can really help the team excel by building productivity tools, prototyping new concepts documenting, or even fixing small bugs. With that, a manager should not let technical tasks get in the way of managerial duties. I like the author's advice about not taking on work that may block your team. That is truly risky and can backfire. I've seen this firsthand -- But a manager absolutely must keep their head in the game technically. They need to be able to interface with other engineers and managers on a deeply technical level. They should have an awareness of their project's codebase that is best gained through being in it. An engineering manager without technical ability is a more like project manager. In my org, I have seen the expectations of what a manager does shift quite a bit. With the addition of a tech lead role, it seems managers are silo'd into less technical, and less hands-on work. I feel that any sort of hard expectation or assigning percentages to management vs engineering time is ignoring the nuances of team dynamics, and individual personalities. A manager who can also effectively contribute code should do that. Likewise, an engineer who can boost team morale, mentor, help recruit/staff the team should. Take a look at the team dynamics and determine what mix works.

307 points by gergelyke 8y ago

I really like the "work on bugfixes and small features". 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.

maxxxxx 8y ago
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.
- gergelyke 8y ago
  Oh that's a great! Are you okay with me adding it to the article?
  - maxxxxx 8y ago
    Sure. The good thing about this is that they were often very good devs so their insights are really good.
palakchokshi 8y ago
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.

CardenB 8y ago

I find the bit about mentoring people outside your org interesting. I'm interested in mentorship myself. Does anyone know if there are actually rewarding mentorship programs on websites like meetup.com? Has anyone else done this?

hodgesrm 8y ago
Check with your local university or community college for mentoring opportunities. For example, the University of California at Davis has a senior design class in their computer science program. You can submit a proposal for a project; if it's accepted you become the mentor and work with the students a couple hours a week over 4 to 5 months. I did this last year and found it extremely rewarding. Edit: fixed typo
- tudelo 8y ago
  Did you have to pay money to do this?
  - hodgesrm 8y ago
    No, it was more like just write a good proposal. There was a problem related to Swagger API specs that had been bugging me for a while, so I wrote it up and sent it in. I was delighted when it was accepted. I'm planning to submit another project this year. Working with students is fun. p.s., The class is ECS 193AB in case any folks living near Davis are interested.
mkirklions 8y ago
What do you have to offer? Im an ambitious person with credentials, but programming is not my day job and Ive made marketing mistakes on my popular website.
- CardenB 8y ago
  Definitely technical mentorship- especially in robotics. Also great career advice for people starting out in their career (in university for CS or graduating soon/just graduated, picking between entry level offers) up to 2 years into career. Or grad school advice.
  - mkirklions 8y ago
    Id be looking for web programming and business savvy skills. Btw, Ive recently fell in-love with embedded systems. Ive built a dishwasher that sets your dinnertable. But the issue is the business, not the tech.

iaresee 8y ago

I like writing metrics-related code as an EM. It’s valuable for me to be able to understand our data that’s tracking our KRs and informing our KPIs. And I get to stay sharp on some frameworks we use here for surfacing metrics to the company.

gtsteve 8y ago

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.

zandl 8y ago
Totally agree on the QA side, you need to see first hand what’s coming out of your team to understand where your team is at.

bojo 8y ago

This article is pretty close to my own situation. I’ve found that the worst thing I can do is work on features that could potentially block everyone, and the best I can do is grease our code ecosystem by updating libraries, compiler versions, and low level code which doesn’t affect business logic.

segmondy 8y ago

I swing back and forth. I go for months without touching the code, then I go for months where I stay in touch. It's easy to think a code base is decent when you stay close to it. Diving into a new code and unfamiliar code base allows me to see how new engineers will approach the code base, what's the onboarding/setup docs? Is it automated? install.sh or containeriazed? Are there tests? FAQ? user documentation, maintenance document? architectural documentations? If I can jump in the code fast and get moving, it's great. If not, I know the team is slacking and I figure out why and cover that area. If pressed for time, then I might do the test/bugfixes cycle. I code multiple times a week at home, so I'm not really pressed to program at work

ilovecaching 8y ago

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.

gergelyke 8y ago
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.
- ilovecaching 8y ago
  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.
  - seabrookmx 8y ago
    A lot of companies do not have the foresight or resources to simply split a team though. There's lots of way to organize teams as well. At previous companies we've organized yes around products, or around skillsets, for instance.
jimejim 8y ago
"We don't let managers code where I work." "...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.

lordnacho 8y ago

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.

ansgri 8y ago
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.
- lordnacho 8y ago
  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.

azhenley 8y ago

As a new professor it seems I am supposed to act more like a manager and do less of the research/coding/data analysis myself. But I love to code! My goal is to keep a small project for myself that I work on when I don't have impending deadlines (basically never?).

purple_ducks 8y ago

> Work on Bug Fixes / Small Features With this, I disagree for 2 reasons: 1) If your devs had to prove themselves technically via hiring process and you didn't, then your technical chops are potentially not up to scratch and devs have to tolerate inferior noise. Ditto with architecture input. 2) The easiest fix isn't always correct. Not having day to day knowledge of the code base means you're more likely to implement something substandard.

mwfunk 8y ago

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.

vanadium 8y ago
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).

bwanab 8y ago

Exactly why I quit managing altogether. One can code or one can manage, but doing both means both are compromised.

agentultra 8y ago

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.

timtyrrell 8y ago
Great article on that here: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
maxxxxx 8y ago
I like the idea but in most companies the salary structure doesn't allow it.

alexchamberlain 8y ago

What do we mean by manager in this situation? Is the first level "team leader" a people manager that engineers, or are we talking higher level managers?

news_to_me 8y ago

> In the past four years, I’ve been working as an engineering manager. First, as the co-founder of RisingStack, then Godaddy and now Uber. Wow GoDaddy and Uber? I guess for some people a company is just a paycheck.

sharadov 8y ago

I guess am going down that path, am on the database side though. It terrifies me to be a people's manager, approving timesheets and crap.. I would love the mentoring part, but I'd rather skip and go straight to being the strategy guy.

leothekim 8y ago

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.

ummonk 8y ago
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.
vanadium 8y ago
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.
drewr 8y ago
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.

JimDabell 8y ago

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

nodefortytwo 8y ago
For me I have always found the best projects to work on are Developer Experience projects. In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i'm delayed it doesn't really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.
- jon-wood 8y ago
  This is exactly what I do, currently my main coding project at work is a library to improve our tracking of system level metrics across applications. If I get some time I can add a few more things that suddenly get tracked across multiple projects, making debugging easier in the future, and if I don't nobody really notices.

ElBarto 8y ago

"Work on Bug Fixes / Small Features" That's terrible advice, in my view. In your job you should always do what is the most useful and productive use of your time. As a tech lead/manager your role is to manage/lead and your time is extremely valuable. In addition, your job as a manager is to allocate resources efficiently. A small feature is a good task for a junior engineer. It helps them grow and their time costs less than yours. Bug fixes should be the job of whoever knows the relevant part of the code best, which is unlikely to be you if you're a manager but even if it is you should aim to train and mentor others to acquire the technical expertise.

ummonk 8y ago
Having first hand knowledge about the state of the codebase is helpful to doing your job as a tech lead / manager. Doing bug fixes / small features is a productive way to gain and maintain this knowledge.
- ElBarto 8y ago
  You can/should have visibility of the code base through design specs and code reviews. There is absolutely no need to do a (potentially junior) engineer's job. It might be 'productive' but it's not the best use of your time or your role, and thus it is in fact a waste of time and money.
  - bearforcenine 8y ago
    If you only have 20% of your time available to write code, then I would much rather you do not review code in which the person who wrote it had 90% or more of their time to write code. The review will be less thorough, correct, and timely than if someone else who regularly spends more time in the code. These 'junior engineer' tasks are attractive for a manager who still wants to be in the code. They are non-critical and small. Perfect for someone with an unpredictable schedule. However, they also provide an opportunity for the manager to have a better, but still imperfect sense of the codebase and technology.

shados 8y ago

Lots of anecdotes here...I'll add more. I worked primarily in 2 type of companies as far as this topic goes. The first (and in my sample, more common) kind was engineering managers as pure managers. You had tech leads which were really DRIs on technical projects, but very much software engineers in their day to day roles, and Engineering Managers which handled money, people issues, and made sure the tech leads did their jobs. At some companies, teams have both. Often each team has one TL and an engineering manager may look over multiple teams. Not always though. That works, but there's a bit of a disconnect. The person who decides if you should get promoted or get a raise (or fired!) very much relies almost exclusively on second hand information. They may have been an engineer in the past, but they're not anymore, and may only have a loose understanding of what is truly happening. They're usually a bit better at handling people issues though. The other kind is the "your boss should generally be able to do your job. Maybe not as well, definitely not as fast, but in a pinch, given enough time, they could". So engineering managers are just a higher form of tech leads that ALSO have the whole people/money/management responsibilities. They code (a little...maybe 5-20% of the time max) and can fully understand the problem the people they manage are dealing with (not just because they did it 5 years ago, but because they deal with them too in the present). That's a lot of work. Much, much fewer people are qualified to do this so to scale, you either have to be a very competitive organization, or actively train/manage/promote engineers into those roles (or steal people from the rest of the organization and train them as engineers. That works too!). I personally much prefer the later (even though another post mentions it as being a potential trap, I saw it work very well when handled properly). It's infuriating to have to explain to a manager that the company's darling engineer actually suck, but the managers only see the end result (without what happened to get there or without being able to analyze the cost) and have significant decisions be made around it. But again, it's very hard to build an organization that way.

opportune 8y ago
>It's infuriating to have to explain to a manager that the company's darling engineer actually suck Holy crap, yes. Well it’s not always that the darling TL sucks but often that they themselves are in a role where they aren’t familiar with some of the tech the people working in their team are working on, so they don’t know how to properly make the large scale time estimates that get reported to the manager (and why would you ever ask the people actually working on specific tasks how long something would take? That makes too much sense and they might not tell you what you want to hear). But when they’re the darling and you’re working to meet the darling’s time estimates that were never realistic in the first place, you get thrown under the bus to the manager when time estimates fail. This actually just happened to me today. This power structure also allows the manager/TL to play good cop bad cop on their employees where all bad news/orders from manager to employee goes through the TL but all good news/orders goes directly through the manager. You can’t really win in a finger pointing game like this. The only fix is to just leave

ducklingslicks 8y ago

That would be great.

encoderer 8y ago

Here's how I do it: 1) I manage a team of fullstack engineers where I do very few coding tasks but also can sometimes chip in on large efforts or when senior people are out of the office. 2) Code liberally on weekends and on my bus ride in the morning on OSS and a SaaS I've built over many years. Staying engaged technically makes me unquestionably a better manager, but I will impede my team's development if I take tasks in the team sprint.

deleted 8y ago

[deleted]

keephere 8y ago

I run an org of 20ish at a FANGish company. I have mgrs and a team of ICs reporting to me. Myself and my managers are on the oncall rotation along with ICs and we do light coding activities. Pros- team morale, better tech decisions, skills stay up to date, oncall is quiet Cons- more time consuming, develops bias against other mgrs that do not code To each his own...

known 8y ago

As Engineering Manager I was doing Code reviews of my team;

Dawny33 8y ago

What is the difference between a tech lead and an engineering manager?

purplezooey 8y ago

If you choose non critical bugs to work on, your managers will say wtf is he working on that, and your next performance review will say "needs better judgement on priority of tasks" and you'll be let go in the next round.

deleted 8y ago

[deleted]

drej 8y ago

This is the worst class of managers I have ever experiences: engineering managers with little dev experience. They rose quickly and became managers fairly early on in their career. They got excited by the opportunity, but then realised early on that they mostly attend meetings and write e-mails. They miss coding, so they try and code between meetings, but without knowing our engineering practices, code reviews, agile methodology, ...

Hippocrates 8y ago

Good perspective. In my experience an engineering manager must be flexible. An engineering manager can really help the team excel by building productivity tools, prototyping new concepts documenting, or even fixing small bugs. With that, a manager should not let technical tasks get in the way of managerial duties. I like the author's advice about not taking on work that may block your team. That is truly risky and can backfire. I've seen this firsthand -- But a manager absolutely must keep their head in the game technically. They need to be able to interface with other engineers and managers on a deeply technical level. They should have an awareness of their project's codebase that is best gained through being in it. An engineering manager without technical ability is a more like project manager. In my org, I have seen the expectations of what a manager does shift quite a bit. With the addition of a tech lead role, it seems managers are silo'd into less technical, and less hands-on work. I feel that any sort of hard expectation or assigning percentages to management vs engineering time is ignoring the nuances of team dynamics, and individual personalities. A manager who can also effectively contribute code should do that. Likewise, an engineer who can boost team morale, mentor, help recruit/staff the team should. Take a look at the team dynamics and determine what mix works.