Speaking Software: Why We Need a New Language to Build—and Lead—with Code
The tactics of old don't work. They don't speak software. To win at software, we must learn to speak its language! We've tried it before, it had a huge impact. Now we need to do it again!
What if the real reason software projects fail isn’t bad code… but bad metaphors?
When five countries lose billions of euros and dollars building software—hospitals go offline, workers go unpaid, and public trust evaporates—it’s easy to call it a crisis. And it is.
It’s the second software crisis!
But it’s not just a crisis of engineering. It’s a crisis of imagination.
We’re still trying to manage software as if it were concrete and steel. As if it were things to plan, budget, and “get done.”
But building software isn’t a like building. It’s not a bridge. It’s a language creation process!
And when we use the wrong language to build and lead in software, we don’t just get inefficiency. We get disasters!
In this follow-up to “The Software Crisis Is Real”, I want to offer a new lens:
👉 What if software development is actually the creation of new languages to solve problems?
👉 What if our organizations need new language systems to support that work?
👉 And what if the very words we use—projects, budgets, estimates—are holding us back?
If that sounds like a shift you want to be part of, you’re in the right place.
🔒 This article is a follow-up to “The Software Crisis Is Real”, an earlier article I shared with my private list. Want to go deeper? Subscribe here to get the full article and future insights.
But now, let’s dive into “Speaking Software: Why We Need a New Language to Build—and Lead—with Code”.
Software Is a Language-Building Medium
Most people think of software as a set of features, or even as “just code.” But that’s like describing a language as “just grammar.” Software isn’t just a product. Software is a medium, and in that medium, we build languages.
Think about it: every time a team ships a new system, they’re inventing a way to talk to reality. We create words (functions), grammar rules (data models, APIs), and shared idioms (design patterns) to describe actions in a domain. In developer terms, we call these Domain Specific Languages—but the truth is, every piece of software is a custom dialect for solving a problem.
And like all languages, software evolves. It needs to.
As we build, we discover that some concepts are awkward, some metaphors don’t scale, and some words just don’t mean what we thought they did. So we refactor. We rename. We rewrite. Not because we got it “wrong,” but because we’re learning how to say things better. We’re incrementally building a new language!
This is why refactoring (in the small) and rearchitecting (in the large) are not signs of failure—they’re how we grow the language, any language. Even English, which I’m using to write this article has been evolving that way for centuries!
And this is also why software development cannot follow linear, deterministic processes like construction. You don’t “pour” software like concrete. You speak it, test it in the real world, and refine it through feedback.
⭐️⭐️⭐️⭐️ This post is sponsored by The Global Agile Summit, where you can find the most advanced ideas on Software, Product Development and Agile! Join The Global Agile Summit, the most forward looking Agile event of 2025
❌ Apotti: When the Language Excludes the Speakers
Let’s go back to Apotti, the €950 million healthcare system failure in Finland. One of the core issues? The system was designed without clinicians. In other words, the people who were supposed to speak this new software language weren’t consulted while it was being created.
What happened next was predictable:
Medication workflows became multi-click nightmares
Test results were lost in translation
Over 600 doctors petitioned to abandon the system altogether
This wasn’t just bad UX. It was a case of a language being invented in a vacuum. And that’s why it failed.
📣 The Real Lesson
If we accept that software is a living language, then the way we build it must change.
We must iterate—not to polish, but to clarify
We must involve users—not as testers, but as co-authors
We must deprecate old ideas—not as tech debt, but as linguistic evolution
This perspective leads us toward incremental, continuous development—not because it’s trendy, but because it’s linguistically necessary. You always evolve a language. It’s inevitable.
We Need a New Language to Talk About Organizations
If software is a language, then organizations are the systems that enable or constrain how that language gets spoken.
And yet, while we’ve developed rich ways to talk about software architecture (think Domain-Driven Design, design patterns, layered systems), our vocabulary for how teams build that software remains shockingly primitive.
Most companies still describe their software organization in the language of accounting:
“How many FTEs are on this?”
“Can we increase headcount?”
“What’s the budget line for that feature?”
This is the corporate equivalent of grunting. It tells you nothing about how work actually flows, where collaboration breaks down, or what the architecture is trying to achieve.
The Old Language: Cost Centers and Control
Let’s be blunt: treating software teams like interchangeable budget units leads to systems that collapse under their own weight.
We saw this clearly with Kmart’s $1.4 billion IT failure (Subscribe to my private newsletter to get the whole Kmart story). A huge tech modernization effort, planned and budgeted like a one-time capital project, ended up accelerating the company’s bankruptcy.
The real issue? No structural understanding of how the organization worked, or how it needed to evolve. Just money thrown at a broken system.
The result? A new system no one could use, and a strategy no one could execute.
We're still stuck with factory-era metaphors:
Headcount. Cost center. Utilization. Resource planning.
These words aren’t just outdated—they’re actively harmful.
They reduce creative, collaborative teams to line items on a budget. They flatten complex communication structures into hierarchies. And worst of all, they leave leaders with only two levers: add budget or remove budget. Translation? Add or remove people.
The New Language: Team Topologies and Flow
Compare that with Team Topologies—a modern approach that offers a language for how software teams relate, collaborate, and evolve over time. It introduces concepts like:
Stream-aligned teams (aligned to value flow)
Enabling teams (coaching and supporting others)
Team cognitive load (as a measurable factor)
Explicit interaction modes (collaboration, facilitation, service)
It’s not perfect, but it’s a start. It lets us ask better questions:
"Where is communication breaking down?"
"Are we overwhelming teams with competing concerns?"
"Do our team structures support the system we want to build?"
This is a huge leap forward from the “add 3 devs to the budget” approach.
Conway’s Law Is a Mirror
And here's the kicker: Conway’s Law tells us that every software system reflects the communication structures of the teams that built it. So if your organizational language is broken, your architecture will be too.
It’s not enough to model clean code—we have to model clean collaboration. And that starts with language.
The Path Forward
If we want to lead in software, we need new ways to talk about:
How work flows
How people interact
How strategy connects to execution
We need to replace our budget-first vocabulary with one that centers on value creation, adaptability, and coherence.
We’ve built languages to describe our code. Now it’s time to build languages to describe ourselves and our organizations!
Our Current Language Pushes Us Into Waterfall Thinking
Here’s a hard truth: most software organizations still operate in waterfall—even when they call themselves agile.
And it’s not because the teams don’t want to iterate. It’s because the language of planning, budgeting, and reporting traps them in a linear mindset.
Let’s break that down.
📊 Plan vs. Actuals: A False Binary
In most orgs, the structure looks like this:
Create a detailed plan.
Budget against that plan.
Execute to “stay on plan.”
Measure success as “plan vs actuals.”
Sounds logical, right? The problem is—it assumes you already know what’s valuable. In software, that’s rarely true.
Even if teams are using Scrum or Kanban somewhere in the “middle” of that process, the overall picture is the old “Water-Scrum-Fall”.
🚨 Disaster Warning: Phoenix and the Perils of Planning Too Hard
Take the Phoenix Pay System in Canada. The goal? Save money and modernize payroll. The approach? Lock in the plan, stick to the budget, and get it done.
The result?
A live system riddled with bugs
Over 400,000 unresolved payroll issues
$3.5 billion in costs and a public trust crisis
Why? Because they prioritized “delivering the plan” over validating the assumptions behind it. And because the “plan was approved”, there was no need to iterate, right? Wrong, and dangerous!
This is the trap: the moment you turn an idea into a fixed plan and a fixed budget, you lock yourself into the illusion of certainty. But software isn’t certain. It’s exploratory. It’s iterative. It’s full of human complexity. Because it must help humans in their complex world!
🔁 In Software: Experiment, Learn, Rinse, And Repeat
What makes software unique is also what makes it powerful: you can test ideas quickly, cheaply, and often. You can get feedback from real users, refine functionality, pivot directions.
So why do we still budget like we’re building a dam?
When we use the language of “promise results before we build,” we end up doing the opposite: we burn money proving that our untested assumptions were flawed. And then we burn more money, becuse we already started, so we might as well spend some more to get it done! (Sunk cost fallacy)
Instead, we need a shift:
From fixed projects to continuous validation
From rigid budgeting to investment: we invest, we assess, we reallocate–like investors
From “how much and when?” to “does it add value?” If so iterate, if not stop
⚛️ Historical Parallel: Newton vs. Quantum
This is like the shift from Newtonian physics (predictable, closed systems) to Quantum physics (probabilistic, open systems). Once we accepted that uncertainty was part of the fabric, we could stop pretending and start working with complexity.
Software is quantum. But our org charts, budgets, and boardroom presentations are still stuck in Newton.
It’s time we updated the language.
A New Language for Software Leadership
If the language we use defines what we can see, then it also defines what we can build.
Right now, most of our organizations are trapped in a dialect that was never meant for software–it was built before we knew what software was!
It’s the language of:
Projects
Yearly budgets
Long term estimates
Allocation of “resources” (most of the time they mean “people”, which is sad)
And what do all these words have in common?
They assume certainty.
They demand predictability.
They suppress learning.
They ignore complexity.
It’s time for a shift.
Here' are a few concepts for a new language of software development.
🛑 #NoProjects → #ContinuousValue
Projects are finite. They imply a beginning, middle, and end. But real value in software doesn’t show up in planning or “the delivery phase”. Value emerges after the system is used and reshaped in context.
Replace projects with outcomes. Align teams to goals, not Gantt charts. Focus on ongoing value creation, not temporary output.
But, how do we know how much it will cost, Vasco?
Great question! Read on!
💸 #NoBudgets → #InvestmentThinking
Budgets assume we know what’s worth funding. But in software, we often don’t—until we test. So let’s think like investors, not accountants.
Invest in hypotheses. Measure early signals. Reallocate based on traction. If it’s working, double down. If not, stop. The system learns and grows.
How about deadlines? Again, great question!
📏 #NoEstimates → #ValueSignals
“How much and when?” is the wrong question. The real question is: “Does this help us learn?” or “Does this move the needle?”
We don’t need estimates. We need feedback.
We don’t need detailed up-front planning. We need clarity on what to keep building—and what to stop.
We need true iterative and incremental software development.
And stop with the big mamoth projects already! They don’t work. Here’s another example:
🛠️ NPfIT: A Billion-Pound Case Study in the Wrong Language
The UK’s National Programme for IT failed in part because its entire approach was built on the old vocabulary: massive project, rigid plan, huge contracts.
No space for feedback. No way to adapt.
And no way to acknowledge that reality had changed.
This wasn’t just a failure of delivery. It was a failure of language and metaphor.
Here’s a much better apporach: pick a use case, start small, grow a working system! Forever. Including when needing to rearchitect something that is already in production.
We know how to do this! We just need to apply it!
🌱 This Is Just the Beginning
We are still learning how to lead software efforts. The practices are evolving. The theories are still being written. But one thing is clear:
The old language is holding us back.
And the new one? It’s already emerging—in our teams, our experiments, and our conversations.
Let’s nurture it. Let’s give it shape. Let’s speak it into being.
Want to be part of this shift?
We’re learning and building a deeper, ongoing dialogue around this movement. We are in the middle of a second software crisis, and we need to step up and present solutions!
At the Global Agile Summit, we are doing just that!
From #NoProjects and #NoContracts talks like Sven Ditz’ talk, to Martti Kuldma’s talk on how to re-architect a whole organization to go from slow and cumbersome, to nimble and adaptable product organization.
We are building a new language to talk about software-powered businesses! And you can be part of it!
See you in Tallinn! Let’s keep this movement going!
At the Global Agile Summit we create the space for you to meet likeminded individuals, and form a community of pragmatic innovators! Get inspired, take action!
Join us in Tallinn, and help define a better way to develop and deliver software
