Four Laws Of Software Economics (Part 1)
Newton taught us that gravity’s not just a good idea, it’s the law.
I’ve spent a lot of the last decade with one foot in the engineering organization and the other with marketing/sales. While the two sides of the business communicate poorly, I think there’s something more fundamental happening: we don’t believe in the same laws of physics. So with some gross generalizations, here are a few core principles of software economics. At the executive level, these should help us drive our tech companies in the right direction – to let gravity pull us where we want to go. Four posts lay out a should-be-obvious set of truths and their matching laws. (Originally presented as a Business of Software talk.)
Reality #1: Your development team will never, ever, ever be big enough.
We all deny this, but it’s obviously true on inspection. As soon as we’ve finishing wrestling and screaming behind closed doors to negotiate this quarter’s minimally viable roadmap, a stack of new requests and demands and executive overrides falls in. Phantom deals emerge, analyst reports favor a competitor’s new feature, and some bit of system infrastructure is suddenly unstable.
More generally, there is an infinitely deep backlog, an unquenchable thirst for more software. Development can never build as fast as we can dream up new things. There’s no white space on the roadmap that we can’t fill with one more UX-clogging featurette.
(Need proof? Try saying these words to any executive: “We’ve found a little slack in next week’s sprint.” You’ll walk away with 50 dev-years of newly urgent work.)
Of course we should staff up, go agile, apply lean discovery, invest in continuous integration, supply high-protein snacks, and have a dog-friendly office. Build a world-class technology team. Worship architects above all others. But we’ll never catch up with demand.
This is partly due to magical thinking. Everyone with a request — customers, ex-customers, prospects, product managers, salespeople, partners, DevOps, support and customer success groups, and the development teams themselves — focuses on that next new idea. It’s urgent and important, so there must be resources to do it. Unconsciously, we take an AND point of view: we can somehow do this just-one-more-small-thing AND still handle all-that-stuff-we-committed-to-but-forget-because-I-need-this-right-away.
Magical thinking is evident in the unconditional way we make requests demands:
- “The CEO says it’s really important.”
- “We already promised it to a big prospect.”
- “How hard could it be? Probably only 10 lines of code.”
- “We’ve been talking about this for months.”
- “We’ve gone agile, which gives us infinite capacity…”
- “My neighbor’s kid could do this in an hour.”
Our unstated thought: it’s not that the development team CAN’T do what we need, it’s that they WON’T do it. If we make a convincing revenue argument or threaten executive intervention, they will admit that highly skilled developers are off reading xkcd – and could bang out this new feature before lunch.
Of course, development teams live in an EXCLUSIVE-OR world. There is no white space, no unallocated resource, no empty slots at the top of the backlog. If we’re going to insert that special configuration option that our VP Sales is sure will close a $28M deal with Deutsche Bank, something else won’t get done. Product managers and Engineering VPs are trained to respond in EXCLUSIVE-OR terms: “Adding a teleportation option will absolutely delay version 6.2, force us to drop self-configuration, and probably push out three-factor authentication. Who’s going to tell our entire customer base that there’s no update this quarter?” TNSTAAFL.
Very occasionally, we do find a small enhancement that fits effortlessly into other work. And we celebrate the dev team’s cleverness. This rare event provides Skinner-style variable reinforcement to the next 100 requesters who now expect an easy work-around to their problem.
So enough depressing talk about inevitable shortages. What do we do with this completely obvious insight?
First, let’s give it a name:
The Law of Ruthless Prioritization
Then, let’s recommend actions consistent with reality.
Until we decide what few things are truly important, mostly unimportant things get done. This has to happen at every level: business unit VPs must decide which product lines get fully funded; portfolio managers must allocate scarce development teams across products; product managers must pick a handful of features to drive revenue and customer love.
Agilists have been telling us this for ages (“start less, finish more”) and reminding us that an 85%-loaded software team gets more done in total than a 100%-loaded team. That motivated, autonomous teams are more productive than management-led death marches. Yet we’re always willing to slip just one more tiny item in. Another brick in the wall.
Executives tend to be action-oriented, quick deciders (ESTJ) and development leads are often introspective, literal speakers (INTP). Devs say “there’s no white space in the roadmap” and we hear “they don’t understand how important this is to me.” We often interpret their literal communication style as whining or lack of commitment, rather than an accurate description of the facts.
So as executives and leaders, we should try to:
- Hear development capacity issues as real
- Identify that hard choices need to be made, and make them
- Push back hard on unplanned interrupts by demanding thoughtful justification
- Recognize that escalations and one-offs are habit-forming. If that’s how folks can get things done, then we’ll have more and more of it.
Sound Byte
Your development team will never, ever, ever be big enough. So you have to apply The Law of Ruthless Prioritization at every level to focus on the few truly important items.