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