Impact at scale in an engineering organization
There's a word that always comes up in career discussions and promotions at large engineering organizations: impact.
When you're earlier in your career, expected impact is often easy to define: you're given tasks to complete over a period of time. If you complete those tasks in a timely fashion and your work is good quality, you've made the expected impact.
But what about when you're more senior? I have found that delivering your work well often isn't considered enough "impact" to get to the next level.
So what are these organizations looking for? Impact at scale.
What is impact at scale? #
Impact at scale is when your work positively affects a lot of the organization. Normal product feature engineering typically doesn't reach this level of impact (although, as with everything, I'm sure there are some exceptions).
How to make impact at scale #
Impact at scale can be a bunch of different things. Two of the most common examples I have seen are as follows:
- Taking on a leadership role
- Championing and executing technical tasks that benefit the entire organization
Taking on a leadership role #
If you really enjoy product feature work, this might be for you. You become the technical lead of a feature (or portfolio of features). You can act a bit like an engineering manager in some sense by delegating tasks within your product area. You make technical tradeoffs, review design documents, and oversee the work of engineers on your feature(s). You are often a bridge between product/design and the engineering team because you both have a strong product and technical sense.
Championing tasks that benefit the entire organization #
Tasks that benefit the entire organization range from quality initiatives to developer experience and productivity. Perhaps you notice that your team's test suite is ineffective and champion an improved testing process. Maybe you implement end-to-end testing or set up code coverage checks and establish a process to gradually increase coverage. Or maybe you notice that your application's local build time is really slow and you decide to do a lot of work to optimize it.
Some ideas if you're looking to make an organization-wide impact:
- Do too many bugs make it to production? What technologies or processes can you implement to fix this?
- What are developers complaining about most? Long local build times? Complex onboarding/setup instructions? Difficulty replicating production scenarios? Fix these things!
- Is your system reliable and performant? Is the organization even measuring this?
- Is your application secure? Do you have automated tooling to make sure it continues to be secure?
- How hard is it for your developers to fix production bugs? Do you have sufficient telemetry?
Measuring impact #
If you're chasing your next promotion, do not forget to measure your impact! You can measure your impact a lot of different ways:
- Find out how many users signed up for your product because of your feature suite
- Compute the total developer time saved due to your faster build process
- Capture the number of bugs caught and fixed prior to reaching production thanks to your end-to-end test suite
Whatever your impact is, it can be measured. One mistake a lot of people make is not measuring the problems they are solving before they make changes. Make sure you're capturing the as-is state and the improvement after your changes.
If you enjoyed this article, consider subscribing on Feedly or your favorite RSS consumer. If you'd like to chat, I'm most active on Bluesky.
- Previous: Govsky