Have More Impact by Doing the Right Work

Writing code—no matter how much, how fast, or how challenging—is not the same thing as having impact on a business.

As engineers, we're rarely taught how to think about and describe the work we do in terms of its impact or effects. We're left to either figure it out for ourselves, or rely on managers, who are usually also figuring it out themselves.

But connecting our work to business impact becomes absolutely critical as a staff+ engineer! The more senior you are, the more you're expected to identify impactful opportunities, convince leadership they are worth pursuing, and then deliver on them efficiently. And the more hiring managers will be happy to see results and impact on a resume. So understanding and explaining the connection between code and business outcomes is a skill worth practicing!

What are outcomes, results, and impact?

Using the right vocabulary helps communicate, and think about, what matters.

The first distinction to draw is between outputs and outcomes. Outputs are the direct products of our work. A written report, a dashboard, or a piece of software are all outputs. Outcomes are what changes because of those outputs. If the output is a dashboard, the outcome might be that we have a real-time understanding of the health of a system. If it's a piece of software, the outcome might be that our customers can now do something they couldn't before, or that more (or fewer!) visitors to our website sign up for our newsletter.

Results—especially in the context of Objectives and Key Results (OKRs)—are another way of talking about outcomes. They are usually, but not always, defined in terms of some kind of metric, and can be a goal (e.g. increase newsletter signup rate from 10% to 15%) or a description (e.g. products-per-customer did not significantly change).

Impact is the answer to "so what?" When talking to the business, more newsletter signups might mean that we have increased ad revenue, or that we're getting more purchases from additional customers entering top of our funnel.

In a business context, the impact of our work is usually related to revenue or expenses or both. There are intermediate metrics, too, like customer satisfaction (CSAT) or net-promoter score (NPS), margin, employee satisfaction, etc. And other types of organizations might have a totally different focus, like the adoption of standards, or percentage of students that graduate.

Start with impact and work backwards to find project opportunities

Once you know what matters to your organization—annual goals are a good starting point—you can look for opportunities to have an impact on those things, and understand whether work is aligned with those goals or not.

The two questions I ask are:

• Could we do something here that would affect the right things?
• If we succeeded, would that affect those things enough?

To answer the first one, it also helps to know the strategy—formal or informal—that your part of the org is following. For example, if a business has a goal around revenue growth, there will usually be some more specific focus areas like attracting new customers, or increasing how much existing customers spend. Different teams can also affect different aspects of the business. If the focus is on acquiring more customers, marketing teams can help get people to the top of a funnel, and product teams can help get more people to the bottom.

This tends to be fractal, with ever team having a narrower focus area that (hopefully) contributes to the overall goals.

Based on what you're trying to impact, you can phrase your goal as an outcome, and then decide what approaches, or outputs, will help you get there.

When I worked at a media company, revenue came from ad impressions, and we could get more impressions the longer readers stayed on the site, which we could measure by time on site or pages per visit (or by aggregate time on site and total page views). We in engineering and product and design couldn't change the content—that's the writers' job—but we could do things like surface more articles that the visitor would also like to read, or make it easier to share. So we proposed engineering projects that would help us deliver those kinds of features and experiments more frequently.

There were other options: we could have proprosed using compute resources more efficiently and so reducing cloud spend. But the company, as a whole, was trying to get more revenue, so cost-cutting measures weren't aligned with what everyone else was doing—on top of which, as customer-facing product teams, even completely eliminating our compute costs would have saved less than 1% of our cloud spend.

Work that helps other teams internally often has another step and needs to look at changes in aggregate. When I worked in direct-to-consumer insurance sales, our product teams did a lot of work to increase conversion through a process that asked a lot of personal questions. We ran a lot of experiments around things like wording of questions and how they were ordered. So when we saw an opportunity to make it easier and faster to build those experiments, there was a connection to the company strategy and goals, and when we proposed spending time on that work, we had leadership's support. In aggregate, this meant we could spend less engineering time on each of these experiments, and more time on things that non-engineers couldn't do, like building integrations that let customers submit applications without requiring a phone call—which was one of the worst converting steps.

Similarly, at the media company, my teams couldn't do much about cloud spend—and so it was a bad use of our time. But our internal platform team could have a big impact on spend by deploying workloads on Kubernetes (k8s) which would, in aggregate, use our compute resources more efficiently and reduce our compute spend significantly. They also showed that moving to k8s would speed up continuous integration (CI) pipelines, which would mean engineers could spend more time on higher-value work that improved pages-per-visit.

The hardest part of this is that sometimes, you have to look at something that bugs the hell out of you, and accept that you can have more impact by doing something else.

More than once, I've had a team that was unhappy with their web performance—which was "objectively" fine but not great—but the data showed that performance improvements, and spending more time on them, didn't significantly improve pages-per-visit or funnel conversion. The team that did end up spending the most time on web performance demonstrated that there was an opportunity to improve our search result rankings, getting our content in front of more people—and it was work that only engineering could do, with help from design.

Lead with impact when you talk about the work

When you're talking about a project, when you're proposing it or when you're talking about what you've done, lead with that impact.

"We can <help achieve this goal> by <working on this problem>."

It's easier for leadership to say yes to a project when you show them that it will have a significant impact on the things they care about. "Reducing technical debt" doesn't mean much, even to engineering, but "reducing time-to-market for product features" might.

Concrete numbers and data look good on a resume, but only if they're meaningful numbers. Very few people will care that you wrote 50,000 lines of code during your tenure. More will care that you led a project that improved conversion, or cut costs by 30%. The lines of code were an implementation detail.