This post is part of a series where Joel Tosi and I write about the course we are developing titled “The Thinking Leader’s Toolkit”.
When Joel and I started drafting this post, we intended to discuss value demand and failure demand. The idea originally comes from John Seddon. He introduced it in his 1992 book I Want You to Cheat and expanded on the idea in his book Freedom from Command and Control. This article on his website explains the concept: value demand is “customer requests that are a normal part of providing a service” while failure demand is work “caused by a failure to do something or do something right for the customer.” All work is thus neatly classified into either failure demand or value demand, and the sum of the two represents the capacity of the system.
Seddon developed this model while working with service organizations. If we applied the concept to software development we could say that value demand is work that your customers want and will pay for. The outcome of this work solves a problem for a customer, makes their job easier, or lets them do something they otherwise couldn’t. Failure demand would include things like fixing product defects, redesigning a confusing user interface that caused users to abandon a task, or fixing a convoluted workflow that caused customers to call the help desk. It’s work that is only necessary because customers are dissatisfied.
However if we only have two categories, where would we put things like test automation? It is not something the customer will pay for. It’s not value demand. But is it really failure demand? This led us to have a spirited conversation about whether failure / value was the right split in software development.
We considered adding more categories. Maybe the right categorization was value demand, failure demand, and “other?” Or “optimizations?” Things in that third category might include maintenance, dependency updates, architecture reviews, or static code analysis and remediation. That didn’t quite sit right though. We recognized that including a third category added complexity but did nothing to add depth or nuance to the discussion.
We then considered the concept of waste from Lean (as adapted by Mary and Tom Poppendieck). Perhaps value / not value was the right split?
The dichotomy felt right, but we needed names for the two categories. We wanted names that would support a thoughtful analysis of where the organizational capacity goes. “Waste” has a very specific definition in Lean, and we did not want to muddy the waters, so that wasn’t the right word. We played with names related to value, but nothing seemed quite right.
After a lot of discussion, we decided that for our purposes the distinction we wanted to make was between perceptible direct customer impact, and indirect or internal impact. We visualized this like an iceberg where the work above the waterline had a perceptible impact, and the work below the waterline played a supporting role. We decided to call the two categories “above the line” and “below the line.”
We also hoped that by making the terms more neutral, it would be easier for a team to have an objective discussion without people bristling about something they worked on being called “failure” or “waste.”
So that’s the backstory of how we arrived at this nomenclature.
Note that it can be difficult to decide if something is above or below the line. Consider an initiative to implement zero downtime deploys. Above or below the line? You could say that it’s below the line because it’s invisible. But you could also say it’s above the line because it increases site uptime.
It turns out that what falls above or below the line depends a great deal on your context. The determining characteristic is the intended impact. It’s above the line work if it is intended to:
- Grow the business
- Drive revenue
- Directly benefit customers or users
For an online retailer where uptime is tightly correlated with revenue, zero downtime deploys means more revenue, so it’s above the line.
By contrast, below the line work is usually intended to cut costs, drive operational efficiencies, or benefit internal stakeholders. A maintenance window in the middle of a weekend for an enterprise SaaS solution might not affect revenue or customer satisfaction at all. In that context, zero downtime deploys might drive operational efficiencies or employee satisfaction, but wouldn’t increase revenue. It’s below the line.
So you can see, work that is above the line in one context could be below the line in another. You need to determine what’s above or below the line within your context.
Once you categorize work as above or below the line, you can map out a path for doing more with less. If we want to dedicate more of our capacity to above the line work, all we need to do is less of the other stuff. That’s all we have to do. Of course. It is so obvious…
…but how do we do that?
This is where our causal models once again peek their heads in. We can use causal models to understand the drivers behind below-the-line work, particularly the below-the-line work that isn’t in direct support of above-the-line work.
We’ll have more to say on that in the course, and perhaps a future newsletter.