A developer on our team recently spent two days optimising a database query that ran once a day during an overnight batch job. The query went from eight seconds to two seconds. Technically impressive. Commercially irrelevant. Nobody was waiting for that query. No user experience depended on it. The six seconds saved multiplied by 365 days equals 36 minutes per year. That developer's two days of work saved 36 minutes annually. This isn't a performance problem. It's a financial literacy problem.
What You Need to Know
- Developers without financial context optimise for technical elegance instead of business impact
- Unit economics - the cost and revenue of each customer or transaction - should inform every build-vs-skip decision
- Financial literacy doesn't mean turning developers into accountants. It means giving them enough context to make informed trade-offs
- This is a systemic gap in how we train technology professionals
The Gap Nobody Talks About
Computer science programmes teach algorithms, data structures, system design, and software engineering. They don't teach revenue models. They don't teach margins. They don't teach the relationship between a feature and the commercial outcome it enables.
The result is teams full of talented people who can build anything but can't evaluate whether they should. They optimise the wrong things. They gold-plate features that don't affect revenue. They resist pragmatic shortcuts that would serve the business better.
71%
of developers say they have little or no visibility into the business metrics their work affects
Source: Stack Overflow Developer Survey, 2020
This isn't the developers' fault. Nobody taught them. And most organisations don't share the financial context that would help them make better decisions. It's a two-sided failure: developers don't ask, and businesses don't tell.
What Unit Economics Means for Software Teams
Unit economics is the revenue and cost associated with a single unit of your business. For a SaaS product, it's the revenue per customer minus the cost to acquire and serve that customer. For a service business, it's the revenue per engagement minus the cost of delivery.
When developers understand unit economics, they make fundamentally different decisions.
Feature Prioritisation
A developer who knows that each new customer generates $200/month in revenue and costs $50/month to serve understands that features which reduce churn are worth more than features that reduce server costs by $10/month. Without that context, server cost reduction looks like a productive use of time.
Build vs Buy
A developer who understands that the company operates on 12% margins knows that a week of custom development costs the company roughly $5,000-8,000 in fully loaded salary. If an off-the-shelf tool costs $200/month and does 80% of what's needed, the maths favours buying. Without margin awareness, building always feels more valuable because it's more technically interesting.
Scope Decisions
"Should we build this edge case handler?" becomes a different question when you know that the edge case affects 2% of users who generate 0.5% of revenue. Without financial context, all edge cases feel equally important. With it, you can prioritise the ones that matter.
The best technical decision and the best business decision are often different. It makes the tension visible so you can navigate it deliberately instead of accidentally.
Isaac Rolfe
Managing Director
What We're Teaching
We're not running an MBA programme. We're adding financial context to the work we already do.
The Business Model Brief
Every new project starts with a one-page brief that covers: how the client makes money, what their margins look like, what this project is expected to contribute to revenue, and what the budget represents as a percentage of their annual technology spend. This takes an hour to prepare. It changes how the entire team thinks about the work.
Cost-Per-Feature Awareness
We've started tracking the approximate cost of each feature we build. Not to create pressure. To create awareness. When a developer sees that a feature they're building costs $4,000 in delivery time, they think about whether that feature will generate more than $4,000 in value. Not precisely. But directionally.
Revenue Impact Labels
In sprint planning, we've added a simple label to each story: revenue-generating, cost-reducing, risk-mitigating, or infrastructure. No story is unimportant. But the labels create a conversation about balance. A sprint full of infrastructure stories might be necessary, but the team should know that no revenue-generating work is moving forward that week.
The Resistance
Some developers push back on this. "I was hired to write code, not think about money." I understand the sentiment. And I think it's short-sighted.
Understanding the financial context of your work doesn't make you less of an engineer. It makes you a more effective one. The senior developers I admire most can explain a technical decision in terms a CFO would understand. They can advocate for refactoring work by explaining the cost of not doing it. They can push back on scope by showing the revenue impact of delay.
That dual fluency - technical and financial - is the difference between a good developer and a great enterprise developer.
Where This Goes
This is part of a broader framework we're developing. Health literacy was the first piece. Financial literacy is the second. Technology breadth - understanding the broader technology landscape beyond your specialism - will be the third.
The hypothesis is that teams with all three literacies make better decisions, communicate more effectively with stakeholders, and sustain their performance over longer periods. We'll share what we learn.