#7 Show Me the Money
People!
This week we continue our search for business value in software development. Last week I discussed a couple of reason for why teams in large organizations don’t do that. This time I’ll go into examples of tracing technical practice back to business value. And a dead simple technique to sniff out business value behind technical ideas.
Remember our prime directive (from last week): Business Drives IT!
How do you ensure that behind all technical decisions there is business value or a business reason?
Easy. Ask: Why are we doing this?!
Product Features
Sometimes it’s obvious: The “checkout” feature in an e-commerce app generates revenue. As a matter of fact, every product feature must have a contribution to the business. We have product managers and/or product owners to define that value proposition. A good product manager will.
Good product managers focus the team on revenue and customers.
- Ben Horowitz, Good Product Manager/Bad Product Manager
Development Practices and Tools
What about development practices, those are not dictated by product.
For example continuous delivery (CD) - what’s the business value of CD? It enables faster delivery of changes. So if we deliver changes that add business value then CD enables us to deliver that value faster. At the same time fast cycle times enable experimentation, which is valuable (if used).
Ok, how about monitoring? Easy, contributes to business continuity, by reducing time to recovery. Less down time means more time to make money.
Caching? Speeds up the application. In consumer apps users leave an application if it is too slow.
(Now I gave easy answers and you’ll notice that those are all based on assumptions. None of these assumptions always hold true. But I bet that your team can reach satisfying answers for your product.)
Let’s turn to a practice with less obvious value: Code review. I argue that through code review we get higher quality code. That means (1) we have lower number of defects in the short term and (2) we can change the product in the long term. That protects revenue now and enables us to run more business experiments in the future. You could say allow us to be more “agile” if that word hadn’t been burned by decades of marketing. Essentially I’m arguing the design stamina hypothesis, narrowed down to code review. Replace “design” with “code review” in the below graph and you get where I’m going.
As a technical leader it is your responsibility to understand the business reasons behind practices and tools. Understanding the rationale and its trade-offs enables you to make technical decisions. Most tools and practices we inherit from previous leaders, others are decisions by current leaders. Regardless, you need to understand why behind those decisions. If you are lucky you can ask the deciders and hope they wrote it down or remember. Otherwise you have to do some archaeology. Either way, you have to challenge yourself to answer the why question behind all your practices and tools. If you don’t find and answer in yourself or your team maybe it’s time to trim some excess process or tools.
Perfection is achieved,
not when there is nothing more to add,
but when there is nothing left to take away.- Antoine de Saint-Exupery
Or in Marie Kondo’s words: Does it spark joy?
Challenge the Team
I admit, I sound like a broken record repeating “you must know the business reason, you must know why”. Beyond that you must challenge others with those same questions: Why?! Why are we building feature X? What is the value? What is the value of the technical solution compared to the required effort?
Several times I encountered the idea of the “configuration CMS”. It boils down to: We have some application configuration, currently handled in (semi-)manually. Updating configuration is a drag for developers, nobody likes doing it. For example translations of text in the user interface. So a grand idea emerges: A web GUI for the other people to update configuration, which are automatically applied to the application. Not a bad idea (also not a great one). But you have to ask:
How much effort is it to build? to operate?
How does this compare to the current effort?
Could we build anything else in the same time that creates more value?
Most attempts fail after the first 2 questions. Often changes are too infrequent to justify the initial development effort. All attempts* fail on the last question (*all attempts I’ve encountered so far). Based on basic economics: let’s say you have 10 developers and 100.000 users. Let’s say the CMS saves you 1.000$ per month. If the alternative development earns 10 cents per user you earn 10.000$ per month. The leverage of consumer value creation is almost always larger than that of developer cost savings. Opportunity cost is not the developer salary in hours invested. It’s the money lost by not creating business value.
Another category of unnecessary development is things that “will be good”. I challenge such a statement by asking: “Why? What’s the business value?”. For example: During design review I saw a database table that a developer wanted to create for logs. All our applications run in k8s pods, with sidecars that ship our logs into a log processing wonderland (e.g. ELK). So why this log table? The only answer I got was “it will be good, it will be useful”. I have never heard a convincing reason, other than that the developer thought of it and liked the idea. So we ended up dropping the table.
Then my favorite category of wastefulness. Practices or tools with the “Google does it” label, or the "best practice" label. That is the “because it’s good” argument with a twist. This time the assessment of goodness is externalized to a third party. Some organization with a different culture, different product and different business. The “Google”, “Amazon” or “best practice” labels don’t have inherent value, they don’t matter per se. What matters is: do you have a reason to believe that this tool or practice will contribute to your business? If no - fuck it.
Finally Alignment
Knowing why we work the way we work - that’s what mean when they talk about alignment. A team that doesn’t know what value it provides to the business and how it does that is not aligned with its purpose.
You are the leader, it is your job.
To understand the why of all existing practices, tools and product features.
To communicate it to the whole team.
To challenge the team to think in the same way.
That’s how leaders align teams, that’s how business drives IT.
Hyperlinks
The Age of the Essay
An essay is something you write to try to figure something out.
Figure out what? You don't know yet. And so you can't begin with a thesis, because you don't have one, and may never have one. An essay doesn't begin with a statement, but with a question. In a real essay, you don't take a position and defend it. You notice a door that's ajar, and you open it and walk in to see what's inside.
That’s it for this week. If you enjoyed this ☝️leave comment or share it with a friend.