Taro Logo
4

How do I grow my career on a team that owns too many critical, legacy services?

Profile picture
Mid-Level Software Engineer [SDE 2] at Amazona year ago

My team is quite small but we own a handful of critical services. Because of the small size, our on-call rotation is around 6 weeks or less but the actual load is somewhat manageable. We do not get an intolerable amount of high severity pages but get a lot of low severity tickets. We constantly work on projects that support goals for other teams that always seem to be higher priority while our tech debt grows. We have identified longer term fixes for some of recurring issues but never have the time to implement them. Most of our planned work for the upcoming year involve modernizing infrastructure or migrating existing services. I'm concerned about whether staying on this team would be conducive to my career growth.

121
2

Discussion

(2 comments)
  • 8
    Profile picture
    Staff SWE at Google, ex-Meta, ex-Amazon
    a year ago

    You can make great strides toward Sr SDE in this situation, but you have to actually own the solutions to these problems. I don’t want to be too direct, but things like “we never have time” sounds like resignation, not a challenge to be overcome.

    Stop having on-call handle low-pri tickets. They take pages. That’s enough. If it’s low priority, it should be treated as such and can be triaged into an appropriate future period of work.

    Get watir rules (thinks that is what it’s called) for triaging incoming tickets before they even get to you, avoiding many and having greater clarity when they do arrive.

    Automate common bug type resolution. Identify the top 1-2 root causes of bugs every quarter and fix them, or at least dedicate time to moving that direction. Allocate time. You don’t have time to do new work if you’re not keeping your system and team healthy.

    Being a workhorse for dependent teams is rough. You need ingestion processes, self-service feature request process, allocate a certain amount of time per quarter or half to these projects, and do ranking WITH all the stakeholders in the room. If you can’t sort it out, then it needs to be escalated. You can’t manufacture more time, it is limited, and you’re taking on more than the team can do.

    This team is in bad shape. Take it to a team in good shape with qualitative survey results from engineers that show improvement, and quantitative measures of incoming tickets, SLA, on-time feature delivery (because you maintain focus) and so on. That is promotable.

    you’re going to have to do most of this to get there anyway. Other teams may not be as bad off, so you may have to find the opportunities yourself. They are plainly visible on this team.

  • 4
    Profile picture
    Meta, Pinterest, Kosei
    a year ago

    I love the answer from Lee.

    One question to ask is, does everyone agree with your assessment that the support burden on this team is too high? You mentioned that the team "never have the time to implement" the long-term fixes - why is it never prioritized?

    Can you document the challenges, and get folks to agree (especially managers + directors) that addressing the challenge would be high-impact?

    If you have the social capital to re-energize the team around this and fix the root causes, that would be promo worthy. If you feel like you can't do it, or there's not broad support for the effort, it may be worth switching teams.