Should managers still code?
187 comments
·March 4, 2025protocolture
serviceberry
> I cant work for someone who doesn't understand what I do.
But you already do. Unless you're working for a tiny startup, your CEO or the Board probably doesn't understand the specifics of your code.
You can't run a large company by making every person super-involved in every detail. You have layers of abstraction that make it possible to reason about an org of hundreds or thousands of employees. The Board trusts the CTO to oversee technology. Your CTO trusts your director / VP / whatever to run a large chunk of it. That person delegates a smaller part of running the company to your boss.
The whole point of each layer is to abstract away some of the underlying messiness. They exercise professional judgment for day-to-day operations and provide a clean interface that provides health signals, requests resources as needed, etc. And I think what many folks miss is that it doesn't stop with their boss. It stops with you! Your boss generally trusts you to make design and implementation decisions and is expecting you to provide a reasonable interface to that. If your boss has a reasonably-sized team but is spending their day writing code, then honestly, why are they in a management position to begin with?
protocolture
>If your boss has a reasonably-sized team but is spending their day writing code
They dont need to spend all day writing code, they need to spend their nights and weekends making sure their skills dont rust.
GlacierFox
So you want them to come to work and do their job, then go home and waste their nights and weekends doing a variation of your job?
How about, a proportion of their work day must be allocated to keeping up to date with the tools behind the thing they're attempting to manage?
joeblubaugh
> they need to spend their nights and weekends making sure their skills dont rust.
Life is more than work
protocolture
Specifics sure. I dont expect them to understand the specifics. I dont want them across every task.
But I also dont want to (and currently dont have to) explain specific risks regarding what I do, I dont have to justify how long things take, because my management understands that. We speak the same language. Its glorious.
I mean just comparing my clients that have relevant technical knowledge, vs the ones that dont, the clients that dont have that knowledge need "meetings" and "catchups" and immense email threads in the order of 10 times the ones that do understand. Thats measurable (to me) waste.
Another observation of mine is that non technical people really have no ability to recruit and manage technical people. I have seen multiple businesses brought low because the "technical" person brought in to manage the "technical" side of the startup actually had NFI. Or when they do accidentally hire someone competant, their requests for resources or time are ignored, even when well justified. The non technical founder or CEO either has to trust someone (which fails a lot) or they dont trust someone (and thats even worse).
burnte
> I cant work for someone who doesn't understand what I do.
Someone can understand what you do without being able to do it.
tdeck
> I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building"
> He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And then wandered off telling me he could definitely do the work if he wanted to.
Frankly, all this anecdote tells me is "don't behave like a condescending asshole". If he'd said the same thing but then managed to do some non-trivial aspect of your job for a few minutes, I think that would still have been a bad tactic. It's just as possible to have humility about skills you lack, and to lack humility about skills you've maintained.
protocolture
Normally I would have 12 or so desktops there.
The server stacks were well above his height.
He probably could have, in his day, wired up 20 odd desktops, got them going, and maybe shave 10 minutes off my batch time.
But he really had nfi with the servers, the stacks were 2ft higher than him already, they all had dual power supplies, lots of idrac ports. He absolutely would have shamed himself if he kept going. And the reason he hired me was the ability to reason and read vendor documentation.
They also take ages to boot compared to a desktop.
So yes I think ALSO dont behave like a condescending asshole, but if he understood what I was doing he wouldnt have needed to leave his office and make a fool of himself anyway.
zemvpferreira
I don’t know man. Can Bezos code? Can he operate a forklift? Would he still even recognize Powerpoint if you opened it for him? At certain points things need to be let go of if you want to keep growing. Some managers might keep technical skills sharp, but I’m not sure they’re much better managers for it.
somethoughts
On the flip side - I find it very understandable that one might not want to have ever worked at Amazon even in its early days and instead would prefer to work (or have worked) at a much smaller, engineering focused organization.
protocolture
Groups of companies, like Amazon, dont really make sense to me in abstract so I cant really comment.
But whoever the head of AWS is should definitely have a grasp of fundamentals.
tibbar
I've seen plenty of managers who increased team output 10% for a few months by coding and completely lost the thread in the meantime. That's how your entire team gets laid off. Leadership doesn't care how much code your team writes, they care that you're working on the right stuff.
An engineering manager's job is: take long-term ownership for the performance of the team. That might include aligning with leadership, marketing your team's work internally, hiring, performance management, team bonding, planning, retros, oncall coverage etc. etc, although sometimes you'll have a PM/tech lead/HR contact who handle some of these.
Every now and then, your bottleneck really is just writing more code (more common in smaller companies). In that case, jump in.
tibbar
As an aside: If you're a line manager of a small coding pod, and your manager is very engaged in company planning and generally competent, then you can probably do a lot more coding. Someone has to do the organizational engineering work, and it's your manager, in this case. Now, if this individual ALSO wants to spend their time coding, then things can go very wrong indeed.
The worst possible scenario is that a manager doesn't know how to prioritize amongst their existing team, and/or doesn't want to say a difficult 'no' and tries to make up for it by coding in the evenings. That's someone who hasn't learned how to really fly the airplane yet.
zmmmmm
> your bottleneck really is just writing more code
You're characterising it as pure "code volume" question but it's completely not the point. Absolutely if they are coding just to directly increase the output of the team they are much better devoting that time to getting more output from the IC's they are managing.
But even better is coding in a way that helps the team overall work better. This can be because they do architectural work, they gain insight into the actual team challenges, it improves how they can estimate the time needed for different tasks, etc.
tibbar
Yep, there's definitely a way to write code intentionally, for the reasons you listed, and I approve of that! But you'll see a lot of engineering managers coding because they are trying to help the team reach its next deliverable. This is usually short-sighted.
I think of it as the management control loop: "I have some spare cycles -> what is the most important work I can do for the team right now?" Coding can be the answer. But some people's control loop seems to be more like: "I have some spare cycles -> what is the most interesting/rewarding task I can do next?" The latter might lead to a lot more coding, but it's not good for the team.
nine_zeros
> An engineering manager's job is: take long-term ownership for the performance of the team
This is a rather naive, mid-level management-style take.
The real EM job is to represent the team to the company, to be aligned with company priorities, and to be a backstop for the team. In other words, being the leader - the face, the prioritize, and the helper of the team.
Performance-style nonsense is what is used in warehouses and factories where the manager is responsible for number of units produced.
But in software, the goal is NOT to produce more but to produce correct/investigate correct/and maintain correct.
As such, EM is very different from warehouse-style management.
tibbar
I'm not quite sure where you're getting "performance = maximizing units of output" from my post, as the whole point was the difference between squeezing out a little more code vs. keeping the team on track doing actually valuable stuff. Either way, I think we mostly agree here: the EM is the face of the team who makes sure the team, as a unit, is doing valuable work as a sustainable pace that's understood as such internally.
However, to be clear, software teams, engineers, and engineering managers are absolutely evaluated on their performance, which is a complex and subjective metric, and the manager is generally the one held responsible for it at the team level.
nine_zeros
> However, to be clear, software teams, engineers, and engineering managers are absolutely evaluated on their performance,
Yes, and no one said that this kind of evaluation has produced long term success. It has widely been recognized that when upper management is more involved in evaluation rather than leading teams of managers themselves, they address issues and market conditions too late. Thus, affecting businesses negatively over and over.
https://hbr.org/2016/10/the-performance-management-revolutio...
In other words, managers are being asked to NOT perform to certain metrics/evals but to make choices that benefit the company - even if it falls outside any evaluation rubric.
dataflow
> The real EM job is [...] being the leader [...] of the team
That's quite a confusing description. Then what does the team lead do? Manage the team?
n_u
Strong yes for 3 reasons
1. Reducing dev friction.
When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it.
2. You get a much better sense of IC’s contributions by writing code.
There are ICs who play politics very well and sell themselves but that set is not the same as the ICs who deliver. If you are writing code you start to notice which ICs have written key features, built critical APIs or worked on hard problems because of comments and Git blame.
3. Understanding your codebase.
I hope most managers have solid CS and engineering fundamentals but that is a necessary but not sufficient condition to grasping the full picture. There’s a reason it takes time to ramp up to full productivity on a new codebase. If you work in the codebase and have had to use that one annoying but critical library or dealt with that tech debt from 2 years ago then you know what is hard and what isn’t. I’ve found when a codebase has a quirk that makes developing certain features hard all of the non-technical people keep forgetting why we can’t do that thing and all the technical people have it burned into their brains.
andoando
I don't see why you need to be writing code to understand all of this. It can help, but almost everything you said is ascertained from daily syncs
icedchai
Daily syncs allow the loud, not necessarily the most productive, to dominate. You cannot judge someones actual contributions by what they say.
andoando
I didn't say you should be judging performance solely on daily syncs, but you have a myriad of ways of doing that as a manager including simply looking at the big-picture content of PRs, what issues a dev identified and solved, what devs contribute to discussions/technical solutions in slack/meetings, what projects are completed, and how well they turn out etc.
But eh? Doesn't matter how loud you are in a sync, you can very easily go off the actual content of what someone is saying. If someone goes off 5 minutes about how they managed to turn an object into a json string, that doesn't exactly make them look good.
Aeolun
You don’t need to be writing code. But it’s a convenient shortcut to a great many things that otherwise take dedicated effort to understand.
Some managers will do that. Most won’t. Given that, it’s easier to just tell them all to code.
andoando
Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.
dv_dt
Fewer or shorter daily syncs is a plus
ozim
I don’t see how you can understand something without being part of it.
It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing.
The same for working with the team - it is so much different than listening and trying to understand.
Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.
andoando
But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code.
If you're really listening and asking the right questions you should be aware of even changes like "Were deciding to use this HTTP client rather than what we currently have". OK why are we doing that? What was the issue? Ask ask ask.
As a manager Id argue you have (or should have) more technical insight into your whole codebase than any IC
dietr1ch
> 1. Reducing dev friction.
This is so important, my managers who didn't code pretended things weren't too bad and took a "just deal with it" attitude whenever I proposed going for a QoL improvement.
vrosas
On the flip side I had a manager who had written a lot of the codebase before I joined and had a terrible time allowing anyone to touch his precious baby, regardless of how much his prior ”art” was hurting us, our productivity, and by extension the company.
ge96
Yeah... I said it was a "flaming pos" I felt bad about that. But he won't let me add tests so idk whatever. (we prototype software so speed is the main goal but yeah, stuff starts breaking, backtracking, hey... tests)
wkat4242
> When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too.
For me a good manager is a facilitator, not a leader. Someone who removes obstacles for us. Whether they themselves are affected or not. Someone only fixing an issue because they have to deal with it too seems like a pretty bad manager to me.
They're not for pushing targets or trying to weed out non-performance, I don't work at a playschool. My manager is there to make sure I can do my job and that I can reach my maximum potential (including making sure I'm in the right job)
webdever
I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work.
Like imagine you were a coding manager 10 years ago with AI experience. Sometime over the last 10 years your team does AI infra. You, as a manager and as an IC, have zero AI experience (you've never trained a model, never used a trained model, never using any of the various AI frameworks). Are you still okay to manage this team or should you be replaced with someone who does have that experience?
mitthrowaway2
Toyota calls it the gemba walk. Managers need to see how the factory is running with their own eyes. Not just live behind a desk and listen to what they hear in meetings.
A movie director can see the sets with their own eyes. But you can't see the state of a software codebase without reading and understanding the code, and the most surefire way to do that is to try to write something, even just documentation.
You don't assess the state of your software by walking around the office and looking at hands on keyboards. You look at the codebase.
theresistor
> I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini?
I don't know that much about movie making, but my understanding is that there would be managers and/or leads within each specialty, who are (among other things) managing the interaction between their specialty and the director / producers.
That seems pretty comparable to what's being discussed here.
jaggederest
> I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work.
Many directors started in other roles in the movie industry, typically as writers, PAs, or other subspecialties. Chad Stahelski was a stuntman and stunt coordinator before he started directing John Wick, and it really shows.
I think the clear distinction is between someone who understands a part of the job, and someone who is good at part of the job. If you don't understand how costuming works, as a director, you're going to have a hard time getting good costumes, but by no means does that mean you're able to pinch hit in that role. I personally believe that it's difficult to replace hands on experience as a way to truly understand something.
In software engineering, I think there's a huge gap between managers who worked in some other industry and transferred over, versus having previously been an engineer, even a mediocre one. Knowing how the sausage is made is hard to replace.
SpicyLemonZest
In any industry, if you want a team to work well, you have to have someone with both authority and hands-on experience who’s responsible for providing day-to-day guidance. Sometimes that person is called a “supervisor” or “tech lead” instead of “manager”, although this typically implies some division of responsibilities as well; no reason the person providing guidance necessarily has to be the same person reporting to leadership or hiring and firing.
oliwarner
Friction can be more of a problem too though. If your manager is objectively better than the team, estimates can get cut short and failing to meet those adds tension.
Obviously a good manager might pitch in, understand their teams capabilities but it's not always a natural transition for senior devs moving to management.
sodapopcan
> or worked on hard problems because of comments and Git blame.
Oh lord we'd better hope they have absolutely IMPECCABLE git fu if they are going to be using this metric. Unfortunately here on HN I've seen people essentially brag that they only know just enough git to get by and "who cares if I don't know all the other commands deeply." In any event, this scenario REQUIRES that a manager know exactly how to determine who originally introduced something, or, exactly where it was significantly improved if they are going to be reading comments and blaming to see "who performs."
The very fact a manager might be doing this has got me a little worked up, mainly as I know great managers who don't do this and who are scared of something as simple as the reflog.
x0x0
Also, I'm just fundamentally skeptical you can do a good job of running a team, or hiring, when you don't know how to do the thing the team does. Software development skill requires active use/work to maintain it.
roenxi
Here here. There are a lot of decisions where there is no real contest between the choices to someone who has tried both options but are difficult to tell apart from a distance. EMs should be in a position where they are trying things in practice.
I'd draw an example of someone who hasn't used git before, making a choice between a git repo and managing code by keeping daily .zip files. Anyone (almost anyone) who is a career coder won't see a choice there.
That example is so basic I think most EM would get that right even if they didn't deal in code but the same dynamic turns up at every level of work. There are situations where there is a right option, the right option is obvious to everyone who is working on it and it is is a drain on the org when management gets confused and thinks that something that isn't an option is viable because they aren't on the ground working on it.
peterldowns
Well said — completely true in my experience. It’s called Engineering Manager for a reason!
etamponi
No. The amount of work that a manager has to handle to do their job right is incompatible with coding at a professional rate. If you have a manager that codes, then they won't have (enough) time to:
- Write and design your packets (if in a corporation), or your career path (if in a smaller company)
- Align with other teams, get consensus, shield you from politics beyond your level.
- Make long term planning and making sure your team and neighboring teams follow it.
- Listen to you and your colleagues and handle conflicts.
EDIT: forgive me for not reading TFA first. I won't change my comment as it aligns very well with the article. I still think that the answer to the "should code" question is no, not maybe... Let's not try to overload and overcomplicate what "coding" means.
mrinterweb
I've seen manager calendars, and their days are packed with meetings. Expecting them to do in depth code reviews, pairing, is unrealistic.
I think eng managers should rely on their ICs to inform them of what is going on, and the manager should be the advocate for IC dev needs. Devs should be able to tell their manager what the pain points engineering is experiencing and the manager should advocate on behalf of their team.
bastardoperator
Depends, I always took a sprint task, certainly less than the team itself, but how do I design a career path if I'm blissfully unaware of the work that is being done? How do I plan long term if I don't understand the technical complexity of the problems being faced? Why would I waste time on conflict resolution when I can spend time enabling and building people? You want to argue about your colleague, or make do you want to advance and make more money?
etamponi
I am not gonna argue because I totally see your point. I'll keep my "No" because I think you can still do everything positive you listed without coding. I know it because I had great managers for 10 years, and none of them touched a line of our code.
They did know how to code. It just wasn't their job anymore.
jamesfinlayson
This so much - I had a manager early in my career who had written code many years ago, but in his management role he touched no code at all - I think he probably spent a bit of time watching Youtube at his desk. But if someone tried to dump work on the team, messed up a shared environment, tried to bother one of the team with an out of band request he absolutely pounced on them and tore them to shreds. He well and truly understood his job was to make sure we could do ours.
jtonz
It has been interesting what both groups of 'yes' and 'no' chime in here. Personally I am on the side of 'no' but for a rather simple reason. I ask myself the following question:
Why spend time being good at something you don't care about being good at any more?
It is purely a personality thing however for me I would like to continue moving up the career ladder and you rarely see CTOs, VpEng rolling up their sleeves and sifting through CloudWatch logs. I want my focus to be on working the skills associated with those roles.
As a people manager that works with many incredibly capable engineers that are aspiring to be managers, I share with them this advice, 'excellent engineers compound their value by making other engineers excellent. It's far more difficult to do that when you are writing code.'
copypasterepeat
This is a tough question since what's best for the team and what's personally best for the manager's career may be in conflict, at least when it comes to the long-term. A manager who doesn't do any coding will over time get rusty and get further and further away from the current best practices, latest library/framework hotness etc. This can lead to awkward conversations of the type where the manager suggests "let's do/use X" where X was the best practice 5+ years ago and then it has to be diplomatically explained to him/her that's no longer the best practice. It can also be dispiriting to the manager if they got into software development because they enjoy coding, but now they have to deal with planning, people management etc., which they might be good at, but it may not bring them the same level of job satisfaction.
jamesfinlayson
> This can lead to awkward conversations of the type where the manager suggests "let's do/use X" where X was the best practice 5+ years ago and then it has to be diplomatically explained to him/her that's no longer the best practice
I wish managers would understand that it's not their job to do that any more - I've had a few technical managers in my time and the best one was totally hands off, except when he recognised a scenario that had caused him grief in the past (e.g. boolean fields in a database or anything completely over-engineered). The other ones have just rapidly descended into "I'm the manager therefore my opinion is final" (including one who had never worked with Java, PHP, MySQL, serverless or AWS but didn't let it stop him from having strongly held technical opinions).
Aurornis
This depends entirely on the company and its size. At a big company it’s likely a manager’s calendar will be packed with meetings.
At a smaller company, a manager of a small-ish team might not have enough meetings and planning work to fill the workweek.
I’ve been at small and medium companies where managers were hired from big companies and felt obligated to keep their calendars full. They would invent new meetings, come up with new ideas, and churn the roadmap to fill the time and look like they were doing something. It was depressing.
eschaton
This has not been my experience; at Apple most of my managers were very good and were also coding.
__erik
People never discuss company size along with this question.
If you're at a giant company, the answer is likely no, there's enough politicing and paperwork where the highest impact thing to be done by a manager is likely not coding.
If you're at a startup / smaller more nimble org in a big company, the answer is likely yes, if you've gotten to the point where you're a manager, in theory you're a very good engineer and you should spend your time coding, but on things that aren't on critical path. Bug backlog, experimental things with no hard deadlines, proof of concepts, all of these are valuable things. Leading from the front is also just generally good with smaller groups.
Also under discussed by people having these debates (typically managers), is not acknowledging how bad most managers are at coding, especially if their job hasn't required them to code in a while. I see all the time that managers look for any excuse not to code, because it would reveal to their team that they're at best an L4 level coder after being in management for 5-10 years.
Aurornis
Agreed. This debate is useless without discussing the context of company size.
If you’re a manager at a big company with a project that intersects with 5 other teams and you have a dozen people who call themselves stakeholders for your work, you’re not going to have any time to code.
If you’re a manager at a small company where everyone knows each other and team sizes are small, there might be something wrong if your calendar is full of meetings.
I’ve been at a couple small companies that hired big company managers. They felt obligated to create more meetings, documents, and discussions to fill their time and look busy. We finally had to start screening for managers who knew how to fill their time with something productive, whether it’s coding or going out and working with customers.
Generating meetings until your calendar is full is a game in itself at a lot of companies.
pragma_x
Should they be able to? Absolutely. Should they exercise this on projects they manage? Probably not.
I ran into this problem years ago. It's not exactly good form to be manager that contributes to the team's project, is at the apex of code review, and is responsible for team performance reviews, all at the same time. It can work, but without other people at your level reviewing your work, you'd be asking the team you manage to call out your mistakes. That's the kind of thing that a lot of people might not be comfortable with, so you're really asking for softball and rubber-stamp reviews on your work. This makes for poor optics: your work always goes to `main` virtually unchallenged, while everyone else has a harder time.
At the same time, you need to be technically competent if you're managing a team while in the review loop. To do otherwise is to create situations where you will lose face with your team. So, sticking to review only is probably the best answer here.
There are workarounds though. It makes sense to maintain a pet automation project just to stay sharp while solving real problems (e.g. every manager needs better reporting). You can also negotiate out cross-team contributions where your work may be reviewed by folks that do not report to you.
dan_can_code
To "lose face" with a team shows a lack of trust. I think it's fine if you don't have a perfect solution, but require some eyes on your work. But you're right, if you don't have people your level (or better yet, more experienced) reviewing your work, getting an honest code review is challenging.
robotsquidward
My best managers were ex-engineers who didn't touch the codebase. They understood how things worked, and could talk architecture & concepts, but they didn't expect to be able to sit down and write code at our level. Maybe they wished they would have the time/opportunity still, but realistically they were focused on leading.
mitthrowaway2
My best managers did code! They didn't close tons of tickets but they did do small things, and by keeping active in the codebase they were very cognizant of the state of documentation and technical debt, and could make informed decisions without relying on second-hand reports. It kept their understanding of the codebase grounded in reality. They knew which features were held together with duct tape, what areas needed attention, and planned timelines and expectations accordingly.
lexandstuff
This is 100% my experience. I appreciate a manager who can jump into the codebase to fix the small stuff: typos, lint issues, updating minor dependencies, etc., unblocking devs from doing the main work. I like when they have some sense of the reality of the codebase, as you put it, and know who is actually contributing vs bullshitting.
The worst managers I've ever had were the so-called "technical" managers who had never looked at the code. They were often involved in technical decisions, but their opinions were entirely based on vibes. Since they were a manager, people felt obliged to listen to their input, even if it was disconnected from reality.
Either: a) be completely non-technical, and make sure you have a technical leader on the team who you trust, who does know the code or b) get involved in the code, enough to support and unblock your team.
only-one1701
In my experience, there's a time limit on how long these kinds of people can be good managers from the perspective of accurately assessing a) which ICs are contributing what and b) how long it it'll take to implement something. The fact of the matter is that an engineering manager who can't or won't write code will never know as much about his team or indeed the product as one who does.
It's a shame that the "maturation" of the tech industry has resulted in these non-coding eng managers whose main skillset is often bullshitting, managing up, or both.
giantg2
This is exactly how it should be in my opinion. This matches my experience with who I saw as being good managers.
fifilura
Were they happy with it or did they become miserable after a while?
giantg2
They were happy with it. On the opposite side, almost every dual role manager I've known have been miserable. Most of the ones I knew dropped out and went back to dev only work. A few stuck it out and got promoted into a no-code management role.
skissane
I once had a job where my job title was officially “Team Leader”, and my job spec was both to do development work and manage a team of 2-3 people doing the same work. (Except my team never existed, because they were all vacant positions and the salary budget I’d been given was too low to actually hire anyone, and then I resigned.) But, in that org, you could manage people without being classified as a “manager”. Whereas everywhere I’ve worked since has had this hard rule, if you have reports you must be a “manager” (or director or VP or whatever), no equivalent concept of “team leader” (although conversely you can be a “non-people manager” who has the word “manager” in your job title but no reports-common for product managers, project managers, etc). But I’ve observed first line managers often de facto act as “team leaders” anyway (actually doing hands-on technical work), but as you go up the hierarchy it gets less common-although exactly where it tapers out is determined more by the individual than the title or management level
mazone
I do managing, coding, design, governance and overall what i call "improve the company" within my areas of expertise and context switching and commitments are the most challenging things. Need to be very disciplined and know the other areas are currently very stable and under control to carve out time for the other things. It is not impossible but it have to be very focused and the problem domain need to be quite good understood before jumping in. Example, writing a internal tool that in worst case get delayed for later is easier to start working on then being part of customer facing product development as all of a sudden i would need to jump into some urgent management tasks or overall just let the governance and long term company quality go down.
simonw
When I've worked as an engineering manager I've found the advice to "stay out of the critical path of getting features into production" to be very helpful. It's difficult to commit to coding timelines as a manager, and it harms your team if you are the bottleneck to shipping something.
But... keeping your hands in the mix elsewhere helps you stay informed and make better decisions. I found writing things like internal debugging tools, documentation, helping out on code review and architectural discussions, building example features against APIs etc were all good uses of my time.
An interesting trend I've observed over the past couple of years is that a lot of my friends who had moved into engineering management and stopped coding completely are picking up more coding tasks now thanks to LLMs - previously spending ~4 hours getting a development environment working and getting back up to speed wasn't justifiable, but LLM assistance means they can now get something small and useful done in just an hour which is much easier to carve out time for.
peterldowns
“Your manager should be able to consistently make small contributions” is also a good litmus test for your developer env/tool/experience. If it takes more than 20 minutes to get set up and start working your team probably has a problem.
alostpuppy
100%
zusammen
Generally, no. There’s a risk of unfair competition for work (they can delegate the stuff they don’t want because they have political power) and their code often becomes “untouchable” because few will call it out if the code is bad.
A hobby project to keep current isn’t a bad idea, though.
evidencetamper
> unfair competition for work
That's a very good indicator of a bloated institution. People have to compete for work instead of pushing it away or avoiding it because they already have their hands full.
But I don't believe there is a general rule that applies here.
Most great managers I had were deeply technical and involved in the nitty gritty of the projects, including coding the very spiky aspects of a project.
Most mediocre managers I had were very focused on relationship building. The kind of manager that would need a hobby project to keep current, instead of being the most knowledgeable person in the room.
SOLAR_FIELDS
The author starts off with this statement:
> I think that there is a big difference between being in the code and writing code. All managers should be in the code, but not all managers should be writing code.
I think it's not possible to be in the code without writing code. People can pay lip service to being in the code as the author indicates, but as we all know there is no substitute for actually sitting down and writing the code yourself in terms of understanding the actual pains and struggles.
And my anecdotal experience says that if you aren't writing at least some of the code, more often than not the disconnect between the manager and what the team is doing grows and grows.
mandelbrotwurst
People might compete for the work they view as relatively more attractive for a variety of reasons even when they are quite busy.
pc86
IMO if an EM is taking the fun stuff, or the high-profile promo packet stuff, that's a symptom of a lot of very bad things. My boss is an upper-level EM and has at least a few PRs in a couple projects every sprint, and it's almost entirely boring-but-blocking stuff, or stuff that nobody wants to figure out, or stuff that is important but not sexy and not likely to get anyone noticed. He's not writing new features or writing UIs that are getting put in pitch decks or anything.
If I were an IC and my boss was picking the sexy work I would leave. If I was a director and one of my EMs was picking the sexy work I would fire them.
LeafItAlone
As an engineering manager, I actually pick up the stuff other people don’t like to do or stuff I notice that is hanging out there. My goal is to move the team forward.
I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun.
bryanlarsen
> I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun.
I've had managers do this to me. What an awful experience. Because they're the manager you can't push back against the awful design decisions they made. They feel it's almost done so don't understand that it takes a lot of time to deal with all the side effects they didn't consider.
LeafItAlone
That’s very valid feedback.
I hope I don’t come across that was and do have some evidence (not to be laid out here) supporting that I don’t.
I think I’ve created a team and structure where the developers I manage are comfortable telling me I’m wrong or what I didn’t consider. It happens weekly. We value honest feedback highly. We do it with respect, but we do it.
We just have some developers on the team that are resistant to ideas that don’t follow a pattern until they see it. And sometimes my communication around the initial idea is poor and the best way I can communicate is an implementation.
scarface_74
A POC should just be a happy path to prove a concept. I had a CTO who would routinely throw together code just to prove out an integration or another concept with hard coded values everywhere and drop the code in Dropbox for me to lead the effort of making it production ready as the architect. He would go back and forth with the vendor until things worked.
This helped me out by leaps and bounds. I was usually swamped with other research. I would then make it ready for production or lead the team to and take care of the edge cases, integration with our config system, logging and alerting, etc.
There is a huge difference between a POC and an MVP. An MVP should be properly designed and scaffolding that you can build on, a POC doesn’t take those things into account.
nobleach
While that is possible, I think a good manager recognizes these pitfalls. My philosophy is "everyone has to scrub toilets once in awhile - that includes me". You'd have to ask my direct reports but, I'd like to say I lean more toward taking the "grunt tasks" that I don't think are super helpful for my folks' career growth.
Then again, I've been called a bad manager on Hacker News so...
LeafItAlone
That’s how I see it myself.
Obviously being a good manager is first and foremost, but I’ve always had more respect for managers that I know can (even if they never do) do my job as well as bring a manager. Early in my career at a startup I had a manager that was both and excellent manager and right there in the trenches with you when issues arose or business deadlines were approaching. The amount of respect I still have for that individual is immeasurable and I’d go work for them again in a heartbeat if they asked.
otherme123
And OTOH, nothing worse than a manager that don't know what he wants nor how to do it, but he "will know when it is right", and keep you redoing stuff.
franky53
[dead]
spicymaki
Reading these arguments are funny to me. By now there should be decades worth of research on this topic, all we seem to do is give anecdote after anecdote with no conclusion.
Either no is doing this research or no one trusts the conclusions.
Other topics like this are WFH or RTO, 4 day WW or 6 day WW. We as a profession seem to never come to a consensus.
I cant work for someone who doesn't understand what I do.
An unused sword rusts in its sheathe.
I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building"
He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And then wandered off telling me he could definitely do the work if he wanted to.
I dont think a manager of software engineers needs to code the application he manages, but he should be continually coding something to remain sharp.
TBH one of my current clients produces hardware and software, medium to large enterprise with close to 200 staff. Their CEO can operate all their products, operate the machines that place chips on the circuit boards, operate the injection moulding machines, write SQL queries to pull data out of their CRM and write code. He tries his best not to do it, but he maintains the skills. That's the goal I reckon. Someone who understands the job all the way to the top.