Mapping Engineering Goals to Business Outcomes

When an engineer is deep in code, fixing a bug or completing a review, it can be hard to connect the dots between these actions and what seem like unrelated company objectives. In traditionally structured organizations, the business sets goals for engineering based on its understanding of the market, customer needs, and the numbers it must achieve to appease investors. Without a clear understanding of how engineering activities impact business objectives, it’s difficult for engineering leaders to make informed strategic decisions, keep teams aligned, advocate for resources, or communicate successes. Engineering leaders must understand these business objectives, map their work to them, and clearly communicate them to engineering teams and non-technical stakeholders.

Start With Why

Often, engineering is seen as a cost center, but in reality, it’s the main driver of revenue in many modern companies. When leaders help their teams understand the “why” behind their work, engineers can let go of the expectation that they must be busy and replace it with the expectation that they must create value. After all, building something right doesn’t matter if it’s not the right thing.

So, how do engineering leaders ensure that their teams’ work is aligned with the business's goals?

Discover Business Outcomes Driven by Engineering Work

Imagine a retail business that sells sporting goods. They want to allow shoppers to easily bundle gloves, sunglasses, baseball bats, and other baseball gear on their e-commerce site. To do this, engineering is tasked with building a widget that offers shoppers pre-defined selections, provides recommendations based on data about the shopper, and reveals an increased discount as more items are bundled. The goal is to have this feature live in February to capture sales for the spring sports season.

To understand the work that will go into this project and balance it with other priorities, engineering leaders should ask the following questions.

1. What happens if it doesn’t get done? In this case, if the project isn’t done in February, the business risks missing its Q1 revenue targets. If it’s not completed according to spec, it may have other consequences depending on what changed. And if it’s not completed at all, the company may experience lower sales volume over a longer period of time.

2. How does it benefit customers? The customers who care about a baseball gear bundle are likely parents of youth baseball players. The problem it solves for them is that it makes shopping easier, and it’s worth solving now because parents want an easy way to buy new gear at the beginning of the season.

3. What happens if it gets completed earlier or better? There are no benefits to completing this project ahead of time, because before February, it will still be basketball season and parents won’t yet be shopping for baseball gear. However, if it’s completed with better quality, it may result in a higher checkout success rate, larger cart sizes, more sales, and ultimately more revenue. The final question in this set is what happens if it’s implemented differently. In this case, it depends on what changed.

All of these questions are intended to spark a conversation between engineering and business partners so they can understand the full scope of the request and produce the best possible outcome.

Frame Engineering Work According to Outcomes

By asking the questions above, the engineering team can learn three important things to guide their approach to the project.

1. The deadline matters, but going faster doesn’t. To deliver this feature on time, engineering should keep speed-related metrics consistent, but they don’t need to improve them to achieve the goal.

2. Levers can be used to optimize the result and prioritize the work. Finding ways to increase the cart size or the success rate at checkout can produce even better results for the business.

3. There is a financial goal associated with this work. It’s clear to everyone on the team how their work impacts the business. If additional resources are needed to deliver the feature, it’s reasonable for engineering to pause other projects or ask to add members to the team.

At the beginning of the project, the engineering leader should look at other work in progress and complete a simple cost-benefit analysis to properly prioritize work. They may discover that another project, which is focused on redesigning the mobile app, has a low number of weekly coding days because the team is investing in research. Since it’s still in the research phase, the team doesn’t yet know the financial impact of a mobile redesign. However, they do know the expected impact of the baseball bundle widget, so shifting resources to it from the mobile redesign will redirect those resources to generating revenue instead of investing in a long-term project with an unclear return.

As the widget progresses, engineering metrics may reveal other changes that need to be made in order to meet the project’s requirements. For example, a high amount of Rework may indicate that work isn’t being planned properly, resulting in duplicated effort and wasted time. Or a large PR Size combined with slow Review Cycles may reveal that one person is handling all the PR reviews, so folks are batching up large amounts of work in each PR.

With an understanding of the tradeoffs inherent in the project, and the knowledge that a delayed or poor-quality widget would significantly impact revenue, an engineering leader would likely decide to make a change to resolve these issues. They might, for example, consider adding a dedicated project manager (PM) to the team to help improve the flow of work. A cost-benefit analysis will show that adding a dedicated PM can improve Traceability, Rework, and developer productivity, allowing the team to release the baseball bundle widget on time. This can result in a net gain of the projected sales from the bundle in Q1 due to increased cart size and checkout success.

Measure and Communicate the Success of Engineering Goals

The right data and context help developers connect the dots between their work and company objectives. Even bug fixes and code reviews carry a different weight when they’re seen in the context of a larger goal, like delivering the baseball bundle widget on time to meet Q1 revenue targets. Asking the questions outlined above and gathering insights in a Software Engineering Intelligence (SEI) Platform like Velocity helps leaders map engineering work to business outcomes and clearly communicate them across the board.