In the trenches: on being an Engineering Manager
blog.digital-horror.com
In the trenches: on being an Engineering Manager
1–10 of 54 posts
Re: In the trenches: on being an Engineering Manager
#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 to determine the success of the company. If, in some amazing conjunction of circumstance, it does there are terrible terrible problems in the hiring pipeline or in who is being promoted to leadership positions because it suggests the company is a barely controlled powderkeg.
And, frankly, this is not what culture looks like. This is preformative name changes to provide a distraction from whatever the real cultural activity is - which is determined by what the EM rewards and punishes; not by what they signal in low-impact cosmetic policies. That is branding - which is important but not a fraction as important as culture.
Re: In the trenches: on being an Engineering Manager
#3> 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…
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
Re: In the trenches: on being an Engineering Manager
#4> 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…
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.
Re: In the trenches: on being an Engineering Manager
#5I 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 the statement is obviously false.
For example, once a principal engineer asserted rather confidently, "At my level, the most important work you can do is usually in Jira." That's a claim that's hard to assess with any objectivity, but I can certainly imagine a different principal engineer feeling the exact opposite, and I can certainly think of many companies where they wouldn't hire/want a principal engineer primarily for Jira work.
Back to this article, any time somebody says "A manager is X" or a "staff is X" I think to myself... well can I think of a company that would want managers who focus almost entirely on not X? The answer is almost always yes.
Re: In the trenches: on being an Engineering Manager
#6Earlier 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.
[deleted]
Re: In the trenches: on being an Engineering Manager
#7> 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…
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 that requires a full rewrite it's probably going to be a no. But if it's not a major change causing a lot of work, we can possibly take a look at it.
If you've set up CI/CD properly, changing the name of the default branch can be done in less than an hour. Source: I did it at $last_company for circa 10x repos in about an hour. This was not related to inclusivity, but it did involve a discussion about whether we should switch or not: why; how; pros; cons.
Having a conversation about changing due to inclusivity is just a different meeting with a different why, how, pros, cons. One of the why/pros arguments might be -- that's now the accepted general default for most (external) repositories so keeping it as master would be kinda weird and might end up needing some explanation during onboarding -- i.e. more work somewhere else later on.
Re: In the trenches: on being an Engineering Manager
#8I 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 would be thrilled to have both a principal who loves jira, and one who doesn't. Someone who tries to straddle both just strikes me as neutered.
When it comes to roles, I always end up back to the Ron Swanson quote "never half ass two things; whole ass one thing."
I do agree with you though, one-size fits all definitions are almost all laughably based on "vibes."
Then again, isn't management pretty much just vibe cultivation?
Re: In the trenches: on being an Engineering Manager
#9> 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…
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 embrace it and handle these conversations with a happy smile on your face, so that the people who actually move the project forward are not distracted by it.
Re: In the trenches: on being an Engineering Manager
#10Welcome to being a line manager.