What Would Software Development Look Like If We Started From Human Flourishing?
A positive vision for development organisations designed from first principles around attending to folks’ needs.
I’ve spent a lot of words on this blog describing what’s broken. The misaligned incentives, the learned helplessness, the quiet tragedy of talented people grinding through systems that treat them as fungible resources. If you’ve been reading along, you already know the critique.
Today I want to try something different.
I want to imagine — concretely, not abstractly — what a software development organisation would look like if we threw out every inherited assumption and started from a single foundational commitment: attend to folks’ needs.
Not as a slogan on a wall. Not as a line item in a manifesto. As the actual organising principle from which everything else follows.
The Starting Question Changes Everything
Most organisations begin with a question like: How do we deliver software efficiently? or How do we maximise output while controlling cost? These seem like reasonable questions. They’re not. They’re questions that have already smuggled in a set of assumptions about what matters, and those assumptions silently shape everything that follows — the structures, the roles, the metrics, the daily experience of every person involved.
What if we started instead with: What do the people involved in this work actually need — to thrive, to do meaningful work, to live well?
This isn’t soft. It’s radical. And the organisation it produces looks almost nothing like what we’re used to.
Whose Needs? Everyone’s.
The Antimatter Principle doesn’t play favourites. It asks us to attend to the needs of all the folks involved — not just customers, not just shareholders, not just developers, but every person whose life is touched by the work. That includes the person writing the code, the person waiting for the feature, the person answering the support call, the person who’ll maintain this system five years from now, and yes, the person funding the whole endeavour.
In practice, most organisations optimise for one constituency at the expense of others. They squeeze developers to delight customers. They squeeze customers to delight shareholders. They squeeze everyone to hit a date that somebody somewhere promised without consulting anyone who’d have to do the work.
An organisation founded on attending to folks’ needs refuses this zero-sum framing. Not because conflict disappears — it doesn’t — but because the conflicts are surfaced, named, and navigated honestly rather than buried under power dynamics and pretence.
What Changes in Practice
Let’s get concrete. Walk with me through what actually shifts.
How Work Enters the System
In most organisations, work arrives as a mandate. Someone with authority decides what gets built, packages it as a requirement or a ticket, and hands it to people whose job is to comply. The need behind the request — the real, human need — is often lost in translation, if it was ever articulated at all.
In our imagined organisation, work begins with needs. Someone has a need. Maybe it’s a customer who can’t accomplish something that matters to them. Maybe it’s a team member who sees a source of recurring pain. Maybe it’s a pattern emerging from support conversations. The need is expressed as a need, not as a premature solution. And the first act is not to estimate or prioritise but to understand — to ask, with genuine curiosity, what’s actually going on for the people involved.
This isn’t ‘requirements gathering’. Requirements gathering is an extraction process. This is something closer to dialogue — closer, in fact, to the spirit of Nonviolent Communication (Rosenberg, 2015), where the aim is to surface what’s really alive in people rather than to classify and judge. It changes the power dynamic entirely, because the people closest to the need are treated as the experts on that need — which, of course, they are.
How Teams Form and Organise
Most team structures are designed for managerial convenience — stable units that can be tracked, measured, and held accountable within a reporting hierarchy. People are assigned to teams. Teams are assigned to projects. The question of whether this arrangement serves anyone’s actual needs rarely comes up.
If we start from human flourishing, we notice that people have a need for autonomy, for mastery, for purpose, for belonging, for psychological safety. They have a need to work with people they trust on problems they find meaningful. They have a need to grow, and growth doesn’t happen on a schedule that aligns with annual review cycles.
So teams become more fluid. People gravitate towards work that connects to their sense of purpose and where their skills create the most value — for themselves and others. This isn’t chaos. It’s self-organisation around real need, and it requires more trust, more communication, and more maturity than a command-and-control structure. But it produces something a command-and-control structure never can: genuine engagement.
How Decisions Get Made
In a conventional organisation, decisions flow down. Strategy is set at the top, decomposed into plans, and cascaded as instructions. The people doing the work make the fewest decisions about the work. This arrangement persists not because it’s effective — it’s demonstrably not — but because it satisfies the needs of the people at the top for control and predictability. Their needs are attended to. Everyone else’s are not.
An organisation grounded in attending to folks’ needs distributes decision-making to where the relevant knowledge lives. Not because decentralisation is ideologically appealing, but because it attends to more people’s needs simultaneously. The developer who understands the technical trade-offs, the support person who hears the customer’s frustration daily, the designer who’s observed the user struggling — all of these people have knowledge that’s essential to a good decision. Excluding them isn’t just inefficient. It’s a failure to attend to their need to contribute meaningfully.
This doesn’t eliminate leadership. It redefines it. Leaders in this world are not decision-makers but need-discoverers — people whose primary skill is sensing what’s needed across the whole system and helping the right conversations happen.
How Quality Is Understood
In most organisations, quality is defined as conformance to specification, or as the absence of defects, or — in more sophisticated shops — as fitness for purpose. All of these framings treat quality as a property of the product.
If we start from human flourishing, quality becomes a property of the relationship between the product and the people it touches. Does this software help someone do something that matters to them? Does using it feel respectful of their time and intelligence? Does building it feel like craft rather than compliance? Does maintaining it feel manageable rather than dread-inducing?
Quality, understood this way, can’t be tested in at the end. It can’t be enforced by a separate QA department. It emerges from a development process in which the people doing the work are themselves flourishing — because people who are stressed, disengaged, and treated as interchangeable parts do not produce things that feel cared-for. They can’t. The care isn’t there to transmit.
How Success Is Measured
Here’s where it gets genuinely uncomfortable for most organisations, because the metrics we’re accustomed to — velocity, throughput, cycle time, story points, lines of code, uptime, revenue per employee — all measure the machine. They tell you how the system is performing as a production apparatus. They tell you nothing about whether anyone involved is flourishing.
An organisation built on attending to folks’ needs would ask different questions. Are the people doing this work learning and growing? Are customers’ lives meaningfully better? Are we building trust or eroding it? Are people choosing to stay because they want to, or staying because they’re afraid to leave? Is the work sustainable — not just this sprint, but this year, this decade?
Some of these things can be measured. Most of them can only be sensed — through honest conversation, through the quality of relationships, through the presence or absence of joy in the work. An organisation that can’t tolerate this ambiguity, that demands everything be reduced to a number on a dashboard, has already revealed which needs it’s prepared to ignore.
The Objection You’re Already Forming
‘This sounds lovely, but it wouldn’t survive contact with economic reality.’
I hear you. And I’d push back — gently — on two fronts.
First, attending to folks’ needs includes attending to the need for the organisation to be economically viable. No one’s needs are served by an organisation that goes bankrupt. Financial sustainability isn’t opposed to human flourishing; it’s a precondition for it. The question isn’t whether the organisation needs to generate revenue and manage costs. Of course it does. The question is whether financial performance is the purpose or a constraint — whether people exist to serve the numbers, or the numbers exist to serve the people.
Second, there’s mounting evidence — from the research on psychological safety (Edmondson, 2019), on intrinsic motivation (Pink, 2009), on the economics of flow (Csikszentmihalyi, 1990/2008), on the cost of turnover and disengagement (DeMarco & Lister, 2013) — that organisations which attend to human needs outperform those that don’t. Not despite the attention to flourishing, but because of it. People who are well do good work. This shouldn’t be surprising, but apparently it is.
Why This Matters Now
We’re at an interesting inflection point. The tools available to software developers are more powerful than ever. AI is reshaping what’s possible. Remote work has rewritten the geography of collaboration. And yet — or perhaps because of all this — the human experience of building software remains, for many people, somewhere between unfulfilling and actively harmful.
The response from most of the industry is to double down on what’s familiar: more process, more measurement, more frameworks, more management, more control dressed up as empowerment. SAFe. OKRs. Spotify models without Spotify’s culture. The names change. The underlying collective assumptions and beliefs don’t.
What I’m describing here isn’t another framework. It’s a foundation. A single principle — attend to folks’ needs — from which appropriate practices, structures, and norms can emerge, shaped by the specific people in the specific context. It won’t look the same in every organisation, and that’s the point. It can’t be a framework because frameworks are, by definition, imposed from outside, and imposition is itself a failure to attend to needs.
An Invitation
If you’ve made it this far, you’re probably someone who’s felt the gap between how software development could feel and how it does feel. You may have had glimpses — a team that clicked, a project where the work felt alive, a moment when building something actually felt like building something.
Those glimpses aren’t anomalies. They’re signals. They’re what happens when, even accidentally, an environment arises that attends to the needs of the people within it.
The question I’d leave you with is this: What would it take to make that the rule rather than the exception? Not in theory. In your context, with your people, starting tomorrow.
I don’t pretend to have the full answer. But I’ve seen that it starts with asking a better question than ‘how do we deliver software efficiently?’ It starts with asking what people need — and then taking the answer seriously.
I’d love to hear what resonates — and what doesn’t. What needs of yours aren’t being attended to in your current organisation? What would change first if they were? The comments are open, and as always, I’m happy to let your questions shape where this conversation goes next.
Further Reading
Csikszentmihalyi, M. (2008). Flow: The psychology of optimal experience. Harper Perennial Modern Classics. (Original work published 1990)
DeMarco, T., & Lister, T. (2013). Peopleware: Productive projects and teams (3rd ed.). Addison-Wesley Professional.
Edmondson, A. C. (2019). The fearless organization: Creating psychological safety in the workplace for learning, innovation, and growth. John Wiley & Sons.
Marshall, R. W. (2019). Hearts over diamonds: Serving business and society through organisational psychotherapy. Falling Blossoms.
Marshall, R. W. (2021a). Memeology: Surfacing and reflecting on the organisation’s collective assumptions and beliefs. Falling Blossoms.
Marshall, R. W. (2021b). Quintessence: An acme for highly effective software development organisations. Falling Blossoms.
Pink, D. H. (2009). Drive: The surprising truth about what motivates us. Riverhead Books.
Rosenberg, M. B. (2015). Nonviolent communication: A language of life (3rd ed.). PuddleDancer Press.
Sheridan, R. (2013). Joy, Inc.: How we built a workplace people love. Portfolio/Penguin.

