Engineering Leaders Need to Speak the Language of Business

This post is part of our historical archive. It represents the beliefs, actions, products, and services of Code Climate as of its publication date. Today, Code Climate focuses on providing enterprise leaders the software development data, context layer, and playbooks needed to build the AI-native software organization their enterprise needs.

Author: Khan Smith
Date: Aug 26, 2021
Read Time: 3 min

Historically, engineering departments have been without reliable, objective metrics, leaving engineering leaders at a disadvantage in conversations with executives and board members. It’s part of the reason engineering is often viewed as a ‘black box’ — where departments like sales and marketing have clear numbers that demonstrate the efficacy of their processes, or their direct impact on the company’s bottom line, engineering has been reliant on reporting progress in ways that often raise more questions than they answer.

A list of features completed, for example, doesn’t convey the amount of work that went into delivering each feature, and doesn’t account for variations in difficulty or complexity. When a list is shorter one quarter, the immediate conclusion may not be that the features were more complicated, but that the engineering team is starting to fall behind.

Reporting on incidents is similarly flawed. The frequency of incidents may increase when the engineering team is encouraged to pursue an ambitious product roadmap without being afforded the time to address technical debt. These incidents may be seen as a reflection of subpar work by the engineering team, when in reality they’re a result of poor planning and prioritization.

To communicate effectively with the rest of the business, engineering needs to speak the language of the rest of the business. To do that, engineering leaders need objective metrics. Objective metrics translate across teams, individuals, and projects. They provide a concrete basis for critical conversations about everything from resource allocation to strategic decisions. Rather than simply asking stakeholders to trust your conclusions, you can use data to show them how you got there.

For example, you can make the case for increasing headcount by explaining that your current team isn’t large enough to keep up with the proposed product roadmap, or you can look at a throughput metric like Deploy Volume and illustrate the engineering team’s capacity with concrete numbers. On the flip side, you can demonstrate the success of a recent hiring push and illustrate the effectiveness of your onboarding practices with a graph of your team’s Cycle Time (a great proxy for engineering speed), demonstrating how quickly new hires are getting up to speed.

Trust is important, but it’s not enough. When you’re advocating for your department — pushing for key resources, raising an issue, or celebrating a success — data will help you make a stronger case.

Of course, metrics are not a replacement for experience, intuition, and expertise. As the expert, it’s still your job to put metrics in context, analyze them, and draw the right conclusions. When communicating with key stakeholders, you’ll need to choose the metrics that matter most to the rest of your organization, and situate them within the larger story of your department.

Steps for Building Effective Engineering Insights

Step 1: Define Your Purpose

The first step in any successful engineering insights strategy is defining why you're doing this in the first place. If you're rolling out developer productivity metrics or an insights platform, you need to make sure there’s alignment on the purpose across the board.

Step 2: Understand Your People

You have to consider who will be using the developer productivity tool/insights platform. It’s also crucial to account for organizational changes. Reorgs are common in the enterprise world, and as your organization evolves, so too must your insights platform.

Step 3: Define Your Process

It's essential to approach this with an experimentation mindset. Start by identifying an area for improvement, make a hypothesis, then test it and use engineering insights data to see if your hypothesis is correct.

Step 4: Program and Rollout Strategy

It’s key to design a value loop within a smaller team or department first. Get a team to go through the full cycle of seeing the insights, taking action, and then quantifying the impact of that action.

Step 5: Choose Your Platform Wisely

Your platform should align with your strategy—not the other way around. You should understand your purpose, people, and process before you even begin evaluating platforms.

Looking Ahead

To build a successful engineering insights strategy, you need to go beyond just installing a tool. An insights platform can only work if it’s supported by a clear purpose, the right people, a well-defined process, and a program that rolls it out effectively. The combination of these elements will ensure that your insights platform isn’t just a dashboard—it becomes a powerful driver of change and improvement in your organization.