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 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

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.

From the article:

> 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.

Larger companies subdivide this more.

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.

If you can't code, you should not be managing programmers. How much code you write will obviously depend on circumstances.

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.

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.

Two things:

- 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 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.

In short, it all depends.

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.

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.

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 exist?

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.

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.

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.

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.

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!

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"?

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.

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.

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)

I haven’t seen anybody else mention this:

Yes, because in a downturn managers get cut first and you never know when you will need to be an IC again.

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.

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?

> 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.

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.

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.

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.

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.

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 found that coding was important, as it helped me to connect better with my employees, and their challenges.

I also found that I could never schedule myself into the critical path. Most of my coding was open-source stuff, on my own time.

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.

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.

Does a floor boss still do work of the grinders and machinists, YES!

Intimate knowledge is what makes a boss better, not by itself alone.

Have to continually sharpen the scissors (mind) and not just the boss'.

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.

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).

"Administration" and "technical leadership" are two different skill and task sets, and it's a shame they're conflated into one position

I've had managers who not only don't code, but never coded. I'd settle for one that had substantial engineering experience in the past.

I like two kinds of managers:

- Managers who came from the trench and can guide us through the mist;

- Managers who know nothing about the trench but leave us alone;

They should be able to automate their work with code: analytics reports, bots, etc. Committing code to product codebase - probably no.

Yes but only a little.

I think managers are often out of touch with what the team puts up with.

Does a football coach need to be in the lineup in order to be great?

It depends on the company and how much is reflect in the paycheck

Yes, if you can't measure it you can't manage 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.

Big no! from me.

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.

whats a manager? I have an AI for that!

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.

too much context switch (and no good answers here)

It's 2025 and the software industry is still debating this :-).

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.

No

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.

Yes

strong yes for me

flat orgs win.

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.

[1] https://en.wikipedia.org/wiki/Division_of_labour [2] https://dora.dev/research/?view=detail

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.

https://world.hey.com/dhh/we-once-more-have-no-full-time-man...

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.

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.

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.

Time is solved by having other engineers.

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.

https://research.upjohn.org/cgi/viewcontent.cgi?article=1343...

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)

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.

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.

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.

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.

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.

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 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 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.

> 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.

> 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".

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.

> However, to be clear, software teams, engineers, and engineering managers are absolutely evaluated on their performance,

Yes, and no one said that this kind of evaluation has produced long term success. It has widely been recognized that when upper management is more involved in evaluation rather than leading teams of managers themselves, they address issues and market conditions too late. Thus, affecting businesses negatively over and over.

https://hbr.org/2016/10/the-performance-management-revolutio...

In other words, managers are being asked to NOT perform to certain metrics/evals but to make choices that benefit the company - even if it falls outside any evaluation rubric.

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.

How is manager's ass more on the line compared to an IC ?

Managers always have a higher job security compared to an IC from my experience.

Poor managers always use this dumb excuse of 'ass on line' to override good decisions by ICs with their own shitty decisions.

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.

That’s very valid feedback.

I hope I don’t come across that was and do have some evidence (not to be laid out here) supporting that I don’t.

I think I’ve created a team and structure where the developers I manage are comfortable telling me I’m wrong or what I didn’t consider. It happens weekly. We value honest feedback highly. We do it with respect, but we do it.

We just have some developers on the team that are resistant to ideas that don’t follow a pattern until they see it. And sometimes my communication around the initial idea is poor and the best way I can communicate is an implementation.

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'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.

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

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.

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?

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.

Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.

Hard disagree. Would it be helpful? Sure. But a good boss just needs to know when to trust the judgement and opinions of his subordinates.

Trouble comes when they don’t understand the work, but make decisions as if they do.

So you want them to come to work and do their job, then go home and waste their nights and weekends doing a variation of your job?

How about, a proportion of their work day must be allocated to keeping up to date with the tools behind the thing they're attempting to manage?

> they need to spend their nights and weekends making sure their skills dont rust.

Life is more than work

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.

Do you read books about management in your evenings?

Thank you

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?

Here’s some good food for thought on the engineer/manager decision, [0] and [1]. Good luck!

[0] https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...

[1] https://charity.wtf/2019/01/04/engineering-management-the-pe...

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

Skill is irrelevant: the output is a small, low-priority feature.