2

Getting Pulled into Projects I Do Not Want

Profile picture
Entry-Level Software Engineer at Taro Community24 days ago

In my team, we own a lot of legacy services. It seems like many of our engineers intentionally avoid these legacy services because they have less impact, and I keep getting pulled into these projects. Even worse, the work is mostly SQL or data engineering, and as a SWE, I'm afraid this will impact my career.

How do I get other people into these legacy service project? My manager is making me the only responsible person for this project on a rearchitecture of a legacy system by reducing head count commitment on the project, and I do not want to be the only person responsible for the project for few reasons. I want to stop doing deep dive on legacy systems which has no impact and has high risk. The legacy system just has so much scope that this deep dive is recurring every week that takes up about a day. In addition, I also do not want to be the sole responsible SDE for a project of such a large scope. Because the timeline of the project is long, the headcount may be justifiable, but I do not want to get isolated in a case when something goes wrong, there will be no one to vouch for me.

Ideally, I think we would all share the work as a team somehow, but our team has been very separate with a different products, so I am not sure what the best way to approach this would be.

40
2

Discussion

(2 comments)
  • 1
    Profile picture
    Engineer @ Robinhood
    20 days ago

    Maybe the service is unable to effectively be shared across teams because it's in a legacy state? Sinking in more time might not be the most effective short-term use of time, but refactoring it so that it's much easier to work with later could help out. And it seems like this legacy system isn't low impact: high risk and low impact are descibing opposite things to me (high risk = high impact).

  • 1
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    19 days ago

    It's unfortunately not really an option to say "I don't want to do this." Instead, you need to share a viable alternative:

    • You have an idea for a higher-priority project that you are uniquely equipped to tackle.
    • You think a shared ownership model would be better for this project. You could argue that it's better for knowledge sharing and team resiliency.

    If you can't avoid it completely, remember that you can allocate time for another project as well. Something that is more greenfield, doesn't need a bunch of permissions, and doesn't have the legacy issues.