Live data from Hacker News

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

jampa.dev

41–50 of 148 posts

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

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

Most of the job is noticing friction and clearing paths — which requires context and trust more than technical superiority.

In practice: Start a note for each engineer you manage. Fred Brooks called this a "career file". Start by writing down things that frustrate them enough to complain about publicly. Add hurdles that come up in their one-on-one. Identify problems you can solve, problems you understand but cannot solve right now and problems you do not understand.

Then put on your PM hat; sort by priority and execute.

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

#42
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 giving feedback to early career engineers

- communicating ideas effectively

- developing 1YP+ plans for their areas.

- idk, there are a lot, senior engineers are rarely "complete"

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

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

In my experience, I have used coaches that don’t have more technical skill than me, but are able to provide insight, questions, and provoke me to think through my problems in ways I might not have otherwise.

I break things down into coaching vs training vs mentorship.

Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.

Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.

Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.

These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.

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

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

I sympathize with keeping one's mouth shut for political reasons. Having a boss who angrily shouts at anyone who dared use their own brain and offer an idea, I learned to keep my mouth firmly shut even if i saw countless problems coming down the road.

It is one thing to do that while you have that boss, but something completely different to keep acting that way even when you have a different boss. The more people you have on a team who keep their mouths shut, the less effective it will be.

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

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

Dude, soft skills. 80% of any job, software development especially, is messy human problems. Engineers more than anyone can generally benefit from improving these skills.

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

#46
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 think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail.

I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.

Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.

I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.

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

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

Top tier sports people still have coaches. Some even have multiple coaches. Musicians have managers.

Unlike coaches for kids/ novices these folks aren’t necessarily better at the craft.

Yet, they (ideally )have a outside perspective that would improve an individual in their craft.

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

#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, however, really appreciate the transparency. It helps them feel more in control when they know what is happening around them, and when things do change they can tie it back to something that was said previously.

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

#49
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 in my role is mostly about seeing the person up for promotion and helping them focus on the right stuff for the teams success. Even great senior engineers sometimes lose focus or miss the sentence in s career ladder that doesn’t mesh with what they want to be doing.

I’ve got a senior IC who is always hesitant to reach out to non-engineers, so to coach him I’m constantly asking him to reach out directly. It will improve his impact if he does so.

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

#50

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…

The goal should be to have teams who want you to be supporting them, not need you to be supporting them. Getting teams to the point where they don't need you isn't actually that hard. They might be only performing at 50% effectiveness, but that's fine if the work is getting done. You should build a relationship with the teams so they want you to support them to get to 90% or even more.

If your teams fail to function without your help then you're clearly not supporting them well enough, and you can't take a vacation or go off sick or be promoted. That is not optimal for anyone.

Post reply on HN