Live data from Hacker News

Things I've learned in my 10 years as an engineering manager

jampa.dev

61–70 of 148 posts

Re: Things I've learned in my 10 years as an engineering manager

#61
post #34

This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college? What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team? I understand we can talk and exchange our concrete life experienc…

I am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on: - influencing without authority. Managing up. Leadership. - getting work prioritized - providing useful performance feedback (promos etc) - coaching and g…

I'm sorry, but if a senior engineer needs coaching on getting work prioritized, they are not a senior engineer.

Re: Things I've learned in my 10 years as an engineering manager

#62
post #34

This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college? What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team? I understand we can talk and exchange our concrete life experienc…

Not an EM, but definitely think a strong technical EM can provide valuable feedback when it comes to system design and data modelling.

Re: Things I've learned in my 10 years as an engineering manager

#63

> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I'm absolutely going to steal this metaphor going forward. Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people,…

> They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I was going to highlight this as well, but it is also one of the trickiest parts of the equation, because by definition this inevitably involves a lot of politics and social implications. What I have learned over the years: let the overall direction, and also the overall competitive pressures, filter down through your umbr…

I agree with that. It's useful for (most) people to understand the overall environment the company is operating in. Probably less every top-down decision the company is making.

Re: Things I've learned in my 10 years as an engineering manager

#64

Enough already. The way to determine what kind of manager a person is, is to listen for the context they use. For an extreme hypothetical example, if you hear a manager talk about locking their team in their cells every night, you will know something about their context. If the manager says "They look to you for leadership and clarity", you know something. It they quote Jeff Bezo, that provides more definition. The l…

> How does this person talk about other people?

I find myself referring to my contractors as: Workers.

What does that mean about me?

I can't call them employees. I read the communist stuff a while ago and decided I didn't want to be exploited, so I thought this was just the proper terminology.

But people on the internet loath being called a worker and have called me out on this.

Meanwhile I yoyo between to nice and too hard... I think I'm naturally too nice to the point of failure. I seem to only be 'too hard' for a few months before I go back.

Thank god my industry is high demand, I think even with bad management we will survive. (I got a masters in Engineering Management + read 10 books, but management/supervision orthodoxy is diverse and contradictory.)

Re: Things I've learned in my 10 years as an engineering manager

#65

Earlier quoted context omitted.

I am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on: - influencing without authority. Managing up. Leadership. - getting work prioritized - providing useful performance feedback (promos etc) - coaching and g…

I'm sorry, but if a senior engineer needs coaching on getting work prioritized, they are not a senior engineer.

I interpret this comment as talking about prioritization across a broader org. A senior engineer should be able to prioritize inside of their team and adjacent teams. But there is a reason why there are levels of engineer beyond senior - beyond just increased technical judgement, there is increased influence in orgs spanning hundreds or even thousands of engineers.

There is always opportunity for growth in this dimension. For example even the CEO has to build the right skills to convince the board of their priorities.

Re: Things I've learned in my 10 years as an engineering manager

#66

> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I'm absolutely going to steal this metaphor going forward. Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people,…

That's true for a junior engineer, but the more senior engineers should be given a view into the organization's priorities and business challenges.

Re: Things I've learned in my 10 years as an engineering manager

#67
> Everyone needs to care about the Product

This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.

Re: Things I've learned in my 10 years as an engineering manager

#68

Why do people espouse goals like “not to be needed?” I never understood that. It sounds like LinkedIn virtue signaling. It’s a capitalist talking point along the lines of “I seek to be good and inexpensive capital for my corporate masters.” My goal is to help my team succeed in such a way as to keep my job or else get a better one. Being “not needed” hardly serves that goal. Look around you. We are in a world that is…

You’re taking it too literally, it’s not saying don’t be useful, it’s saying don’t make yourself a bottleneck. It’s a very common failure mode for new engineers turned manager, leading to a frustrated team that feels micro-managed and the perception from leadership that you don’t have your shit together and can’t adequately handle the scope you’ve been given.

Re: Things I've learned in my 10 years as an engineering manager

#69
>The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay.

>“Oh, but I have a PM for that,” you might say. But having a PM is not enough.

It should be, that's literally their job. Developers and EMs shouldn't be doing that part for them.

In the same way developers need to know how to ifs and loops, Product Managers need to find out which features to build and user pains to fix.

Maybe, just maybe, we need to stop raising the bar for interviewing developers and start raising the bar for the other people working with developers, instead of getting developers to compensate for shortfalls.

Re: Things I've learned in my 10 years as an engineering manager

#70

Earlier quoted context omitted.

When I was in the Marines, we had a rule of thumb that every Marine needed to know their own mission and the mission of units two or three echelons above them. So individual Marines needed to know their mission, their platoon's mission and their company's mission. Company commanders needed to know their mission, their battalion's mission and the division's mission. More specifics for echelons closer to you. This is c…

My dad is a retired Marine and I learned several things from the NCO system and Marines in general: good leaders (EM/Sergeant) will generally never ask you something they cannot also do (implies they are your peer, even if they are not), and Marine Corps manuals are able to take anyone who can read and make them operate technical things. Their manuals are written in a very direct stepwise way to get people up to spee…

This. Every time I've lead people, IF they were already or were able to become high agency, we were efficient and capable. Control freak managers were usually guilty of what they obsessed over before they became managers. Good workers always leave bad managers in time, which always hurts the company.

Post reply on HN