from Hacker News

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

by bartaxyz on 7/27/23, 10:38 AM with 8 comments

Hello HN,

My company recently did a re-org, and shuffled people around. The project I've been working on (as EM) was paused, and I was put into the core company product. Half of my team stayed the same people, but the other half are the existing engineers who worked on the core product for a long time, and they're also very senior engineers.

I'm always tried to be a hands-on manager. One that could usually jump in, and do code reviews when necessary, or deal with incidents, the same way a senior engineer would. But also establishing trust, and letting people to take ownership over various parts they were interested in. This is sadly not possible in my current situation, though. I lack a lot of the context, and there are a lot of skeletons in the code & infra to worry about (making it more difficult to jump in, and propose changes).

The bottom line is that the engineers around me have way more context than I do. Not just about the engineering side, but also the product in general, and ways of working (there are multiple teams working on the core product). Which is fine with me for the onboarding period. I'm learning new things every day, and slowly progressing. But I'm left wondering how can I have a positive impact on the team, especially in this transition period.

Would anyone here have any advice? Something that worked (or didn't work) for you either as an engineering manager, or even as a senior engineer with a manager who lacked the technical understanding of what you were building, but still was a great manager to you.

TLDR: Company did a re-org, and I ended up in a team of senior engineers while having very little context of the infra & product. What's the best way to have a positive impact on the team in the short & the long term?

  • by mooreds on 7/28/23, 12:40 PM

    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.

  • by diavelguru on 7/28/23, 5:06 AM

    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.

  • by stocktech on 7/27/23, 3:40 PM

    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?"

  • by Ezra on 7/28/23, 3:17 AM

    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.

  • by bwh2 on 7/27/23, 5:58 PM

    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.

  • by nprateem on 7/29/23, 7:38 AM

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