Live data from Hacker News

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

jampa.dev

31–40 of 148 posts

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

#31

I wholeheartedly agree with point 7 Your goal is for your team to thrive without you. I spent a lot of time also playing a Scrum Master role in addition to my regular duties. So much so that some managers asked me to pursue this full time. I always explained that my goal is to be there just as a point of contact and that the team should be able to manage itself. Sadly, I see so many managers, scrum masters, or even r…

Agreed, I was fortunate enough to learn this lesson early in my management career when I was passed over for a promotion I felt I deserved for someone who's team was able to operate without them. Looking back, I know this is why he got the role rather than me, my team couldn't live without me whereas his could and therefore he could take on the expanded role.

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

#32

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…

“Don’t be needed” isn’t “don’t be valuable.” The EM should not be a bottleneck. The EM should be able to take a vacation without being paged. (So should anybody on the team!)

My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.

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

#33
> "Most engineers prefer feeling appreciated over having a ping-pong table."

Truer words have never been spoken. Note the OP put the word "Most" in there. Sure... there are a few ping-pong fanatics, but not as many as there are humans who like an emotionally fulfilling work environment.

A related sentence I've uttered is "Most engineers prefer more control over their daily tasks than cash bonuses." But again, the word "Most" is doing a lot of heavy lifting here. My experience is no more than 25% of devs will trade cash for micro-management. YMMV.

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

#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 experiences, same as I would talk to and listen to any other person, but the word "coaching" implies one party is superior to the other in one very concrete area.

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

#36
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 not an EM (anymore) but I see a lot of more junior engineers struggle with ambiguity and complex decision making in general.

It is not uncommon to end up in situations where there are not clear right answers and developing the techniques as an individual, and as a technical contributor to navigate these well is tricky.

I don't think this is an EM specific function at all though and is just something more experienced people should be doing for their team. I think the EM definitely has a role in making sure people identify that they could benefit from that kind of help and make sure they find it, but doing the actual coaching is optional.

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

#37
post #25

>I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. I think there's another key here - Don't assume someone else knows something. If you don't know why something is done some way, find out who does and make sure they do. I've been in so many situations where the organization gets complex - person A is loaned over here or person B is working on project X because team Y needed feature…

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 complicated by the fact that Marines deploy as MEUs, MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule of thumb and guiding principle more than a hard and fast requirement.

I've ALWAYS been annoyed by engineering organizations that don't think developers at the leaf nodes of the org chart need to know what's going on. Devs may not do anything with the info, but letting people in on what's happening seems to send the message that "management thinks you're important enough to hear what we're working on" and every now and again, individual devs need to make decisions that depend on these more abstract / higher-level goals.

1. https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...

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

#38
post #8
post #4

Damn, this person looks like a good manager. These are all things I have seen in my good managers over the years when I had them.

Yes, he has a lot of accumulated experience!

If only all experienced managers could have developed the same amount of understanding.

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

#40
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…

Coaching doesn't imply superiority. Most coaching can be done with little to no context and the goal is to guide the other person in finding the right answer on their own. I think you might be confusing coaching with mentoring.

As an example, I attended a coaching training session and when we broke out in groups I played the coach role. The other individual brought up a concrete issue they were having and I was able to unblock them and I never met that person before. I was their guide even though I had no context (but I have experience mentoring and coaching).

I've been a manager for years and there's a lot outside of raw technical ability that a good coach and mentor can keep you honest on. Rarely will you find someone who's reached full potential or who doesn't want to improve at all (maybe surprisingly based on your comment but I have found seniors to be the most eager to grow)

Post reply on HN