Engineers who don't appreciate the role of the product/marketing/management layers don't seem to understand that if they had to take on those responsibilities it would leave them with no time left over to write any code. If nobody takes on those responsibilities then our company won't make money to pay anybody to write code. It's not chicken and egg, it's cart and horse.

If you don't want to become a marketing expert as well as a product design expert for the sake of doing all these things simultaneously consider being glad others are taking things off your plate and coordinating work without you so you can focus on writing code.

Regardless if the manager is helping the team they almost always drain resources to aggregate information that they can synthesize upstream. It's a system that is so fragile it's not hard to see why we have an industry full of people that experience this.

As for "draining resources" to do whatever reporting they need to do I don't think I understand what is fragile about it or why it would be anything other than necessary. It's like log aggregation/introspection, you do it because you want to see what's going on at a lower level without dealing with the minutia of every point of data.

To this end as engineers we design code that fills management roles all the time in our systems, and we understand perfectly why their role is needed but sometimes fail to realize that human systems are analogous. Nobody is arguing why a load balancer can be an important part of a system, or the values provided by ORMs, but here we are arguing about what managers do in a complex human system.

I'll point out that the world is pretty diverse and there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer. There's an interesting phenomenon that it seems like a lot of folks manage to build up reasonably long careers while only running into one side of this divide or the other and not even realize that the verdict on ORMs isn't a settled fact where one choice is always right.

Perhaps it's similar with engineering management and we should be having a more nuanced conversation.

This doesn’t mean that both groups are right though.

I think a more accurate take is that it can "drain resources" from the individual to provide a net positive impact to the team (ideally). The problem with a lot of the cynical takes here is they appear to be only considering the perspective of the individual.

It's like the idea that if somebody stops by my office to ask a question; it's great for them to get an answer, but a detriment to me because it interrupts my work. If all I cared about was personal productivity, I would lock my door but the overall team productivity would likely suffer. A good manager puts together a system/culture that balances all those competing goals to the betterment of the team.

Here’s an idea: Provide this information before they have to ask, when it’s convenient for you. Like between tasks.

Took a 5min break? Move the damn story over to done. Got stuck and seeking clarity but are blocked? Leave a quick comment.

If your manager has to ask what’s going on, you’re not communicating enough.

Not to say this work is necessarily not worth the cost, but it absolutely costs something.

Sometimes that's all the manager wants, and the team lets them down. Sometimes the team takes hours estimating work that no one can reliably estimate, because management wants a burndown chart to feel good about, even though the last n burndown charts were wildly inaccurate.

As with any situation, issues happen at every level. What's unique to managers, though, is that they combine overwhelming power on the team with zero accountability to the team. Obviously when something goes wrong the team is going to be mad about it.

Spending on marketing is like building and maintaining a nuclear arsenal in this respect: It is to everyone's detriment (yes, everyone) but if the competition does it, you must also.

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.

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.

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.

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.

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.

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.

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!

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.

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

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.

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?

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!

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

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

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.

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.

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.

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.

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

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

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.

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

> Often just attracting bad personalities.

> Its always someone who wants to do something different then engineering, they become a manager.

You are saying these things as though they are simple truths that I am just supposed to accept. But I do not.

People who end up as managers are selected for their potential and receive lots of support, more often than not.

Often attracting great personalities since the job is about interfacing with people, more often than not.

It's always someone who wants to do management, whether or not they want to continue engineering, more often than not.

> Imagine if we hired engineers because someones friend thought it sounded interesting and they had to do all their learning on the job.

Yea, sounds terrible. It's a darn good thing we don't hire engineers or managers like this.

> managers are selected for their potential and receive lots of support

This support im questioning. Its all on the job training. I went to business school, i actually have a business degree. I didn't leave that school feeling like i should manage or lead. The "training" is on the job, the people who teach are your small peer of manager peers and maybe some corporate style training. Corporate training has never been effective from what I have seen.

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.

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

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.

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.

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

Also Devs: "Managers are so useless lmao"

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.

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.

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.

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

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.

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

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?

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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

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

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

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.

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.

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

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.

Your analogy is bad only because you have no idea what you're talking about. Technical people need managers because technical people will do things other than their actual jobs and I say this very frankly as a developer. It is remarkable how similar doctors and engineers can be in that they are lost if left to their own devices. Just as an experienced engineer will wear many hats and can manage themselves, experienced doctors also successfully set up their own practices where they can manage themselves. But a good hospital manager can literally save and change lives

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.

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.

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

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

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.

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.

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.

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

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.

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.

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?

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.

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

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.

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.

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.

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.

Well product or sales probably don't like stuffing the product with ads, they only put it in there because you like collecting a paycheck every month.

I don't think your view is anywhere near as common as you think it is, but maybe in your immediate peer group there's some self-selecting cause for believing so.

I cannot do sales, I do not want to do sales, but if I want a job someone needs to do sales. To me sales looks like an awful job, but some people really get a kick out of it and I'm glad they do because otherwise I would earn a lot less than I do.

We love to think that "if we build it they will come" but the reality is very different, and most of us work for companies that would struggle to grow without some form of sales or marketing operation, no matter how good the product might be.

You meet new people. They tell you about their problems. You explain to them how your product can alleviate them. You work on finding a common position regarding what you could bring at which price. When it works, you get a big cheque. It’s pretty fun really.

Once that connection has been made I can definitely see the attraction.

As for what I think about managers: unsure, I have been a manager, worked under many managers (most of them bad) but I am still not sure if mangers should exist or be replaced with another role.

The point of my question is to make people stop and think about the chesterton's fence of why is that position there. For example your janitor example. Extremely well defined position. Most people do not want it (including yourself).

The reason most engineers don't have secretaries is because we usually prefer doing the same thing with automation and scripts.

Edit: To clarify lead engineer, they have authority over technical decisions, not people management.

I was terrible at it. Forced to actually contact customers I had no clue what to do. I had no idea how to price things. I communicated terribly and drove away initial customers.

I learned a healthy respect of other positions in a company, because when I tried them I had to accept they were actually hard.

And sorry, unlike a program you’re writing, you don’t have any say in how the logic works (or doesn’t). The rules are set and you’re in the system. You might be able to find some variations in other companies.

As you grow, you do realize that software engineering is a piece in the overall puzzle and you mellow down and start to learn the interfaces with other functions. Even then your superiority bias won't away but will mellow down for sure. This is simply because your success as a mid-senior engineer is no longer a function of just your engineering skills. Its a function of how well you can sell your ideas, how you can articulate your messaging so that every other function can work with you, how do you get buy-in from competing parties etc. But again, engineers will brush these aside as 'politics' unrelated to software engineering :)

Year after year after year I learned again and again that there's something truly toxic about middle-management and up. It's like the higher you go, the worse the air gets, and your brain starts to get clouded and fuzzy. Technical people stay in their roles for decades and get better and better over time; management plays musical chairs where they change roles every 2 or 3 years. The new role has almost nothing to do with their old role. If you saw a whole group of people randomly switch every couple years between being an Aerospace Engineer, then a Software Engineer, then an Environmental Engineer, then a Structural Engineer, you'd rightly go: wow, all these engineering jobs must be super easy! They just throw anybody into those roles. They don't take any time to learn, etc. etc. So why, when people randomly switch every couple years between product manager, director of operations, financial director, project manager, sales manager, director of internal innovation, director of digital growth, director of New-Techy-Buzzword -- why do you not conclude the same thing? All those jobs are stupid and worthless, clearly, because they come and go with the wind, and anyone in the mid-to-upper-management sphere can take on any of those roles. Clearly they require no training. Clearly they are not hard. Having an MBA degree does not qualify you to do all of those roles, unless those roles have absolutely nothing to them. Note that I intentionally excluded anything having to do with "legal" in there, because that's an actual job that takes an actual expert.

My long-winded point is that I did the exact opposite of what you claim. I used to believe that software engineering is a piece in the overall puzzle and that all these other functions are an important part. But I learned, time and time and time again, that the primary driving force in corporate America is the Principal Agent Problem and that all these roles are just titles to be shuffled around among those in the Business Caste for their own personal benefit. Entire companies are nothing more than pawns in the game these guys (and it is mostly men) are playing with each other, jockying for the most impressive-sounding titles, extracting as much money as they can from the public sector into their own pockets. If they're actually doing their job well, they're losing at the game. You have to switch jobs every couple years to keep up.

The last 2 paragraphs of your comment can be applied to your behavior actually.

Your comment added nothing because it was responding to a straw man rather than the article itself.

Imo, the real problem is that engineering work is disproportionately difficult compared to management and yet, management gets recognition, visibility and power to control engineer lives. This happens in every step. Engineering interviews are insanely harder than management, engineering promos are opaque and need grinding for years as opposed to management promos in growing companies and these days, senior engineers have to manage politics as well. Engineering managers are not useful in any way but yet, get higher compensation and recognition. Why?

The only manager that engineers like are those who have previously been strong engineers themselves. It's the earned respect that lets people be ok with bosses. Not titles themselves. Certainly not people management or glorified assistants managing spreadsheets for upper levels.

Perhaps this is why there are so many bad examples. The job is nearly impossible to do exceptionally well.

Therefore technical people develop a special sort of humility, reminded everyday of their errors by the law of physics, that bad managers who fail forward never do.

I mean, structural engineers are fighting physics. Software engineers, generally, are fighting information theory. FWLIW, I spent 15 years as a (quite successful) programmer with a lot of bullshittery going on about what code works. Have you never shipped buggy code and played it down b/c of time constraints or you were just tired or not motivated or realized this bit doesn't actually need to be perfect?

That's actually why I switched to being a people manager - I was a mediocre programmer that people thought was exceptional because I was good at the b.s. I find people management much more difficult to do well, and much more rewarding when growing junior eng into senior eng compared to shipping a bit of code.

Great EMs have that experience; and it makes their/your job way harder because now you understand, at a deep enough level, what the people you manage are going through. When product reqs come across the desk of an IC-turned-EM, they can feel that gut punch immediately: "fuck, this is going to be so hard, that system is so legacy, and Sarah is super overloaded right now because she's the only one with any experience on the message bus transformer converter ingester"

Management track EMs actually do have it easier, because they get to think in the discrete world of tickets and human resources.

At a high enough level in any company: senior leadership needs to think about the world as perfectly discrete like that, because there's so much other bullshit going on that worrying about the specifics of the message bus transformer converter ingester would drive them off a cliff. But EMs aren't that. But many, many EMs think like that, and a big part is the incentive structure of their career path; their boss thinks like that, and their boss's boss thinks like that, so if I want to have my boss's boss role one day I need to think like that.

The strawman side of what I'm arguing is: "Well, you're just describing a bad EM". But the whole point is that that's quickly becoming the average in the industry, and that average is starting to define the role. Career-track management who get promotions, then write the hiring reqs for their replacements, and every other EM below them, combined with a massive shortage of engineering talent meaning companies need to define a different bar for their EM hiring reqs anyway.

And engineers who don’t invest in their work emotionally are not usually the best

>> Maybe you work at some poor company that can't promote devs high enough so they're forced into some form of management role to get a promotion.

How does this follow from what I said? Also, I have a bit of experience so it’s not one company

I believe that the job is nearly impossible to do well. Which leads a lot of people to suspect that the role of Engineering managers is badly defined. Which leads to all the complaints above. Nobody is happy with the current org structure.

I think it's fair so say that gross incompetence is easier to recognize in a programmer than a manager, especially to the untrained eye. It's also true that a well-functioning team may be easy to run and the manager shouldn't have to do much except not fuck it up.

But at any kind of scale, all problems are people problems, and there are never ending systematic dysfunctions and organizational problems. Everyone can be making a valid claim to doing their job, yet the output is nowhere near what it could be. These types of problems can be difficult to diagnose and extremely difficult to unsolvable at the high end. One must be technical enough to understand the details, able to zoom out and understand how costs of various paths interact with UX, operations, security and other concerns, and then say the right things in the right venues to nudge people in the right direction while also maintaining the morale and agency of all the ICs who do the actual work.

It is brutally difficult, and the reason most EMs are bad is not out of malice or sociopathic tendencies (though I will say the emotional toll is high for non-sociopaths which is probably one reason they are disproportionately represented in management and executive leadership).

Can they? Certainly. Do they? Well, not as often as you might like.

I used to work for a government contractor who had what I liked to think of as a "butts in seats" strategy. The contractor got paid by taking something like 50% off the top of what the customer paid for the employees (back when I was a contractor in industry, that was more like 15% but that is neither here nor there). The "complexity and nuance" that goes into running that business for a maximal profit involves keeping the direct customers happy---and they're managers, not users---while having as many employees as possible. You need to ride the line between leaving money on the table and having so much broken that higher levels of the customer start to get upset. Laying down narratives is a very important part of that process.

This isn't, however, limited to government contracting. I've ridden quite a few projects into the ground in industry because the goals and incentives of Product Managers, Program Managers, etc., were not aligned with the goal of a successful project simply because there are many ways to be a successful manager and a track record of successful products is not the easiest.

Yes, they were all smart people. Many were even likable, skilled leaders. But if your goal as an engineer is to be part of a successful product and not to be a well-rewarded part of a successful manager's organization, then you will not be happy. Is that what you mean by "professional immaturity"?

It seems really unfair to a developer, who thinks "if I screw up the entire company halts, if you screw up I have to work harder". And so the developer can't shake the feeling that management is bullshit.

There is way-way more to it than the title. Nowhere did the author reduce the contribution of non-engineering roles.

An excellent read!

When that happens, other people have to be involved to take over.

There are real requirements to communicate with other parts of the business, customers, coordinate who is doing what and triage what is needed when.

So generally, I agree with you that the mindset isn’t a great one.

At the same time, there are methodologies that aim to alleviate exactly this problem by ensuring engineers directly control more than they often do.

Scaled Agile (SAFe) is my favorite because of two core tenets.

1. There are 2 backlogs, one managed by product/business and one managed by dev/ops/arch. Going into planning, capacity allocations are given to each (usually 70-30 product dev). Priority among those backlogs is entirely handled by the group managing it.

2. PI Planning where backlog items are presented from each group and dev is responsible for planning out those priorities over the next 8-12 weeks in the manner that they believe is best. Everybody who could potentially answer questions that devs have is present with their schedules cleared to streamline the decision making process. Plans are discussed with management, risks assessed and finally agreed on.

I love this process. It gets everybody on the same page as far as who is doing what, when and why. It reduces friction and lets devs focus for 2-3 months at a time without a directional shift.

Planning from product is focused on the next PI instead of the constant “we have to drop everything and work on X now!” situations that so often happen.

I wish more orgs would adopt it. I hear so often about devs stuck in orgs claiming to do so that aren’t actually doing any of the things that make it great and it’s frustrating.

I love how you also snuck Scrum master in there, a role no one needs. Project managers are also often shoved into places they’re not needed (I’ve generally found them to be a net negative vs having the manager be responsible for it).

Meanwhile there are numerous process and personnel challenges that go completely ignored, because these Engineering Managers think their primary responsibility is as some kind of overseer preventing employees from doing their jobs wrong.

I would love if software companies started hiring dedicated, trained Managers. But that doesn’t seem like a thing they do. Instead they just promote an Engineer to Engineering Manager and hope for the best.

During my time writing software professionally I've had good, bad, and neutral managers.

I've found most of my good managers at companies that produce software as a product. These managers were technically trained and rose to their management roles through working as engineers at other companies. In two cases these managers were actually the CTO.

Most of my bad managers have been at companies that rely on software to facilitate their business, but do not consider software to be their business. These managers knew little about software and our teams were usually bloated by non-technical roles and often unproductive. Every idea ultimately had to be passed through engineers for validation / refinement and engineering became a very constrained resource.

Neutral management is where I would place most of my managers. They don't really aid in or detract from my productivity. They're there and doing things (even if those things are not always visible to me). They demonstrate enough value to dispell the feelings of: "If you weren't here then we could hire another engineer to actually work on this problem".

That said, you are 100% correct that if I didn't think about these things at all then I'd be much happier. After all, happiness is reality minus expectation.

Mind you - to "them", these "dreaded MBAs", the development organization is a problem, often regarded as cost, and development is done by... developers. Sometimes the developers is the actual problem and they have gradually sunk the software in to a unmaintainable swamp of crappy code and debt - but this is a competency and hiring problem. It will not be solved by any framework or project manager. But you need the competency in your leadership to understand what's what and this is missing from pretty much any large org I've set foot in. The high functioning teams is these settings are more a stoke of luck, and they often have to utilize guerrilla tactics to keep delivering value.

I've seen my fair share of global CIO's talking us through cloud and blockchain, never have to actually deliver and move on to the next company or fancy role.

I've seen CIO/CTO not trusting developers and believing no-code and citizen development to be the end all. Guess what - more unmaintainable crazy stuff

I've seen large organizations falling in to the "one system" trap on all levels, even trickling down to the software teams - a dedicated 8 person jira team for the whole org! What could possibly go wrong.

I've also witnessed amazing autonomous development teams that move at amazing speed with quality. In these settings you have management that understands the process of supporting a business with valuable code.

Most of the time IMO it's the business themselves that cause a lot of the problems facing developers by not understanding that it's they who own the processes getting digitized.

They buy software from vendors, staff up a project team to integrate, fire and forget. This "fire and forget" project mentality is what accumulates in a shitty org, and shitty orgs start from the top.

If you haven't read "Turn the ship around" it embodies all of this. This condensed video is really worth a look:

https://www.youtube.com/watch?v=psAXMqxwol8

Having these ideas in mind, particularly backed up by some good background as is present here - some discussion on knowledge work, Peter Drucker quotes - is context orgs ought to try to be aware of, prevent from happening.

Sad to see such a well written well explained article reduced to "grow out of their mindset" antagonism. There's not any argumentation in this rebuttal, just personal badmouthing & berating. The conflict described is real, but apparently people who feel tensions & dissonance of it all are all just "immature".

Yes we know management metrics can't predict every end date, we know agile doesn't solve every problem, we know blockchain is a solution without a problem, we know code complete and the mythical man month are some of the best programming books.

There is no meaningful correlation between title, schooling, and/or effectiveness in management.

Everything would grind to a halt if it weren't for people who do X. Everybody else exists because X people are doing X.

For better or worse, this is what we, as an industry, have adopted and a generation has grown up not knowing any better.

All roads lead to the engineer. Bad managers can be worked around. Mindless PMs can be worked around. But if every engineer at apple suddenly stopped working there would be real economic consequences. If managers and PMs stopped working they'd be replaced by engineers who are by and large more capable at adaptation anyway. Engineers should hold all the power. In most orgs management exists to prevent what is effectively an artificial union forming among engineers. Most, I'd argue even 99%, of engineers do not want to be sitting in meetings and spending 9 hours a day building CRUD. Without the guy cracking the whip over your head you wouldn't. I wouldn't. Anyone wouldn't. The power dynamic favors managers - hence all the hate.

MBAs take a lot of flak because much like the kid engineer coming out of school who believes he's legitimately God's gift to man the MBA does the same. The difference? The MBA controls your salary, whether you keep your job, whether you get your job, the direction of the company, the marketing of the product, the features that will be worked on, the finances of the company, etc. The MBA holds legitimately all power that is not engineering. As such, by generalizing and blaming "the MBA" you are more right than wrong on who is the real problem. I believe most engineers should go back for their MBA. Not to get better at business but to understand their enemy. An entire career is boiled down to a few excel formulas.

Do you know what makes me happy? Not even knowing my manager exists. Not even knowing my PM exists. In my a little over 10 year career I can name two managers and one PM that actually made a fundamental difference to me. I'd be infinitely happier if PMs and managers were replaced by robots that let me do my job and enjoy what I do. Instead, even something as trivial as "I'd like an extra day to optimize this because I can see it having problems under load" needs to be "scoped" and "talked about", then it needs to be "put into a future sprint", then it needs to be "pointed", "tagged", "etc". This is borderline tyranny to someone who is creative. Only a spreadsheet monkey sees value in this nonsense because at the end of the day I'm right (because I built it) but I won't be given time to do it until it breaks (because the MBA), when it does I will be on pagerduty and probably hearing about it (from my manager), and then I will need to ask for time and a meeting will be called to discuss and do JIRA nonsense (by the PM). You see? As an engineer it's always my fault. Even when I'm right. Who are the people who will arrive at my desk to blame me? Them.

It's funny how these ultracapable genius engineers don't just start their own company free of these bullshit manager and PM roles and just steamroll the competition, isn't it?

1. They would rather be building cool things than doing all the other things involved in running a company. Nobody said managers are doing literally nothing, just that they're generally not very good and they really don't deserve or earn the authority they have. Their role is a support role, like a typist or a document manager or something. They should be considered basically secretaries to the engineers, so your question is "why don't the engineers all go become secretaries then?". Not to bash secretaries, but rather to give you the point that their authority comes not from what they do, but rather from the caste they were born into and/or the college they graduated from.

2. Many of them would go and start their own (likely very successful) companies, if doing so weren't a gated community open only to either (A) those who already have lots of connections and lots of family money to fall back on as a safety net if they fail, and (B) those who are willing to subsist on dry Top Ramen and live out of their car for years while they devote 100% of their time to their startup. Most of the good engineers out there have responsibilities like kids and/or mortgages, because it takes a long time to become a good engineer. And most people aren't born into the "business caste" that starts companies and becomes high-level managers at companies in the US.

3. They do. When it does happen, they become wildly successful and do completely fucking steamroll the competition, because the competition actually truly veritably is garbage run by chucklefucks who are only there because they were born into the Business Caste.

lol, okay, maybe before you have a couple $50k/yr revenue customers that rely on that legacy/tech-debt to run their business.

ask windows/office devs or linux kernel devs how often they get to fix all that tech debt.

(other people doing stuff, inducing mild amounts of accountability)

> This is borderline tyranny to someone who is creative.

> most engineers should go back for their MBA. Not to get better at business but to understand their enemy.

That's an incredibly adversarial attitude severely lacking in self-reflection and empathy. It's really tough to work with people wound so tight. Having been a manager, if I were yours, I'd be working on helping you grow up a bit, and if that didn't work, I'd be helping you find a different role that was more suited to your...ahem...creativity. A role far away.

I play ball at work because if I play ball I continue to make enough money where at the end of the day I don't care. I'm fully capable of reading a room and know full well the consequences of stepping out of line. Frankly a manager "helping you find empathy" strikes me as a form of indoctrination.

But thank you for the deep psychological analysis. Frankly I'm glad you're not my manager because the saccharin nature of your psuedo intellectual post would probably have me quitting anyway. It's always the "empaths" who are the first to fire the shots across the bow in the face of valid (albeit direct) criticism.

The scary part is, if you went to a selective enough school, it kinda works.

The Ivy League undergrad -> elite MBA -> management consulting -> C-suite pipeline is especially frightening.

The worst in my opinion is finance-- it's like driving using the rear view mirror. No business has ever succeeded or failed because their accounting was really tip top.

People would laugh at the idea of a good leader being thrust into a SWE role based solely on their leadership skills. Yet we often think transitioning from a SWE to a leader is just picked up. I'm asserting that they are different skillsets. Will being a good developer help lead a team of SWE? Absolutely, but that alone doesn't provide the requisite knowledge and skills to perform a manager role, but we often think that's the bulk of what's necessary.

Not so sure about that. In the beginning of my career I looked up greatly to a lot of people in these roles. The older I get the more that has faded. Truth is I can do their jobs fine, but they can’t do mine; yet they have a tendency to look down on me.

(I’m in Sweden though, and the MBAs still have a very strong grip on the Nordics. Might be a different social dynamic in the US.)

Coordination is necessary. Communication is valuable. Running a business is complex. Product managers do valuable work. Designers do valuable work. QA does valuable work. Leadership does valuable work. Engineers do valuable work.

The core of an EXTREME number of complaints about modern professional software development lies in the pervasiveness of Career Management; and EMs are an extremely attractive entrypoint for people into this kind of track, who have no experience in any of the IC-facing roles, yet now they're managing ICs.

Just go look at the vast majority of job postings for EMs. The requirements are extremely bare on actual, hard engineering experience; maybe you see the last requirement read something like "built an app in java or c++", and it never gets covered in the interviews.

You can't manage a role you haven't held, I will die on this hill. Senior leadership is fucking hard; that takes specialized skills, MBAs maybe, a little bit of crazy as well. EMs are not that, and anyone who tells you what EMs do is remotely as specialized as what the people higher up do is probably an EM. At their best, EMs should have an engineering background (or at least PM/PO; having worked with engineers as peers); they should know what it takes to build modern software systems from the inside; they should know how to mentor. At their worst, EMs who don't know any of this, but know management, spend their days as a Jira parrot and can make the lives of the people they manage miserable.

Its actually astounding to me that this is controversial, and that people don't recognize that the only reason companies change the requirements bar for EM positions is because, if they made the bar what I describe, that candidate would also make a great engineer; and companies are short engineers, not short "people who manage people". Its not out of some grand design that the best managers live on the management track. Many, many other specialized disciplines don't do what Big Tech does. The tracks for Engineers and Engineering Managers shouldn't be separate; they should be one track. But Big Tech companies don't want their engineers leaving the IC role, so they make do; and the irony of it all is all this does is lower the average quality of EMs in the org, which causes engineers to leave anyway; just to competitors.

That's why Engineering Management is bullshit. It doesn't have to be. Much of what that role does is necessary; its just overwhelmingly filled by the wrong people, who then morph the role into some bastardization of what it should be, get promoted, then write the job spec for their replacement.

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

[2] https://careers.google.com/jobs/results/77396557743170246-en...

[3] https://boards.greenhouse.io/cloudflare/jobs/3135805?gh_jid=...

Yet, you also used just five examples, presumably from your own experience, to tar entire professions.

Yes, there exist incompetent PMs, Architects, Team leads, and so on. There are also competent ones. Just like there are incompetent and competent engineers. No profession has a monopoly on bullshit.

The exact same thing can be said of programmers/developers; there are TONS of bad ones. The fact that there exist bad managers/pms/etc does not invalidate the need for good ones.

it doesn't matter if you have the best product in the market, if the competition releases before you and has obtained all the clients. for the client, the task of moving to a slight better solution may not cover the cost.

just because people have other jobs, it does not make them stupid. of course, what i've said in here is over simplified, there are a lot of other jobs required in order to have a healthy, viable product with clients and cash flow.

Unfortunately one of the side effects of having something so important also be so complex, hard to reason about, and hard to prove causation for, is that there are a lot of empty suits attracted to an area where it's hard to disprove that they contributed, but a lot of money to be made if they can convince the right people that they did.

By definition we can't know how many are genuinely hardworking contributors, how many are parasites, and how many are somewhere in the middle (e.g. did some good work but is phoning it home these days, got lucky but misattributed their own success so now just doles out bad advice). Claiming that only one of these three groups exists is of course naive - but when running into people who have a different perspective or make different claims, it's worth keeping in mind that the subset of these groups they've run into might differ from your own.

Cow dung is common too, but not necessarily useful. Maybe for manure...

Most actual work happens despite those roles, not because of them... Or even against them - and is dilluted, sabotaged, rushed, and crapped upon all the time by the decisions of the roles above.

If you meant "software production needs this role", then no. Software production (from Xerox Parc to the Linux kernel) can be just fine without them.

If you meant "a modern corporate bureucracy needs those roles to make a product", then maybe, but that's part of the reason those enterprise products are shitty.

There are just as many useless managers as there are useless reports. The reason you see so many 'managers suck' posts is because they're in a position of authority over the talent they manage. That's all.

Management shouldn't mean authority, it should be like HR or IT, a support role.

AKA the manager.

I'm gobsmacked by the entitlement of these people.