Micro Focus is now part of OpenText. Learn more >

You are here

You are here

4 ways to translate software development into business value

Ori Keren Co-founder & CEO, LinearB

Even in companies with good culture, there isn't always a strong desire for business and engineering to understand each other. There's a big gap between them in terms of frame of reference, language, and expectations.

One person, the vice president of engineering—part executive and part developer—uniquely lives in both worlds and therefore has an opportunity to translate between them. The best of them embrace that role as a core part of their day-to-day responsibilities and one of the best ways they can help their company succeed.

Being a great translator is more than knowing how to speak both languages. Here are four strategies that will help any software development leader become successful at translating development work into business value.

1. Connect development metrics with the overall goals of the business

The vice president of marketing has dashboards that show the number of marketing qualified leads and sales qualified leads. The vice president of sales has reports showing how many deals are in each phase of the sales cycle. And the vice president of customer success has a tool to show customer engagement and renewal metrics.

Great vice presidents of engineering should have dashboards, too. The focus should be on leading indicators that monitor the quality of the process rather than focusing on outputs or trailing indicators such as how many lines of code the team wrote or even how many bugs were found.

Figure 1. Software development cycle time measures the amount of time from when work started to when the product was delivered. This metric, borrowed from lean manufacturing, is one of the most important for software development teams and affects most other business and engineering-related KPIs as well. Source: LinearB

With this data, you can draw a clear connection between development key performance indicators (KPIs) and the overall goals for the business. For example, if you want to predict how fast you're shipping new value to customers, you show cycle time, and if you want to predict how satisfied customers are with the quality of the product, you need to show the quality of the process with pull request review coverage and review depth.

Bringing consistent metrics to your staff meeting each week will help elevate the development process from being an enigma to being a well-understood function in the business.

2. Teach software development forecasting to your executive team

The most common questions a vice president of engineering gets asked concern the timing of a new feature being shipped. This seems like a fair and obvious question to ask. But look more closely. After a while, the CEO stops asking the vice president of sales, "Hey, are we going to hit our number this quarter?" because the answer can be found by looking at the revenue dashboard and seeing:

  • The number of days left in the quarter
  • The number of deals and amount of revenue already closed
  • The number of deals left open and the total contract value
  • The number of deals open across each phase of the sales process

Then they can compare this data to previous quarters to see if they are on, ahead of, or behind schedule. For engineering vice presidents, part of the job is to teach the CEO and the other business leaders to look at their department in the same way.

And although forecasting is a tough task, if those leaders want to know whether feature XYZ is on time, they can look at a dashboard such as this:

Figure 2. Show business stakeholders what an iteration schedule looks like in dashboard form to better explain how time allotment is connected to work in progress (WIP) and work completed (branches). Source: LinearB

Over time, the CEO and the vice president's peers will develop data-driven intuition (yes, this is a thing; just read Malcom Gladwell's Blink: The Power of Thinking Without Thinking). They will understand whether you are currently in a hitting, missing, or overachieving trajectory. So instead of asking, "Are we going to hit our date?" they'll say, "It looks as if you are slightly behind schedule compared to last week/iteration. What can I do to help?"

Instead of saying, "Customer ABC really needs the new feature to work, so no bugs this time," they can gain confidence that the vice president of engineering and the dev team leads will shift resources to control when there are too many high-risk items open that generate more technical debt.

That's the goal: to help the CEO and other executives understand how they see their business so they can be a more active participant and so they can start measuring the process of software development, not just the outcome.

3. Build cross-team relationships and empathy through data

It takes a long time to teach someone to speak a new language. Furthermore, if the language isn't practiced in real life every day, people tend to lose the skill over time. The best vice presidents of engineering know they can't let this happen. Building strong relationships with their peers is critical to creating rapport that constantly reinforces the message.

When stakeholders are only asking about metrics such as feature delivery deadlines or bugs, great engineering leaders teach them how to view software development differently. For example, they quantify for the business leaders what the impact of changing dev team priorities at the last minute can be and help them understand why developers don't reply to email quickly. To be a great partner, the key is to understand what motivates teams and what KPIs they care about most.

One goal should be to start every morning by looking at data to determine the health of the business. Not just any data, though. The best vice presidents start with cycle time, which is the most accurate indicator of process efficiency, then look at the team WIP to validate that the team is not in overload.

They also look at other leading indicators such as pull request pickup time and pull request review time to detect bottlenecks that can affect the team's current sprint and their performance over time.

By using consistent metrics to measure the dev team’s process, they are ensuring that the entire team speaks in a consistent language about what they do. This is the first step in being able to speak a common language with the rest of the business. It is imperative engineering leaders translate business functions to their team.

Being able to see the customer perspective and the big picture is a critical skill for developers to acquire.

4. Help teams gain skills with a shared lexicon, connect the dots between code and customers

The best vice presidents of engineering help teams by creating a common vocabulary:

  • Sales cycle time is the length of time it takes a sales rep to close a deal on average.
  • Engineering cycle time is the length of time it takes a dev to deliver a work item on average.
  • High-risk deals are important deals to the company that may not close.
  • High-risk branches are important work items to the company that may not get finished.

A lot of this stuff is synonymous, and it helps developers to see that the rest of the business thinks about their day-to-day work in the same way they do.

Great engineering leaders also draw simple connections between code and customers. Developers should talk to customers directly. If that sounds scary to business leaders, think of how much scarier it is to rely on a developer to create a product for someone the developer doesn't understand.

At the very least, great vice presidents of engineering can create opportunities for the team to visually see how customers use the product they are building.

Bridge the divide

When vice presidents of engineering master this translation, their teams deliver more value to customers and the whole company thinks differently. The executive team gains confidence that forecasting software development is possible, or at least can have the same accuracy as forecasting marketing leads or sales revenue.

The executive team shows interest in the software development process and metrics and understands the implications and trade-offs of their requests. Developers feel as if they work for someone who truly has their back. The business as a whole thinks, “Our engineering team really gets it.”

The starting point to translating engineering to execs is finding these key metrics and understanding how to demonstrate team, not individual, performance.

Keep learning

Read more articles about: App Dev & TestingApp Dev