[halfmatthalfcat]

Oh please, there's a reason why those comments exist - because more terrible managers exist than those "good ones" that you allude do. I would posit a guess that most, if not all, engineers on HN have had to live through at least one terrible manager that has soured/tainted the position. Speaking for myself, I've lived through many and it's a miserable experience to be under these people.

Nobody is saying that the functions of these roles aren't necessary, they're saying that the people who live in these roles are overall bad, don't know how to effectively execute these tasks and present an aura of superiority over the technical roles when they're providing very little value at all.

[rco8786]

That’s silly. Managers exist on the same spectrum as any other role. Most are about average. Some are better, some are worse. Same with engineers themselves.

These articles are undoubtedly written by people who have never been managers themselves, and frankly just don’t have any idea what the job is for. Which is fine - everyone starts that way. But to then assume the job is useless is classic sign of imaturity.

> Nobody is saying that the functions of these roles aren't necessary

That’s literally the premise of the article posted.

[015a]

Maybe these articles are written by people who have never been managers themselves. I'd also posit that most of the defense of the position comes from managers. Do you not recognize the irony in this?

I'm sure you're aware of what they say: Its difficult to get someone to understand something when their paycheck depends on it. Do you have the self-awareness to recognize that this, alone, is a huge reason why managers immediately come to the defense of their position?

I've been in the industry for 20 years now. I've worked with good EMs; I've worked with bad EMs; I've been an EM (less often). That spectrum isn't even relevant to the underlying assertion that the core definition of the role is invalid. Its extremely rare to work with an EM whose entire scope of responsibilities wouldn't be more productively served by a peer PM. The only advantage to an EM title is in the organizational power structure, which is far too often leveraged to abuse their reports by trading quality output and mentorship for more working hours, burnout, and Jira graphs.

[bumby]

This is interesting. What, in your opinion, should the core definition be (if anything)? And how is that eroded when tasked to an engineering manager vs. a project manager?

One of the major issues I have with the article is they lean heavily on the "creative work can't be managed like manufacturing widgets" train of thought. It feels to me that they define developers as artists when the article is about engineering. I think those are different roles are different. Even though both require a certain amount of creativity/subjectivity, it's a mistake IMO to conflate the two.

[erikpukinskis]

A Project Manager is a non-executive role. They facilitate the flow of information that keeps a project on track, including reporting progress up.

A Technical Lead, Design Lead, and/or Product Lead is the final arbiter of executive decisions about how a project will be completed.

A Coach meets regularly with ICs to help debug workflows and interpersonal issues.

A Manager signs paychecks, and takes responsibility for the work actually getting done professionally, reporting to HR when it’s not and taking action on behalf if The Company when needed. They are the legally responsible person for the things happening underneath them in the org chart. In an ideal week they do nothing at all.

Engineering Managers tend to do some combination of all of these things, usually most of them poorly since that’s way too much work for a single individual.

[bumby]

Thanks, that's an good breakdown. I'm curious, is this an ideal or a pragmatic approach? At first blush, I understand the distinctions but it feels more like a theoretical organization rather than a real one. I've personally never worked in an org with all those roles so, as you say, they tend to get mashed together.

It does seem like there would be a naturally pressure to lump together the roles. I suspect that if your ideal week happens too much (where the manager does nothing at all), executives would question why they're needed.

[erikpukinskis]

In my opinion it’s a pragmatic approach. When these roles get lumped together it creates conflicts of interest that have materially adverse effects on productivity.

That said, you’re right most companies will hire 50 engineers and 10 managers before they hire a single coach or project manager. Or allow IC leads to make their own decisions. So for those companies it’s theoretical. :)

But these roles all exist. You’ll find job listings on LinkedIn for all of them. So they’re happening somewhere!

[treis]

Not the GP but it's nigh on impossible for an EM to do their job. Roughly speaking they are supposed to be the voice of developers/engineering. But since they are not hands on the code they don't know the reality of the code base and so can't be an effective advocate. Ultimately they end up being a relayer of messages.

I think the role needs to exist but it's not a per team role. You need one for every 4 teams or so. They're there to build the teams, make sure they're running right, and do the high level resource allocation. Day to day management of the team should be a collaboration between a lead developer and a product owner.

[bumby]

Maybe part of the problem is there is no consensus on what an EM "should" be doing. Note that the comment above this one gives a much different synopsis of the role.

[015a]

I think Software Development is far more creative than you give it credit. Let me list a few realities of modern software development:

1) You give a spec to ten different engineers. You'll get ten wildly different solutions, from decisions within a single programming language, to different programming languages, to microservices and serverless.

2) So: make the spec more specific to reduce the variability. Now an engineer has to write the spec; and we're back to square one where the spec is just an expression of how they would develop it. You give it to ten engineers, and you still get ten different solutions; but maybe less variable.

3) Of those ten solutions, most will fail in weird ways, because software breaks. That's what software is known for; breaking. Its hard, probably impossible, to write reliable software, and we're on a deadline, so like 30+% of the team's time is spent just on operations.

4) Of those ten solutions, most will fail to account for some edge case, because the spec didn't cover that edge case, because (reasons). Well, file a followup ticket.

Those bullet points represent so much variability in how the future will play out that any ability to "manage" it is an exercise in futility. Add in interruptions, add in PTO, add in cross-team coordination, incidents, every day longer that a project takes reduces the accuracy of estimates substantially; that can't be managed (well).

That's why product engineering is fundamentally a creative effort. Maybe not like Art or Music; I liken it to more like, well, video game development (which, you know, people write code in so its really confusing to me why Culture considers that creative but not typical software development, I guess its because they produce something Pretty and Fun).

Video games have deadlines. They have business demands. Customers. Product-market fit. Roadmaps. Coordination. Massive, massive variability in implementation. Massive unknowns about what the final product will look like. Massive technical problems involved in bugs, performance, optimizations, maintenance, different platforms.

Here are five careers pages for major video game studios. Seriously, go to all of them, and tell me how many positions they have open for "Manager of People Who Do Traditionally Creative Things": [1] [2] [3] [4] [5]. Its not many, if any. They have roles like this, for sure, but they're not phrased or labeled from the perspective of "Writer Manager"; they're phrased as Lead Writer.

And the critical point there is maybe one involved in the hierarchy and power relationship. But more importantly, its background! The Lead Writer WAS a Writer. That's experience in the domain of the people you're leading; that helps massively in every responsibility this role should have. Timelines? Hella. Roadmapping? Heck yeah. Mentorship? The forbidden word that big tech managers hate.

But Tech is a weird microcosm where EMs are just Managers. The best EMs have an IC background, but many job postings list ZERO requirement to that effect [6], and ask any Engineer-turned-EM: They ain't doing much Engineering anymore. That's not just a benign anomaly; its a problem with how our industry builds companies. And we sit around twiddling our thumbs wondering why engineers hop jobs every year or two; its because, well, the pay is probably better, but also because its a coin flip on whether your manager is actually good, or just some guy that talks good.

Hypothetically, what is a better path forward? Get rid of "Engineering Management". The team has a Lead Developer, who is legally or whatever, the person who "manages" the team (there's that word again, KILL IT WITH FIRE). That role is a peer to PMs, POs, Designers, etc. That role requires a long history of actually doing engineering; and still does it, at least from a high level (meetings are necessary and, yeah, its hard for Engineers-Turned-EMs to find time to code; but writing/reviewing specs, PRs, mentoring the team by helping them debug problems, I'm salivating at the idea of having a manager like this).

[1] https://www.insomniac.com/careers/

[2] https://sms.playstation.com/careers

[3] https://www.valvesoftware.com/en/ (kind of interesting that their home page is their open roles. hiring like crazy! no managers).

[4] https://www.epicgames.com/site/en-US/careers/jobs?keyword=ma...

[5] https://www.respawn.com/careers

[6] https://stripe.com/jobs/listing/engineering-manager-payment-...

[bumby]

Everything you've said can be related to any other engineering discipline. Think of how many mechanical ways your car can break. Or a building can degrade. They have creative ways of dealing with that too. But do we insist that automotive or architectural design can't be managed? The distinction is other disciplines have managed away a lot of those failures through the constraining the design alternatives to standards and best practices (and sometimes regulatory codes). In other words, software feels like it's more creative because it's less well managed. So to say it can't be managed because it's more creative is circular logic.

What you've really illustrated is that software is hard. Engineering is hard. The distinction is that other engineering disciplines have had a much longer time to codify good practice. I bet if you went into, say steam engine design in the mid-1800s, it would feel a lot more creative than today. For a variety of reasons, software development is not nearly as good at implementing standards and to go into all of them would be a digression. However, I think the distinction that we disagree on is that it's due to anything inherently different in software. I'd make the case that software is easier in some respects (e.g., it doesn't display wear out failure modes) and harder in others (e.g., it tends to have more interface failures). I'm saying it feels more creative because it's less well managed. If you've ever worked in a heavily regulated sector like safety-critical software, it definitively feels less creative than a CRUD web-app development effort for this very reason.

I personally think part of the issue is that EM becomes a career-track that can start immediately out of school. It's similar to the change in MBA programs. The better MBA schools used to require that you have worked in industry for about a decade before even applying; now it seems like most schools offer a management track without necessarily having any experience. The result is a self-selection for people who want to manage without necessarily having a concrete understanding of what they are managing.

[rco8786]

> I'd also posit that most of the defense of the position comes from managers. Do you not recognize the irony in this?

That’s not irony. That’s someone with no domain expertise saying something and then someone with domain expertise refuting it.

If I, a casual baseball fan, made a claim about umpires being useless in baseball and then an umpire came in to explain otherwise, that would not be irony.

I’m also not an EM, though I have been one in the past.

I don’t understand your point about PMs. You’re saying that the responsibilities of an EM should be that of a PM. So you’re just arguing for a name change? Or something else?

[olddustytrail]

Don't know if that is what they're suggesting, but I would suggest:

owner/board -> worker teams (up to 5 individuals) -> team helper (this is the previous manager role)

Edit: I will also add that it's strange, the more experience I have of incompetent managers, the more I'm told I don't understand them!

[015a]

> I don’t understand your point about PMs. You’re saying that the responsibilities of an EM should be that of a PM. So you’re just arguing for a name change? Or something else?

Well, its not just a name change, but generally Yes.

The biggest thing is from the Org Hierarchy perspective. I want to preface what I'm about to say to be perfectly clear: This is not true in every company.

EMs have the final say on resourcing for code-related tasks; but poor understanding of the code, systems, etc because the Lead/Senior devs live there. EMs have the final say on product decisions from PO/PMs under them; but a poor understanding of the product because the PO/PMs/etc breathe that. EMs have the final say on designs; but a poor understanding of UX because the designers have that.

The best EMs always have some background in one of the roles I outlined above. They come from an IC background, they were due a promotion, burned out in the IC role, ran out of promotions in the IC track, whatever.

But in many situations the role of an EM becomes a mediocre mashup where the one thing they're actually good at is navigating the politics of org hierarchies; or if you want to be Business Proper, call it Communication. Ask any high school guidance councilor where "Communications" lands on the list of Valuable College Degrees and you'll get a pretty consistent answer. But: EMs somehow escaped this destiny, because tech has a weird distortion field on incomes right now.

Here's the sinister part: Because EMs hold power over everyone who reports to them, its common to see turf wars over responsibilities. Example: "We don't need to hire for a PM, I'm doing that". That's why it isn't just a simple name change; its their fundamental place in an org hierarchy that can make the role a net drag on an organization. Orgs hire them without a tactile definition on the responsibilities of the role [1]; just extrapolate "manage the engineers" to three paragraphs and call it good. You'll do roadmap planning (in collaboration with senior leadership and the PMs). You'll help prioritize incoming work from different stakeholders (in collaboration with the PMs, Customers, and Engineers). You'll help build the team (in collaboration with Recruiting). You'll mentor the engineers (but, we don't require any engineering background, so how you'll do this well is anyone's guess).

The role doesn't actually DO anything valuable; again, at best, the person has IC experience and can carve out a niche that's a hybrid of that IC experience and more coordination/communication. But at average, they're a message bus that attends meetings and parrots messages from someone that actually matters to someone else that actually matters [2].

[1] https://stripe.com/jobs/listing/engineering-manager-payment-...

[2] https://www.youtube.com/watch?v=m4OvQIGDg4I

[ewuhic]

PM as product or project?

[pyrale]

Yes.

(said tongue in cheek, but the confusion is so often carefully maintained that...)

[halfmatthalfcat]

The power dynamic between managers and those they manage is the differentiator. Sure it's a spectrum but half of that spectrum (from average to god awful) have power over your career/work, to your detrement.

[rco8786]

> Sure it's a spectrum but half of that spectrum (from average to god awful) have power over your career/work, to your detrement.

It is always your responsibility to advocate for yourself, your career, and your work.

If you are an engineer you should view your manager as a marginal value add only. Some managers add more value to your career than others, for sure, but it's still marginal relative to the effect that YOU have on your career. If you find yourself on a team with a truly bad manager who is having a negative affect on your career, get out...but this is truly a rare occurrence in my experience.

[johnbellone]

If your manager is only adding a marginal value to your career it is time to have a conversation with them. A manager that isn't advocating for their team isn't a good manager at all. They're something else.

[rco8786]

A manager can only add marginal value to your career. ONLY.

You spend 40+ hours a week on you and your career. Your manager spends a small fraction of that directly on your career.

100% agree that they need to be advocating for you/your team, finding the right projects for you/your team, etc, etc. But at the end of the day your career is your responsibility, and it's only a fraction of your manager's responsibility.

[bumby]

I'm not sure I agree here, because the manager has the ability to impact all those other hours.

A good manager helps remove the hurdles that will make those 40+ hours immensely more productive. A bad manager adds to those hurdles, potentially whittling productive hours to nothing.

[pyrale]

> You spend 40+ hours a week on you and your career. Your manager spends a small fraction of that directly on your career.

If your manager has little more leverage than you do, that's true. In many orgs, managers have considerably more leverage than their reports, and their help is mandatory to get some things (promotions, pay increase, access to conferences and trainings, changing teams, passing messages up the chain or laterally, support for escalation, etc).

The only trump card the report has is leaving, but they pay for that by losing all the social capital acquired at the current company.

[osigurdson]

This view makes it seem that the manager is compensated directly by the team.

[bratbag]

Thats assuming the average is net neutral to your career/work.

The average engineering manager may be a net benefit, or a net detriment. The rest we can extrapolate from there.

[UncleMeat]

I do think that this is fair and it is a reason why bad managers stand out so much in people's minds. I think that making it feasible for a team to fire its own manager would be generally a good thing.

But this has little to do with the argument that management as a concept itself is self serving bullshit.

[tayo42]

Why? If most managers are useless that means most in the role aren't actually helping or doing anything yet the world seems to go on. Why have that role then? If you can have someone who is a negative in that role, then you can get rid of it.

[rco8786]

> If most managers are useless

Big IF. Even worse-than-average managers are not useless. To have a truly useless manager is an extreme rarity.

> means most in the role aren't actually helping or doing anything

You're painting a broad spectrum of people on a binary scale. A bad manager is maybe 30% as useful as a great manager. But 30% useful is still better than not existing.

> If you can have someone who is a negative in that role, then you can get rid of it.

By this logic every job is useless. Any role can have someone bad at it.

[tayo42]

Idk if its that big of an "if". People who are ending up as managers are rarely highly trained in the job or receiving a ton of support. Often just attracting bad personalities. Its always someone who wants to do something different then engineering, they become a manager. Imagine if we hired engineers because someones friend thought it sounded interesting and they had to do all their learning on the job.

> By this logic every job is useless. Any role can have someone bad at it.

Its not really the same because there's only one manager. If i had redundant managers maybe then a couple bad ones could get by. bad engineers have a tons of checks to prevent them being a real drain. theres no code review for a manager.

[writeinpencil]

I don't agree. There is a good line in the book "Impro" about good and bad teachers. It says that we think of "good teachers" as providing a lot of some substance called "education" while "bad teachers" provide only a little. In fact bad teachers can and often do not only fail to provide education but actively make students less educated by, for instance, teaching wrong ideas, punishing arbitrarily, etc etc. The same is true of managers. They can easily drop below zero and start to have a negative impact on productivity and their employees.

[droopyEyelids]

I think this is the sign of inexperience/immaturity.

What you're describing is a universal aspect of life. From parents, to teachers, to managers all the way back to chieftains of prehistoric tribes there have been power differentials between people and the more competent person has not always been the more powerful.

[halfmatthalfcat]

And we're honing in on the pain point of that aspect of life. I'm not having a revelation here, I'm lamenting the fact with my peers on a site dedicated to technology/engineering.

[015a]

I think what you're describing isn't inexperience or immaturity; its idealism in the idea that competent people should hold power.

The world may not work like that, but it isn't immature to fight for it.

[__alexs]

I have been a manager and a manager of managers and I think we really do not have good data on whether not "management" as a profession in software engineering really adds value. We're bad at quantifying the value of engineers, and we're worse at quantifying the value of managers.

There are definitely a wide range of non-engineering skills required to produce good software but that doesn't automatically justify the existence of a dedicated engineering manager role in most or even any teams.

[sulam]

I can justify it quite easily. Take it away and see what happens.

[015a]

I don't think its possible to just take it away and see what happens, because organizations build the concept of EMs into their entire culture.

As an example: I worked in a Big Tech org where the only way to get anything from another team was an org hierarchy jump. ICs could reach out directly; ignored. Some teams didn't even have a way to reach out to them. You had to go EM, then maybe a Director, then it filters down, and maybe a day, maybe a week later, you'd get an email introduction. It doesn't have to be like this, no one even decided it should be like this, but because they had the hierarchy that's how the culture evolved.

The better comparison is to look at companies who don't have that role, or define that role significantly differently from the traditional Big Tech definition. There are many; of course, not as many as the latter. And just like companies who do have the role traditionally defined, there are success stories and there are failure stories. To me, the more I've read up on those stories, the more I've realized how pointless the role is.

Or, maybe more accurately; how much of the role's responsibility is really to be a crutch for bad culture, bad upper management, bad hiring practices, bad interviewing, etc. That ain't totally pointless, but if you're also flipping a coin on the quality of each EM you hire, and moreover the coin is rigged because we don't even have an industry standard definition for what defines success in the EM role in the best cases; there are better ways of reaching the same destination.

But, you know, most of the time those better ways require an ounce of Trust from senior leadership, and that's like pulling water from desert sand.

[sulam]

There's not a ton of consistency across even relatively similar-looking tech companies in my experience, so you really should expect your mileage to vary. My N=3 large tech companies in my career is not so much better than your N=1 example, but it does allow me to say that these things are not consistent at all, with some notable exceptions, usually constrained by employment law.

[ferrumfist]

Devs: "Overworked? Too many disparate responsibilities? Not being able to write enough code? No team cohesion? This is a systemic failure of leadership, start interviewing for other positions."

Devs: "We, as software developers, are underappreciated! People only pay attention to us when things go wrong!"

Also Devs: "Managers are so useless lmao"

[eastbound]

I like this caricature but remember that, since this is not a regulated industry, there are many different personalities, and those who think this way don’t succeed for long.

[bratbag]

What happens is that an otherwise productive engineer has to step up and perform the role, but without any recognition of the extra responsibilities or any reduction in expectations of their individual contributions.

So then they find a job somewhere else and another otherwise productive engineer has to step up.....

Meanwhile the other engineers continue on blissfully unaware, patting themselves on their backs for how they don't need to be managed.

[015a]

I've seen this happen in smaller teams; it can work well! Productive teams and skilled engineers can manage their own workload. Not all of them want to do that, so that needs to be taken into account, but it can work spectacularly.

I've also seen it work poorly. We've already established that there are good and bad EMs; there's good and bad in everything. That doesn't justify the role of the EM!

I've also seen PMs do this. This is the far more common situation, and it works! Workload planning ends up being a collaborative effort on the team, with the senior engineers holding domain knowledge over operations, maintenance, architecture, implementation, while PMs/Designers/etc hold domain knowledge over the business, customers, etc. Work once in an environment like this; well, at least a good one; and it will make anyone and everyone question why EMs exist at all. There's no room for them. They wouldn't contribute anything even if they were added to the mix.

[julik]

And no extra agency and no extra authority. I've been in that spot, had the best 4 months of my life (lack of authority was painful). Then 2 clueless managers were hired above me.

[spc476]

I've been at my current job for 12 years. For my first three years, I had no manager [1]. I then did an internal transfer to development, and had a 'meh' manager [2]. He burned out after a few years. The next manager I had was great. Technically, he shouldn't have been our manager as he was a director at the company, but due to financial politics, the company couldn't hire a manager for us. He just told us what we needed to do and otherwise, let us developers alone to do the voodoo that we do. He was eventually let go and one of the other developers on our team was promoted to manager. He too, was great, just telling us what to do, and trusting us to do the voodoo that we do. He retired. My current manager (from the company that bought us out) is bad. Enterprise development being shoved down our throats, not only telling us what to do, but how to do it.

So, in my mind, a good manager will tell the team what to do, listen to them, and let them do the how. Next up is no management---in my experience, I knew what needed to be done, and got it done. It was great, but I realize that was a bizarre case that normally doesn't apply everywhere, but because of the nature of the work I did, only a few other people actually knew the work involved. The 'meh' manager didn't hurt, but really didn't help. And bad management, well ... let's just say a bad manager can really damage a company.

Until bad management showed up, our team always delivered on time, had smooth deployments, very few bugs in production, and otherwise, was not a source of issues for anyone. Now, we've missed multiple deadlines, horrible deployments, bugs in production and our customer, The Oligarchic Cell Phone Company, is very pissed. And it's not the sole fault of my current manager, but of upper management in general.

[1] I was initially hired in QA to test the call processing side of our product (the bit that happens when a call is placed). The existing QA manager only knew how to QA the cell phone handsets, not the call processing server side. I knew next to nothing about the cell phone handsets. It was clear the QA manager was not a good fit for me.

[2] He wasn't great. I don't think he was as bad as some other employees said he was. He was a developer who was forced into a management role.

[ryandrake]

I've worked in a place without eng managers, product managers, scrum masters, various MBA people, you know... all those employees that a certain segment of HN thinks are useless. It was just Sales and Software Engineering, and the CEO, to whom everyone reported. It was the worst job I've ever had.

Developers just developing, without interference from evil managers and clueless PMs! Amazing! The ideal work environment for the genius bootstrappy engineer! Sounds like heaven, right? It was not. It was total chaos.

1. Nobody knew what they should be doing and what were priorities. Someone from sales would run downstairs and say "I just sold Foo to a giant customer! You need to build Foo now!!" and everyone would go off and start building Foo. Then the CEO would fly in and ask "Why are you not building Bar? I'm personally interested in Bar, please show some results! Oh, and any product changes need to be personally approved by me now. Byeeeeee (gets on his plane again)". So developers kept developing but had no idea what to develop.

2. Joel Test[1] was 0 out of 12. Since it was just developers developing, nobody had time to write a spec, or set up source control, or design a build/release process. Those were icky tasks that stupid PMs and managers did. Developers want to develop. So the software engineering process was a clown show. Releases to customers were always late, and when they happened they were built directly from an engineer's workstation (they would just find a tree that actually built without errors, and that was the release).

3. If the software failed in the field for a customer, and this happened constantly, there were no useless support staff to talk with that customer, do basic tier 1 and 2 support, diagnose, and so on. Customers simply got angry, and since it was just developers developing, they had nobody to call and rage at, so they'd call the CEO. Then CEO mad. CEO would make a developer fly out to the customer's site with a laptop and debugger to pacify the customer. Now, that particular developer wasn't developing and was sad.

4. Things like career growth, mentorship, training, learning new best practices, none of that existed. It was just developers developing, so there really was no knowledge transfer or any distinction between junior, senior, staff, and so on. Nobody's job was to set these things up, so it never happened. There were no levels so no concept of promotion. If you wanted a raise, you'd go to the CEO who would just say no. That was basically your career development.

So yea, go find a place without managers and MBAs and let me know how it goes.

1: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

[allendoerfer]

> 2. Joel Test[1] was 0 out of 12.

Sorry, but then you and your colleges were not senior enough to handle an environment like this. This is not a question of missing management, but also missing (technical) leadership.

While I do not know if it would have solved all your problems, you can make this environment better, without adding a management layer in between.

[015a]

I can't speak for everyone, but I would not argue against PMs or Senior Leadership.

There are two critical differentiators in the role of an EM: power over those managed, and the bias toward management over productive output. The people who predominately fill those roles are those who are good at management, not those who are good at production (and, by the way, the "good EMs" which DO exist are generally people with a history as an IC, and treat the role more as a PM).

[eequah9L]

> nobody had time to [...] set up source control

Now wait, how do developers develop without source control?

As an individual contributor, I consider a number of things in that paragraph good practice. Specs, say. But source control? That's just so fundamentally basic that I lack vocabulary to express how essentially important I consider it to be. How does a team get anything done without one?

[__alexs]

Can you design an organisation in which has managers, which would fall apart entirely if you took them away? Yes absolutely.

I'm not sure this really demonstrates that they added value so much as they just prevented value from getting subtracted by other dysfunctional parts of the organisation.

[soperj]

I've worked for months while they hired a new manager, and we just had less meetings.

[bratbag]

Conversely, I had to attend more meetings when I didn't have a manager, because they were no longer there to act as a filter/shield for the chaff around the corn of what I needed to know.

[soperj]

What do you need to know from your manager exactly? Majority of my assigned work is coming from my project lead.

[nicoburns]

Presumably someone was still managing you (e.g. there was someone for you to go to if you wanted to book time off, ask for a pay rise, etc)?

[soperj]

Vacations are booked through a booking system, pay raises are negotiated by a union, so not an issue.

[weezin]

I imagine bikeshedding galore lol.

[bojo]

Exactly this.

[liuliu]

> Managers exist on the same spectrum as any other role. Most are about average. Some are better, some are worse. Same with engineers themselves.

I do understand what OP said somewhat though. Mostly due to Peter's principle, thus, managers are not "about average" but "mostly incompetent". It is easier to promote people managers than ICs in growing organization, hence it is easier to play out Peter's principle in real life for people managers.

[b3morales]

The key that I think makes all the difference is to treat moving to management as not a promotion, but just a change to a different career track. Same as if the person went into design or any other non-engineering role.

[taneq]

Remember that the Peter principle only applies to people who’ve peaked and who are in roles with some meaningful promotion path remaining. It doesn’t apply to someone who’s working their way up the ranks and is currently an engineering manager. It also doesn’t apply to someone in that role in a small-to-midsized company where there’s nowhere further to be promoted without buying out the owner.

[grumple]

The Peter Principle is just an idea someone had (and intended to be satire) and not an actual factual reflection of the way the world works.

[fluoridation]

The fact that it's satire doesn't make it untrue.

[drewcoo]

Not just that. The fact that it's satire means it's at least somewhat true.

[afarrell]

However if the satyrical speaker did not believe that they had a duty of care to the truth, then it is bullshit[1].

[1] Prof. Harry Frankfurt, On Bullshit. http://www2.csudh.edu/ccauthen/576f12/frankfurt__harry_-_on_...

[fluoridation]

Not really, that does not follow. It is possible to speak the truth by accident.

[ZephyrBlu]

It does seem to be a reflection of how the world works though. Most promotions risk being promoted to your level of incompetence because they are happenstance. They mostly occur either when you're joining a new company or someone leaves/company is growing which makes room.

Being promoted because you are excelling in your position and taking on responsibilities of the one above is the rarest main reason from what I have seen.

[vlovich123]

> Most are about average

Surely you meant to communicate something different here and not a mathematical impossibility.

Do you mean most fall within 1 standard deviation of the average? That still means half the managers you encounter would be below the average quality assuming a normal distribution (which it’s clearly not - skills tend to follow the power law).

Most engineers are actually decidedly quite bad at software development itself for what it’s worth. The equivalent of a first level line manager is typically a first level engineer (not always but usually). Good managers get promoted to manage managers / multiple teams which dilutes their qualities (they now have to train other managers to be good). So think about whether you’d put a very junior engineer in charge of a project and what kind of results that might have, especially since if the manager is actually good they’ll be promoted away whereas an IC who’s hood is simply given more responsibility on the project but the role doesn’t change too much.

[rco8786]

Really unclear what point you are trying to make. But yes my intention of using the word "about" average and not "exactly" average was to communicate that most people hover somewhere around the middle. If you want to get really specific and get into stddevs, be my guest.

[vlovich123]

"Most people" cannot be above average. That's an information free statement.

[radicalbyte]

> Most are about average.

That is not how averages work. It depends on the distribution.

[ameister14]

It's most likely a bell curve

[spiderice]

To answer your nitpick with a nitpick, averages can work that way. Do you know the distribution of engineering managers well enough to say that most aren't "about average"? GP was making a claim about engineering managers.. not about all averages.

But regardless, that's missing the point. The point is that the distribution of engineering manager quality is likely pretty similar to that of any other role. So claiming that "there are way more bad engineering managers than good ones" seems likely to be untrue unless you also believe that about nearly any other engineering/management/product position.

[radicalbyte]

> To answer your nitpick with a nitpick, > averages can work that way. Do you know > the distribution of engineering managers > well enough to say that most aren't > "about average"?

Sorry it hit a sore spot; especially in a community such as this we should at least try to speak accurately regards statistics.

That's not what I'm saying. The OP is stating that it holds for averages. It doesn't. It might in this case but we don't have the stats.

The statement just doesn't make sense - you can say exactly the same about a random value. It will hold in some cases. Average too. However it will not hold in all cases.

[drewcoo]

> Managers exist on the same spectrum as any other role.

Anecdotally, I've met a lot more people who don't want to manage (again) than people who don't want to be ICs. I think that indicates a different "spectrum" of humanity.

[charles_f]

> Managers exist on the same spectrum as any other role.

I think it doesn't help that you'll find about 1 manager for 8-10 engineers. The same spectrum, but lower raw numbers, might give an exaggerated impression of mediocrity.

[linuxftw]

The 'average' manager may indeed be a net-negative, much like the average car crash.

> frankly just don’t have any idea what the job is for

We know what the job is for, but maybe there's no actual value there.

Do doctors have managers? Do lawyers have managers? No, they might report to some administrative body, but they mostly work on contract or in teams. The 'communicate with customers' nonsense is delegated to lower-paid clerical staff, not 'managers.'

What engineers need is low-level clerical people to handle the day to day comms with others outside the org. We don't need managers, unskilled labor needs managers.

[aniforprez]

> Do doctors have managers?

Yes. If a doctor is working in a hospital, there are most certainly managers. Obviously not "technical" managers in that they're doctors themselves or the doctor's "boss" but in that there are managers who are co-ordinating workforce, priorities, staffing, supplies etc etc. This is very much a thing and is more broad than engineering managers but is an incredibly important task so the daily admin work does not come to a doctor who is probably prioritising saving lives and helping people

> The 'communicate with customers' nonsense is delegated to lower-paid clerical staff, not 'managers.'

This is incredibly demeaning of people in hospitals who actually have to do these jobs. There's a massive amount of work required here and it is by no means "clerical". When "customers" literally have their lives in a doctor's hands, the complexity increases hundredfold. There's legal sensitivities, paperwork, spending, collections and so much more stuff involved and this is not even counting the kinds of things they need to do which involves interfacing with patients and their kin about sensitive matters. This is not simply "admin work". This is critical, life saving stuff

[tayo42]

Are managers of doctors saying ridiculous things like you need to only seem patients 30 and up this week, or your not diagnosing enough strep throat.

[aniforprez]

Assuming there is an analogue between a very clinical and technical field like development and an incredibly volatile and human field like medicine is futile. They don't have many of the same problems we do

Instead they have to force doctors to break bad news to patients' relatives or do it themselves, get signatures from both parties for procedures, coordinate in/out patient streams, listen to doctors demand equipment and medicines and face upper management denying them their requests and tons of other such bullshit. Medical insurance and its intricacies is a whole big ball game that they have to constantly play with so that's fun

[compiler-guy]

I have plenty of friends in the medical field and yes you hear stuff like this all the time. “Thirty and up” because maybe there is an underserved community. “Not diagnosing enough strep throat” because maybe there is a recently discovered epidemic and doctors hadn’t been testing for that.

People who have a high level view can direct the folks down in the trenches quite productively.

[tayo42]

> People who have a high level view can direct the folks down in the trenches quite productively.

This shouldn't be middle managers. technical leader is better for that or most senior on the team. An actual leader on the team.

[shkkmo]

I don't think "hospital administration" is really an analogy that helps your argument since the growth of that sector has a significant share of the blame for rising healthcare costs and all kinds of other issues. Some level of support and oversight is needed but it seems to frequently grow to the point where it becomes a net negative.

[mattkrause]

If you consider interns and residents doctors (which they are), it's not a wild leap of imagination to consider attendings "medical managers".

[linuxftw]

> Yes. If a doctor is working in a hospital, there are most certainly managers.

Maybe some places. In the US, most doctors are independent providers for hospitals, they don't have a traditional 'manager'. Outside of a hospital setting, this is also true.

> This is not simply "admin work". This is critical, life saving stuff

It may be, but it's lower skill work delegated to people that are subordinate to doctors, not their managers.

[aniforprez]

> In the US, most doctors are independent providers for hospitals, they don't have a traditional 'manager'

You are putting a round peg in a square hole. As I already stated, these are not the kind of managers we see in development where your manager is your "boss". Even as independent providers, doctors will have someone they are interfacing with who will see to the admin and other work so they are focused on medicine. Less than half of all practicing doctors in hospitals in the US are independent. Most of them are employed by the hospital. You are grievously misunderstanding the role of the "manager" here. There are certainly far fewer managers in independently practicing medical facilities like clinics but that's because the volume is far lower and the doctors themselves wear many hats

> but it's lower skill work delegated to people that are subordinate to doctors

Again, this is very insulting to the people working these roles. They are not "subordinate" and the work in not "low skill". These are parallel roles to doctors. Leaving this kind of work to doctors would result in a failure of the medical profession in its entirety because of the sheer volume and sensitivity of it

[linuxftw]

> As I already stated, these are not the kind of managers we see in development where your manager is your "boss".

We're talking about the kind of managers software engineers have. Doctors don't have those kind of managers, that's entirely my point.

> Again, this is very insulting to the people working these roles. They are not "subordinate".

They are definitely subordinate in any patient-care scenario. Anyway, I feel like you're missing the point of the analogy, analogies aren't perfect, and you know well what I meant.

If you want to argue lawyers and doctors have managers, fine, give engineers that kind of a manager. IMO, these are subordinate clerical people.

[mattkrause]

I'm not sure that's true.

Many lawyers do work on separate projects: Alice drafts my will, Bob handles your divorce, etc. Since these can usually proceed independently, there's not much to manage. However, bigger cases/projects usually do have a structure: someone, perhaps a partner, interacts with the client, develops a strategy, and delegates its implementation to associates.

Likewise, the doctor who manages your blood pressure in a private practice is fairly independent. On the other hand, hospitals, especially teaching ones, often incredibly hierarchical, with med students at the bottom and layers of interns, residents, chief residents, fellows, and attending, with a department chair on top. Attendings can treat patients individually, but they also oversee the work of the more junior staff; they're even called "supervising physicians" in some places.

If any project has more than a few people, I'm not sure how a "team" can proceed without at least a de facto organize/leader, and if that leader spends most of their time leading....well, that's a manager.

[fisf]

The important distinction is:

A partner in a law firm, who oversees a large case, is a lawyer. A doctor overseeing med students, etc. is .. a doctor.

These are competence and seniority hierarchies. That is very often not the case for eng. managers (and so inherently more dubious and less useful).

Try telling a surgeon, that his new supervisor is basically a glorified clerk, who will tell him what to do and in what timeframe. Having worked with doctors, I can vividly imagine a hilarious scene.

[adra]

Doctors have professional bodies that they can be removed from, same with lawyers, and accountants, and any number of professional associations. But the big differentiator is that largely these professionals do their work solo. They may need to consult with peers from time to time, but their day-to-day bread and butter is their own. Software development is not solo for the vast majority of devs. They need order and the ability to be directed to create a piece of the larger pie.

This is from a 20 year dev who's spent a few of those in management, but enjoys development more.

[rco8786]

> Do doctors have managers?

LMAO. Yes. They are doctors who went into management.

[gautamdivgi]

Isn’t that true for everything though? More bad devs exist than good one? I guess a manager could make the same claim that devs are making his life miserable.

[PakG1]

Yeah, it goes both ways. Worse is when someone thinks that they're this magical unicorn that is always right when they're in fact more often wrong and correspondingly makes trouble for everyone else. They make you out to be the enemy when you're not. It's horrible when that person is a manager. But it's also horrible when that person is a developer. Or any other role. I've managed people that you just have to let go, after trying every method known to man, you can't fix their fundamental psychology and neuroticism. Some people are just broken and organizations unfortunately are not equipped to deal with that (would be nice if every organization could have an in-house psychiatrist, but that's not the reality we have).

I will concede this though. When that bad person is a manager, EVERYONE on the team can suffer, the entire culture can suffer. When that person is just a team member, others on the team can usually figure out how to just avoid that person so that the problem can be compartmentalized. Better still, a good manager will not tolerate the bullshit because they know that it can poison the team if not handled properly. When that person is a manager, there's no avoiding the problem and team policies and culture will be poisoned accordingly so that the best people leave and nothing good is left.

[Goronmon]

Isn’t that true for everything though? More bad devs exist than good one?

It wouldn't surprise me to learn that a large number of users in this community have actually worked in a bubble of tech outside the norm where most devs were actually pretty solid overall. A developer who is truly incompetent (not just mediocre) would have a very hard time even getting hired at a FAANG or similar, let alone stick around very long.

[aprdm]

Be careful with the echo chamber you Want to believe in vs what it is. There’s plenty of incompetent people at FAANG or in HN.

[user3939382]

Actually I've developed the wisdom to realize that 90% of people are not good at what they do for a living. They don't have that job because they're talented at it, they have it because they needed a job.

[015a]

Its true, but I think the impact is what matters. Even a below average dev produces output; it may be substantially less than a great dev, it may not be of the highest quality, they may require more hands-on reviews and mentorship from other devs on the team, but its still producing output. In comparison, a bad manager can invert the productive output of a team or individuals on that team; high attrition rates, high quiet-quitting rates, prioritizing the wrong things, interrupting work such that little gets done, not playing defense, etc etc etc.

The "old" saying (well, I've heard it said a few times) is: bad software (probably) won't kill your business. There's a litany of examples to this effect. However, bad management will, with increasingly leveraged effects the further that bad management is from the line worker.

[t43562]

Bad developers write code that has a negative impact on team prouctivity. e.g. by insisting on a wildly overcomplicated implementation or writing poor tests and being aggressive to anyone that questions them, or being highly negative about some decision or other to the point where the team are not sure if that person is in charge or their manager is.

They can also pester everyone with mountains of trivia in PRs and refuse to change anything in their own and so on and on.

My own boss says "the main thing is to hire nice people - everything else can be improved" and that changed my perspective a lot. I think he's right.

A bad EM can do more damage of course. :-)

[Koshkin]

But the worst thing ever is when a bad dev gets promoted to the position of a dev manager or a tech lead. Armed with “knowledge” and “experience,” and now with a degree of authority, they would put their weight on everything they touch. The damage will be immense (but no one would care).

[sidlls]

So now we’re including actual engineers in this perpetual rant against management, now? Is it only engineers whose sole job is to write code given a spec who are valuable? At what level of seniority is a job “useless” or worse?

[julik]

Bad devs do not have reports they would have authority over. Bad EMs do.

[halfmatthalfcat]

The power dynamic is completely different. Managers have the ability to hire/fire, guide technical decisions (usually for the worse) and set the tone for the team since its "their" team. The team itself has very little recourse over a bad manager.

[ForHackernews]

They can quit. I promise you as a manager I spend at least half my time trying to keep developers happy and engaged because losing even one of them will cost the team way, way more in productivity than indulging somebody who wants to implement a perhaps-overengineered solution.

I don't know how it is everywhere, but in my neck of the woods good developers are hard to recruit and expensive to lose - they have a lot of leverage and they know it.

[halfmatthalfcat]

I've met devs who don't have the self-confidence to leave their current job under a terrible manager because they don't want to go through the equally terrible interview loops. They're stuck in some kind of purgatory.

[nonethewiser]

But a manager is something you progress into. How did bad people progress into it?

[felizuno]

This is actually pretty consistent across companies: being the most senior person around when the last manager leaves. Sometimes it's a senior dev, sometimes a PM, heck I've seen it be somebody from the UX org. The path of least resistance is a quick promotion from within. As many of us have experienced this leaves us with a non-zero amount of managers who are both unqualified and uninterested in their role, but accept it for status (you're supposed to get promotions after X years right?) and pay reasons.

[zuppy]

what people don't undertand (and that included me, when I did the change) is that being a manager is a totally different job than being a developer. you can be an extremely good developer, but be a lousy manager. there are different skills needed for those roles and not all of them are transferable. when you transition from a senior developer, you don't transition into a senior manager, you start from zero. it helps to be a good dev, but it's not a guarantee for success.

[johnbellone]

This is a common misconception and it is exactly how "bad people" progress into a role where they aren't a match. It is an entirely different role. Most engineering managers come from an engineering background and rely on the learned experiences of that job in order to be successful.

[UncleMeat]

There are oodles of terrible managers. There are oodles of terrible everything and we definitely remember the bad experiences more than the good experiences. Especially since a lot of what a good manager does (deflect distractions, ensure consistent prioritization, hire people who don't suck) makes it seem like nothing is actually happening.

A very large number of people really are saying that these roles aren't necessary. Larry Page famously fired all of the managers at Google at one point in the past. I regularly see people say that zero management at all would be preferable, both for startups and megacorps. Heck, the article itself is about this very idea.

[dahart]

Sturgeon’s Law: 90% of everything is crap. This applies to managers and to engineers. Turn your argument around and ask what happens when good managers have to deal with crappy engineers, because there are a lot of crappy engineers too. (And note especially that engineers can be bad on many axes. It’s possible for people with excellent technical skills to bring negative value to the organization due to poor attitude or poor communication, among other things.) Do you want good managers to judge you and assume that you’re a bad engineer just because they’ve had to manage some other bad engineers? Bad engineers also taint the role and lead to a certain earned reputation.

But if everyone projects their worst fear on the role, then we’re all stuck making assumptions, being pessimistic, and missing the good people because we’re blinded by our stuck ideas incorrectly generalizing individual people to their roles. If we can’t stop to see the good things and what does work, then functioning together is difficult and it drags down the team.

What value do you see in good management, and what makes a good manager in your experience?

[awillen]

I'm a PM, and I've had to live through a fair number of god awful engineers. It's miserable to work with them, too.

I don't malign the profession because I've had bad experiences. Engineers should be smart enough to know that experiencing a bad manager, or even a few bad managers doesn't mean that " people who live in these roles are overall bad, don't know how to effectively execute these tasks and present an aura of superiority over the technical roles when they're providing very little value at all."

That's just being irrational and salty.

[malcolmgreaves]

I’ve had to work with a lot more terrible engineers than terrible manages.

A lot of the time, what makes someone good or terrible in their role is maturity and professionalism.

[WastingMyTime89]

I don’t know. I think what some people complain about here when they talk about bad management has nothing to do with management. Most seems to complain they have to do reporting which is not fun. While that’s generally true I wouldn’t call that bad management.

I had a relatively bad (inexperienced and overwhelmed would be truer) manager once when I was still doing engineering years ago. I know he was bad because I had to do a significant part of his job for him notably regarding smoothing interpersonal issues in the team and cross-team communication in the org. I don’t see most people here complaining they have to do too much management.

[bumby]

>because more terrible managers exist than those "good ones" that you allude do.

The irony is that I've heard the same said about engineers. It's easy to take the cynical point of view, but probably not wise or accurate. Like the OP, in my experience the people making those types of claims tend to have an overly simplistic view of the problem.

[fsloth]

'more terrible managers exist than those "good ones" that you allude do'

This is quite hyperbolical. A person can have a life experience of "mostly bad manager", but that does not mean "most managers are bad" or that "most people have experienced bad management".

I've been 16 years as a professional software engineer. I would not describe anyone to whom I was a direct report as "bad manager". Quite contrary, I've been quite happy with most of them. This does not mean a life without conflict or misunderstanding, of course.

Statistically, bad management is of course a non-neglible problem, but the above makes the situation sound hopelessly pathological.

[ansre]

> I would posit a guess that most, if not all, engineers on HN have had to live through at least one terrible manager that has soured/tainted the position.

FWIW, all my engineering managers have been great.

> Oh please, there's a reason why those comments exist - because more terrible managers exist than those "good ones"

I guess that's just your experience? Just because you've had a few bad apples doesn't mean all engineering managers are terrible.

> present an aura of superiority

Sounds like you're just projecting your experience onto other folks.

[paxys]

I'd wager the percent of terrible managers is the same as that of terrible engineers. We all have worked with such coworkers at some point in our careers. Yet no one ever turns around and says "the engineering role is bullshit", simply because that would invalidate their own careers.

[tayo42]

Eningeers get tons of actually effective training and schooling. Alot of people probably spent at least 4 years in school learning a science where there are right and wrong answers. It's easy to evaluate engineers. Most managers seemed to get to that role by accident, or because they knew the right person. I think there's way more underperforming managers. Managers aren't going to school for years, even when they do the degree they come out with feels useless.