2 min read

Time-to-usefulness as a metric for innovation excellence

In their brilliant book, Accelerate — Building and Scaling High Performing Technology Organizations, Forsgren, Humble, and Kim suggest four metrics for measuring the software delivery performance of a team or organization:

  • Lead Time: The time from code committed to running in production;
  • Deployment Frequency: How often deploys happen;
  • Mean Time To Restore (MTTR): How quickly can teams restore service after production outages; and
  • Change Fail Rate: What percentage of deploys result in service impairment or an outage.

In their research they found that high performing teams and organisations operated significantly faster than their peers. These high performers were able to deploy to production in hours, rather than months, and deploy multiple times per day without compromising stability or uptime.

Developer experience plays an essential enabling role in achieving this level of performance. In our experience in working with builders and digital innovators, we would suggest another metric for developer experience excellence: Time-to-usefulness.

Time-to-usefulness

We define time-to-usefulness (TTU) as:

The time it take a newcomer to transition from 'new laptop' to 'business impact'.

Newcomers may refer to traditional software developers or any other business practitioner, such as actuaries or data scientist, who will take up the role of a builder.

High performing teams and organisations deliver a TTU of days rather than the weeks and months that is often the case. Similar to the other four metrics, this translates in the ability to operate at an order of magnitude difference in experience than their peers.

TTU for sustaining innovation

In his groundbreaking research on motivation, Victor Vroom of the Yale School of Management found that an individual's Expectancy, or anticipation of the connection between effort and impact, was the key foundation for long term motivation.

We've all experienced the honeymoon moment of joining a new team, project or organisation where we're full of ideas, excitement and a desire to contribute. When that energy can quickly translate into the ability to make an impact we are far more likely to sustain our sense of motivation and our hunger to innovate. When that energy hits a proverbial brick wall of bureaucracy, context overloading and panicked helplessness, the small glowing ember of innovation quickly dies.

The three biggest impediments to TTU are:

  1. The how do I structure this problem: I see something that needs fixing, but how do I start making progress in formulating a solution.
  2. The barriers to entry problem: When 80% of the effort is expended on solving barriers to innovation such as environmental, permissions and boilerplate code, it's very difficult to expend meaningful mental energy on formulating an innovative solution.
  3. The how do I productionize and serve my solution problem: It's one thing to write code that solves a problem. It's an entirely more daunting problem to try think about how to get that solution into the hands of people that need it.

Decreasing TTU requires intentionality in improving developer experience and ruthlessly eliminating the three former mentioned impediments.

At the core of Alis Exchange, our attempt at addressing this has been the development and adoption of the Alis Build platform. The tooling, templating and simple Define, Implement and Consume framework eliminates the three frictions and enable builders to digitally innovate faster than ever before.

What is the effect of the platform on TTU? We will let our clients share that.

TTU < 5 days

A newcomer at one of our clients went from a boxed laptop and zero cloud experience to a productionized process solution in less than 5 days. This short testimonial from a new builder, Daniel, captures the excitement that comes with immediately being able to innovate and make an impact.

Read more about the case study here.