4 ms·

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.

by 015a 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
  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 4y ago
    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 4y ago
  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/ https://www.insomniac.com/careers/ [2] https://sms.playstation.com/careers https://sms.playstation.com/careers [3] https://www.valvesoftware.com/en/ 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=manager&page=1 https://www.epicgames.com/site/en-US/careers/jobs?keyword=ma... [5] https://www.respawn.com/careers https://www.respawn.com/careers [6] https://stripe.com/jobs/listing/engineering-manager-payment-processing/1938093 https://stripe.com/jobs/listing/engineering-manager-payment-...
rco8786 4y ago
> 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 4y ago
  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 4y ago
  > 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-processing/1938093 https://stripe.com/jobs/listing/engineering-manager-payment-... [2] https://www.youtube.com/watch?v=m4OvQIGDg4I https://www.youtube.com/watch?v=m4OvQIGDg4I
ewuhic 4y ago
PM as product or project?
- pyrale 4y ago
  Yes. (said tongue in cheek, but the confusion is so often carefully maintained that...)

by 015a 4y ago

bumby 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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 4y ago
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 4y ago
  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 4y ago
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/ https://www.insomniac.com/careers/ [2] https://sms.playstation.com/careers https://sms.playstation.com/careers [3] https://www.valvesoftware.com/en/ 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=manager&page=1 https://www.epicgames.com/site/en-US/careers/jobs?keyword=ma... [5] https://www.respawn.com/careers https://www.respawn.com/careers [6] https://stripe.com/jobs/listing/engineering-manager-payment-processing/1938093 https://stripe.com/jobs/listing/engineering-manager-payment-...

rco8786 4y ago

> 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 4y ago
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 4y ago
> 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-processing/1938093 https://stripe.com/jobs/listing/engineering-manager-payment-... [2] https://www.youtube.com/watch?v=m4OvQIGDg4I https://www.youtube.com/watch?v=m4OvQIGDg4I

ewuhic 4y ago

PM as product or project?

pyrale 4y ago
Yes. (said tongue in cheek, but the confusion is so often carefully maintained that...)