How do you convey impact for non-product, technical efforts like adding tests and fixing crashes?

Here are a few ideas for how to think about the impact of technical projects:

1. Consider how well they align to the overall goals of your team and the business. Are customers complaining or churning because of reliability issues? Is performance a big differentiator for your product? This is likely to influence how much your management team cares about this type of work.
2. As you mentioned, sometimes the customer of your work is other engineers at the company. It never hurts to get feedback from your customers. If your work moved the needle in a big way for a few people, it should be easy to get feedback to back that up. If your work made a small difference for lots of people, it might be easier to measure.
3. Lastly, it's just true that the impact of tech debt projects is often hard to quantify. That's why it helps to have an eng leadership team that understands software development and has good judgement when it comes to technical impact. You can't run a team on numbers alone!

• I definitely agree that we should focus on business impact when trying to evaluate any type of work. Another important factor is complexity. And ideally both of these factors should be covered in a package for Performance reviews to justify engineer's work.

• Coming back to your question, impact for BE could be measured in terms of its influence on business. And usually there are internal and external facing BE project impact:

  • Internal: Saving engineering time by simplifying commonly executed tasks (like adding new functionality faster as you mentioned).
    • This impact is usually measured in X amount of saved engineering hours per day/week/month. And this should be not a very precise answer - just a rough estimate in regards to the average time it took to add such functionality before/after the corresponding BE project.
  • External: Increasing product's reliability/decreasing latencies and e t c via more robust integration tests, bug fixes or refactoring.
    • This impact is usually measured in its influence on the end users. E.g. eliminated Y% of crashes or decreased cold start time by Z%.

• I also want to mention that sometimes companies even put a special emphasis on BE projects. E.g. Facebook has a special axis for their calibrations called Engineering Excellence. So they expect each engineer to regularly spend their efforts dedicated to the projects in this area.

• For technical issues that actually affect the user experience (crashes, ANRs, etc), you can wrap them in an experiment to measure the impact. You can bundle similar fixes together to make deltas clearer and/or use a long-term holdout group to observe user impact long-term.
• Unfortunately, a lot of the more purely technical efforts (e.g. refactoring code), you need subjective feedback, especially initially. Ask relevant peers whether the effort improved their engineering quality of life and you can inline that feedback in your performance review packet.
• You can generate "metrics" for qualitative feedback by running surveys, which is what we did back at Meta. Every half, we would run a survey asking engineers to rate various engineering pillars from good to bad (pillar examples: Oncall system, code velocity, debuggability) and we used this to track engineering system improvements over time. If you were running one of these Better Engineering efforts, your goal was to generate an increased survey score for the pillar connected to your project over time.

Recommended additional resources:

• Solving A Multi-Million $$ Instagram Bug
• Building An Internal Tool At Meta With 100s Of Users: Additional Equity + Promotion
• Effective Communication: Leading A Multi-Org Re-architecture At Meta