Live data from Hacker News

In the trenches: on being an Engineering Manager

blog.digital-horror.com

41–50 of 54 posts

Re: In the trenches: on being an Engineering Manager

#41
post #9

Earlier quoted context omitted.

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? A…

Usually these things are obvious, no? (If not then it's going to be very challenging to be a [people] manager.)

Depending on location and/or cultural composition of the team these things will be either no-issue (no one cares enough to voice either approval or opposition, if some change is requested by management or some platform introduces some changes it's just inconsequential for the team) or there will be someone who sometimes will voice suppport/opposition so their needs have to be weighted (but as long as there's no conflict within the team it's smooth sailing) and then, if there is conflict then there's obviously a cold war in the making. (And at that point either the manager has enough authority and agency to work out some lasting compromise, start removal of someone, or they are at least can recognize that it's time to look for a new job, as things about to get ugly.)

Re: In the trenches: on being an Engineering Manager

#42

Earlier quoted context omitted.

Reasons why nobody worthy of the title engineer should take this definition seriously: 1. It is recursive 2. It equates training and education with competence 3. It was written by a bureaucracy

I don't see why any of those are negative qualities.

Well number 1 is a negative quality because it is a negative quality.

Re: In the trenches: on being an Engineering Manager

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

Re: In the trenches: on being an Engineering Manager

#44

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…

But changing the name of the default branch is not worth one hour of eng time, much less the annoyance of the other team members. I understand that the term "master" is offensive to upper class white people, but I just don't care. They need to stop acting like crybabies and get on with doing their jobs.

It was in our case, because of legacy working practices from the old team (who weren't there when we arrived). It was making everything more confusing for us, and annoying. We weren't working in the same way they did (which was completely nonsensical in my view).

So it made sense to switch things after putting up with it for 6 months. We were annoyed enough that the mental load of not being annoyed about it anymore was worth one hour of me changing it so we could show up to work free of being annoyed of this specific thing. Plus we were getting new hires who were very junior, so having things match "how to git" tutorials on the internet made way more sense. Plus it made every repo match, no longer did we have 10x repos doing things one way and another 30x doing things another way.

I legit just had to click a bunch of buttons in gitlab for an hour. It wasn't hard. I've wasted way more time sitting in meetings with executives talking nonsense.

The pro strat would probably have been to do this while in a meeting with executives tbh.

Re: In the trenches: on being an Engineering Manager

#45
post #34

Earlier quoted context omitted.

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? A…

Oh my god, if my manager asked me to waste my time on such trivialities - or even worse, calling team meetings to “discuss” them so that we can now collectively waste our time, I would quit the next moment. During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.

> calling team meetings to “discuss” them so that we can now collectively waste our time

it's not a dedicated meeting conversation. I would probably post it as a slack thread. If anyone wants to put their thoughts in, go ahead. If you don't, fine.

Number of people in the team who don't post by the end of the day ==> number of people who don't care.

Number of people in the team who do post by the end of the day ==> number of people who do care.

if number of people who do care > number of people who don't care, read the comments on the train home and have a think about what to do about it.

> During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.

Well... that sounds like a good way to burn a reference.

edit —

> waste my time on such trivialities

in your own individual personal opinion this thing is trivial.

being part of a team means being part of a larger whole. whatever that looks like — including if other people on the team don’t share your opinion, or have similar but different opinions.

funnily enough the article explicitly mentions differing opinions being a good thing.

Re: In the trenches: on being an Engineering Manager

#46
post #43

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

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

Re: In the trenches: on being an Engineering Manager

#47
post #41

Earlier quoted context omitted.

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? A…

Usually these things are obvious, no? (If not then it's going to be very challenging to be a [people] manager.) Depending on location and/or cultural composition of the team these things will be either no-issue (no one cares enough to voice either approval or opposition, if some change is requested by management or some platform introduces some changes it's just inconsequential for the team) or there will be someone…

I find your comment interesting. You start by saying, well, this should be obvious, right? Then you list five cases where, to me, things are not obvious. Like, i have so many hypothetical questions about each case. I won't bore you with them, but the change being pushed by management one i find particularly interesting.

Usually these are things we don't want to do, or shouldn't do (else we'd probably have done it already or have a plan for it at least). But folks in "management" or "executive teams" usually don't listen to engineering arguments about complexity spirit demons :(

so there are a lot of political questions i'd be asking in my head with that. e.g. Can we use this as a negotiation tool to stop "management" pushing for this-other-thing-we-also-don't-want-to-do?

Re: In the trenches: on being an Engineering Manager

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

Re: In the trenches: on being an Engineering Manager

#49
post #34

Earlier quoted context omitted.

Oh my god, if my manager asked me to waste my time on such trivialities - or even worse, calling team meetings to “discuss” them so that we can now collectively waste our time, I would quit the next moment. During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.

> calling team meetings to “discuss” them so that we can now collectively waste our time it's not a dedicated meeting conversation. I would probably post it as a slack thread. If anyone wants to put their thoughts in, go ahead. If you don't, fine. Number of people in the team who don't post by the end of the day ==> number of people who don't care. Number of people in the team who do post by the end of the day ==> nu…

Your job as a manager is to cut noise down for your team, so that they can focus on the signal. If you cannot decide on your own that some things are just plain silly and not worth their time to democratize the decision, then you’re not cut out for this job - sorry.

Re: In the trenches: on being an Engineering Manager

#50
post #11
post #8

Earlier quoted context omitted.

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…

The hypothetical question as I understand it isn't about which skills, but rather which activity yields the greatest expected value.
Post reply on HN