Last month a developer on our team asked why we couldn't just rebuild a client's entire authentication system "properly." The existing system worked. It had some technical debt. It wasn't pretty. But the client's budget was committed to features that would generate revenue, not an auth rewrite that users would never see. The developer's instinct was technically correct and financially wrong. They didn't have the context to know the difference.
What You Need to Know
- Financial literacy for tech teams isn't about accounting. It's about understanding how technical decisions affect business outcomes.
- Developers who understand revenue models, margins, and budgets make better trade-off decisions
- This is the second of three literacies (health, financial, tech) we're building as a team capability
- The gap between technical quality and business value is the most common source of tension in enterprise delivery
The Literacy Gap
Most developers understand technology deeply and business shallowly. This isn't a criticism. It's a training gap. Computer science degrees don't teach revenue models. Bootcamps don't cover gross margins. The industry trains people to write excellent code and then puts them in environments where code is only valuable in relation to business outcomes they don't fully understand.
The result is predictable. Developers optimise for technical quality. Business stakeholders optimise for commercial outcomes. The two groups talk past each other, not because they disagree, but because they're using different definitions of "good."
64%
of software developers say they rarely or never have visibility into the business impact of their work
Source: Stack Overflow Developer Survey, 2020
What Your Team Needs to Know
How the Business Makes Money
This sounds basic. It is basic. And most developers can't explain it clearly. Not the high-level "we sell software." The specific model. Is it subscription revenue? Project-based billing? Licensing? Per-user pricing?
When a developer understands that the client's revenue comes from per-transaction fees, they think differently about performance optimisation. When they know the business model depends on user retention, they think differently about UX quality. The technical decisions don't change. The reasoning behind them does.
What a Margin Is
Revenue minus cost. That's it. But the implications are significant.
If a client is operating on 8% margins, a cost overrun on a software project isn't an inconvenience. It's an existential threat. If they're operating on 40% margins, the same overrun is absorbable. Knowing which world your client lives in changes how you scope, estimate, and communicate risk.
How Budgets Work
Enterprise budgets are allocated annually. They're divided between capital expenditure (building things) and operational expenditure (running things). They're approved by people who have competing demands for the same pool of money.
Every hour we spend on work the client didn't ask for is an hour they're paying for that they can't spend on something else. It's about respecting that the money isn't ours.
Isaac Rolfe
Managing Director
When a developer understands that the project budget came from a finite pool, competed for by other departments, approved after months of internal advocacy, they treat that budget differently. Not with fear. With respect.
The Time Value of Software
Software that ships in March and generates revenue for ten months is worth more than the same software shipped in September that generates revenue for four months. This seems obvious. In practice, teams routinely delay releases for polish that doesn't affect revenue.
The calculation isn't always "ship faster." Sometimes quality directly affects revenue. But the trade-off should be explicit and informed, not accidental.
How We Teach It
We're not running a finance course. We're integrating financial context into the work we already do.
Sprint planning includes business context. When we prioritise features, we explain why in business terms. "This feature unlocks the next billing tier for the client" is more informative than "this is high priority."
Budget visibility. Every team member can see where the project budget stands. Not to create pressure. To create awareness. When someone sees we've used 70% of the budget and delivered 60% of the scope, they make different decisions than when they're working in a vacuum.
Client P&L basics. For major clients, we share a simplified view of their business model. What they sell, how they price it, where the pressure points are. This context transforms how the team thinks about trade-offs.
Estimation feedback loops. When we estimate a feature at forty hours and it takes sixty, we don't just note the overrun. We discuss the business impact. What else could those twenty hours have produced? What's the cost of the delay?
The Uncomfortable Truth
Some developers don't want financial literacy. They want to write code. The business stuff is someone else's problem. I respect that preference and I disagree with it.
In enterprise delivery, every technical decision has a financial consequence. Ignoring that doesn't make it less true. It just means someone else is managing the consequence without the technical understanding to do it well.
The best enterprise developers I've worked with understand both sides. They can explain why a refactor is worth the investment in terms a CFO would accept. They can also explain why a shortcut that saves budget now will cost more later. That dual fluency is rare. We're trying to make it less rare.
Next: technology literacy. The third piece of the framework, coming later this year.