Engineering managers should not exist

This article got it all wrong. The management hierarchy is merely a proxy that reflects the real power structure in the organization. Even if you successfully eliminated engineering managers, there will always be an implicit hierarchy which is worse IMO. You're not supposed to pretend like there's no such structure; you need to reflect it transparently and put those with powers to the position accountable for the decision they made.

I remember an interview from a former Valve employee [1] who described the company culture as "high school". This precisely points out the problem lying under those manager-less structure. The exact quote was:

> "But the one thing I found out the hard way is that there is actually a hidden layer of powerful management structure in the company and it felt a lot like high school. There are popular kids that have acquired power in the company, then there's the trouble makers, and everyone in between."

[1] https://www.polygon.com/2013/7/8/4503326/valve-hiring-and-fi...

Managers exist because this model of organizing humans to do work dates back a few centuries, at least. We don't know any better and in any organization large enough you'll run across people that if they aren't told what to do, they won't do anything or will do minimal.

As an EM, I'm not a decider on any compensation element other than "maybe a little more for this person, please" which typically translates into someone at a higher pay grade taking it from someone else, which sucks.

As an EM, I can't outright fire anyone, there is an entire process with Directors and HR and Chief Whatever Title types for that to happen, as it should be - those shouldn't be rash/quick decisions unless its something egregious/obvious.

As an EM you are typically powerless and caught in the middle between those pleading/demanding to get more done (upper mgmt) and your team telling you the reality of how complicated and lengthy it is do to the work. The team is usually always right and upper management is too busy having meetings about meetings.

As an EM the pay level isn't drastically higher than a lead or whatever magical titles HR uses.

As an EM I don't pick up any fun or critical lane work because I'm stuck in meetings all the time. I do cleanup and shit work any dev could do but also that is boring and usually nobody wants to do it.

Why does anyone choose this? I ask myself this more often than not and when that frequency increases then it might be time to move back to an individual contributor role, again.

I've been an engineering manager for a couple of years now and I don't agree (shocker I know), but I think that's because I function very differently in my role compared to the description in this post.

My #1 job is to support the engineers below me. I make sure projects don't scope-creep (PM should do this in theory but they often don't), I make sure my direct reports have someone they can go to when they get blocked, and I ensure our code quality and standards are upheld without being a micro-manager in doing so.

Also when it comes to salary increases and promotions I think it's crazy if an engineering manager doesn't fight for their best performers to get those regularly. You're just doing a bad job if you don't get your quality people raises. Your best engineers will simply leave eventually, which is much more expensive than a raise would have been. For engineers who don't perform well, they should have clear communication and actionable steps toward promotions and raises.

I think the real issue is a lot of engineers have bad managers, period. It has little to do with if they are called an "Engineering Manager" or not.

Management is supposed to be a support role, and it behaves that way in some professions (eg law, medicine).

But once you give them control over salaries and budgets, they end up controlling everything else. And management begets more and more management.

Have you seen the opposite? Where Product handles the Product, Architects and Leads handle Technical decisions? All Engineering Managers are left then are metrics and localized HR. They end up managing multiple teams, since its hard to justify such a small job of managing a single team for such a large title. They end up getting overloaded on teams, and start managing by dashboard, because talking to all 30+ of your reports is impossible.

The most useful job they can do is to take on responsibility. When everything becomes decisions by committee, at least one person has to occasionally take the reigns and say "Yes, do that one and forward." That is their real value in big companies from my standpoint. The issue is when they are all concerned about their management, defer the decision upwards, and now you have a King who must approve everything.

IME, in the structure they've described, either the project manager becomes the de facto manager (terrible outcome because they don't have the technical knowledge to do the job properly) or an engineer with a strong personality fights the project manager and becomes the de facto manager (okay short term, but guaranteed burnout long term).

A better model is to ditch the project manager and give the engineering manager an administrative assistant.

No person should need an engineering manager, but nearly every single team deserves one.

It's not difficult to be productive as an individual; but teams are much more complex and require constant tweaking. The highest performing teams are continually improving. A good Engineering Managers puts the systems and processes in place that make the team stronger over time.

But if you're not going to get excited about making your team as awesome as possible, then maybe management is just effectively being an agent of HR. Sounds miserable.

I learned a lot working side by side an engineering leader who built Google Docs (I hired him in as our VPE). He taught me the importance of two types of authority: positional (org hierarchy) and personal (technical, market understanding, tribal knowledge/relationships, etc.).

The best managers have both.

The worst have only positional and flex it constantly.

The mediocre have positional but rarely flex and rely on their teams.

Regardless, there always needs to be both types of authority so the ultimate accountability of performance to a goal can cleanly bubble up. As goals become broader, it's unfair to pin the accountability on one individual without putting them in a position of positional authority so they can then give smaller authority (and responsibility) to the individual team members.

Source: I have managed and scaled teams up to 100+ people. I've served both engineering (Head of Eng, CTO) and HR leadership (VP People) roles.

Both engineering managers and engineering project managers are results of an obscure or non-existent vision. When you don't know why you have an oar in your hands you need a person with whip to remind you.

There are two good types of managers I've seen:

Director+: Who largely delegate off to Tech Leads, etc. They don't have the time to get in your hair, and are focused on what is truly important.

Non-Technical Managers WHO KNOW IT. They don't try to make technical calls. They are there to support the team and make sure it runs smoothly. They end up highly dependent on their leads. Not the end of the world, but they better pick well.

Any technical manager, eventually becomes #2. "Rusty Programming Skills" etc.

I've seen, one manager who could hold Tech Lead and Manager. Even then as good as he was. He would have done better with some leads and more delegation. But that is one first level manager in 25+ years.

In the end, engineers need support. We know how. We need to know the what, and why.

I have worked at multiple tech companies, and I still don't understand why an engineering manager is not a manager for one area of the product. The manager's reports should work on a specific, well-defined project together, and the manager should be guiding that project to completion. When it's done, move on to the next one on the priority list.

Everyone on the team would be a "product manager" because they should all be involved in understanding the value of what they're building and what customers think of it.

Instead we have a strange overlap of HR, engineering manager, technical program manager, project manager, product manager, tech lead, and tech lead manager. It's unnecessary.

Horrible article. So many things are wrong. As with any thing in this industry, there's a pretty big spectrum and nothing can be generalized. Someone with a decade of experience simply cannot write such an article. This is click bait at best.

I'm tired of the stupidity of having an engineering manager, a team lead, a Scrum master, and then a product owner.

So, what, you're going to give me 4 "bosses" as a principal?

Same goes for these directors and VPs who can't give up working with IC direct reports, so now you've got 5 or more.

I remember someone or some company referring to non-engineering leadership as phonies, but I wish I could remember who. They had a rule: no phonies in management.

I like the idea, but I think there's more to it than that. But this whole 4-5+ "bosses" or "leaders" BS needs to stop.

Having experience both inside and out, I find large tech to be uniquely bad in this regard, but for an unexpected reason. Whereas outside large tech, managers are typically part product manager, part tech lead, part project manager and part people manager, inside it those are all distinct people. It leaves the EM role stripped it down to solely people management which pushes away many people who would make great managers, leaving only those who can't get a more attractive TL job.

The ideal the writer describes is called the tech lead. They have their place, but somebody still needs to be able to hire and fire. If not the EM, who?

Engineering managers should not exist? I agree in an ideal world they shouldn’t. Ideally all teams should self-organize in harmony and dance barefoot singing kumbaya forming a perfect holacracy. Alas, we don’t live in an ideal world, and some people like me decided is a problem worth working on even if we don’t enjoy it as much as writing code.

The true purpose of an engineering manager is to be a Directly Responsible Individual for the output of the team. Someone who makes sure day-to-day operations go smoothly, sure, but is also looking ahead for future business needs and making sure resourcing, training, etc line up. Almost all tasks an EM does can be delegated many different ways (Engineers. Tech leads. Product managers. Project managers. HR. etc...), but the EM will either make sure that each role is being handled or will take care of it themselves. They patch together a functional result from a patchwork of people joining, training, leaving, and going out of office or burning out.

EMs, like most managers, are typically paid more than most engineers. The reason why is very simple: They've sold their soul to the company, and that is, in fact, fairly valuable.

We don't have engineering managers at my job. works fairly well. we have managers that manage the HR aspects of the job and do some coordination of the work as far as placing people where the work needs to be done. but they are completely hands off on the technical side.

I read in this article lack of experience working in different organizations and lack of understanding of complexity of organizational structure. It’s nonsense with a clickbait headline pretending to be revelation. Why?

1. Most organizations have EM with one or another job title and many of them function very well. It is not a problem of specific role if something goes wrong. It’s often unfit people.

2. The role of EM is the role of people manager. This role is hard to delegate to anyone else: outsiders like HR will not know people well enough, assigning it to a product or project manager will overload those roles with functions unrelated to the primary job (great product managers are leaders without authority - it doesn’t mean they should take over their cross-functional teams). Principals are not managers by definition, they are people who have chosen different type of career not willing to do anything with interpersonal stuff. People management is a scope of work big enough to have a dedicated person for a team of 4-10 people, bigger teams will need more.

3. Engineering manager is a first point of contact for the business regarding feasibility and planning topics. While engineers work, managers talk. In theory a principal engineer can be such person, but not every team can and should have someone at this level. In fact, most should not - this is the role for the teams with over 50 people and it’s an org-wide role. If you have principal or architect in a team of 10, you are doing something wrong with the career path and probably overspending.

The article is almost as authoritative as it is unsubstantiated.

I find it funny how enthused programmers are about creating localised surveillance states for every other worker, yet the mere idea of having a manager for coders is anathema to so many if them. Coders aren't that special. Over management makes everything worse, programming isn't a special case.

> Before that I have over a decade of software development experience at companies small and large.

Can anyone with actual engineering experience comment? Software development is not engineering.