Listen. Build. Iterate.
What if it really is that simple?
Attend closely. Build carefully. Adjust relentlessly.
There’s a particular smell to overcomplicated software. A mix of burnt coffee, stale Post-its, and fear. You’ll find it lingering in rooms where the walls are plastered with frameworks nobody believes in anymore, where dashboards glow like slot machines, and where everyone is busy explaining why nothing is actually their fault.
This is the part of the industry that loves to talk. Talk about strategy. Talk about alignment. Talk about transformation.
A lot of… talk. Endless, looping talk—performed with the confidence of people who haven’t listened to anything real in months.
And then, sometimes, usually off to the side, there’s a small group doing something unfashionable. They’re not loud. They’re not evangelising. They’re not renaming their backlog after Greek gods. They’re just… listening. To users. To systems. To the friction in their own hands when something feels wrong. And then they build something small. They build it properly. They ship it. They watch. They adjust.
No drama. No manifesto. No theatre.
Which raises the dangerous question nobody gets paid to ask:
What if that’s all that’s really needed?
Is it possible that most of what we call “process” exists to compensate for our refusal to listen. We stop listening to users, so we invent personas. We stop listening to systems, so we invent KPIs. Each layer adds distance, abstraction, and plausible deniability. Nobody hears the scream when the thing doesn’t fit reality anymore.
Listening, in real software teams, is not soft. It’s brutal. It means accepting that the user doesn’t care about your roadmap. That production doesn’t respect your architecture diagrams. That the code remembers every lie you told yourself while writing it. As Kent Beck once implied with infuriating calm: the system is always telling you the truth, you just have to be willing to hear it.
Iteration is what happens when you admit you don’t know yet—but you’re willing to find out. It’s not speed for the sake of speed. It’s a refusal to pretend certainty. You place a small bet. You observe the outcome. You adjust. You do not defend the idea like it’s your honour at dawn. You let reality do the real talking.
And quality—real quality, not brochure quality—is what makes this loop survivable. Sloppy systems punish curiosity. They make every change expensive, every experiment dangerous, every lesson humiliating. High-quality systems do the opposite. They invite change. They bend without shattering. They allow learning to stay cheap.
This is why the best teams look boring from the outside. They don’t announce revolutions. They don’t “roll out” culture. They listen. They build. They refine. Over and over again. Quietly accumulating value.
If you strip away the slogans, the certifications, and the comforting myths, software at its healthiest resembles a craftsman’s bench, not a war room. Tools within reach. Feedback immediate. Mistakes visible. Improvement continuous.
The scandal is not that this approach is radical. It is that it’s old, obvious, and still ignored.
Which brings us back to the heresy:
What if listening carefully, building something small and good, and iterating honestly is not a naïve simplification—but the last discipline standing when everything else collapses?
Software fails less often from a lack of intelligence than from a lack of attention. Long feedback loops allow false beliefs to survive. Listening shortens the loop. Iteration tests belief against reality. Quality keeps the cost of learning low.
This is empiricism without the lab coat—working software as evidence, whether the organisation is comfortable with it or not.
Some practices to consider
Ship the smallest thing that can speak back to you
Treat user confusion as data, not failure
Refactor continuously so tomorrow’s change is cheap
Observe production like a living system, not a report
Prefer reversible decisions over perfect ones
Some things to avoid
Confusing listening with polling
Mistaking speed for haste
Letting quality erode “temporarily”
Defending ideas instead of testing them
Adding process to avoid uncomfortable truths
A helpful checklist
Are we hearing real users weekly?
Can we change this safely tomorrow?
Do we trust what production is telling us?
Is learning getting cheaper—or more expensive?
Are we listening… or explaining?
Complexity will always offer to save you—from humility, from uncertainty, from paying attention. This entry is a reminder that you don’t have to accept the offer.
Listen.
Build something real.
Let it answer back.
Have fun x