Ask HN: How to have impact as engineering manager to a senior engineering team?

Pretty simple:

* Find the problems

* Help with them

The problems on your new team are not the problems on the old team (code review, incident management). But I guarantee there are problems and ways to make it work better. So observe and ask to find the problems, confirm they are issues, and then start working on them.

Here's a non-complete list of possible problems for your new team:

* Too many things to build, hard to prioritize

* Not getting enough customer feedback

* Not getting the right customer feedback

* Unable or unaware of other company resources to improve their work

* Too few people to build what needs to be built

* Not staying consistent in technology

* Not exploring new technology enough

* Whipsawed by senior management with new goals every week

* Career growth stymied because they are stuck on a successful project

* Personality clashes

* Everyone does everything

* Everyone is siloed

Identifying the particular issues for this team and helping resolve them is what I'd focus on if I were in your shoes.

You ended up…..are you content in a leadership role or were you thrust into one? Are you happier in an individual contributor role? The engineers are paid to engineer and should have all the context. If you want to be the best manager let them be and ask them hat you can do for them. If it’s getting pizza or setting up offsite team meetings then go for it! I always pause when I hear a manager or director express the desire to code. This is a red flag for that position. Not as much as you have been promoted past your competence, rather you are so good as an individual contributor you were bumped up to manager due to your engineering prowess and desire for more power/money/status. Unfortunately the engineering must be de-prioritized as a manager or director. Your intentions to establish trust are good as are letting those who should own do the owning. Let the team of engineers worry about the skeletons and jumping in to propose changes. If your role is to manage AND also do all those other things I believe you were sold a rotten bill of goods. Your mission should be your team. Nothing more or less. I’d clarify the role with your immediate supervisor. Now having said that, its always a good idea to have a previous engineer manage other engineers to call bullshit and to be able to build morale. I look at us as the grunts like in the Marine Corps. Those who come from the enlisted to become officers have infinite respect compared to the newly minted officers. Anyway it should be fun, unless it isn’t which means the day job sucks. Good luck.

I signed up for it, and I'm not expected to code anymore (I only do so in my free time nowadays - which actually made it even more fun!). But my company expects the engineering managers to be basically at the same level as senior/staff engineers when it comes to experience & knowledge. Part of my work is coaching people, which now I cannot really do in many ways.

But I'm on a good end anyways, since I have a team of people that I know I can trust with things. So I'm here mostly to find out what would be the best way for me to approach this. Thanks for all the advice!

You can always ask the team. Either in a 1-1 or a retro, "What does my role look like for you?" or "What are your expectations of a manager?"

I’ve been through this a few times over the last many years. In one case, joining a team with 3–4 people who have been with a product for 10+ years. And the product was much, much older than that.

I would treat it the same as onboarding to a new job, which is essentially what you’ve done.

One question I would have is, Is being “the best” developer on the team the most impactful way that you can contribute? If you could snap your fingers, and have all the minutiae transplanted into your head today, by magic, what would that get you? My guess: not that much.

I know nothing of your situation, but it sounds a bit like you understand the absolute importance of being trusted and empowering people, but are perhaps uncomfortable with the complement—you have to trust your team, and be empowered by them as well.

Simple, technical things that you can probably contribute to right away, while learning the product and codebase are usually build, deployment, and testing. You could lump doc in there too. All are extremely important, all will save everyone on the team hours per week (or even per day!) and all are usually areas where there’s rot and neglect and you can have a big positive impact, without blocking real work or needing all the context for larger features or nasty heisenbugs.

You can/should absolutely still do code reviews. I don’t know how organizations you’ve been a part of work, but I would expect a new grad developer to start doing code reviews on basically their first day in the industry, even if it’s not super valuable immediately, or authoritative; this is no different.

Focusing on outcomes and asking questions, “how can we improve X by Y% in Z days?” is as valuable than being able to offer a solution for the same. If they know what they’re doing, let them!

As a general heuristic, if you have a team that is a lot better than you at something, you should find ways for them to be doing more of that, rather than trying to meet or exceed them in every area. Assign yourself the tasks that they are bad at, the impact on the team and org is going to be a lot easier and quicker, and people mostly like to not have to do stuff that they’re bad at. It’s win-win-win-win.

There’s a lot of nuance IRL, I’m happy to chat if you want to catch up and talk over a few ideas. The good news is that earnestly trying to do a good job is like 80% of the job, so it sounds like you’re on a decent path.

Consider focusing on managing the team through this: "there are a lot of skeletons in the code & infra to worry about." Sometimes what happens is you have seniors who know the technology and product inside and out, but don't think in terms of team dynamics and the organization's ability to deliver effectively.

Your job is now to manage, not engineer. Learn leadership, or if you want to keep coding, change jobs.

Very blunt, I appreciate that. Though, engineering leadership is certainly different than other types of leadership. Managing through example was my current way of working. I'd be collaborating with engineers, and try to coach them when I could, or sponsor them when I couldn't (provide with either internal or external coaching).

I didn't mention that I'm coding in my initial post, and the reality is that I currently don't code at my job. So while I appreciate your answer, it doesn't really apply to my case, or my question.