Are we succeeding as a software team?
Well, if our job were feature delivery, we could look at the parade of JIRA tickets in our “complete” column. That is only part of our job, though.
The purpose of a software team is to provide valued capabilities to customers, internal or external. To do that, our software has to be up, it has to be fast enough, usable enough — a whole slew of properties that don’t show up in JIRA.
Availability, security, and the like are emergent properties of systems. You can (and should) take measurements that give you clues about how you’re doing. When they change for the worse, that’s a signal to pay more attention to the property they’re a signal for. Not the number.
You can’t really measure emergent properties, but you can look for them.
While you can take a measurement here and there, emergent properties live in the everything else of a system. You can’t measure the everything-else, but you can notice it sometimes, if you ask.
Here’s something we all want: flow, as in flow of work through the system. This emerges from a lot of not blocking the work. Not handing off, not waiting for other teams, not running into problems, not doing rework later. We can measure flow in a few ways: deployment frequency, lead time, quantity of tasks in any queue. These can signal when flow is slowing down, but they can’t tell us how to speed it up. For that, we need to ask about it: “What is blocking you? What is this piece of work waiting on? What is hard today?”
Security is an emergent property: does our software not do stuff we don’t want it to do? That can break in any piece of combination. We can’t prove or count the negative. We can look for signs of trouble like: are all our libraries up-to-date? That’s the #1 source of vulnerabilities. For the rest, we can ask about it: “What validations do we need on this piece of data? How do we know this request is legitimate?”
Availability is: our software does do what we told it to do, whenever a customer wants it. Availability is a lot of not falling over under unexpected conditions. You can crudely approximate it by counting minutes of uptime (for some definition of “up”). You can get closer by counting events, like with a Service Level Objective (SLO). When that number takes a turn for the worse, it’s time to get deeper in context. For each change, ask “How do we handle errors? If this dependency goes down, what do we do? How will we see what’s broken?”
If customers find our software delightful, that’s a property of the overall system. Its responsiveness, consistency, usefulness, charm — this isn’t one thing, it’s between all the things, and it isn’t measurable. So we ask them “Would you recommend our product to someone else? scale of 1-10.” That might clue us into a drop in delightfulness. It won’t tell us what to do. If we care about this, we can ask developers: “Will this change slow down the user flow? How does this interact with other features?”
The end property we want out of all our software is: value for customers. This is measured by what customers pay for it, in ARR (annual recurring revenue). Sometimes, in the extreme of product-owning-teams, we break that value down by capabilities. Yet this denies all the value that each capability adds to the others. A company that can both give me a credit card and let me categorize the expenses I charge to it (without receipts) is more valuable than the sum of one company for each. Value is an emergent property. Revenue is a clue, and a late one. To get a wider view, we can open our ears to customer complaints and praise. Elevate the influence of the Customer Support team.
Five properties, five measures, and questions they might prompt:
| Availability | SLO or uptime | “How do we handle errors? If this dependency goes down, what do we do? How will we see what’s broken?” |
| Security | Library recency | “What validations do we need on this piece of data? How do we know this request is legitimate?” |
| Flow | Deploy frequency | “What is blocking you? What is this piece of work waiting on? What is hard today?” |
| Delight | Net Promoter Score | “Will this change slow down the user flow? How does this interact with other features?” |
| Value | ARR | “What frustrates people?” “What combinations of features matter?” “Why do people recommend our software?” |
One property to obsess over
There’s one more property of software, even harder to measure, and even more important than any of these—because it’s how we can get to any of these other properties. The emergent property to rule them all is malleability: can we change it?
This is a property of the organization, plus the code, the architecture, and especially the interplay between them. As a company grows and its software settles into a form, it takes longer and longer to push out new features. You might say “technical debt” or “organizational debt,” but this isn’t debt, it’s value. Inertia comes with value: people and software are counting on your systems to do what they do now. Especially people and software internal to the company.
I don’t know how to measure malleability, but we can ask about it. “How do you feel about this code?” (at the time of commit) is a good indicator of code quality direction. “Who is responsible for this piece of the system?” If people don’t know, that’s a big red flag. “Where will this restructuring introduce handoffs between teams?”
Emergent properties vs focus
Notice that all these questions get in the way of a Laser Focus on Business Value (that is, someone’s estimate of business value). Laser focus is the enemy of emergent properties, and therefore it is the enemy of systems. While we need goals and deadlines to give us guides for action, we take action subject to preserving these emergent properties. Use the measures to notice when one of them has been neglected, and then ask about it, and listen to the answers. This signals everyone that you do care about the future of the software and the company, beyond this quarter and its feature delivery goals.