Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In the trenches: on being an Engineering Manager

blog.digital-horror.com

Post reply on HN
Print view View original

11–20 of 54 posts

Re: In the trenches: on being an Engineering Manager

#11

Post by zug_zug »

jahsome wrote: post #8
zug_zug wrote: post #5

I think this is a decent article, with some distilled wisdom... Though I also think it has some repeating status-quo mumbo-jumbo. Every time somebody says a soft-science claim and presents it as a fact, I try to vet it with this heuristic: It can't just sound good, or satisfying, but is it actually true? Imagine whether a case can be made for the exact opposite statement, or whether there may be circumstances that th…

As someone whose been sort of "up and down" the role ladder, and is very intentionally closer to the bottom than the top for right now, I think I am disproportionately perceiving the wisdom in that jira comment. I don't think it's the _only_ important thing, but I think I do agree with the sentiment that it may be the most important. Personally I'm all about diversity of perspectives when it comes to building a team.…

I think it only takes a few moments of skepticism to show that "Is X the most important thing about being a Y?" doesn't mean anything.

Being good at something obviously comes down to multiple different skills (manager may require social skills, writing skills, perception, business acumen, intuition, etc). So to try to ask which of those skills is "most" important is a poorly-defined problem, because there isn't such a thing as an 1-unit of of writing skill to weigh against 1-unit of intuition skill.

For whatever reason, a lot of people are drawn to these types of oversimplifications that are so drastic they become meaningless.

Re: In the trenches: on being an Engineering Manager

#12

Post by dijksterhuis »

twelve40 wrote: post #9
dijksterhuis wrote: post #7

Earlier quoted context omitted.

You're seemingly presenting this as an option between two binary cases. paraphrasing my impression of the vibe of your comment into the two distinct options: > Your collective opinions about how we work as a team matter > You're only here to work on things that are considered a priority In reality, there is always some nuance/middle ground available > Your opinions about how we work here matter. If this is something…

i think this is actually good advice when rephrased as: you are now a low-to-middle manager (that is called out specifically), so you neither call the shots nor are you mainly measured on your daily tech contributions, so from now on you can no longer avoid whimsical, irrelevant BS that is a waste of time like debating the branch names, because fielding that is a part of your job description now, so you need to embra…

Sort of. I wouldn't call it whimsical, irrelevant BS though. From the article:

> I remind myself that my role isn’t to be the most skilled person in the room but to create an environment where the most skilled people can thrive.

If most people in the team think we should switch to main instead of master, why would I sit there and deny the change? How am I going to find out if most people on the team think this way? Ask the question, let a discussion in whatever forum ensue, make some notes, ask some "dumb" columbo style questions, see what comes out of it.

It's not about me being right anymore. It's about the team being right. Ideally, together.

Re: In the trenches: on being an Engineering Manager

#13

Post by dijksterhuis »

Nice write up. Liked the thing on spotlighting. Experienced that in a non-dev role before and never really realised what that was at the time.

Some bits reminded me of some of the lessons in the linux kernel management style guide, so gonna link it here in case someone hasn't come across it before.

https://www.kernel.org/doc/html/latest/process/management-st...

Re: In the trenches: on being an Engineering Manager

#14

Post by roenxi »

rectang wrote: post #4
twelve40 wrote: post #3

Earlier quoted context omitted.

Yeah if they have time for "deeper discussions" about this, just run. Apparently, it's higher up in the article than the "choose postgres" managerial advice lol

Fine by me. Tech companies can sort themselves into groups: those where such discussions are welcomed and those who run from them. And I'm happy to see a manager put the "people" section above the section on "technology": > As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.

> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.

Yeah it is a lovely sentiment, but it is a sweet nothing if someone doesn't understand the techniques to back up nice words with an appreciation for the people behind the work.

We discover in the follow up that to this EM it means engaging in endless debate (the GitHub issue may have more spilled ink than a Tolstoy work) over the appropriate default branch name. That isn't what prioritising people should look like in practice. In fact that sort of debate springing up and becoming a serious milestone is the sort of thing that should trigger a check for whether empathy failures are taking place. Why is a culture developing where the team is being focusing on such trivialities instead of something that promotes their success or the success of groups like the greater organisation or customers? People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren't getting attention.

Re: In the trenches: on being an Engineering Manager

#15

Post by [deleted] »

roenxi wrote: post #14
rectang wrote: post #4

Earlier quoted context omitted.

Fine by me. Tech companies can sort themselves into groups: those where such discussions are welcomed and those who run from them. And I'm happy to see a manager put the "people" section above the section on "technology": > As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.

> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work. Yeah it is a lovely sentiment, but it is a sweet nothing if someone doesn't understand the techniques to back up nice words with an appreciation for the people behind the work. We discover in the follow up that to this EM it means engaging in endless debate (the GitHub issue may have more spilled ink tha…

[deleted]

Re: In the trenches: on being an Engineering Manager

#17

Post by [deleted] »

roenxi wrote: post #2

> Whether it’s debates like the shift from master to main in git or deeper discussions around inclusivity in language (master/slave rename in redis), these things can shape team culture. Well, that'll certainly do something to team culture. If an EM seemed to be significantly invested in this sort of decisions then I would form strong opinions about their ability to prioritise. This is just not an issue that is going…

[deleted]

Re: In the trenches: on being an Engineering Manager

#19

Post by fzeroracer »

roenxi wrote: post #14
rectang wrote: post #4

Earlier quoted context omitted.

Fine by me. Tech companies can sort themselves into groups: those where such discussions are welcomed and those who run from them. And I'm happy to see a manager put the "people" section above the section on "technology": > As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.

> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work. Yeah it is a lovely sentiment, but it is a sweet nothing if someone doesn't understand the techniques to back up nice words with an appreciation for the people behind the work. We discover in the follow up that to this EM it means engaging in endless debate (the GitHub issue may have more spilled ink tha…

> Why is a culture developing where the team is being focusing on such trivialities instead of something that promotes their success or the success of groups like the greater organisation or customers?

> People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren't getting attention.

I think there's a bit of irony in your two statements because you're arguing that the EMs should lack empathy for changes you deem trivial, and have empathy for changes you don't deem trivial. This is how you destroy an organization because these small issues fester into something more poisonous for your org.

For example, the branch naming schema cuts both ways. You could have a mostly yay vote on the branch naming pass, but the nay vote interprets it highly negatively or vice versa. Which means it's the EMs job to try and defuse that situation both by being welcoming enough to address these trivial complaints and by trying to identify the root cause.

Re: In the trenches: on being an Engineering Manager

#20

Post by roenxi »

fzeroracer wrote: post #19
roenxi wrote: post #14

Earlier quoted context omitted.

> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work. Yeah it is a lovely sentiment, but it is a sweet nothing if someone doesn't understand the techniques to back up nice words with an appreciation for the people behind the work. We discover in the follow up that to this EM it means engaging in endless debate (the GitHub issue may have more spilled ink tha…

> Why is a culture developing where the team is being focusing on such trivialities instead of something that promotes their success or the success of groups like the greater organisation or customers? > People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren…

> ...you're arguing that the EMs should lack empathy for changes you deem trivial

If an EM can't identify this change as trivial then they are going to be on the bottom of the spectrum of EM managers. It is trivial, everyone can tell that. Which side of the decision anyone comes down on is up to them, but if the issue of prioritising branch names becomes a subject of long talks, meaningful debate, inquiry and fact finding missions then the EM has done a bad job. OSS projects can tolerate that sort of thing because the entire OSS movement is ideological from the foundations up so they have to deal with ideological issues. But workplaces are for a different set of standards and ideally involve some professionalism.

If you have formed a genuine connection with someone, probed their emotional state and determined that the default label of the git repo is important enough to them that they are going to feel strong emotional disturbance over? And that it is the biggest issue in their professional life and deserves to be prioritised for follow up? The right thing to do is probably to send them to get some professional help. Or congratulate them on having achieved true joy in the workplace. Or reassess your ability to read people because you just probably got it wrong. Any which way such people are remarkably rare - generally more empathy will uncover that the default branch name is not the major issue that needs work.

Post reply on HN