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 helps leaders map engineering work to business outcomes and clearly communicate them across the board.

Request a consultation to learn more.

Technology is evolving very quickly but I don't believe it's evolving as quickly as expectations for it. This has become increasingly apparent to me as I've engaged in conversations with Code Climate's customers, who are senior software engineering leaders across different organizations. While the technology itself is advancing rapidly, the expectations placed on it are evolving at an even faster pace, possibly twice as quickly.

New Technology: AI, No-Code/Low-Code, and SEI Platforms

There's Generative AI, such as Copilot, the No-code/Low-code space, and the concept of Software Engineering Intelligence (SEI) platforms, as coined by Gartner®. The promises associated with these tools seem straightforward:

• Generative AI aims to accelerate, improve quality, and reduce costs.
• No-code and Low-code platforms promise faster and cheaper software development accessible to anyone.
• SEI platforms such as Code Climate enhance productivity measurement for informed decisions leading to faster, efficient, and higher-quality outcomes.

However, the reality isn’t as straightforward as the messaging may seem:

• Adopting Generative AI alone can lead to building the wrong things faster.
• No-code or Low-code tools are efficient until you hit inherent limitations, forcing cumbersome workarounds that reduce maintainability and create new challenges compared to native code development.
• As for SEI platforms, as we've observed with our customers, simply displaying data isn't effective if you lack the strategies to leverage it.

When I joined Code Climate a year ago, one recurring question from our customers was, "We see our data, but what's the actionable next step?" While the potential of these technologies is compelling, it's critical to address and understand their practical implications. Often, business or non-technical stakeholders embrace the promises while engineering leaders, responsible for implementation, grapple with the complex realities.

Navigating New Technology Expectations and Realities

Software engineering leaders now face increased pressure to achieve more with fewer resources, often under metrics that oversimplify their complex responsibilities. It's no secret that widespread layoffs have affected the technology industry in recent years. Despite this, the scope of their responsibilities and the outcomes expected from them by the business haven't diminished. In fact, with the adoption of new technologies, these expectations have only increased.

Viewing software development solely in terms of the number of features produced overlooks critical aspects such as technical debt or the routine maintenance necessary to keep operations running smoothly. Adding to that, engineering leaders are increasingly pressured to solve non-engineering challenges within their domains. This disconnect between technical solutions and non-technical issues highlights a fundamental gap that can't be bridged by engineering alone—it requires buy-in and understanding from all stakeholders involved.

This tension isn't new, but it's becoming front-and-center thanks to the promises of new technologies mentioned above. These promises create higher expectations for business leaders, which, in turn, trickle down to engineering leaders who are expected to navigate these challenges, which trickle down to the teams doing the work. Recently, I had a conversation with a Code Climate customer undergoing a significant adoption of GitHub Copilot, a powerful tool. This particular leader’s finance team told her, "We bought this new tool six months ago and you don't seem to be operating any better. What's going on?" This scenario reflects the challenges many large engineering organizations face.

Navigating New Technology Challenges and Taking Action

Here's how Code Climate is helping software engineering leaders take actionable steps to address challenges with new technology:

1. Acknowledging the disconnect with non-technical stakeholders, fostering cross-functional alignment and realistic expectations. Facilitating open discussions between technology and business leaders, who may never have collaborated before, is crucial for progress.
2. Clearly outlining the broader scope of engineering challenges beyond just writing code—evaluating processes like approval workflows, backlog management, and compliance mandates. This holistic view provides a foundation for informed discussions and solutions.
3. Establishing a shared understanding and language for what constitutes a healthy engineering organization is essential.

In addition, we partner with our enterprise customers to experiment and assess the impact of new technologies. For instance, let's use the following experiment template to justify the adoption of Copilot:

We believe offering Copilot to _______ for [duration] will provide sufficient insights to inform our purchasing decision for a broader, organization-wide rollout.

We will know what our decision is if we see ______ increase/decrease.

Let’s fill in the blanks:

We believe offering Copilot to one portfolio of 5 teams for one quarter will provide sufficient insights to inform our purchasing decision for a broader, organization-wide rollout.

We will know what our decision is if we see:

• An increase in PR Throughput
• A decrease in Cycle Time
• No negative impact to Rework
• No negative impact to Defect Rate
  

Andrew Gassen leads Code Climate's enterprise customer organization, partnering with engineering leaders for organization-wide diagnostics to identify critical focus areas and provide customized solutions. Request a consultation to learn more.