When Doing Digital Transformation, Think Capabilities, Not Maturity

Last week, we looked at how the 2018 book Accelerate: The Science of Lean Software and DevOps gave us a practical framework for measuring software development productivity. This week, we’re going to take a look at a second valuable idea in the book — that is, when doing digital transformation, think in terms of organizational capability, not maturity.

First, some context. The authors of Accelerate have studied hundreds of organizations over the course of four years, as part of their research program into software delivery. We’ve discussed the differences between high-output software orgs vs low-output software orgs in our previous post, but it’s worth highlighting the fact that Accelerate’s research was done with an eye towards helping organizations with their digital transformation. If you’re a company with a middling software engineering arm, the insights from Accelerate should — in theory! — help you become better at producing software.

This is interesting to us because we deal with data analytics here at Holistics. As I write this in 2020, we’ve seen probably a hundred different companies building out their business intelligence departments. Accelerate’s ideas seem particularly relevant when you consider the rate of failure most digital transformation efforts have had over the previous decade.

What is a Maturity Model?

We’ve covered maturity models in the past. In my post on data analytics career thinking, for instance, I wrote about Emilie Schario’s Three Levels of Data Analytics — a method for thinking about a company’s level of data maturity. Schario proposed three levels of data maturity:

1. Reporting — your company reports raw data in dashboards or scheduled reports.
2. Insights — your company is able to generate insights from relationships between facts.
3. Predictions — your company is able to use its data to forecast the outcomes of business decisions.

In a previous edition of our Holistics newsletter, Holistics co-founder Huy also shared a post about Big Data Maturity Models by Jon Brathseth. Brathseth’s post comes with this helpful illustration, which should give you a pretty good idea about the nature of such maturity models:

In essence, maturity models prescribe a set number of levels. In the data analytics context, your company might belong to the ‘analysis’ level — and if so, your goal is to advance to the ‘learning’ level, and so on.

Maturity models are useful if you want to categorize companies from the outside — that is: as an investor, or perhaps as a prospective employee. This idea was the at the heart of my previous post on data analytics career thinking: I argued that since the arc of your career as a data analyst depends on the data maturity of the company you’re joining, you should spend a little time to evaluate that company before you agree to join them.

The Downsides of Maturity Models

While maturity models may be useful for categorizing companies, the authors of Accelerate believe that such models are a bad idea if you intend to implement digital transformation in your organization. They give four reasons against using them.

Maturity models focus on helping an organization arrive a mature state

First, maturity models assume that organizations can arrive at a certain ‘mature’ state, and then consider themselves done. This is unrealistic, because competitive pressures and changing markets force companies to continually adapt. In contrast, capability models focus on helping an organization continually improve — and assume no set point for maturity.

In the context of data analytics — we could say that you’ve arrive when your company is able to use data to forecast the outcomes of its business decisions. But then where do you go from there? And what do you do when the market shifts around you, and you realize that your business intelligence capabilities aren’t up to the task of modelling things quickly enough?

Maturity models prescribe a linear path to high performance

Second, maturity models assume that all companies move from one level to another in lock-step. In Emilie Schario’s Three Levels of Data Analytics, for instance, you could argue that a company cannot generate insights if it doesn’t already produce reports, and that it cannot forecast if it doesn’t currently generate insights.

But this isn’t always true. For instance, a company might be able to generate insights in its product department, but has no need for forecasting from the data department. Meanwhile, marketing is merely using the data department to generate weekly reports.

The truth is that ‘level 1’ and ‘level 2’ may look very different across different teams and different organizations. Maturity models are too simplistic because they assume all companies travel along the same linear path. In contrast, capability models are multidimensional and dynamic, and allow different parts of the org to take a customized approach to improvement.

Capability models are outcome based, maturity models are not

Third, capability models focus on key outcomes within the organization. For instance, Accelerate proposes that all software organizations improve their capability to ship code to production. They make it very clear that the best software orgs are able to go from code committed to code deployed … within one hour. By making this capability explicit, they tell organizations what they need to develop, and what that goal looks like in the very best teams.

In contrast, maturity models simply measure the technical proficiency or tooling base in an organization … without tying it to outcomes. These end up being vanity metrics: which mean that while they are easy to measure, they don’t tell us anything about the impact they have on the business.

Maturity models define a static level of achievement

Fourth, maturity models define a static level of technological, process, and organizational abilities to achieve. Take Brathseth’s ‘Big Data Maturity Models’, for instance. The current levels in his model assume the state of big data today. But wait a few years and it’s likely none of his categorizations would be as useful.

The authors of Accelerate explain that what is considered ‘good enough’ and even ‘high performing’ today is no longer good enough in the next year. They know this empirically: their research and data collection show them that this has happened repeatedly over the span of four years.

What Capabilities Does Accelerate Recommend?

Accelerate recommends 24 capabilities. I summarise them below, but we should keep in mind that they’re taken from high-performance software organizations, not high-performance data departments. Applying them to a data department would require some thoughtfulness.

With that out of the way, Accelerate’s 24 capabilities come in five categories. They are:

Continuous Delivery

• The organization uses version control for its code.
• The organization uses deployment automation when deploying code to production.
• The organization practices continuous integration.
• The organization uses trunk-based development — which means all development is done on the ‘master’ or ‘trunk’ branch. Feature branches are temporary and short-lived.
• The organization has a test suite that is automated.
• The organization does test data management. This means they have a process for testing the data used in their automated test suite.
• The organization integrates security practices into their entire development workflow.
• The organization practices continuous delivery (CD).

Architectural Capabilities

• The organization has a loosely coupled architecture.
• The organization empowers its to pick their own tools, adapted to their unique challenges.

Product and Process Capabilities

• The organization incorporates customer feedback into their product development.
• The organization has a good understanding of the flow of work from the business all the way through to customers, and makes this flow of work visible to everyone in the org.
• The work the organization does is sliced up to smaller batches, so it may be released frequently.
• Teams within the organization are able to change requirements and specifications in response to what they discover in the process of building the product, or talking to the customer.

Lean Management and Monitoring Capabilities

• Organizations have a lightweight change management process.
• The organization monitors of key quality and productivity metrics.
• The organization receives proactive notification when something goes wrong, and that information is shared and acted on without fear of reprisal, or fear of internal politics. (This is linked to having a Westrum generative organizational culture, see below).
• The organization limits the amount of tasks that can be ‘work in progress’ (aka WIP limits)
• The organization uses visual displays and dashboards to track key indicators — including work in progress and error rates.

Cultural Capabilities

• The organization has a Westrum generative organizational culture.
• The organization supports employee learning
• Collaboration among teams are possible in the organization, with no fear of blame and no fiefdoms. (Also linked to a Westrum generative org culture).
• Workers polled in high-performing organizations tend to have high job satisfaction, as measured via anonymous surveys administered by Accelerate’s research team.
• Leadership is committed to implementing all of the above capabilities, either intentionally or by accident.