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

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

jampa.dev

Post reply on HN
Print view View original

111–120 of 148 posts

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

#111

Post by parthdesai »

ecshafer wrote: post #101
parthdesai wrote: post #61

Earlier quoted context omitted.

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

I worked with someone who had 30 years of experience, and would routinely go down rabbit holes of minimal value that they thought were valuable. Days spending on local environment setup and configuration scripts, for multiple platforms, when it only took a few commands to start everything up in a few seconds. Or making custom patterns to "improve maintainability" of the code base, that were brittle, overly abstract,…

Well in my opinion, they really aren't a senior engineer then. 30 years of experience doesn't automatically mean you're a senior engineer IMO.

To me, you can trust a senior engineer to get the project done properly without any oversight

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

#112

Post by mattbrewsbytes »

satisfice wrote: post #10

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…

Its more about being a servant leader and not a bottleneck than literally being "not needed". Its a mindset of wanting your team to be able to operate without having to check with you (the EM) on every little thing. I've also heard it called having IC's be a "manager of one" where they can independently work on things, get work finished, etc. without needing constant nagging.

A good manager I had once had the approach of setting guidelines and "just getting out of the way" and I try to follow that, it works well for most people.

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

#113

Post by dakiol »

As an IC that's been in the industry for over a decade, I don't see myself jumping into the management track. I just can't. I see my calendar and I see few meetings, and typically I have the power to move some of them (because some of them are arranged by me). I see my manager's calendar and it's constantly packed with meetings he probably cannot move. Worse than that, I see for instance he has one meeting at 10, then another at 12, then another at 3 and then another at 5. Like, you cannot escape that hell. I start my work at 10, work solid 4-5 hours or so and then close the laptop. I cannot sacrifice that kind of freedom

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

#114

Post by throwaway8177 »

This is a great list!

The biggest lesson for me was that your job as a manager is to be the soft power representing the authority of the investors. Everything else you hear about management is people rationalizing their role and figuring out how to tow the line. That's why it's so hard and stressful.

The hardest lesson comes when you're ordered to fire someone from your team. HR has decided to implement a performance rubric and wants to maintain the company's position in the hiring market place as a competitive place to work. You must fire the poorest performing member of your team. Who do you pick?

That's the essence of management. Who do you reward, who do you punish, how do you show that you're towing the line?

Most folks, myself included, are promoted into an EM role. No training. No certifications. If you're lucky you get a few training videos from HR if the company you work for is big enough to have an HR department. As an EM you are now in charge of the careers of the people who work under you.

This is why you get such a high variation in the quality of EMs. Some people are a nightmare to work with. If they get a bad impression of you there's nothing you can do. You're cooked when it comes time for that manager to let someone go. There are no objective metrics. They have to pick someone and they will find the reasons.

I left management because I couldn't handle it. Too stressful.

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

#115

Post by BerislavLopac »

gramie wrote: post #79
crjohns648 wrote: post #48

> 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,…

I recall hearing that Google had a term similar to this: A "shit umbrella" was a manager who protected the development team from all the politics, blame, and mismanagement coming from above. A "shit funnel" was a manager who directed all the shit coming down, directly onto the team.

Yeah, I've been using "shit umbrella" for a long time. But the "transparent shit umbrella" is an even more powerful, albeit more disturbing, metaphor.

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

#116

Post by dilyevsky »

_tlo4 wrote: post #75
djb_hackernews wrote: post #42

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…

> Influencing without authority > Getting work prioritized > Developing 1YP+ plans for their areas I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing…

In a large company there aren’t enough teams to lead for everyone who wants to get more money (promoted) so management invents these meaningless (for a regular senior) hoops to jump so they can track kpis and can’t be accused of favoritism. Something like that =)

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

#117

Post by madeofpalk »

gambutin wrote: post #54
crjohns648 wrote: post #48

> 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,…

Honestly, I’m not sure. If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.

You're right, probably not everything! It's a managers job to understand what you don't need to know or worry about. But I find it very useful to understand why something is happening, or what else is happening out there that might have an impact on us and we should worry about.

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

#118

Post by madeofpalk »

_tlo4 wrote: post #75
djb_hackernews wrote: post #42

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…

> Influencing without authority > Getting work prioritized > Developing 1YP+ plans for their areas I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing…

Architecture, choosing languages and frameworks, the code review process are all aspects where "influence without authority" comes into play. What if you want to introduce a new lint rule or CI process that might impact other teams?

Having technical influence across other teams of peers is exceptionally important for senior developers.

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

#119

Post by willio58 »

dakiol wrote: post #113

As an IC that's been in the industry for over a decade, I don't see myself jumping into the management track. I just can't. I see my calendar and I see few meetings, and typically I have the power to move some of them (because some of them are arranged by me). I see my manager's calendar and it's constantly packed with meetings he probably cannot move. Worse than that, I see for instance he has one meeting at 10, the…

As someone who did get on the management track a couple of years ago myself, I think it’s great you have that perspective. I miss being able to turn on some tunes, code for a few hours, and call it good for the day. At the same time, I have always naturally fell into leadership positions I think mainly because I like helping people make better decisions. As an IC, I despised broken processes, bad decisions from product, and overall poor management. As an engineering manager, I have some amount of control over these things and I hope those I manage, as well as our users, have benefited from me being in this role.

A few examples of things I heavily influenced:

- reduction in investment of time, effort, and cost going to offshore engineering. We’ve reduced bugs and effort from our engineers in coordinating between disparate time zones.

- advocacy of a design system shared between design and dev teams. We now have one.

- reduction in the amount of meetings our devs are expected to attend weekly, increasing time they can spend building

- heavily advocating to reduce number of clicks for our users to get where they need to be, benefit UX greatly

- better defined incident management process

It’s not perfect though, the amount of control I have is still limited, and I am in meetings basically all day sometimes.

While I will say that would have sounded like hell to me a couple of years ago as an IC, I have been able to sway the direction of the company meaningfully in ways that feel ultimately more impactful than what I could have done jamming on some code in the same amount of time. The cost of doing so is a little more stress, but hey I get to do so from the comfort of my home and I’m allowed a good amount of schedule flexibility outside of some specific meetings each day. It’s definitely not for everyone though!

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

#120

Post by kaydub »

dakiol wrote: post #113

As an IC that's been in the industry for over a decade, I don't see myself jumping into the management track. I just can't. I see my calendar and I see few meetings, and typically I have the power to move some of them (because some of them are arranged by me). I see my manager's calendar and it's constantly packed with meetings he probably cannot move. Worse than that, I see for instance he has one meeting at 10, the…

And most the meetings end up with the same people in them where we're just repeating the same shit to an additional 1-2 people per each meeting
Post reply on HN