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.
> 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?
For the sake of argument, a company could be structured such that your boss knows what you do and their boss knows what they do but not necessarily what you do.
There are a lot of jobs where the bosses bosses boss does know the job as that’s where they started.
Your post has an authoritative tone but is too reductive and dismisses the real world often working in a completely opposite way, so I’m not sure it’s a credible argument.
He didn't say your bosses boss is not allowed to know what you do, but that they _not necessarily_ know what you do. It's like abstractions: they can be leaky, but you'd better still know who's responsible for what.
While we're on the topic of abstractions, the summary of Bertrand Russell comes to mind:
What is work? Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other such matter; second, telling other people to do so. The first one is unpleasant and ill paid; the second is pleasant and highly paid.
I can think of 2 patches: first, "matter" ("it") can be replaced by "bit"..
(What is the nature of the responsibilities that come with telling people what to do? Towards those who pay, who, if they did not inherit, must also have been highly paid? Towards the work/workers: it certainly helps to understand the work, but if it is neither unpleasant nor necessary, then perhaps "supplying the why" shouldn't be called a responsibility :)
Hypothetically, those jobs could all be very similar if your company did more or less one thing lots, like managing a whole bunch of plumbing contractor teams.
This is pretty far from the original example though.
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).
> 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.
Which they pay you for? Otherwise why don’t you drop them as clients? I’m unclear how that’s “waste” from a business perspective.
Most of us rarely interact with these people so it doesn't matter. They're just the newest placeholder name in the emails I get every few months as they're shuffled around.
> 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?
No. This would be a person who already happens to spend their nights and weekends coding. There are plenty of people who like building things, whether it’s woodworking or software.
> 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?
Maybe, but it would need to be solving a real problem the team has, not just leetcode or some random thing. Part of sharpening the saw is the struggle, and subsequent overcoming, which requires solving a real problem.
But you also don’t want a manager owning a critical path project as the developer. Part of a manager’s effectiveness is being available. That doesn’t work in crunch time when a project needs head down coding all week to meet a deadline.
But if a manager is building a trading bot or chess engine on their own time, they will encounter all kinds of real world challenges.
If you get what you want you'll have a shitty Pull Request for you to review on Monday mornings with your eager boss waiting for your approval on the PR.
> waste their nights and weekends doing a variation of your job
Why is that a waste? I'm an EM and code both at work and on nights/weekends. During the work day, I spend most of my time helping other people directly (code review, talking through designs, 1:1s, xfn collab, etc.) To build larger things, I do them nights and weekends.
It's not a waste. I'm better as an EM because of it. And being a better EM gets me more of what I want (fixing healthcare).
Not everyone can do this—and at some point in my life maybe I can't either—but it absolutely makes me better at my job. I don't consider that a waste.
Code review, respect from engineers, directly feeling the pain points in our development process, I can commit small features strategically (like if a partner team isn't getting a lot of love but we're under-resourced), better partner pairing with engineers, balancing tech debt with new features, shipping directly to users builds empathy
> Why is that a waste? I'm an EM and code both at work and on nights/weekends. During the work day, I spend most of my time helping other people directly (code review, talking through designs, 1:1s, xfn collab, etc.) To build larger things, I do them nights and weekends.
Please take care of your health.
Humans need sleep,
Even when you think you don't.
Try to get enough sleep.
Try to have at least some time during the day where you don't have any mental stress.
I have these videos that keep showing on my Instagram suggested reels that remind me that in a hundred or two after I am dead, literally nobody will have any clue I even existed. If hard work makes you happy, that's good. Keep working hard. However, definitely make time for sleep.
Controversial opinion: you shouldn't need drugs (caffeine) to help you wake up.
For a lot of people, their job isn't 100% of their life and their weekends are reserved for... Life.
I respect you though. I'm glad your job is something you enjoy to the extent you happily regularly extend it into your personal time.
You just don't know how to manage your time yet. This is every manager's first few months. The totality of your work should be done at work, or you're actually pretty bad at your job, efficiency wise at least. You'll tell yourself you're doing more than others, but eh.
Anyway, people told me that and I scoffed as well, so it's useless to type this, it's the type of thing you adapt after going through it.
I tend to agree with your assessment of this post, however as you rise up as a manager and possibly executive, one of the most highly valued behaviors is responsiveness. Knowing things and responding quickly, even after hours, can grease a lot of wheels in a large org.
This is actually another argument against coding as a manager. There’s value in staying connected to the craft, and being able to navigate the code base and answer specific questions with facts has a good amount of value. However in a large technical organization with distributed system the hard problems are always people problems, and hence if you want to grow as a manager you need to orient primarily in that direction. It’s okay to spend some time “staying sharp”, but it can be career limiting if you don’t recognize the higher level problems that only a manager can solve.
We actually can't judge this without really looking at outcomes.
If the parent leans on the hard earned skills to make better decisions that improves outcomes for their team and by extension the org, then it's entirely possible it makes them a better manager.
Where it gets complicated is questions non-related to this:
- Who and how is anyone measuring outcomes? This is often very difficult in abstract.
- Is the org actually setup to allow these teams to flourish? Will the measurement be fair, or is there effectively internal sabotage?
- What's the reward for being better? Would the parents life actually be materially better for making the effort?
Personally, I agree with the parent. On average, having good ICs making your IC decisions lead to better outcomes. Where there's grey areas is there's more than 1 way to structure this. Player managers are definitely valid. Better than non-technical managers with good soft skills making poor engineering decisions over and over.
Where I'd disagree is the continuous effort. Once you've reached a certain level, a lot of what happens below syntax. Occasionally you end up managing something you don't understand with contention in the team.
At this point, you either invest or defer. The problem with the latter, in my experience, is very few devs have experience with commercials, so most of the arguments are based on laziness, interests, or purism, rather than outcomes.
For the record, whilst there's managers we like working for, if they're not able to extract reward for business outcome for the few that chase that, are they actually any good?
Counterpoint: I don't want a boss who is so detached from the rest of life & society that they have copious free time on nights and weekends to practice coding.
> I cant work for someone who doesn't understand what I do.
A better word might to 'appreciate' what you do. I'm mostly a manager/leader/vision person now and occasionally still code. Even though I've written a lot of code over the years, there's no way I could just drop in on a complicated project and understand all the intricacies without some ramp up right now. And that's ok. I appreciate the challenges everyone (engineering, customer support, operations, etc...) I manage faces and trust the people who do that work.
There is only so much time in the day, and if I'm tinkering with Node versions I'm not doing the work I need to get done.
'Appreciating' is a very hard thing to do. I think it's an impossible task for one man. Not only do you oversee many people, but there are so many dimensions you can appreciate in someone.
The way I see it is that for a healthy office, you need to have peers who appreciate each other in a vocal way so that the managers/leads can hear it. Cause not everyone sees what you see. You notice someone is really good with something? See someone keeping up with the literature? Find a way to bring it up in group setting. It's not a given that everyone notices what you notice.
The thing about appreciation is that you can't just say it about yourselves. It always need someone else. You cannot say things about yourself other than your outputs cause it'd only look petty. Only when someone else says it, it's considered. Of course, be proper with it.
All I'm saying is appreciation is a shared responsibility. And if you do it right you might also become someone's favorite person.
True, but not in the way I think you might be inferring. A construction planning/quoting engineer can give incredibly well detailed and highly accurate plans and timelines for building a building, road, bridge, etc. They don't know how to make the steel, or how to weld properly, or how to mix the concrete, or how to measure slump, or a thousand other tasks the construction workers know by heart. I don't need to know exactly how my developer does XYZ, but I can have a strong enough understanding to know if it's the right approach, how long it will take, what problems to expect, how to work around them, etc. I have an on-staff developer who is brilliant, and even though I don't know SQL very well, nor the language our EMR is written in, he comes to me sometimes for technical advice because I understand what is happening internally, and even come up with ideas on how to solve problems without being able to implement the fix myself.
It requires honest appraisals of your own skills and weaknesses, which is tough. But when I give an estimate on programming projects, we hit my targets on time, on budget, because I know how to write a spec, how to manage a dev team, how to QA, and how to keep development running productively. I can code a little, but I'd be the worst coder on my team, but that's not how my time is best spent.
I have 25+ years of dev experience, and currently work as an engineering manager for teams who write code in a language I've never used (but in a domain I understand well). What do you think I'm missing?
You haven’t provided enough information to say for sure. If all your reports are happy, then probably nothing, but that’s a big “if.”
Language barrier can be quite high between JS, COBOL, and Haskell depending on what the situation is. With 25 years of experience, how have you not found the time to learn basically every language used in industry today?
This really calls into question your understanding of the difference between the words "what" and "how". I know and understand what a marketing intern does, but I don't know how to specifically record a TikTok that will appeal to Gen Z with an IQ below 115. And I don't care, because I can measure the performance and fire or hire the intern.
Can you measure the performance and accurately separate it from things like how well Tiktok as a platform is doing, the general economy, and public sentiment about your company?
Of course not, unless you were also an expert on making Tiktok content for the same audience and could definitively say what should and shouldn’t work.
I guess I don't get what's objectionable about working for someone who doesn't understand how you do what you do. Isn't what matters being appreciated? I certainly can't work for someone who doesn't value what I do, but I can care less whether they actually understand how I do it.
I guess it depends on the perspective, and the attitudes of those above you towards your work. If people and product managers are showing deference to your team's expertise in this knowledge domain (whatever it may be), then that's good, and I don't think anyone here is going to complain about that working relationship.
Where folks get objectionable (myself included) is when those same managers conflate superior rank with superior knowledge. It's the CIO demanding we use a specific product suite without objective justification, or the SVP forcing a given architecture because it suits their political objectives rather than organizational ones. That's presently on the rise as tech companies (in particular) bring in "outside talent" (aka, the same failed-upwards managers and leaders of unrelated enterprises in their social circles) instead of promoting from within or hiring qualified candidates, and it results in a whole host of grievances and problems that can rot the org from the inside out.
The clue is the rise of these sorts of posts, trying to coach us on how to step into leadership roles and transition from Individual Contributors to People or Product Managers instead. The takeaway I got was less "managers shouldn't code", and more "managers should not assume their code is better or necessary just because they're managers"; in other words, to strike a balance.
And if they have no clue what the job is about they will inevitably appreciate/promote/give raises to people who talk the most random jargon in meetings rather than to people who actually work.
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.
>>I don’t know man. Can Bezos code? Can he operate a forklift?
Most top level legendary CEOs, could. Zuckerberg, Gates, Jack Welch, Edison, Larry Page, Sergey Brin all worked their way up from the floor to the corner office.
>>At certain points things need to be let go of if you want to keep growing.
This is how you arrive at the situation Boeing is currently. Im sorry but not all businesses have a cookie cut text book way of running things. In fact running any business worth its salt will require you to know the skills at the floor level in a very deep sense.
> Most top level legendary CEOs, could. Zuckerberg, Gates, Jack Welch, Edison, Larry Page, Sergey Brin all worked their way up from the floor to the corner office.
Sure but the tech CEOs success is an anomaly : most if not all the people you cited were able to get to the top because the context was highly exceptional (because personal computing and internet were a total greenfield).
(Also not to mention that, beyond those exceptional circumstances, most of them were already coming from pretty rich families)
Most companies in the world are not ran like this.
I'm pretty sure the CEO of AWS can't do any engineering work anywhere in AWS. He's an MBA and an Industrial Engineer (whatever that is). He used to be a product manager.
You still need to understand what you are selling, like in a very deep sense. Even if not at the technical levels, you need to understand how the financials of it all works, how to take product and sales roadmap forward. How to hire, fire, how to spend and on what to spend.
All this involves understanding the product in a very deep way, and a good deal of technical details as well. Else your staff will play you like a violin.
Absolute hands off abstract management by words won't cut it anywhere.
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.
> 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.
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.
> I cant work for someone who doesn't understand what I do.
Managers are responsible for maximizing what people they work with can achieve. This does not require them to be able to do what their team can do.
> 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.
A counter to this is; a manager of software engineers needs to remove roadblocks impeding the success of the team.
Good managers enable their coworkers, micromanagers weigh in on or perform commits.
> How do you know what roadblocks are valid to remove if you dont understand what they do.
Roadblocks are almost exclusively a "people problem" - politics, identifying stakeholder needs, inter-team coordination, etc.
> How do you performance manage employees if you dont understand what they do.
By working to identify value added to the organization via quantifiable metrics and working with team members to define professional growth tasks relevant to both the person and the organization.
None of the above requires a manager to know how to do what the people hired can do.
>>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.
I'd even go to the extreme of saying the coding skills/brains fade by inverse cube law. Skill =~ 1/t^3 (t = time since last practiced the skill). Musicians are known to say something along similar lines, like as little as a day of missed practice and they can feel it.
I used to be quite good at calculus as a teenager, and today I could look at the easiest problems there are and go blank. Only a faint echo of those days remains.
I have long suspected that Doctors suffer similar decline in ability as years go by from Medical school, and you can be sure in as little 2 - 5 years, most managers would struggle to imagine what writing code could look like.
If your boss can do your job, one of you is redundant.
Managers of engineers should be the interface to the business and other units within the organization. That's a big enough job without requiring coding skills on top of it.
If your boss can do your job, he can understand what you're doing and correctly determine how you perform. One of you is only redundant if the manager doesn't have his time filled with other things.
An engineering manager actually reads the output of the engineers and participates in having it applied to realise bigger projects. He makes higher level decisions about the engineering projects.
You don't really want your senior and staff engineers bogged down with career management, hr disciplinary implementation, team salary budgeting, and all the miscellaneous other duties of a manager. You want them thinking deeply about the code, the business problems, and how the two meet.
In terms of evaluating job performance, you've got peer reviews, deadlines met, contributions in meetings and so forth.
In other words, a manager should have their time filled with other things. Unless the team is really tiny (too many managers), there's plenty for the manager to be doing- planning with product / sales / design teams alone should be enough to keep them busy.
I think that's the crux though, for some reason companies think that a team of 3-5 engineers needs a full time people manager. Unless you are dealing with all juniors or a bunch of primadonnas I don't see how every team needs their own people manager.
I used to work for this guy. He was a network engineer by trade, and I understand a very good one.
However, his story goes, one day he was asked to design a telephony solution for a tech support call centre.
He fell in love with the call centre. He very quickly gained a deep understanding of what they were trying to achieve with the telephony solution and pulled a bunch of critical data out into a dashboard for them after learning how they operated.
He asked for a job and they gave him one. He was an effective manager because he had a deep understanding of the role of the 200 staff he managed, and was able to effectively spot issues with staff based on their metrics.
He could have done my job, but understanding it gave him the exceptional ability to add value to 200 staff at once. Neither of us was redundant.
> I can't work for someone who doesn't understand what I do.
Then you will never work for any human being. None of them will know what you do as well as you, unless they're doing it with you, and if that's the case, they're not really someone you work for.
Bosses become bosses because they want to stop doing the work. They want more money, and more respect, and they want to make decisions without needing to clean up their bad decisions. Bosses become bosses because they don't want to do what they've been doing.
There is no such thing as an engineer who does real work who is paid as much as a manager. They just don't exist in any company I have ever worked for. All managers of any pay grade automatically make more than any engineer of any pay grade, which creates a ceiling for engineers. Bosses become bosses because people are penalized for remaining engineers.
Management simply does not care about the experience and knowledge gained by engineers, and they value it less than a manager who is fresh out of college and who has zero experience with anything.
No, bosses should not code; they chose their path. Fuck 'em.
What do you mean? Figuring this out has been the best thing for my career. Jettisoning jobs where I spend all my time managing upwards is career building.
If one was a coder once, they don't need to keep coding to understand what a coder does.
Plus it's a bit hard to be a manager of different profiles and different stacks and understand what everyone does from a coding point of view (different stack, different frameworks and abstractions etc) especially while time passes and tech changes so much, so quickly.
I do agree that it's important for a coder to keep coding but mostly for the manager itself as it's removes some of the old biases and it's a continuous learning process on something that, technically speaking, they should be passionate about.
Plus it does help to have conversations with other developers and don't sound like a person who only listens to vivaldi at a dnb concert.
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.
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.
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.
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)
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.
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.
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.
If a manager communicated with and listened to their team, but their team had written a web service with gaping security holes or disastrous data integrity practices because all their senior engineers were incompetent and/or were hired at a level that was above their ability, would that manager find out just from chatting with them?
I promise you that it's not guaranteed. You need to actually go looking through the code to find everything that's wrong.
Doesn't work, because the team won't always tell you of the issues that block them (normalization of deviance). Sometimes you need to find out yourself.
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
After thinking about what you wrote here I have some conclusion:
If someone is "good manager" that does all those things whether he writes the code or not he is going to be a "good manager" anyway. Explicitly writing code might not be best use of time but hey if person feels like he needs it that is on him.
If someone is "bad manager" that doesn't bother to deal with technical details and wants only to do "important management stuff" and thinks he can manage by proxies like counting story points or counting closed tasks, does not care about HTTP client A or B and learning the system, he is going to be a "bad manager" and will never even care about writing code.
Finally "bad manager" and "good manager" - is hard to tell because "bad manager" can be good for the company or a team as much as "good manager" and depending on many other factors it can be that "down to earth, hands dirty, good manager" might be really bad for the company or a team depending on business context.
How do you do any of that without extensively reading code? Do you consider reading large volumes of code not "sit[ting] down and cod[ing]"? Just because you're not actually producing large volumes of commits does not mean that it's not coding.
I think "coding" is commonly understood as writing code, not reading code, you know like if I say "I coded google jamboard", someone thinks I developed it, not read the source code. But besides, why do you need to extensively read code to understand whats going on?
Assume you read your code base once and understood it. You get a feature, discuss how its going to be done (well add this table, add these endpoints, etc). You should have a damn good idea already what thats going to look like in your codebase. I don't think knowing all the low level details is necessary (most people would call that micromanagement) and besides writing code yourself isnt going to help know all the low level details of all the other projects
> 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.
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?
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.
> 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.
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.
> 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.
Though the fact that directors have certain biases from how they working into the role does also highlight an issue with this kind of effect: when you have technical leads or project managers on a big multi-disciplinary project, they will have a natural tendency to favor the areas they are more familiar with, and bias the decision-making and planning of the project around that. It can be difficult to step back and optimize for the project/system as a whole.
> 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)
When the company tells your manager "we need to cut wood" and you tell your manager "I need to sharpen my axe", these things are in harmony but it's still a balancing act. The manager should trust your judgement, but they may also have a better view of the short-vs-long-term tradeoffs, and sometimes we spend too much time sharpening. Sometimes we don't spend enough.
I think a good manager should be able to take a swing with the axe to get a feel for its sharpness.
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.
I think every team needs a TL. If the EM isn't filling that role, then another team member should be, and most of what you're talking about falls on the TL (with some sanity checking from the EM by talking to other team members about these things as well)
I think it depends on how it is done, and the kind of ICs you have on the team. It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones.
I've found it really helpful to be a support programmer. not someone that takes on big tasks. nothing with a hard deadline. not something that someone else needs to do their work. leftover cleanup. testing. minor refactoring. build.
you need to keep your hand in the game just to understand what's going on with the codebase. but you're not an a-list player here.
> It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones.
Yep agreed - I've seen a couple of managers that were probably fine as developers but struggled (to their extreme detriment) with being pretty average compared to the senior developers that they were managing. Their 'helpful advice' just served to show how superficial their understandings of the systems were.
Just curious have you managed people? At what capacity (tl? Em? Pm?)? How big was your team? What was the company env like in which your team(s) functioned?
I guess I should have added some context. I have been (and keep swinging between) ic and management roles (including managers) regularly. I love coding and try to sneak in some when I have time (as a manager).
But that a manager should always code is not something i found helping the team or the manager - all the time. One size does not fit all. In startups yes frankly there is hardly a need for a manager and it is TL, TPM, EM role combined into one.
In larger cos though a most managers are innundated with all kinds of non technical work (meetings, alignment, perf management, product discussions etc). While having coded before is a great thing keeping uptodate is actually robbing the manager of time for all other things on the plate (and those actually benefit the team beyond what meets the eye).
Besides at large orgs there is also so much technical (think large scale design and integrations) knowledge that a manager needs to keep track of which also needs time investment.
Then there are various level/career related things that necessitate one or more TLs a manager needs to work with or manage and coding often gets seen as a manager "not doing their job" or worse stealing a junior engineers opportunities.
There's a lot more that is very environmental but hope sets some context.
In practice, many act as an intermediary who can take the credit for the wins while passing down blame for the misses.
It's not a good leadership trait but it's an effective career advancing move.
The entire list on the post reeks of aspirational intermediary that doesn't actually do any of those things as effectively as empowered project/team leads who do contribute to the product. It's fluff and very easy fluff to remove without feeling pain. Of course, mediocre teams will have mediocre developers who won't want responsabilty and will benefit from intermediary "bossy" managers.
Man, I wish the manager's ass was ever on the line. The amount of times I've seen a manager's whole team get laid off and the manager get moved to a different team to fuck everything up again is too many times.
I think I've seen a manager get laid off never. And often seen half their team laid off because they were terrible at their job, but the management class takes care of their own.
Yeah if I implemented my manager's ideas, I'd be the one fixing them too. No thanks - if I have to deal with the problems, I'll decide the solutions too.
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.
> 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.
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.
No idea where these guys work where they can just roll up their sleeves and start coding. I would love to help out but there is zero time for me to code.
One of the reasons I keep doing it is because I know if I fall off the wagon it will very quickly translate into that situation. As long as I have everything set up like the actual devs do and know all the processes, it isn't a lot of time for me to jump in and do bits and pieces. And even though its a very slippery slope, there are absolutely cases where it takes longer to explain what I want than just to do it. Sometimes I will start it off to get the architecture right and then leave a trail of points to complete it with someone on the team. So there are times when it's a "time saver" and it's a win all round.
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.
> 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.
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.
> 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.
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.
Pardon my cynicism, but this doesn't really change anything. These companies are still evaluating their employees, just informally. They are still promoting and firing people. There are still teams who are doing well and teams that are not. There are teams that picked the right goals and met them, and teams that failed to deliver on their promises for yet another quarter. There are still teams with happy stakeholders and teams that infuriate everyone whom they interact with.
It doesn't matter how you measure it or try to ignore it, the buck still stops with the manager of each team.
There is plenty of words written on what the difference is between leading and managing.
True leaders are role models, not higher-ups, the ones where authority comes from competence, not position, showing the way, not just telling what to do, facilitating self-organization, giving direction, prioritizing, giving vision and perspective, not orders, fostering intrinsic motivation.
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.
I've definitely seen this - managers reviewing or submitting code that was woefully unfinished. It forces the team to decide how much to push back against the person who decides if they get a raise in a way that's decidedly unfair. It also taints your perception among the team.
It's that old quote - better to keep silent and be thought possibly a fool than to speak and remove all doubt. If your job isn't primarily coding, and you parachute in to "help out" and end up making more work than you save, that burns a lot of goodwill that you can't really get back. You're not some junior dev that's going to get better with mentorship.
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.
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.
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.
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.'
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?
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.
Strong agree. The best managers I've worked for have been capable of coding and were often former devs, but didn't insert themselves into the team's flow like that.
It's very easy to turn "but I code" into a weird ego trip for a manager to try to look good while just making their team slow down to deal with the fact they're bad at code review or coding at all.
It's not like there's a lack of work to do for most managers that's not coding.
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.
If you can't make a half-day of time once a quarter to fix a bug or make a minor UI change, then I would argue that you are wilfully avoiding doing it, and that some introspection as to why you are avoiding it would be helpful.
Is your environment too complicated to set up? Is the process of deploying something too onerous, and you'll still be trying to get it into production by this time next week? Do you not have any easy bugs to work on, and is that because they all get fixed or just because nobody's recording and triaging them? Is your tech stack too complicated for an infrequent contributor to understand?
These are all really important things to know! And you would know them if you tried to write some code! Any code at all, written at any frequency less than a year apart, would help understand your team.
I am a manger and the best I can do is occasionally fix minor bugs and improve public docs. I feel like doing that is very important to better “stay in touch” with the product.
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.
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.
> 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).
What do you mean by "coding at a professional rate"?
The reason managers should code is more so that they maintain familiar with the state of the codebase. There's no particular output rate required for this, they don't even need to merge their changes, but they should be getting their hands dirty and making sure they still know how the pieces fit together.
I wouldn't trust a long term plan from someone with their head in the clouds. They have to be able to see the ground to draw a roadmap.
If they close a few tickets here and there, that's just icing on the cake.
TFA says the manager should be in the code but not necessarily writing code. I disagree. The only way to be in the code is to write it, even if you throw away what you write. I agree with TFA that the manager should not be in the critical path (unless there's some sort of crisis). But I don't think they can keep current in the state of the code by just reviewing PRs, unless they're a real coding genius.
There are orgs where you ask another team for help unconditionally with your problem affecting the company and there are orgs where no one will help you, huge problems be damned and you can't even get your coworkers to cooperate without going to your (and their) boss.
That's not "working with other people" - that's office politics.
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.
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.
A few comments also mention experience being out-of-date. I expect that's true in webdev, but an embedded C developer could take a 10 year break and still be using the same compiler version.
It varies a lot with context. Manager isn't even a well-defined term.
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.
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.
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.
I think this is kinda the best way. If you're a manger who used to code, do the sort of tedious tech debt stuff for your team. Update dependencies. Build small tooling improvements. Do the sort of stuff your devs probably want to do but have higher priority work that will get in the way. That's likely work that doesn't require you to have deep knowledge of how everything works, but still provides value.
If your project is complex enough that's not an option, then write onboarding docs and other technical stuff. IMO, the manager shouldn't be writing code much, but they should always keep a running version of the project. They should be able to run tests, confirm that PRs function locally, just keep a basic attachment to things.
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.
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.
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.
“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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
As with virtually everything in this thread, it matters how you do it. Sounds like you did it well.
I’ll add one other great edge in building a quick POC yourself. Sometimes your idea actually _is_ bad, and trying to articulate it in code helps you see it.
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...
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.
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.
I've never seen a dual role manager that is actually good. It's usually a senior dev that gets stuck with management duties. They are usually good technically but then lack finesse and knowledge about most managerial issues (budget, employment law, team dynamics, etc). You're now at a disadvantage because the stuff they are supposed to protect you from or have power to help further your career is not developed. If your managers don't have enough management work, then flatten your org and expand their reach so they do.
It really only works in orgs that are large enough to accept a bit of bloat, mature enough to have good managerial practices and invest in growing managers, and where the new manager has only a couple reports (2 is the perfect number). So you take a very good, senior IC who wants to be a manager, you cut their IC duties by 25-50% and you give them 2, maybe 3 direct reports. This is after doing some sort of formal managerial training, internal or external, and with the acknowledgement from their director/senior manager that they're going to be spending more time with them for the next 2-6 months and having skip 1:1s to make sure everything is going ok.
How many organizations do you think check all those boxes and are willing to do that? It's not many.
I've bounced back and forth between IC and EM (intentionally) and I've seen some that get very very close then completely blow it with one of these. One in particular would put people through management training for a full day each week for months, give them a very senior director, all the "right things" but then cut their IC duties by maybe 10-15% at most and give them a team of 12 people to manage. And they wondered why fully half of new managers wanted to go back to IC work after a year or two.
The best realistic thing I've seen, and my current workplace, is pretty good with small teams and training and all that, but basically doesn't offer any pay increase from upper level IC to first-level management and so you have to be okay with basically 20% more work for the same money. It's not perfect but one benefit is you don't get any managers who are only in it for the money.
I don’t see your contact info in your HN profile but could I get in touch with you to learn more about how teams can get this right? My email is in mine.
> Do code reviews. Don't just skim PRs (sorry, reader!), but really dig into them: run the branch locally, test it, think critically about the design and the implementation, and provide feedback. Record a video of your review to highlight things that could be better.
Please no! Most managers want to increase output and engineers are aware of that. It is exceptionally frustrating when your manager tells you during your 1:1 that they want to help move things along and then does quite literally the opposite in a PR.
If you must dive deep into a PR, get the PR unblocked and then follow up with the change. Or stop telling your direct reports that you want to help unblock them.
Anything that can be done in a follow-up shouldn't have to block a PR. But if the architecture is wrong, it's better to fix before than after. You are speeding your teams throughput by pointing out the problem earlier rather than later.
But I don't think a manager necessarily needs to be at this level of detail.
> But if the architecture is wrong, it's better to fix before than after.
Although this is true; if the manager is thinking about and getting involved in architecture after the PR is written it does suggest something has gone wrong. If there are architectural considerations then it is good to discuss them with the coder before they start developing.
PR review is a great time to pick up subtle bugs, do last-line sanity checks or get used to someone's style but if they are a bad arena for combating most code issues. If they are picking up design problems there is probably a process flaw to be corrected.
> if the manager is thinking about and getting involved in architecture after the PR is written it does suggest something has gone wrong. If there are architectural considerations then it is good to discuss them with the coder before they start developing.
That's the ideal yes. The problem with poor design/architecture is that it's never actually architected and designed. It just happens as part of a process where someone codes something without actually considering this to be a "design" (something that will affect future code, and solidify over time).
So the job of whoever it is (senior developer, manager, colleague, ...) is to point out the poor design. The hope then is that it can be fixed before it is merged AND that next time there will be no "accidental design".
This is one of the situations where the ideal is in pretty easy reach. 5 minute conversation when handing out tickets. "Hey [insert employee number here] - how are you thinking about doing this ticket?". Or check in with them during standup.
That one question and a few minutes will both save hours of time and get better quality work. Letting the dev put time into work that gets redesigned in the PR is questionable management. Not the end of the world if it happens every so often but it suggests a lack of context in the job. If there is time to redesign during the PR there was time to think through what was acceptable quality before the work started.
If you as a manager have the time to do an in-depth code review like that... you're doing micromanagement and you're showing that you don't trust your subordinates. And clearly, you don't have anything more important to do.
Modulo the video, I did exactly this when I ran a team, only for what I thought were "important" or "gnarly" PRs. It works. I rarely had to spend more than an hour on a PR, because small, atomic PRs were all but mandatory on my team, with "atomic" taking precedence over "small". I would also review some of the PRs post-facto, after they are committed, as I was almost never a "formal"/blocking reviewer on them.
Recording a video seems excessive to me. No one has the time or desire to watch me bloviate about something that I could say in a few PR comments that can be quickly skimmed.
Can I get in touch with you to ask more about your time leading teams? No contact info in your HN profile but if you’re interested, my email is in mine.
From a practical point of view, I think anyone who has written any substantial amount of code is aware of the cost of context switching. Now picture a diary where you have 5 to 10 meetings a day with 30min free slots in between, and staying on top of emails on top of that. How much thoughtful coding do you expect to achieve?
I think managers gain at doing some coding to stay in touch, and certainly home projects are very useful. But it is impractical to expect anyone who runs a large team to be productive in term of writing code.
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.
It should be unsurprising that we don't really have a science of what company policies work best. There are a lot of variables at play and they likely interact with each other in non-linear ways. Outcomes are hard to measure and may look different at different time horizons. For example, if policy A results in more productivity but makes retaining effective employees more difficult you may need several months or even a few years of observations to truly understand the effects. Companies are quite private about their information and they want control over their own company policy. Experiments are costly to perform. How would you perform one? Randomly select a bunch of companies and try to randomly get them to adopt different sorts of policies?
I think this is why you see a lot of herd behavior amongst companies. Some business leader who feels they just have an intuitive sense of what's best just tries something. Are they right? Who knows? But if the company does OK it is evidence the policy isn't a total disaster so more companies follow suit.
I upvoted your comment earlier and came back just now hoping I’d find it at the top with replies linking the research that must exist. But no; you’ve just been buried under a mountain of anecdata. Ohh well.
What profession does? You realize there are vested interests, competing interests and a varying degree of people optimizing for their individual careers, right?
Summary: Managers who know how to manage, but don't know how to do anything are not the best managers. The best managers are the great individual contributors who never ever wanna be a manager but decide they have to be a manager because no one else is going to be able to do as good a job as them.
Managers who didn’t want to be managers are the worse ones. They don’t know how to play politics and compete for resources against other managers and make sure their team gets raises and promotions.
The skillset you need for management are different from those you need as an IC
Yes and Steve Jobs led illegal collusion between most of the big tech companies to keep compensation down. He wasn’t exactly the most employee focused CEO.
There's a third option that's missing from that dichotomy: people who are OK individual contributors but who are actually really good at managing people.
These are the best managers, because they have the disposition/skills to be a good manager, but also aren't going to make dumb engineering decisions.
IC's who become reluctant managers are generally terrible managers because it's not what they're good at and not what they enjoy.
let me add a fourth then: ICs who had really great managers and became great as a result, and when given the opportunity decided to then become the next great manager and mentor the next group of great ICs.
This comes from the perspective of someone who manages managers. So if you're looking to hire managers, and don't care about retention, perhaps this is good advice to follow.
But if you're looking to evaluate your manager, or hire managers who can retain great people, maybe not the best advice.
"But what does this mean for frontline engineering managers? Is the new normal just about writing more code and doing less of the other things that peacetime managers would normally do?"
"Should they be able to do code reviews? Yes."
There is no standard answer here. At many companies it is the Head Of Product who also oversees the tech team. They may not know how to write code, and will not know how to do code reviews. Some project managers lead engineering teams without knowing how to code. That's especially true outside of the tech industry.
For anyone interested in specific numbers, I interviewed Eric Garside about his experience scaling Freshly from 3 engineers to almost 80 engineers, see here:
My view - as a manager - is that as I get older (simply put) I’m not as good any more as my younger team! While I help them, I also learn a lot from them as well. And I love that.
I have experience: project management, real life, edge cases, dealing with C-levels and customers, risk mitigation, being calm when sh*t hits the fan, mentoring, etc. These are things the team benefits from far more than my fingers typing away.
At the same time, if I’m actually doing my job well, I really don’t have time to code.
I also want my team (senior and junior) to have a feeling of ownership. The company has goals and directives, but what’s being built belongs the team, not me. All the successes are theirs, and the failures are mine alone.
When do my fingers hit the keyboard? When there’s a time crunch (if I’m not willing to work more how can I ask the team to?), when the team is having a difficult time with a particular problem, or maybe when there’s some downtime and I can fix a few outstanding bugs or work on something extremely isolated (I never want to get halfway through something and then have to hand it off to the team).
Background: I used to be a developer and have managed developers. Now I work in info sec and manage info sec.
Longer answer: this question has been discussed throughout my career.
(1) Does it help for a manager to understand what a team does and needs to do? Absolutely yes. Some managers can do this without domain experience but it's a lot harder for them and the team.
(2) Should a manager keep doing what their team does? Probably not. I can actually do most of what my team does faster and better, but they need to learn to do it. I don't scale. I can mentor them, and if there's a need for more resource I can get it for them.
Edit: I do actually still write code - but just in my own time because I enjoy it.
A lot of what's in the article resonates with me. Specifically, I've seen cases where managers unwittingly use coding (a problem they feel comfortable with) as a way to escape from facing more serious manager responsibilities (problems they don't feel comfortable with). When you've got 10 years of experience doing X, and you just started doing Y two years ago, it's natural to try to play to your strengths by doing X.
But as a manager, there's a whole category of things that only you can effectively do, because the social environment and power structures are set up that way. In that context, coding is a distraction for a manager. Writing code often takes a lot of mental energy and stays in your head even when you're not at the keyboard.
I don't want my manager getting nerd sniped when they should be coaching a struggling colleague, advocating to upper management, having a tough conversation with a toxic team member, or reigning in the PM.
I’m in favor of managers being engineers but everything you wrote is true. I wish I had read this comment a few years ago, it would have saved me and my teams some trouble.
I understand most people have negative experiences with managers that can't code, but I would argue that the experience with these managers would also be bad if they could code.
You don't need to be able to code as a manager but you need to be highly skilled.
The only problem that arises then is that for decisions based on technical knowledge you have to trust others.
The main problem I see is that a lot of managers are too mediocre for the job and compensate it by trying to sell themselves.
Back at my first salary job, the CTO of the company would occasionally jump into the code base to write some code when everyone else was busy .
It was a very small startup, but seeing him do that motivated me to work harder. It was also just a very awesome thing for him to do, since he could have just said no I have to go pick up a pie this evening figure it out .
Below him, the best manager I've ever had, was regularly writing large amounts of the core code base. In my opinion this is really good for team morale. If you want to call yourself a startup, this is how things should be done .
When I think about it, I really would only like to work for startups with around 50 people or less, or mega corporations. I don't particularly like the quasi 1,000 person start up with 800 rules, and a lack of stable funding.
Managers should not be evaluated based on code output -- it's not their job. However, writing code here and there -- to evaluate new technologies, make a rough prototype, or demonstrate a technique to be adopted by individual contributors -- may aid them in their management responsibilities and should be embraced when it does.
I've seen what happens when a manager is also responsible for individual coding duties. He ended up with roughly twice the work, shifting between two mutually incompatible mental modalities all the time, cranky with his subordinates and making a lot of sad phone calls to his fiancée explaining that he'd be late home from work, again. Not a good fate for any worker, even if the pay and prestige are better.
Middle management for software engineering has gone through a paradigm shift. The trend for businesses is flatter structures, manager roles with more responsibilities and this reality largely includes being as deep in the code as direct reports.
Since 2023, most roles I reviewed or interviewed for were player/coach roles, often close to 50/50 split. In my last EM role, I was hired for exactly this.
I found very few EM roles that are primarily managing with only "being in the code"; I can count on my hands out of hundreds of Engineering Manager roles. Probably closer to 95% or more EM roles require hands-on technical work similar to Tech Lead roles.
I have noticed this as well, and if you're interviewing at a startup, it's almost guaranteed to be a highly technical position. Either a hybrid EM/Tech Lead role or a hybrid EM/architect role.
Yes, managers not coding was caused by ZIRP. It's a dumb idea.
- You need to understand the work to evaluate your team
- You need to understand the work to prioritize and rank what's important
- You need to understand the work to know which roles to hire for
- Good developers typically don't want to have a non-technical engineering manager
- The budget for a non-contributing team member reduces your budget for engineers
- It creates a more hierarchical and less flat org chart, which creates communication scaling challenges
I would only consider non-technical managers for companies with large budgets and a non-technical product. Not only should they be technical, they should be excellent.
This is a good article, and I find myself agreeing with it almost entirely. My current manager is one of the most effective development managers I've ever had in my career, and I think a good part of that is because he is involved in the codebase, but not directly responsible for new features in whole.
I have had managers with no concept of what's going on the codebase, and those were dysfunctional development teams that produced poor results, despite great communication and productive meetings.
I have had managers that were effectively another engineer on the team, and those were dysfunctional development teams that produced decent results, but had poor interaction with stakeholders and no unified direction.
As in many things, the ideal seems to be a happy medium. Someone who can read the code, who can write the code, and is interested in both, but whose duties are not primarily to do so.
I agree with this sentiment! One way to set up teams is with a squad leader who acts as shit shield first, and developer if the company is running smoothly. That way if the boss manager is a full time shit shield with little time to understand product, the team still has a local product owner to guide the team’s vision and concept of the product, but the power imbalance is also less as the team lead could fairly easily be deposed by accessing the manager.
One important distinction to make is the difference between a manager who started out as an IC on the project (esp. the case when they actually built the thing from the ground up) versus a manager brought in from the outside. I think the former is more likely to be hands-on and generally speaking the expert in the room. But, sometimes you need the latter. It can be challenging (even counterproductive) for the latter person to try to be technically relevant, when they are often the least technically knowledgeable person in the room when they join.
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
As an aside, I like the implied job description in the article:
- Hiring and retaining great people.
- Owning the team's strategy and roadmap, and ensuring efficient execution.
- Making decisions to ensure that the team is working on the right things and saying no to the things that don't matter.
- Dealing with fires, escalations, and other crises that pop up all of the time.
- Building a strong culture within the team so that people are engaged, challenged, and motivated.
- Mentoring and coaching your reports so they get better and can have more work delegated to them, thus increasing output further.
- Managing the team's stakeholders so they can offer their steer to the team early and often.
- Actively performance managing the team so that superstars can continue to shine and underperformers can be coached or exited.
- Building close working relationships with other teams so that smooth collaboration happens across the organization, leading to a better and more cohesive product.
I don’t think you can answer this for all managers of all teams all at once. Most of the time the answer is probably no but sometimes it’s not. Sometimes good managers want to code and they need to in order to stay happy. Sometimes your team is fast moving and small and your manager needs to code to keep up. Sometimes your manager is so busy managing they can’t. It just depends.
> It depends on the manager, the team, and the organization. As a senior leader, I would rather my managers be in the code as per the above list, but not necessarily putting themselves in the critical path by writing code, given that they are likely to be interrupted more often, have more meetings, and be pulled in more directions than their reports.
I once had a lead programmer (who was a great one) who insisted that a manager should not have access to the source code of our project. I have often worked with engineers who were nervous about who could check in code so I kind of understood. And this really was a great lead, technically strong and a good leader so I said, fine no code access for me.
It was a terrible mistake for me. So much of my value as a manager was being understand what the engineers were doing. I am not a great programmer but I can do it, and I could usually understand what an engineer was trying to do from looking at their check ins rather than listening to them in stand ups. I was just not that useful. There were times when the team was doing things that I knew I had seen done before with much better before with different methods, but just talking about it was relatively ineffectual.
I'm a good coder, not a great one. I hire great coders to work for me so that if I had to write code I would be the worst and least productive person on the team.
Therefore it is to everyone's benefit that I don't touch code. I do sometimes put on an engineering hat and help with brainstorming how we will build new things, or asking questions about open issues that no one has asked, but that is the extent I will get involved in engineering. I try to only get involved when it's something where my decades of experience will add a lot of value.
And historically all the best managers I ever had were the same -- former engineers who could understand everything we were talking about, but did not get involved in coding or code reviews.
Your manager should never be a blocker to getting things done.
A manager should never write any code that is part of the critical path of the deliverable.
Every single time without fail that I have had a manager who still tries to be an active contributor, one of two things happen.
Either they never keep their commitments as a coder because they are spending too much time on their management duties including meetings, manhole up, and career development for their reports or they are horrible managers who don’t or can’t do what I need from them as a manager - get me the resources I need to do my job, play politics and manage up and especially fight for raises.
Curious why large open source project (like linux) have no manager for all the political stuff but works well but every private company have a huge management chain for less complex stuff.
Entry level managers (supervisors in working class tongue) code. They are often player coaches and own a series of tasks. They work more than the other guys and are compensated more and on the manager path. They are lieutenants or sergeants.
Directors manage multiple supervisors and own a complete function. They are like colonels. They don’t code as their job is aligning with senior management and across teams/divisions/organizations. It’s political.
As a manager, I make a point to produce some code that makes it into production every quarter, but my reason for that is not because I can't help myself from writing code. Rather, I want to understand the pain of the sdlc. I want to understand firsthand how long it takes to get something deployed and how many steps it takes. Being able to empathize, rather than just sympathize, with my direct reports has made me a better manager.
I come from the $MegaCorp world rather than startups. We shipped massively successful products reaching billions of people.
Our managers did not write code, nor would they have been better managers if they did, IMO. They represented the team to the wider company, they facilitated communication across teams, kept us informed of changing goals and priorities, etc. Basically helped everybody row in the same direction.
- It's dangerous for the manager's career to lose the ability to code. After five years they will have regressed nearly to a Jr engineer's ability and would need significant effort to get back into interviewing shape. I've interviewed so many managers who didn't like management or aren't quite good enough to stay in the management track who can't even remember how an if statement works.
- Small companies and early startups are much more likely to need engineers over politicians, so the manager working on engineering is much more helpful in smaller teams.
In my experience in all pretty small companies, keeping hands on the keyboard was essential for me and the team. This was great because I got tired of being a manager and wanted to go back to pure engineer again.
I find a good manager treats me like a peer and not some superior. Part of that is being in the trenches and having experience with what I'm working on. Maybe they're not taking on entire features anymore or doing the same level of code review as others but I think for a manager who manages ICs - they should be much closer to the code. Maybe this would be the "team lead" in some companies or a supervisor type role but I think I prefer that kind of person to be my actual manager than some other nebulous person who doesn't even interact with me on a daily basis.
A big problem I had with some managers who didn't code was that they sometimes had wild expectations. They were also not good mentors. They couldn't really teach you much of anything because their job was so distinctly different from what you were doing.
Tldr: managers should be in the code, but should not code themselves.
The article suggests managers should focus several tasks that depend on the ability to code, but not produce code themselves. I think that's not sustainable. When a manager stops producing code, their skills in that area begin to deteriorate. I've seen it happen several times. When you stop coding, you'll eventually start missing crucial things in code review, make very poor estimations of labour involved, and assign the wrong team members to tasks. It won't happen immediately, but it will happen within 5 years.
I think a better way is to keep producing code, but at a lower rate. If the project you're working down doesn't permit low-commitment development, start developing tooling or pick up a side project. A coach doesn't need to be a top-player in the coding field, but they do need to remain fit.
One of the most regrettable things I did was stop writing code. There were the usual things; to busy to keep it up, not a good look in mgmt circles, keep coding hurts your upward mobility potential etc., all true, but I felt I was on a slippery slope towards effectively managing development.
Tech is in constant flux. While the basics rarely change, and yes, there is a lott of reinventing the wheel in programming approaches, thongs do progress and you feel your grasp weakening.
So now I code again. Not daily, but enough to complete some projects on my own. It feels great, and it definitly has a positive impact on my overall capabilities.
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.
It can help but it's not essential. Most coders make lousy managers and most mangers make lousy coders. Sometimes you find people that can do both.
The meta question here is do you need a person to manage you or can you perform at your peak without being micro managed. If so, you might be management material ;-).
I've worked as a employee, freelancer, consultant and lately as a CTO. As a consultant you tell managers how to manage. When freelancing you don't lift a finger unless you are told by your client, who is not your manager (important to be able to tell the difference). If you start consulting them effectively, make sure you increase your rates.
If you are an employee, you might have a career path that may involve you evolving into a manager. And as a CTO of a small company it's my job to make sure shit gets done. And sometimes that means getting hands on and leading by example. And sometimes that means delegating work and optimizing my time use. And sometimes I like having some fun. I hate delegating fun things.
A CTO that isn't hands-on is not a CTO and cannot provide long term meaningful technical leadership. Any technical skills they have don't have a long shelf life. Companies with no CTO and a hands off VP of engineering are probably not technology companies. This is a problem if they are trying to be one. Or used to be one.
I've consulted a few of those. I've also advised startup founders to not hire a CTO and instead find themselves a good VP of engineering. Because they weren't creating a tech company and their technical staff was OK but clearly not management material. In a startup, CTO is a founding role. A tech lead reports to the VP of engineering, a CTO reports to the CEO. Or sometimes is the CEO as well. Big difference. The VP of engineering is not a C level executive typically. They aren't co-founders. They don't hold a lot of equity. Good CTOs that can double being a decent VP of engineering are rare. Very different skill sets. The opposite is more common.
We got along better before all these managers arrived, could ship huge projects with 100 people and one ceo. And the ceo wrote code and didn't do any of the nonsense most managers fill their days with.
Yes, because you need to have a feel for the quality and direction of the systems your organisation is building and maintaining, independently of the people you have dominance over. Because that hierarchical relation itself will make it hard for them to accurately communicate to you how it's going and the more time you make them spend explaining things to you instead of cooperating with each other, the worse for the team that actually gets stuff done.
You should also keep using programming and automation to perform managerial tasks and not degenerate into constantly droning away in some mind-numbing office software suite.
Should managers know about what they are managing in general?
I know most people will say yes but many will argue they don't need to actually do it to have that knowledge. But my experience is that with software and IT, things just move too fast for that. Managers need to continuously stay active at some level to keep up to date enough to make reasonable decisions from a management perspective. Of course it always depends what you mean by "manager", if you just want someone to approve leave, check on project status and organise birthdays, farewells and christmas celebrations .... well yeah you are wasting someone who can code on that.
It should be mandatory they code a bit. It should also be mandatory they don't code too much.
This may not have been true in the past but times have changed in my 40 years as a programmer.
Don’t allow your skills to atrophy. If you get to a high position, it’s much harder to find a job at that level. If you can code, you can always find something.
If you can’t code, and you can’t get a manager role, you’re in trouble.
That’s why I have one year of expenses in a liquid savings account in addition to retirement savings. So I can have the runway to get back into coding if necessary.
Are you proposing that they do coding on the side after they get off of work? I have a strict policy of “no side work” and I have since graduating from college in 1996. When I get off work, I don’t think about computers again until I go back to work the next day.
I’m not a manager. But I am now a “staff software architect” working full time at a third party cloud consulting company after pivoting from software development and doing a previous stint working at AWS in the consulting department (full time direct hire - AWS Professional Services).
My specialty is supposedly developing applications using AWS services. But as I moved up I find myself doing no coding.
My job is half working with sales and being the first technical contact for a customer and writing long and detailed requirement documentation and getting the customer to sign the contract for us to do the work. The other half is as a tech lead coordinating between the customer, project manager, sales, and the subject matter experts on our side who lead/implement the various “work streams” (development, data, cloud architecture, etc).
First issue, when I was looking for a remote job last year and the year before as a developer as a plan B job, every opening had hundreds of applications and I heard crickets. This has never happened to me and I looked for software development jobs in 1999, 2008, 2012, 2014, 2016 and 2018. The job at AWS fell into my lap in 2020.
It’s a shit show out there right now for software development jobs especially remotely. Did I mention I was looking for regular old enterprise Dev jobs?
On the other hand for differentiated strategic cloud consulting jobs, I had no problem getting offers quickly.
No thank you. All of the worst managers I've worked with know just enough to offer annoying suggestions but not enough to understand why it doesn't work (usually workplace politics). Sometimes I can't "just" do anything. The best ones I've worked with used to code 5+ years ago.
I don't want to spend my time managing my manager. He thinks I'm an idiot because I can't follow his simple instructions and I think he's naive and ready to fire me. Bad for all of us!
Isn’t one of the best gifts a manager can give to their team, the gift of clarity?
A manager able to give their team programmatic tests to pass brings a level of precision which makes it much easier for them to know when the work is done.
If managers communicate requirements in the form of acceptance tests more often, then the problem of projects running over time and over budget will occur significantly less often, because there will be clear finish lines for dev teams to run towards and cross, and reproducible pass/fail outcomes to inspire confidence.
Of course they should. The volume does not matter as much as the depth. alternatively you could ask "Should managers understand the domain in which they work"?
There should be fewer layers of middle management and more individuals who genuinely understand why they are building the product and for whom. Success is ultimately defined by how effectively your product solves customer problems — everything else is secondary to that goal. I've had brilliant managers that never programmed in their entire lives and had horrible managers that had >10 year experience programming.
A lot of this really depends on the scale and scope of the codebase(s) that the manager is accountable for. Staying on top of a service with a few very clear usecases is very different than staying on top of several services, jobs, and tools across multiple repositories.
The ideal is to try and structure code in such a way that it "screams" about what is going on, but realizing that ideal in some contexts is extremely difficult.
Big distinction we’re not talking about is: coding just to stay sharp, or coding to actually merge to production?
Strong no from me on (2). Production coding takes tiime and focus and would eat into manager’s management work.
On the other hand, managers at all levels should actively engage with the output of their org. For the direct manager of a development team, that means periodically running the build, maybe coding on weekends (which I do) to explore ideas and prototypes, etc.
This comes at a good time for me as I’m being threatened with a promotion from dev to management. But I have a question: I am being told that for SOX compliance, the manager approving a release can’t have any code in the release. Any devs or managers at publicly traded company that can tell me if this is bunk or not?
I'm manager and contribute every week for clean up, refactoring, add tests, extra e2e testing and overall fixing issues in existing development and production environment that are either too boring or affecting team operations. Sometimes contribute to small features but I make sure Im.not blocker or promise things to anyone (mainly work on experiments with no SLO)
A manager of developers should know how to code, but any formal expectation of them coding shouldn't exist. This holds for medium to large organizations. The managerial duties should be enough to require the vast majority of their attention. Expecting development on top of management is a way to add fake capacity to a team to help ensure burnout.
20 years ago I got tired of programming day-to-day and became a manager who still dabbles in development. I don't contribute to production code, but I do architecture, prototyping/research, and will roll up my sleeves to help a stuck programmer do debugging.
> If you mean being the primary implementer of features, then probably not.
It's my belief that any engineering manager worth their salt should push back on this and argue for a seat at this table, every single time. I don't want to work for someone who is disinterested in new functionality in codebases under their purview.
I want my manager to manage. I need them to play the politics to get what I need as far as resources, to set business priorities and to make sure I’m aligned with those priorities.
I need them to then trust me to accomplish the objectives myself on smaller implementations or to lead the team on larger implementations.
I'm not asserting anything about if a manager should code, but rather calling out a statement in the article. A good engineering manager should never be surprised by some new functionality.
Keep in mind that many companies don't do non-coding engineering leaders anymore. So from a career perspective, if you take a role that's non-coding, you are making yourself unemployable for large parts of small - medium sized companies, as well as larger companies that don't do this.
Practitioners need to be led by a practitioner. I worked for a while with a team leader whose only connection to the team was absorbing credit, giving confusing orders and acting like he saved the day. I dont want to work with aggregator managers ever again.
I don't code much anymore, the vast majority is reviews the only time I really need to get on the tools is if it's a concept that I need to teach someone, or more likely, something has gone quite badly wrong and it's 2100 and I don't feel like waking anyone.
Absolutely not. Nothing like an out of touch manager slowing down their engineers with random PR comments and questions. They should not go deeper than the design document/architecture level. They are not adding any value trying to put their washed skills on display.
I code a little but largely on the periphery of stuff so as to not be in the critical path. I try to fix small bugs snd keep up with the code base but with nine reports I've got much other work to do.
Should managers still code... or... should managers know how to code? They are very different questions. The former answer is probably no. The latter is much more interesting, IMHO.
If they're directly managing coders, then they absolutely must be able to build, tweak, and run their product by themselves, and articulate the reasoning behind its design decisions.
i lead dev teams in the consulting world, I don't code even though i really want to. Sometimes I get pulled in for time sensitive work or the hard stuff but that's about it. Every time I get bored as a manager and reserve some fun stuff for myself a crisis happens that needs my attention and then the code falls behind schedule. So I guess that's the end of that.
i like the analogy of a sports team coach for being a manager. You can motivate, cheer, train, and drive the team to victory but you can't step on the field.
I think reliable managers probably don't have enough time to write codes (unless they work 70~80 hours week), but at least they should be able to review other's code.
One important caveat: I recommend that managers take on coding tasks that are SMALL and UNIMPORTANT. Leave the key work for the front-lune developers (feel free to code review it).
At one point in my life, I became a manager that didn't code. Way too many meetings, travel, and non-technical things to do, so no time and most importantly, no headspace left for coding.
Over the course of about two years this drove me to mental issues. I was unhappy, I could not have a technical discussion with people working for me, I felt inadequate and dumb. On a practical level, I was expected to make technical decisions, but couldn't, because all I had was poorly communicated information from people working for me. That is not enough!
I realized two things:
1. It is not possible to do technical management without coding yourself. CTOs that don't code are not good CTOs.
2. I never want to be in a work situation where I am away from coding.
Since then I've been very happy, first co-founding a business where I had a CTO role (and coded), and then solo-founding and running a business where I code all the time.
Anyone in a people leadership role has to have a political mindset. You simply cannot be technically oriented and politically oriented at the same time. This is not a negative, the human brain, generally speaking, can't focus on two unrelated priorities at the same time.
I have had a highly negative experience over this. When resolving technical conflicts, you expect technical merit and reasoning to be used. But managers who also meddle in technical affairs use political leverage and tactics to see their desired technical outcome. This is a very unpleasant and toxic affair overall.
Imagine trying to solve a bug, but your manager wants a specific work around implemented which will result in bigger problems down the road. If you disagree with your manager, your performance review will suffer, you will be called disagreeable, hard to work with,etc.. You are only considering the best course of action from a technical perspective. Your technical peers can also review your code and reasoning and you can debate in a civilized manner over the technical merits of the issue. But as soon as a manger is involved, things will get toxic fast. It is nearly impossible to avoid micromanagement as well.
Especially if the manager really knows what they're talking about. Then they'll really be looking over everyone's shoulders and causing drama.
It is such a disorienting thing, having to fight political drama over simple and straightforward matters. This is how I learned what gaslighting is! I would be reaching out to people I consider a lot smarter than myself, asking their opinion on the subject (and they'd mostly agree with me), because I legitimately got disoriented and doubted everything I knew.
I really hope none of you experience this. At least when someone is being mean/toxic for other reasons you can explain it away, but when they use their technical expertise, that's a whole new level.
The whole concept of your management trusting you with the details and expecting you to show result goes out the window this way.
> If you disagree with your manager, your performance review will suffer, you will be called disagreeable, hard to work with,etc
I think your experiences sound like a case of a very bad coworker, whether manager or not.
I don't want a manager who knows nothing about the applications and the architecture. I have no desire to punch a clock and be coddled with public mentions and work parties. I want to work with people (including my manager) who want to solve problems together, and solve them the right way.
There may be problems that arise because my manager is busy trying to do technical work but I'll take that any day over a manager who can barely speak the same domain-specific language, constantly gets facts wrong, gets upset as a result of their misunderstandings, applies arbitrary deadlines and expectations, and calls for endless status requests in the midst of all this. No thanks.
Oh and forget any kind of technical direction! Because your manager is forced to accept what people tell them, it becomes a free-for-all where the programmer with the biggest ego wins.
And yes, I too am essentially just describing a hypothetical bad coworker. There are probably some great managers out there who are ignorant of the technology. (Ugh.) But I will put my money on 'technically proficient' or 'involved in the code' every single time.
it depends. Last ~3 years i was CTO of small company - with a software team of 7-10. With the idea of - no-more-coding (TM). Just the other 90% - from cleanup repos and jira etc project things - to organise proper reviews and workflows - process things, etc, to.. pushing infrastructure, hiring and pitching to investors/clients. But the codebase was.. not ideal. It was hard and tempting but i managed not to touch it directly, only did rise architectural-and-similar-level issues, and did (somewhat nitpicky) code reviews - like, date-arithmetic IS very important, pretty-please. Still, had to build a crawler over the production-codebase to visualise the event-flows and map consequences - a reverse-engineering live-Documentation, kind-a. Scratching my own itch? pfft. (hint: There was no other docs..)
But then there were some small non-essential projects that would have been complete distraction for the team.. so i took one, then another. In nodejs which isn't my cup of tea - so even better, learned some things the hard way. Though.. lucky they were rarely needing support, or it would have become a chore.
Then, one day, the company was acquired, and.. i am not a CTO anymore, but a (tech and also non-tech) Lead of some future greenfield project, ~re-factor with diff.goals. So here we go - research, architect, code, hire, discuss, demo, eh.. usual tiny-startup thing - except that the politiking and the now-everyday-a-new-policy chase me away.
So.. IMO one has to keep some of the programming skills sharp. In order to stay relevant. But this applies when you are 1 level away from actual coding. If farther.. probably no time, and no point. Although.. too long staying hands-off, and there may be no coming back - and losing grasp of how-it-feels-like to be in the trenches.
I was a manager for about 9 months before being laid off. The goal was to attain power but also work on the huge backlog of work we had. I wanted to use the power to block outside forces that would push my engineers in the wrong direction or remove their focus for investigating things like platform bugs.
What ended up happening was that the project work even though completed was used to gaslight me for 6 months as breaking the platform and causing bugs. Issues that infra team promised to “fix later”.
Go ahead code when you’re a manager it can be effective, but be careful when working with outside ineffective teams they will put blame on you if they can. Management is political and once you start making moves that outshine other teams, opposition will come out of the wood work to bring you back to their level of unhappiness.
The trick to identifying this is when people start naming you at meetings you aren’t in. It might be good things they are saying but that may shift as the good things well dries up.
Ex-Dropbox manager here. I also built BetterHelp (sorry) and I was the VP of Engineering Grooveshark.
Dropbox was the first job I've had where managers are not expected to code although they still go through a small ramp up where they can fix a tiny bug or make a hello world commit and deploy it to production to show that they understand how some of the systems work. Due to some crazy circumstances with the team I took over, I never even got to go through the ramp up. I was thrown straight into the deep end leading a team dealing with an urgent crisis that could end the business.
It was scary as hell, going from what in hindsight had been a "TLM with extra responsibilities" in my previous jobs to a full fledged EM role with all of the same accountability for quality and timely production, but none of the direct control. But I quickly realized that I was surrounded by people who were at least as capable as I was and usually more brilliant.
I think my greatest technical strength was always in eliminating technical complexity, making systems more robust and maintainable. It turns out you can still spot the blinking red lights of unnecessary complexity just by talking about the systems from a high level and asking the right questions, and when you help other talented engineers see those problems, they will naturally want to fix them. No need to jump in and do it yourself.
Once I knew I had a team I could trust and understood the strengths of the different players, I had to shift my focus to learning how to be a real manager. Managing people is a wildly different skillset than writing good code or building a good product, and I realized that I had never really been a manager despite leading teams of people. My apologies to everyone who ever worked for me before this point. Without realizing it, I had always treated the human factor as an annoyance and I probably hindered the growth of past teams a lot by stepping in and doing the high stakes, high urgency stuff myself.
When folks grew under me, especially at Grooveshark when I was young and immature, it was a happy accident and not something I was very intentional about. At Dropbox I really learned the importance of investing in people, giving them opportunities to grow and creating space to allow them to make mistakes. I didn't touch a line of Dropbox code or ever commit a thing, but my teams were high impact and many of the engineers who worked with me told me I was the best manager they've had.
Now I'm a co-founder at my own startup and, of course, I'm writing code again. Yeah, I'm a little rusty with some of the language specifics but I've been talking to brilliant engineers about their work for the last 7 years, when it comes to robust system design I'm probably a better engineer than I was the last time I wrote production code that was used by tens of millions of users. I will of course be in the hybrid role of building and managing folks for a while, but I hope I can keep my manager chops honed and support my team properly as I build and grow it and, eventually, stop writing production code again.
Managers should never write or review code. This is a fundamental principle of human work, it has nothing to do with code itself. Honestly I don't know what insane HN meme started this trend and made it acceptable, but it really needs to end now.
The whole point of different roles doing different things is distribution of labor [1]. This idea is thousands of years old, this shouldn't come as a shock. As an extreme oversimplification, the people who are very good at a particular thing, should focus on that one thing. The more responsibilities or tasks someone has, the worse their output will be. Specialization enables higher quality, faster work, with less difficulty and waste.
A coder's job is to write code. A manager's job is to manage people. The author's post listed nine different important responsibilities for managers, that has nothing to do with code. But then just brushed it off, like it's easy! People, these aren't easy things to do, nor are they quick! Just doing general management work will easily suck up 40 hours a week on any team. If you've run out of management tasks, you probably aren't managing well.
Almost every manager I have had has not performed well. With the exception of one, they never trained as a manager, nor read or understood the basic yet critical functions and skills of a manager. Some of them used to be engineers and were just promoted up to a job they are incompetent at (the Peter Principle). And some moved into the position from some other job that wasn't management (or engineering management). On top of that, often there is a shortage of project managers, product owners, etc. These are critical roles to ensure high-quality, faster output for a team. In the absence of people filling those roles, and on teams that are not high-performing teams, it's up to the manager to fill those roles for their team.
So now the manager is not only responsible for the careers of their direct reports, they're responsible for keeping the team on track and producing high-quality, fast work. I've only ever seen one or two managers that could accomplish this feat - and that's before we add-on writing and reviewing code. How the hell are they supposed to get the time for all this, much less build up expertise in all these things, simultaneously?
I would argue that knowing how to code at all makes for a dangerous manager. I've had several managers turn into micro-managing freaks, telling me how to do my job, even preventing me from doing my job. They insisted they knew better, because they had written some code in the past, or adminned a server one time... yet I'm the one with the most experience and skills in that field. (Dunning-Kruger seems worse in those with authority, who don't wield it with humility)
On the other hand, the most effective manager I have ever had, had zero idea how to code. Because he was not technical, he focused on his actual job: mobilizing groups of people towards a task, measuring its progress, helping resolve human challenges, protecting his direct reports, and helping them progress in their careers. He never once told me how to do my job. He instead asked myself and my peers a series of simple questions in order to have us explain what we were doing, and through that process, we actually discovered several times that we should do it differently, or solved our problem.
So if the manager isn't writing or reviewing code - who will?!
An engineer's job is to build things. So someone who specializes solely in engineering should be reviewing code, designs, etc. There are many different roles for people who do this - software architect, systems architect, engineering team lead, staff engineer, principal engineer, etc.
A long, long time ago, the whole point of having "Senior" in your title was to convey the fact that you were an expert in your field. If there was a "Senior" engineer, that was the person you went to to tell you if you're doing it right. Hey, I just wrote this algorithm, does this look okay, Senior Engineer? I'm changing this field, can you see anything that might go wrong, Senior Engineer? Now of course it just means a college grad got a promotion after staying for 2 years.
Not having a real Senior Engineer somewhere in the company means you are going to end up making some real turds. Having a manager take the place of a Senior Engineer doesn't help, because they can't do two completely different jobs well. You can't be both a great plumber and a great electrician. You can half-ass both, though, and get half-assed results.
If you're a manager and you want to have a high-performing team, stop writing/reviewing code, and instead do everything you can to implement the suggestions here [2]. There is an enormous amount of work needed to achieve these suggestions, so you will not have any time to look at code, I guarantee you. But your team will end up working much better, producing better outcomes.
Of course they should still code, otherwise they're not engineering managers, they're project/product managers, and good engineers will not follow those people.
Whenever we talk about EM duties, it's always a list of fuzzy, empty words:
> Owning the team's strategy and roadmap, and ensuring efficient execution.
This is project management.
> Making decisions to ensure that the team is working on the right things and saying no to the things that don't matter.
This is product management.
> Dealing with fires, escalations, and other crises that pop up all of the time.
How can an EM that doesn't code deal with fires? The only thing they can do is pull the sleeve of someone else who does code, and then, what, hang behind their shoulder until the fire is put out?
> Building a strong culture within the team so that people are engaged, challenged, and motivated.
This is meaningless. We're not children.
> Mentoring and coaching your reports so they get better and can have more work delegated to them, thus increasing output further.
Mentoring them at what? If an EM doesn't code, how can they mentor in an area that's relevant to the mentee (i.e. a coding engineer)? They can coach them on moving Jira tickets more effectively, or playing office politics better?
> Managing the team's stakeholders so they can offer their steer to the team early and often.
Again, product management.
> Actively performance managing the team so that superstars can continue to shine and underperformers can be coached or exited.
Combination of meaningless and project management. In order to be able to evaluate someone's performance, you need to know their work. If you don't, the only metric you have is number of tickets, or "velocity" or whichever other bullshit metric you use because you're not in the trenches.
> Building close working relationships with other teams so that smooth collaboration happens across the organization, leading to a better and more cohesive product.
Office politics.
The only one that make sense is hiring and retaining great people, but you can't do either without being a technical person.
EMs that don't code making technical decisions is a showcase for divorcing decision making from suffering the consequences of those decisions. And having teams with EMs + tech leads + team leads etc. is just making things worse by diluting the responsibility.
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.
reply