Taro Logo

How do I balance addressing fires and working on p0's?

Profile picture
Mid-Level Software Engineer [E4] at Meta2 years ago

The product I support breaks often and I've been the go to individual to resolve internal fires. Addressing them takes time away from tackling more impactful tasks, and it's beginning to affect my output. My team doesn't find such infra issues as priorities so fixing them gets little visibility and I'm concerned this will have a negative impact on my PSC. How do I balance this properly?



(1 comment)
  • 1
    Profile picture
    Robinhood, Meta, Course Hero, PayPal
    2 years ago

    Heh, this is such a Meta issue. I literally faced the exact same situation back when I was an E4 at Meta. Here's my advice on dealing with it:

    1. Talk to your manager - In particular, figure out how much credit you are getting for fixing these problems for your PSC. It should count towards "Engineering Excellence", but the question is if the value is greater than what you would achieve just ignoring problems and going all in on your roadmap work. In general, managers should be protective of your time and aware of how you're spending it - The current situation will break your focus and overwhelm you. That's not good for an E4 as E4s generally need more stability to find their path to E5.
    2. Spread the responsibility among the team - You referred to these problems as "fires". This means that somebody has to fix them. It's not fair for you to take on the entire burden - It should be distributed among the team. The oncall process is responsible for this; here's my advice on how you can make your team's oncall better. And of course, if your product is constantly breaking, the team should come together to fix it - Group all the root causes for fires together and go through the most common ones one by one.
    3. Weave firefighting into your identity and maximize credit - This one is optional and depends more on what you prefer to do. I have seen many engineers grow to E5 and E6 doing this, and this is something I did myself. "Fixer" is a formal Staff Engineer archetype at Meta, and you can get a lot of value if you double-down on firefighting behavior and fixing bugs in general and build your reputation around it. Tactically what this mean is asking your manager to be less involved in roadmap work, so you spend more time owning the integrity of the system. Revamp the oncall process, and create a "Stability Workstream" where you go through all relevant bugs/fires (past and present), put them into a giant spreadsheet, organize them by priority, and create a roadmap to systematically get rid of them.

    On a side note, a classic Meta trick to get more credit (and this applies to many companies in general) is to take a bunch of small to medium sized things, group them into under one umbrella, and create a formal "workstream" out of it that you then write a lot of Workplace posts about. It shows that you're a leader and helps a lot with E5 promo. The failure mode is just receiving tasks ad-hoc here and there, constantly suffering a productivity penalty. When you don't paint the bigger picture around everything, you won't get nearly as much credit.

Meta Platforms, Inc. is an American multinational technology conglomerate based in Menlo Park, California. The company owns 3 of top 4 social networks in the world: Facebook, Instagram, and WhatsApp. More than 3.5 billion people use at least one of the company's core products every month.
Meta232 questions