How to describe the problem, action, and impact for performance reviews?

What would have happened if you didn’t exist? You weren’t there at all. The team needed a loaner because they lacked capacity. If you didn’t bail them out, what would the impact be to the timeline of the migration, or if they prioritized it over other work, realistically how many engineers for how long would be pulled from other tasks? What would happen to the things that were deprioritized?

yes, this will be speculation and estimates, but the numbers likely exist because the team said “we can start work on extractions in Q2 2023” and someone said “what if we loaned you an engineer and they only needed support” and they agreed.

If you only did what was committed, and didn’t take on the rework of the API, how would it have impacted the migration? Could you have done the extractions but it would have taken longer, performed worse, generated tech debt? How much would that have cost to fix?

The deadline slipping doesn’t sound like it was because you made poor decisions. Your input still led to shipping, and I imagine without you the slip would be worse. Quantify it. Ideally quantify how you impacted the remote team’s design and vetting process, too, since a substandard API was delivered.

@Lee Thanks, that makes me feel a lot better! I should have clarified that I know the overall impact of this endpoint extraction, i.e:

• 1/ it contributes X traffic to the monolith
• 2/ the monolith costs us $Y/month to operate
• 3/ there’s an Engineering-wide OKR to migrate off the monolith by Z date
• 4/ loaning me to this team allows them to meet the Engineering-wide OKR
• 5/ reworking the API allowed the shadow reads to pass, which gave us confidence that there’s parity between the monolith and BFF endpoints
• 6/ no incidents occurred due to our careful extraction

However, if this endpoint extraction has, for example, n different problems and I took m actions to mitigate them, should I describe the impact of each individual action? Or should I write a giant paragraph describing all the problems, then another paragraph describing all the actions I took to mitigate them, then end with a paragraph describing the overall impact of this endpoint extraction? Sounds like the impact of reworking the API was to make the shadow reads pass, giving us confidence that things will work properly on the clients and ensuring an incident-free rollout?

How to describe the problem, action, and impact for performance reviews?

In your scenario, it looks like you should really focus on what the shortcomings were of the API you cleaned up.

• Did the API not scale with volume of users?
• Did it have serious security vulnerabilities?
• Was the API slow (i.e. takes 5+ seconds to return a response)?

I feel like my actions had “no impact” because we slipped our deadlines regardless.

There's more to impact than hitting deadlines. It seems like you had 2 forms of impact:

• You prevented the deadline from slipping more - When I hear "serious shortcomings" in a big company like DoorDash, I immediately think "If left untreated, this will cause a SEV". SEVs are so high-stakes when you operate at the scale of a company like DoorDash, and when they blow up, they always cost a ton of engineering time. This means that addressing issues more proactively generally saves time.
• You upheld your team's reputation - Since you're working more on the infra side, the perception of your team and its engineering quality is very important. By protecting the sanctity of your system, you are helping ensure that your team has an easier time getting others to use its services in the future.

Or should I write a giant paragraph describing all the problems, then another paragraph describing all the actions I took to mitigate them, then end with a paragraph describing the overall impact of this endpoint extraction?

This format will vary based on company, but in a vacuum, I just want to say that you generally should avoid big paragraphs and convert to bullet points instead (this is what I did for my performance review at Meta). Giant paragraphs are no fun to read.

At the end of the day though, I wouldn't worry too much about formatting as I'm sure that in a company like DoorDash, there are followed standards for performance review writing. Create your self-review draft early and share it with your manager. Ask them if the format you chose sucks. From there, iterate. I recommend watching our video about optimizing the self-review as well.

Regarding format, that may be more company-specific but if I were reading it, I’d want it laid out in: Section header, Monolith Deprecation Summary paragraph detailing the big picture Numbered list of each contribution, API issue corrected, each time-saving action. Each of these will have problem/action/impact for that one thing. Closing summary of the overall result/sum of impact.

This may not be best, but I would prefer context and be able to see detail as well as big picture impact for this project.

In my opinion, this becomes an exercise in communication. As you were working on the migration, did you have some sort of regular cadence of updates about the project which captured the delay, your extra efforts, and the eventual result?

That would be ideal because you now have permalinks to the story, and how your efforts, collaboration, and hard work prevented a much longer delay.