9 ms·

In the trenches: on being an Engineering Manager

82 points by juxhindb 2y ago

coding123 2y ago
[dead]
roenxi 2y ago
> 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.
- twelve40 2y ago
  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
  - rectang 2y ago
    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 2y ago
      [deleted]
    - roenxi 2y ago
      > 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.
      - deleted 2y ago
        [deleted]
      - fzeroracer 2y ago
        > 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.
- dijksterhuis 2y ago
  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.
  - twelve40 2y ago
    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.
    - dijksterhuis 2y ago
      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.
- deleted 2y ago
  [deleted]
zug_zug 2y ago
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 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.
- jahsome 2y ago
  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?
  - zug_zug 2y ago
    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.
BikiniPrince 2y ago
Welcome to being a line manager.
dijksterhuis 2y ago
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-style.html https://www.kernel.org/doc/html/latest/process/management-st...
AllegedAlec 2y ago
Before reading: making the text highlight colour the same as the background is a choice.
- drorn 2y ago
  This needs to be discussed more. Great article though.
bilvar 2y ago
In my experience engineering managers have been just exception handlers, not leaders. If they can handle the exception by finding the right person to delegate to its fine, otherwise they rethrow so that that it bubbles up and the next level of management can catch it. Generally, they never made any real decisions or have any real vision to inspire with and execute.
- withinboredom 2y ago
  Are you on a team with strong personalities that actually lead? If so, then that manager is probably a bug in their ear about what the business wants. I love and hate managing those types of team because it is literally like herding cats. When they are going in the right direction, it is a blast. When they disagree with you, it can be painful. Especially if you have no real teeth to provide negative feedback. Leading a team when everyone is just "there for a paycheck" is much easier, but not as much fun. You basically just need to make sure all the tickets are lined up and everyone is working on the right things.
dfee 2y ago
> For those looking to transition into leadership, My biggest pet peeve in this industry is the self anointing of the “leadership” attribute. Its management. Just management. Some managers may be leaders, but most aren’t. Some ICs may be leaders. Most aren’t. Some politicians may be leaders, but most aren’t. Or maybe I just never grasped what leadership means. Either in the context of the world or our industry.
- cbsmith 2y ago
  I'm with you. There is a world of difference between leadership and management. Plenty of engineers who are good leaders.
t43562 2y ago
Cultural fit to me is a completely inadequate term to describe what I'm thinking about in an interview. Are they going to be an arsehole? This is my biggest worry after dealing with a couple, first as people above me then as members of my first team as a combined team lead/line manager. This is about being able to be reasoned with and not destroying team morale. I have always tended to feel that being right is more important than harmony but over time I realised how many of my "right" decisions were balanced by wrong ones and however many times I thought I saved the team with some good idea, someone else did it just as much with another one. In other words I'm on the very edge, at best, of being the arsehole myself. Someone who is further over the line than me definitely makes it miserable to go to work. I want my team to get on reasonably and each get a feeling of fullfillment out of the day and feel respected which requires good behaviour from me but also from them. I perhaps wouldn't want to say this to my own boss (who is ok) but I really care about this more than about the company itself. Companies have no loyalty and will make you redundant at the drop of a hat. They also sometimes do silly things which doom them and prevent you from being able to save the situation. You get given impossible things to do and stress out trying to do them. While this is happening, however, we can have a reasonable week without undue drama, fights, humiliation or fear. There's no reason that good software can't be the end result but more importantly you'll have an experienced team at the end who get better and better at working together and are potentially going to stay on.

82 points by juxhindb 2y ago

[dead]

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

twelve40 2y ago
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
- rectang 2y ago
  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 2y ago
    [deleted]
  - roenxi 2y ago
    > 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.
    - deleted 2y ago
      [deleted]
    - fzeroracer 2y ago
      > 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.
dijksterhuis 2y ago
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.
- twelve40 2y ago
  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.
  - dijksterhuis 2y ago
    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.
deleted 2y ago
[deleted]

zug_zug 2y ago

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

jahsome 2y ago
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?
- zug_zug 2y ago
  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.

BikiniPrince 2y ago

Welcome to being a line manager.

dijksterhuis 2y ago

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-style.html https://www.kernel.org/doc/html/latest/process/management-st...

AllegedAlec 2y ago

Before reading: making the text highlight colour the same as the background is a choice.

drorn 2y ago
This needs to be discussed more. Great article though.

bilvar 2y ago

In my experience engineering managers have been just exception handlers, not leaders. If they can handle the exception by finding the right person to delegate to its fine, otherwise they rethrow so that that it bubbles up and the next level of management can catch it. Generally, they never made any real decisions or have any real vision to inspire with and execute.

withinboredom 2y ago
Are you on a team with strong personalities that actually lead? If so, then that manager is probably a bug in their ear about what the business wants. I love and hate managing those types of team because it is literally like herding cats. When they are going in the right direction, it is a blast. When they disagree with you, it can be painful. Especially if you have no real teeth to provide negative feedback. Leading a team when everyone is just "there for a paycheck" is much easier, but not as much fun. You basically just need to make sure all the tickets are lined up and everyone is working on the right things.

dfee 2y ago

> For those looking to transition into leadership, My biggest pet peeve in this industry is the self anointing of the “leadership” attribute. Its management. Just management. Some managers may be leaders, but most aren’t. Some ICs may be leaders. Most aren’t. Some politicians may be leaders, but most aren’t. Or maybe I just never grasped what leadership means. Either in the context of the world or our industry.

cbsmith 2y ago
I'm with you. There is a world of difference between leadership and management. Plenty of engineers who are good leaders.

t43562 2y ago

Cultural fit to me is a completely inadequate term to describe what I'm thinking about in an interview. Are they going to be an arsehole? This is my biggest worry after dealing with a couple, first as people above me then as members of my first team as a combined team lead/line manager. This is about being able to be reasoned with and not destroying team morale. I have always tended to feel that being right is more important than harmony but over time I realised how many of my "right" decisions were balanced by wrong ones and however many times I thought I saved the team with some good idea, someone else did it just as much with another one. In other words I'm on the very edge, at best, of being the arsehole myself. Someone who is further over the line than me definitely makes it miserable to go to work. I want my team to get on reasonably and each get a feeling of fullfillment out of the day and feel respected which requires good behaviour from me but also from them. I perhaps wouldn't want to say this to my own boss (who is ok) but I really care about this more than about the company itself. Companies have no loyalty and will make you redundant at the drop of a hat. They also sometimes do silly things which doom them and prevent you from being able to save the situation. You get given impossible things to do and stress out trying to do them. While this is happening, however, we can have a reasonable week without undue drama, fights, humiliation or fear. There's no reason that good software can't be the end result but more importantly you'll have an experienced team at the end who get better and better at working together and are potentially going to stay on.