Over the past nine months, we've been running what started as an informal experiment and has become a deliberate programme. We're teaching our team three things that aren't in any computer science curriculum: how their health affects their work, how money flows through the businesses they serve, and how technology beyond their specialism shapes the decisions they're asked to make. We're calling it the Three Literacies. It's the most important non-technical investment we've made.
What You Need to Know
- The Three Literacies framework combines health literacy, financial literacy, and tech literacy into a unified professional development model
- Each literacy addresses a specific blind spot that causes real problems in enterprise delivery
- The framework isn't about expertise. It's about enough understanding to make informed decisions and communicate effectively
- Teams with all three literacies make measurably better trade-off decisions
Why Three
Technology professionals are deeply skilled in their domain. That's a given. But they operate in a context that requires understanding beyond their specialism.
They work in bodies that need maintenance. They build software that exists within commercial realities. They make technical decisions that intersect with technologies they don't specialise in. Gaps in any of these areas produce decisions that are technically correct but contextually wrong.
We've written about health literacy and financial literacy as individual concepts. This post is about why they compound - and what happens when you develop all three deliberately.
The Three Literacies
Health Literacy
Not medical knowledge. Practical understanding of the inputs that affect daily performance: sleep, movement, stress recognition, recovery.
The developer who understands that their afternoon focus problems are a circadian rhythm, not a character flaw, changes their work schedule. They do creative work in the morning and mechanical work after lunch. Output improves without willpower or effort. Just knowledge applied.
We've seen measurable improvements in sustained focus and reduced sick days since we started sharing basic health science with the team. It's not dramatic. But it's consistent.
Financial Literacy
Not accounting. Understanding of how technical decisions affect business outcomes: revenue models, margins, budgets, unit economics.
The developer who understands that the client operates on 8% margins treats budget overruns differently from one who doesn't know what a margin is. They're not anxious about money. They're informed about context. That context improves every scope and priority decision they make.
64%
of software developers have little or no visibility into the business impact of their work
Source: Stack Overflow Developer Survey, 2020
Tech Literacy (Beyond Specialism)
This is the one we're still developing. A frontend developer who understands enough about database design to make informed decisions about data fetching. A backend developer who understands enough about UX to recognise when an API design creates a bad user experience. Not cross-training to the point of competence. Cross-training to the point of informed conversation.
The gap here is subtle but persistent. Specialists who can only discuss their specialism create communication bottlenecks. Every cross-cutting decision requires a meeting because nobody has enough breadth to identify the trade-offs without assembling the experts.
How They Compound
The power isn't in any single literacy. It's in the combination.
A developer with health literacy and financial literacy looks at a crunch-time request differently. They understand the business pressure (the client's quarter-end deadline is real). They also understand the human cost (two weeks of overtime will reduce the team's cognitive performance for the following month). They can articulate the trade-off in terms the client understands, rather than simply saying "the team is tired."
A developer with financial literacy and tech literacy evaluates a build-vs-buy decision differently. They know the cost of internal development. They know the capabilities of the external tool. They can compare them in business terms rather than defaulting to "let's build it" because building is more interesting.
Each literacy on its own is useful. We're trying to make it less rare.
Isaac Rolfe
Managing Director
What We've Done
Monthly Sessions
One hour per month dedicated to each literacy. We rotate topics. Recent sessions covered: sleep architecture and its effect on decision-making (health), how SaaS unit economics work (financial), and an introduction to infrastructure-as-code for non-infrastructure developers (tech).
The sessions are practical, not theoretical. Each one ends with something the team can apply immediately. "Try consistent sleep timing for two weeks." "Ask the client about their revenue model in the next meeting." "Review the deployment pipeline and ask questions about anything you don't understand."
Integration into Work
The literacies aren't separate from delivery work. They're embedded in it. Sprint planning now includes business context (financial). Retrospectives now include a wellbeing check (health). Architecture discussions now include perspectives from all disciplines present (tech breadth).
Measurement
We track three things quarterly:
- Self-reported wellbeing (1-10 scale, anonymous). Trending upward since we started.
- Client communication quality (client feedback on stakeholder interactions). Improved, particularly around scope and priority discussions.
- Cross-discipline contribution (how often team members contribute meaningfully to discussions outside their specialism). Increasing gradually.
None of these are scientific. But the directional trend is consistent across all three.
What's Next
The framework is still evolving. We're publishing it not because it's complete, but because it's working and other teams might benefit from the approach.
The biggest lesson so far: professional development that focuses exclusively on technical skills misses the majority of what makes someone effective in enterprise delivery. The code is the easy part. The context around the code is where most value is created or destroyed.
We'll write more about tech literacy - the third leg of the model - later this year. For now, the message is simple: invest in the whole professional, not just the programmer.