Re:As eng manager, you so frequently get request to drop wha...
by derefr on Wednesday June 29, 2022 @11:55AM
(#31921957)
"Engineering manager" can refer to different things to different people.
Some people think it means "a project/product manager (PM) for an Engineering team/org." PMs are all about meetings, because their job is to sit with the team, understand what they're doing, and then use that information to 1. glue the team together at the joints (i.e. act as an Enterprise Service Bus for the team's otherwise-flaky message-passing); 2. help the org understand where the team is with their work; and 3. balance the needs of the org with the needs of the team (mostly by pushing back against the org when people without the PM's understanding of the "inside view" of the team, request things that make no sense given that "inside view.")
Other people interpret the term "Engineering manager" as more akin to a tech lead — someone who does engineering, but whose responsibility is technically to marshal resources (other engineers on the team, usually more junior) to get things done. While these folks still do engineering, they only do it when things either "slip through the cracks" such that there are no people free to work on something (usually because the thing is urgent/unplanned, but everyone is busy with planned work); or when nobody on the team has the personal experience with the problem domain and also doesn't really need to have that experience (e.g. when an old legacy component is falling over and needs to be patched Right Now, despite a rewrite for that component being almost shipped.)
The problem comes when orgs try to conflate/confuse these two roles, and install one person (either with only one of the two skillsets, or with both) to serve both roles. Usually the person either becomes stretched far too thin; or just fails to do the half of the job they know less about.
Some people think it means "a project/product manager (PM) for an Engineering team/org." PMs are all about meetings, because their job is to sit with the team, understand what they're doing, and then use that information to 1. glue the team together at the joints (i.e. act as an Enterprise Service Bus for the team's otherwise-flaky message-passing); 2. help the org understand where the team is with their work; and 3. balance the needs of the org with the needs of the team (mostly by pushing back against the org when people without the PM's understanding of the "inside view" of the team, request things that make no sense given that "inside view.")
Other people interpret the term "Engineering manager" as more akin to a tech lead — someone who does engineering, but whose responsibility is technically to marshal resources (other engineers on the team, usually more junior) to get things done. While these folks still do engineering, they only do it when things either "slip through the cracks" such that there are no people free to work on something (usually because the thing is urgent/unplanned, but everyone is busy with planned work); or when nobody on the team has the personal experience with the problem domain and also doesn't really need to have that experience (e.g. when an old legacy component is falling over and needs to be patched Right Now, despite a rewrite for that component being almost shipped.)
The problem comes when orgs try to conflate/confuse these two roles, and install one person (either with only one of the two skillsets, or with both) to serve both roles. Usually the person either becomes stretched far too thin; or just fails to do the half of the job they know less about.