Filter by Category
Filter by Author
When my son gamed our potty-training system to maximize cartoons, I realized something: measuring the wrong thing drives the wrong behavior. The same is true in software development—if we focus solely on output, we risk missing the outcomes that truly matter.
While most people settle for the first workable solution, designers dig deeper, exploring a multitude of ideas and embracing risk. This is their superpower.
The tension between designers, developers, and product managers often feels like a struggle for dominance—but what if that tension is the key to building great products?
My three-and-a-half-year-old son, Evan, has decided that he’s just not that interested in getting out of diapers. He’s our last, and we’re ready to stop funding Pampers, so we’ve resorted to the most time-honored of parenting tools: bribery. Each time he pee-pees in the potty, he gets to watch a cartoon. Evan hasn’t peed in his training pants in weeks.
We’re so smart, we told ourselves. We motivated him! We’ll be out of diapers in no time.
Except we won’t—because Evan has learned that if he parcels out his urine over time, he gets more cartoons. As I write this, he’s watching what I’m told is his ninth episode of Octonauts today.
Evan has figured out that measurements drive behavior.
In every software development organization I’ve worked in, we’ve had a roadmap of features to build. We want to make sure we’re on track to accomplish that roadmap, so we start measuring the delivery of software. The reasoning seems sound — we want to make sure that we deliver our roadmap, which will drive more customers and greater revenues, which will allow us to grow. We all like growing, so we start measuring how well the team can deliver to the plan.
Predictability matters, too, right? We need to know when Feature A will be done so that we can know when we’ll work on Feature B. So we start measuring the team’s ability to deliver on time.
Even if you don’t tell the teams that they’re being measured by what they deliver, they know. They know because eventually, they miss a date, and it’s made clear that they’ve let the rest of the organization down. If Feature A is late, we’ll be late for Feature B, and we’ve committed to it on the roadmap.
So to ratchet up predictability, the company might put someone in charge of delivery. Maybe it’s a software development manager. Maybe it’s a ScrumMaster. Maybe it’s a PMO. But somebody in the company is made accountable for delivery. (Ironically, this person who is accountable for delivery typically does little to no work that directly contributes to delivery — but that’s a topic for another day.)
With accountability established, the company sighs in relief. We can now count on what we planned! We’ll deliver according to schedule! And typically, we do — even if it’s the wrong thing to do.
I didn’t set out to maximize the number of times Evan pees in the potty. I set out to stop spending the GDP of a small nation on diapers every year. (And to stop wiping butts that aren’t mine — that’s also a definite bonus.)
Thing is, Evan has zero interest in pooping in the potty. Why poop when he can get cartoons for pee? So we maintain a Costco membership just to buy diapers by the gross.
We achieved a lot of output, but we totally missed the outcome we were shooting for.
When we measure software development by shipping alone, we measure output, and we drive myopic behavior.
No one is adopting the new feature, but we can’t spend any more time on it. We have to move on to the next thing.
People are struggling with the usability of the new feature, but we don’t have time to fix it. We’ll circle back in a later sprint. (Look, I’ve said it, and I’ve meant it, but I’m telling you: it’ll never happen.)
But nothing was ever added to a roadmap without some idea of why it mattered and what it would accomplish. Nobody ever says, “Just release a feature called X; we don’t care if it works.” (OK, in some companies, that’s not true, but for the sake of argument, put our fingers in our ears and pretend those awful places don’t exist.)
We don’t build software for the hell of it. We build software to drive some difference in the world. If we want our teams to make that difference happen — to deliver great outcomes — then we must free them from the tyranny of management that measures output alone.
Shipping on time, in and of itself, is not a virtue. If we meet deadlines by shipping products that don’t affect the change we need to see, we’ve done worse than nothing: we’ve wasted time.
Evan isn’t getting cartoons each time he pees in the potty anymore. Instead, we’ve told him that once he doesn’t need diapers, he’ll get a Baymax figure for his Disney Infinity video game.
He’s very excited about it. It just might work.
(And here’s hoping we don’t find ourselves at the pediatrician’s office with newfound constipation issues soon. Measurements drive behavior, after all.)
