Measuring the business impact of engineering

When you look for engineering metrics, you often come across deployment frequency, change lead time, and velocity.

These metrics provide good insight into engineering performance as a function, but they do a poor job of reflecting the business impact of engineering.

I feel like they’re so far removed from how business stakeholders measure success that it’s hard to imagine why they would care about improving engineering excellence.

So, how does better engineering performance translate into bussiness value?

That’s the question I’ve been reflecting on, and I’d like to share some thoughts.

There’s no universal metric.

While engineering function metrics are relevant to any software team, metrics that measure business impact differ across teams.

Why?

Because bussiness metrics measure the performance of a specific bussiness domain (e.g., sales, accounts receivable, or loan processing).

This means business impact metrics will vary depending on the domain of the solution an engineering team is building.

Domain-specific performance metrics.

Continuing this thread, while there are no universal metrics, business domain metrics can be used to measure the impact of a software solution.

The impact of a loan processing system could be measured by loan processing cycle times or loan application completion rates.

The impact of an accounts receivable solution can be measured by the average number of days it takes for a customer to pay an invoice, or the percentage of invoices paid before the due date.

Engineering contribution to performance

But business metrics of software solutions are still not engineering metrics.

They reflect the impact of a software solution on the business.

And delivering a software solution is usually a collective effort of cross-functional teams.

So, how does engineering performance influence solution delivery?

Engineers usually don’t have a lot of control over what is being built or why it’s being built.

They do control how it’s built.

Specifically, how fast it’s delivered and at what level of quality.

In other words, engineers may not control whether a solution improves a business metric, but they do influence how quickly those improvements happen.

Thus, the speed of change in domain-specific metrics could serve as a useful proxy for the impact of engineering excellence.

It’s not something I’d track religiously, but I find it a useful mental model for connecting the dots between engineering performance and business impact.