Archive

Needs

Your Software Requirements Are Worthless

Every day, software teams burn millions of pounds building the wrong thing because they mistake fuzzy feelings and opinioneering for engineering specifications

Software teams continue writing requirements like ‘user-friendly’, ‘scalable’, and ‘high-performance’ as if these phrases mean anything concrete.

They don’t.

What they represent is ignorance (of quantification) disguised as intellectual laziness disguised as collaboration. When a product manager says an interface should be ‘intuitive’ and a developer nods in agreement, no communication has actually occurred. Both parties have simply agreed to postpone the hard work of thinking and talking until later—usually until users complain or products break.

The solution isn’t better communication workshops or more stakeholder alignment meetings. It’s operational definitions—the rigorous practice of quantifying every requirement so precisely that a computer could verify compliance.

What Are Operational Definitions?

An operational definition specifies exactly how to measure, observe, or identify something in terms that are meaningful to the Folks That Matter™. Instead of abstract concepts or assumptions, operational definitions state the precise criteria, procedures, or observable behaviours that determine whether something meets a standard—and why that standard creates value for those Folks That Matter™.

The term originates from scientific research, where researchers must ensure their experiments are replicable. Instead of saying a drug ‘improves patient outcomes’, researchers operationally define improvement as ‘a 15% reduction in Hamilton Depression Rating Scale scores measured by trained clinicians using the 17-item version at 6-week intervals, compared to baseline scores taken within 72 hours of treatment initiation, with measurements conducted between 9-11 AM in controlled clinical environments at 21°C ±2°C, amongst patients aged 18-65 with major depressive disorder diagnosed per DSM-5 criteria, excluding those with concurrent substance abuse or psychotic features’.

This example only scratches the surface—a complete operational definition would specify dozens more variables including exact clinician training protocols, inter-rater reliability requirements, patient positioning, statistical procedures, and missing data handling. This precision is what makes scientific breakthroughs reproducible and medical treatments safe.

The Software Development Challenge

Software teams constantly wrestle with ambiguous terms that everyone assumes they understand:

  • ‘This feature should be fast’
  • ‘The user interface needs to be intuitive’
  • ‘We need better code quality’
  • ‘This bug is critical’

These statements appear clear in conversation, but they’re loaded with subjective interpretations. What’s ‘fast’ to a backend engineer may be unacceptably slow to a mobile developer. ‘Intuitive’ means different things to designers, product managers, and end users.

Worse: these fuzzy requirements hide the real question—what specificaly do the Folks That Matter™ actually need?

How Operational Definitions Transform Software Teams

1. Connect Features to the Needs of the Folks That Matter™

Consider replacing ‘the API should be fast’ with an operational definition: ‘API responses return within 200ms for 95% of requests under normal load conditions, as measured by our monitoring system, enabling customer support agents to resolve inquiries 40% faster and increasing customer satisfaction scores by 15 points as measured on <date>.’

This eliminates guesswork, creates shared understanding across disciplines, and directly links technical decisions to the needs of the Folks That Matter™.

2. Turn Subjective Debates Into Objective Decisions

Operational definitions end pointless arguments about code quality. Stop debating whether code is ‘maintainable’. Define maintainability operationally:

  • Code coverage above 80% to reduce debugging time by 50%
  • Cyclomatic complexity below 10 per function to enable new team members to contribute within 2 weeks
  • No functions exceeding 50 lines to support 90% of feature requests completed within single sprint
  • All public APIs documented with examples to achieve zero external developer support tickets for basic integration

Each criterion ties directly to measurable benefits for the Folks That Matter™.

3. Accelerate Decision Making

With operationally defined acceptance criteria, teams spend less time in meetings clarifying requirements and more time attending to folks’ needs. Developers know exactly what ‘done’ looks like, and the Folks That Matter™ verify completion through measurable outcomes.

4. Bridge Cross-Functional Disciplines

Different roles think in different terms. Operational definitions create a common vocabulary focused on the needs of the Folks That Matter™:

  • Product: Transform ‘User-friendly’ into ‘Users complete the checkout flow within 3 steps, with less than 2% abandonment at each step, increasing conversion rates by 12% and generating £2M additional annual revenue
  • Design: Transform ‘Accessible’ into ‘Meets WCAG 2.1 AA standards as verified by automated testing and manual review, enabling compliance with federal accessibility requirements and expanding addressable market by 15%
  • Engineering: Transform ‘Scalable’ into ‘Handles 10x current load with response times under 500ms, supporting planned user growth without additional infrastructure investment for 18 months

5. Evolutionary Improvement

Operational definitions evolve as the needs of the Folks That Matter™ become clearer. Start with basic measurements, then refine scales of measure as you learn what truly drives value. A ‘fast’ system might initially mean ‘under 1 second response time’ but evolve into sophisticated performance profiles that optimise for different user contexts and business scenarios.

Real-World Implementation: Javelin’s QQO Framework

Some teams have already embraced this precision. Falling Blossoms’ Javelin process demonstrates operational definitions in practice through Quantified Quality Objectives (QQOs)—a systematic approach to transforming vague non-functional requirements into quasi or actual operational definitions.

Instead of accepting requirements like ‘the system should be reliable’ or ‘performance must be acceptable’, Javelin teams create detailed QQO matrices where every quality attribute gets operationally defined with:

  • Metric: Exact measurement method and scale
  • Current: Baseline performance (if known)
  • Best: Ideal target level
  • Worst: Minimum acceptable threshold
  • Planned: Realistic target for this release
  • Actual: Measured results for actively monitored QQOs
  • Milestone sequence: Numeric targets at specific dates/times throughout development

A Javelin team might operationally define ‘reliable’ as: ‘System availability measured monthly via automated uptime monitoring: 99.5% by March 1st (MVP launch), 99.7% by June 1st (full feature release), 99.9% by December 1st (enterprise rollout), with worst acceptable level never below 99.0% during any measurement period.’

This transforms the entire conversation. Instead of debating what ‘reliable enough’ means, teams focus on achievable targets, measurement infrastructure, and clear success criteria. QQO matrices grow organically as development progresses, following just-in-time elaboration of folks’ needs. Teams don’t over-specify requirements months in advance; they operationally define quality attributes exactly as needed for immediately upcoming development cycles.

This just-in-time approach prevents requirements from going stale whilst maintaining precision where it matters. A team might start with less than a dozen operationally defined QQOs for an MVP, then expand to hundreds as they approach production deployment and beyond—each new QQO addressing specific quality concerns as they become relevant to actual development work.

Toyota’s Product Development System (TPDS) demonstrates similar precision in manufacturing contexts through Set Based Concurrent Engineering (SBCE). Rather than committing to single design solutions early, Toyota teams define operational criteria for acceptable solutions—precise constraints for cost, performance, manufacturability, and quality. They then systematically eliminate design alternatives, at scheduled decision points, that fail to meet these quantified thresholds, converging on optimal solutions through measured criteria rather than subjective judgement.

Both Javelin’s QQOs and Toyota’s SBCE prove that operational definitions work at scale across industries—turning fuzzy requirements into systematic, measurable decision-making frameworks that deliver value to the Folks That Matter™.

Practical Examples in Software Development

User Story Acceptance Criteria

Before: ‘As a user, I want the search to be fast so I can find results quickly.’

After: ‘As a user, when I enter a search query, I should see results within 1 second for 95% of searches, with a loading indicator appearing within 100ms of pressing enter.’

Bug Priority Classification

Before: ‘This is a critical bug.’

After: ‘Priority 1 (Critical): Bug prevents core user workflow completion OR affects >50% of active users OR causes data loss OR creates security vulnerability.’

Code Review Standards

Before: ‘Code should be clean and well-documented.’

After: Operationally defined code quality standards with measurable criteria:

Documentation Requirements:

  • 100% of public APIs include docstrings with purpose, parameters, return values, exceptions, and working usage examples
  • Complex business logic (cyclomatic complexity >5) requires inline comments explaining the ‘why’, not the ‘what’
  • All configuration parameters documented with valid ranges, default values, and business impact of changes
  • Value to the Folks That Matter™: Reduces onboarding time for new developers from 4 weeks to 1.5 weeks, cuts external API integration support tickets by 80%

Code Structure Metrics:

  • Functions limited to 25 lines maximum (excluding docstrings and whitespace)
  • Cyclomatic complexity below 8 per function as measured by static analysis tools
  • Maximum nesting depth of 3 levels in any code block
  • No duplicate code blocks exceeding 6 lines (DRY principle enforced via automated detection)
  • Value to the Folks That Matter™: Reduces bug fix time by 60%, enables 95% of feature requests completed within single sprint

Naming and Clarity:

  • Variable names must be pronounceable and searchable (no abbreviations except industry-standard: id, url, http)
  • Boolean variables/functions use positive phrasing (isValid not isNotInvalid)
  • Class/function names describe behaviour, not implementation (PaymentProcessor not StripeHandler)
  • Value to the Folks That Matter™: Reduces code review time by 40%, decreases bug report resolution from 3 days to 8 hours average

Security and Reliability:

  • Zero hardcoded secrets, credentials, or environment-specific values in source code
  • All user inputs validated with explicit type checking and range validation
  • Error handling covers all failure modes with logging at appropriate levels
  • All database queries use parameterised statements (zero string concatenation)
  • Value to the Folks That Matter™: Eliminates 90% of security vulnerabilities, reduces production incidents by 75%

Testing Integration:

  • Every new function includes unit tests with >90% branch coverage
  • Integration points include contract tests verifying interface expectations
  • Performance-critical paths include benchmark tests with acceptable thresholds defined
  • Value to the Folks That Matter™: Reduces regression bugs by 85%, enables confident daily deployments

Review Process Metrics:

  • Code reviews completed within 4 business hours of submission
  • Maximum 2 review cycles before merge (initial review + addressing feedback)
  • Review comments focus on maintainability, security, and business logic—not style preferences
  • Value to the Folks That Matter™: Maintains development velocity whilst ensuring quality, reduces feature delivery time by 25%

Performance Requirements

Before: ‘The dashboard should load quickly.’

After: ‘Dashboard displays initial data within 2 seconds on 3G connection, with progressive loading of additional widgets completing within 5 seconds total.’

The Competitive Advantage

Teams that master operational definitions gain significant competitive advantages:

  • Faster delivery cycles from reduced requirement clarification—deploy features 30-50% faster than competitors
  • Higher quality output through measurable standards—reduce post-release defects by 60-80%
  • Improved confidence from the Folks That Matter™ from predictable, verifiable results—increase project approval rates and budget allocations
  • Reduced technical debt through well-defined standards—cut maintenance costs whilst enabling rapid feature development
  • Better team morale from decreased frustration and conflict—retain top talent and attract better candidates

Most importantly: organisations that operationally define their quality criteria can systematically out-deliver competitors who rely on subjective judgement.

Start Today

Choose one ambiguous term your team uses frequently and spend 30 minutes defining it operationally. Ask yourselves:

  1. What value does this QQO deliver to the Folks That Matter™?
  2. What specific, observable criteria determine if this value is achieved?
  3. What scale of measure will we use—percentage, time, count, ratio?
  4. How will we measure this, and how often?
  5. What does ‘good enough’ look like vs. ‘exceptional’ for the Folks That Matter™?

Aim for precision that drives satisfaction of folks’ needs, not perfection. Even rough operational definitions linked to the needs of the Folks That Matter™ provide more clarity than polished ambiguity.

Implementation Strategy

Start Small and Build Consensus

Begin by operationally defining one or two concepts that cause the most confusion in your team. Start with:

  • Definition of ‘done’ for user stories linked to specific value for the Folks That Matter™
  • Bug severity levels tied to business impact measures
  • Performance benchmarks connected to user experience goals
  • Code standards that enable measurable delivery improvements

Define Scales of Measure

Write operational definitions that specify not just the criteria, but the scale of measure—the unit and method of measurement. Include:

  • Measurement method: How you will measure (automated monitoring, user testing, code analysis)
  • Scale definition: Units of measure (response time in milliseconds, satisfaction score 1-10, defect rate per thousand lines)
  • Measurement infrastructure: Tools, systems, and processes needed
  • Frequency: How often measurements occur and when they’re reviewed
  • Connection to the Folks That Matter™: What business need each measurement serves

Evolve Based on Learning

Operational definitions evolve as you learn what truly drives meeting the needs of the Folks That Matter™. Start with basic measurements, then refine scales as you discover which metrics actually predict success. Regular retrospectives can examine not just whether definitions were met, but whether they satisfied the intended needs of the Folks That Matter™.

Document and Automate

Store operational definitions in accessible locations—team wikis, README files, or project documentation. Automate verification through CI/CD pipelines, monitoring dashboards, and testing frameworks wherever possible. The goal is measurement infrastructure that runs automatically and surfaces insights relevant to the needs of the Folks That Matter™.

Conclusion

Operational definitions represent a paradigm shift from ‘we all know what we mean’ to ‘we are crystal clear about what value we’re delivering to the Folks That Matter™’. In software development, where precision enables competitive advantage and the satisfaction of the needs of the Folks That Matter™ determines success, this shift separates organisations that struggle with scope creep and miscommunication from those that systematically out-deliver their competition.

Creating operational definitions pays dividends in reduced rework, faster delivery, happier teams, and measurable value for the Folks That Matter™. Most importantly, it transforms software development from a guessing game into a needs-meeting discipline—exactly what markets demand as digital transformation accelerates and user expectations rise.

Operational definitions aren’t just about better requirements. They’re about systematic competitive advantage through measurable satisfaction of the needs of the Folks That Matter™.

Take action: Pick one fuzzy requirement from your current sprint. Define it operationally in terms of specific needs of the Folks That Matter™. Watch how this precision changes every conversation your team has about priorities, trade-offs, and success.

Further Reading

American Psychiatric Association. (2013). Diagnostic and statistical manual of mental disorders (5th ed.). American Psychiatric Publishing.

Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley.

Cockburn, A. (2004). Crystal clear: A human-powered methodology for small teams. Addison-Wesley.

DeMarco, T. (1982). Controlling software projects: Management, measurement, and estimation. Yourdon Press.

DeMarco, T., & Lister, T. (2013). Peopleware: Productive projects and teams (3rd ed.). Addison-Wesley.

Falling Blossoms. (2006). Our Javelin™ process (Version 2.0a). Falling Blossoms.

Gilb, T. (1988). Principles of software engineering management. Addison-Wesley.

Gilb, T. (2005). Competitive engineering: A handbook for systems engineering management using Planguage. Butterworth-Heinemann.

Gilb, T., & Graham, D. (1993). Software inspection. Addison-Wesley.

Hamilton, M. (1960). A rating scale for depression. Journal of Neurology, Neurosurgery, and Psychiatry, 23(1), 56-62.

Kennedy, M. N., & Harmon, K. (2008). Ready, set, dominate: Implement Toyota’s set-based learning for developing products and nobody can catch you. Oaklea Press.

Morgan, J. M., & Liker, J. K. (2006). The Toyota product development system: Integrating people, process, and technology. Productivity Press.

Sobel, A. E., & Clarkson, M. R. (2002). Formal methods application: An empirical tale of software system development. IEEE Transactions on Software Engineering, 28(3), 308-320.

W3C Web Accessibility Initiative. (2018). Web content accessibility guidelines (WCAG) 2.1. World Wide Web Consortium.

Ward, A. C. (2007). Lean product and process development. Lean Enterprise Institute.

Weinberg, G. M. (1985). The secrets of consulting: A guide to giving and getting advice successfully. Dorset House.

Yourdon, E. (1997). Death march: The complete software developer’s guide to surviving ‘mission impossible’ projects. Prentice Hall.

Ready – Book Review

Ready: Why Most Software Projects Fail and How to Fix It by Luniel de Beer and Max Guernsey, III

Image

A Tale of Two Ambitions

‘Ready’ presents itself as a solution to software project delivery struggles, and it delivers precisely that—masterful process engineering that may however be optimising the wrong thing.

The authors’ central thesis—that premature implementation causes most software development waste—leads to Requirements Maturation Flow (RMF), a three-part framework creating explicit gates around implementation readiness. Think Design by Contract for work items rather than code methods: preconditions (Definition of Ready), postconditions (Definition of Done), and invariants (responsibility rules).

What RMF Actually Delivers

The book’s opening case study at ‘The Bank’ is compelling: teams transforming from delivering nothing to shipping working software after adopting systematic readiness practices. The detailed progression from chaos to flow is vividly illustrated with workflow diagrams and specific examples.

RMF creates mechanisms for:

  • Explicit collaboration before implementation starts
  • Documented shared understanding via bespoke Definitions of Done and Ready
  • Workflow gates that prevent premature starts and closures
  • Visible tracking of readiness work
  • Contract-like responsibility transfers between Product and Engineering

The practical guidance is outstanding—detailed templates, adoption strategies, common objections with responses, and integration patterns for Scrum/Kanban make implementation genuinely feasible.

The ‘Software Last’ Context

When viewed through Seddon’s ‘Software Last’ principle—understand the work first, then design solutions to support that work—RMF operates at a specific layer of the problem stack.

RMF doesn’t address whether teams should build what they’re asked to build—it focuses entirely on the handoff: ‘Given that we’ve decided to build X, let’s make sure we build X correctly.’ Questions about whether X is the right solution are explicitly outside the book’s scope.

The authors acknowledge this limitation directly: ‘The techniques in this book don’t tell you what to build, why to build it, or how to find out whether it’s the right thing to build.’ This honest scope disclaimer might help reduce false expectations.

The Bank example illustrates this perfectly. After RMF, they successfully built a loan repayment portal that satisfied all stakeholders. But the book never asks: Did customers actually need a portal? What work were customers trying to accomplish, and what prevented them from doing it well? RMF enhances confidence in execution without addressing purpose.

The Gall Warning: When Solutions Become Systems

Gall’s Systemantics provides a devastating critique of RMF’s approach. His principles predict exactly how this kind of designed system will behave in practice.

‘A Complex System Designed from Scratch Never Works’: RMF is precisely what Gall warned against—an elaborate, architected solution with three interconnected habits, multiple behaviours, templates, gates, and responsibility transfers. The book presents this as a complete framework without showing how simpler practices might work first.

‘Systems Tend to Oppose Their Own Proper Function’: RMF aims to help teams build the right things correctly, but Gall would predict it will oppose itself. Teams may become obsessed with satisfying DoD/DoR criteria rather than delivering value. Readiness work becomes an end in itself. Process compliance replaces judgement—’The DoR is satisfied, so we must start’ even when common sense says wait.

‘The System Always Kicks Back’: Gall would predict RMF creates new problems it wasn’t designed to solve. Teams learn to game DoDs that are easy to satisfy rather than meaningful. Collaboration meetings consume increasing time. Elaborate DoRs give an illusion of control whilst missing real sources of uncertainty.

‘Systems Serve Themselves’: Most damning—who benefits most from RMF? Process consultants, teams that prefer meetings to building, and managers who want visible ‘readiness progress.’ Meanwhile, customers waiting for working software see longer delays as teams perfect their readiness processes.

The Upstream Questions (Deliberately Out of Scope)

RMF creates elaborate processes to ensure teams build exactly what Product Management requests. The framework’s collaboration meetings are structured around ‘How do we build X correctly?’ rather than ‘Should we build X at all?’

This is by design—the authors explicitly position RMF as addressing execution mechanics, not strategic direction or stakeholder identification. Questions about whether Product Management is listening to the right people or solving the right problems are upstream challenges that RMF doesn’t claim to adress or solve.

The Ethical Question (Also Out of Scope)

This raises an interesting question: Do development teams have a professional responsibility to question whether they’re building the right things for the right reasons? RMF’s focus on execution efficacy doesn’t address this question—and the authors don’t claim it should.

However, it’s worth noting that teams focused intensely on execution mechanics without corresponding frameworks for questioning purpose might inadvertently become more efficient at building things nobody needs. This isn’t a flaw in RMF per se, but rather a reminder that execution excellence requires complementary disciplines around strategy and purpose.

What Works Within Its Scope

Despite these caveats, RMF offers genuine value for teams suffering from implementation chaos:

  • Framework agnostic: Enhances existing methodologies rather than replacing them
  • Incremental adoption: Start with RMF 1, see benefits, then expand
  • Practical mechanics: Detailed templates and guidance make implementation feasible
  • Process discipline: Contract-like nature of DoD/DoR creates healthy constraints
  • Collaboration structure: Systematic approach to shared understanding addresses real coordination problems
  • Honest positioning: The authors clearly state what the book doesn’t solve

The Real Innovation

RMF’s core insight is bringing the rigour of Design by Contract to human collaboration and work handoffs. Instead of code method contracts, teams get collaboratively negotiated work item contracts with clear preconditions, postconditions, and responsibility transfers.

This is genuinely sophisticated process engineering. The problem is the assumption that better process engineering addresses root causes of software project struggles—though the authors are now explicit that this isn’t their claim.

Who Should Read This

Definitely read if:

  • Your teams struggle with constant rework and implementation chaos
  • Requirements frequently change mid-implementation
  • ‘Almost done’ work items plague your sprints
  • You want systematic approaches to collaboration and handoffs

Read with caution if:

  • Your organisation tends toward process bureaucracy
  • You suspect you’re building wrong things (regardless of execution quality)

Don’t read if:

  • You need help identifying what to build or for whom
  • Your problems are primarily market timing, funding, or strategic direction

Verdict

‘Ready’ succeeds brilliantly at what it explicitly attempts—providing systematic relief for teams drowning in implementation chaos. The framework offers concrete mechanisms where many teams have only informal practices. The authors’ honest acknowledgement of scope limitations prevents false expectations about strategic guidance.

However, readers should watch for Gall’s predicted pathologies: RMF serving itself rather than its purpose, readiness work expanding beyond necessity, and process compliance replacing judgement about value creation.

The book positions RMF appropriately within the larger Synapse Framework, acknowledging it doesn’t replace product strategy or vision work. This contextual honesty significantly strengthens the overall package.

Bottom line: If your problem is delivery mechanics, this will likely help—and the authors are clear about what problems it doesn’t solve. The combination of sophisticated process engineering and honest scope positioning makes this a valuable resource for teams struggling with implementation chaos.

Teams struggling with implementation chaos will find systematic, practical relief. The book is explicit about not solving upstream strategy or vision problems—which makes it trustworthy rather than overselling its scope.


‘Ready: Why Most Software Projects Fail and How to Fix It’ is available at https://leanpub.com/ready

Further Reading

De Beer, L., & Guernsey, M., III. (2025). Ready: Why most software projects fail and how to fix it. Leanpub.

Gall, J. (2003). The systems bible: The beginner’s guide to systems large and small (3rd ed.). General Systemantics Press.

Jones, C. (1994). Assessment and control of software risks. Prentice Hall.

Meyer, B. (1997). Object-oriented software construction (2nd ed.). Prentice Hall.

Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute.

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.

Seddon, J. (2003). Freedom from command and control: A better way to make the work work. Vanguard Press.

Sutherland, J., & Schwaber, K. (2020). The Scrum guide: The definitive guide to Scrum (2020 ed.). Scrum.org.

The Antimatter Principle: Why Nobody Needs Their Needs Attended To

How attending to people’s needs might be the key to everything

The antimatter principle is deceptively simple:

“Attend to folks’ needs”

Just that.

A Brief Introduction: A Clarification After Fifteen Years

I first articulated the Antimatter Principle some fifteen years ago and have been writing about it regularly ever since. But with Claude’s help, I’ve just realised something significant: many people might be misunderstanding what the principle is actually about.

When I say ‘attend to folks’ needs’, I suspect some readers might focus on the ‘needs’ part. They start cataloguing what people might need, developing frameworks for identifying needs, or creating systems for meeting various requirements. But that’s not what the principle is fundamentally about.

The magic word isn’t ‘needs’—it’s ‘attend’!

I chose this word very deliberately. Compare it with ‘meet’ folks’ needs. ‘Meeting’ needs implies taking action, providing solutions, filling gaps. But ‘attending’ to needs is fundamentally different—it’s about presence, recognition, witnessing what’s actually there.

As a long time organisational psychotherapist (and student of Rogers, Rosenberg, and others), the power of ‘attend’ is embedded in my subconscious. But I now realise that for many readers, this distinction might not be immediately obvious. There’s also the social and relationship dimension: the very act of attending builds bonds in ways that meeting needs often doesn’t. When you attend to someone, you’re creating connection through presence rather than transaction. And there’s the reciprocity principle—when you truly attend to someone’s needs (in the way this post explains), they’re more likely to begin attending to your needs and the needs of others. Attention begets attention. This social phenomenon is especially profound in organisational, community and even nation-state contexts.

The Antimatter Principle isn’t about becoming an expert in human needs or developing sophisticated ways to meet them. It’s about the quality of attention you bring to people. It’s about really seeing them, being genuinely present with their experience, and offering the kind of attention that allows them to be fully themselves.

This distinction matters enormously. Focus on needs, and you become a problem-solver, a fixer, someone constantly scanning for deficits to address. Focus on attending, and you become something much more valuable: someone who can be truly present with another human being.

When I defined the Antimatter Principle as “attend to folks’ needs”, both elements were intentional. Needs matter—but the transformative power lies in the quality of attending. This balance between recognising real human needs and offering genuine attention without agenda has been baked in to the principle from its inception.

But here’s the paradox: when you actually attend to people’s needs—really attend to them—you discover that nobody needs their needs attended to — in the way we usually think about it.

Needs are Mostly Subconscious

Most people have very little conscious awareness of what they actually need. They’re just living their lives, dealing with whatever comes up, focused on work, relationships, daily tasks—if they’re focused on anything at all. The whole framework of ‘meeting needs’ often misses how people actually function.

Yet when you genuinely attend to someone—crucially, without any agenda to fix them or solve their problems, but simply to be present with what’s actually happening for them—something remarkable occurs. The very act of real attention, freed from the burden of trying to improve or change someone, often dissolves the sense that anything needs to be fixed or met. It’s precisely the absence of agenda that makes the attention so powerful.

Rogers and Frankl: Foundations for Understanding Attending

Carl Rogers discovered something similar in his therapeutic work. He found that when he could be genuinely present with clients—accepting them completely as they were without judgment or conditions—they often found their own capacity for growth and healing. Rogers’ revolutionary insight was that the quality of attention and acceptance mattered much more than specific techniques or interventions. People seemed to have an innate ability to move towards wholeness when given the right relational conditions.

Viktor Frankl added another crucial dimension to this understanding. Through his work with concentration camp survivors and later patients, Frankl discovered that the need for meaning—to feel that their experience matters, that their struggles have significance, that they’re connected to something larger than themselves—is often people’s most fundamental need. When you attend to someone’s need for meaning rather than just their surface-level complaints, you’re often addressing what they most fundamentally require. Frankl showed that people can endure almost anything if they can find meaning in it, demonstrating that this need for significance is as real and vital as any physical need.

Let’s explore how the Antimatter Principle works using the T-Squad five thinking patterns that reveal why this simple approach is so powerful.

Transform Constraints Into Advantages: Why Our Resistance to Attending Is Actually Wisdom

The obvious constraint is that attending to people’s needs seems demanding, time-consuming, and emotionally draining – both for the attendant and the attendee. Most people resist the idea because they imagine it means becoming everyone’s unpaid therapist or getting overwhelmed by others’ problems.

But here’s the transformation: when you actually attend to people properly—without trying to fix or solve anything—it’s often less demanding than the alternatives.

Think about how exhausting it is to constantly deflect, avoid, or half-listen to people. Or to engage in the endless cycle of giving advice that doesn’t work, then feeling frustrated when people don’t take it. Real attending—just being genuinely present with someone’s actual experience—often requires less energy than these defensive strategies.

The constraint becomes an advantage when you realise that attending doesn’t mean taking responsibility for outcomes. You’re not signing up to solve anyone’s problems. You’re simply offering the quality of attention that allows people to be fully themselves, which often enables them to find their own solutions.

Most people who resist attending to needs are actually protecting themselves from the burden of trying to fix everyone. But the Antimatter Principle isn’t about fixing—it’s about attending. And attending, paradoxically, often reduces the total emotional labour in your relationships rather than increasing it.

Systems-Level Perception: How Attending Creates Ripple Effects

Look at what happens to the whole system when someone consistently applies the Antimatter Principle.

In relationships, the dynamic shifts from transactional to generative. Instead of people keeping score of who’s giving and who’s receiving, attention becomes abundant. When someone knows their experience genuinely matters to you, they’re more likely to attend to others in the same way.

In families, the emotional climate changes. Children who feel truly seen develop better self-regulation. Partners who experience real attention become more generous with each other. The quality of attending spreads through the system like a beneficial virus.

At work, teams that practise the Antimatter Principle often become more resilient and creative. When people feel their actual experience is acknowledged—not dismissed or ignored—they’re more willing to share problems early, more likely to collaborate authentically, and less likely to waste energy on interpersonal drama.

But here’s the systemic insight: attending to needs actually reduces the total number of unmet needs in the system. When people feel genuinely seen and understood, many of their surface-level needs simply dissolve. The need for constant reassurance, the need to prove themselves, the need to defend their position—these often evaporate when the deeper need for recognition is met through quality attention.

The Antimatter Principle creates a positive feedback loop: the more you attend to people’s real needs, the fewer needs there are to attend to.

Generate Unexpected Connections: The Pattern Across Domains

The Antimatter Principle appears in surprising places once you know what to look for:

In medicine: The most effective doctors often aren’t those with the most technical knowledge but those who can attend to patients as whole people. Cf. Compassionomics. When patients feel truly seen and understood, their healing often accelerates in ways that can’t be explained by treatment protocols alone.

In education: Students learn best from teachers who can attend to where they actually are rather than where the curriculum says they should be. The attention to their real state of understanding often matters more than the quality of instruction.

In teambuilding: The highest-performing teams often have folks who attend to what’s actually happening rather than what should be happening. When people feel their real challenges and constraints are understood, they become more resourceful and creative.

In customer service: Companies that train staff to attend to customers’ actual experience rather than just solving problems often create deeper loyalty and fewer repeat complaints.

In activism: Social movements that attend to people’s real lived experience rather than telling them what they should think or feel often create more lasting change.

The pattern reveals something profound: in every domain, attending to what’s actually present rather than what you think should be present unlocks human potential in ways that direct intervention often can’t.

Develop Metacognitive Awareness: Thinking About How We Think About Needs

Most people have never examined their own patterns around needs and attending. Start noticing:

Your attending quality: When someone shares something important with you, where does your attention actually go? Are you listening to understand their experience, or are you scanning for how to respond? Are you present with what they’re saying, or are you already formulating advice?

Your need-meeting assumptions: When you think about helping someone, what do you automatically assume they need things? Do you listen for their actual experience, or do you project your own solutions onto their situation?

Your resistance patterns: What makes you want to avoid attending to someone? Is it fear of being overwhelmed? Worry that you won’t know what to do? The belief that their problems are their responsibility? Misanthropy? Understanding your resistance helps you recognise when the antimatter principle might be most needed.

Your agenda-detection: Notice when you slip from paying attention to someone’s actual experience into trying to change their experience. This shift from presence to agenda often happens unconsciously but dramatically changes the quality of interaction.

The metacognitive insight is that most people think attending to needs means taking on burdens, when it actually means offering a quality of presence that often lightens burdens—for both people involved.

Build Comprehensive Mental Models: How the Antimatter Principle Actually Functions

To apply the Antimatter Principle effectively, you need to understand the way it operates:

The Recognition Layer: Most human suffering comes from feeling unseen or misunderstood. When you attend to someone’s actual experience without trying to change it, you provide recognition that often addresses the root of their distress rather than just the symptoms.

The Safety Layer: Real attending creates psychological support—the sense that it’s okay to be exactly as you are right now. This support often allows people’s natural resilience and problem-solving capacity to emerge.

The Meaning Layer: When someone attends to your experience, they’re communicating that your experience matters—that you matter. This addresses Frankl’s fundamental need for significance, which often underlies surface-level complaints.

The Agency Layer: Attending without trying to fix preserves people’s sense of agency. You’re not taking over their problems; you’re simply witnessing their capacity to handle their own experience.

The Connection Layer: Quality attention creates genuine connection that doesn’t depend on problem-solving or advice-giving. This connection itself is often what people most need, even when they think they need something else.

The Efficiency Layer: Paradoxically, attending to needs often resolves them more quickly than trying to meet them directly. When people feel truly seen, they often discover their own solutions or realise that what they thought they needed isn’t actually what they needed.

The Practical Application

The Antimatter Principle isn’t about becoming everyone’s counsellor. It’s about recognising that in your daily interactions—with family, colleagues, friends, even strangers—the quality of your attention always matters more than the content of your response.

When someone shares a difficulty, instead of immediately offering solutions, maybe try attending to their actual experience: ‘That sounds really challenging’ or ‘I can see why that would be frustrating’ or simply ‘Tell me more about that.’

When someone seems upset, instead of trying to cheer them up or solve their problem, try attending to where they actually are: ‘This seems really important to you’ or ‘I can see this is affecting you deeply.’

The shift is subtle but profound: from ‘How can I fix this?’ to ‘How can I be present with this?’ From ‘What should I do?’ to ‘How can I attend to what’s actually happening here?’

Why This Works

The Antimatter Principle works because it addresses what people most fundamentally need: to know that their experience matters to someone else. When you attend to someone without trying to change them, you meet this deepest need completely.

Most of our surface-level needs—for advice, solutions, comfort, reassurance—are often proxies for this deeper need to be seen and understood. When the deeper need is met through quality attention, the surface needs often dissolve naturally.

Nobody needs to have their needs attended to—because when someone truly attends to you as you are, you discover that what you most needed was simply to be seen, understood, and recognised as mattering. The attending itself completes something that no amount of problem-solving or advice-giving ever could.

Putting Folks’ Needs First – Skip the User Stories vs Use Cases Debate

The software industry spends an enormous amount of energy debating practices—user stories versus use cases, agile versus waterfall, documentation versus conversation. Meanwhile, the people who actually matter—the ones who will use, buy, build, maintain, and profit from our software—are often afterthoughts in these discussions.

It’s time to flip the script. Instead of starting with methodology and hoping it serves people’s needs, let’s start with the Folks That Matter™ and choose our approaches accordingly. This is what the Antimatter principle calls “attending to folks’ needs”—recognising that the value of any practice lies entirely in how well it serves real folks’ actual needs. Let’s can the endless debating by attending to folks’ needs.

Who Are Your Folks That Matter™?

Before you write your first user story or draft your first use case, pause and identify who actually needs to understand and act on your work. These aren’t abstract roles—they’re real people with specific needs, constraints, and ways of thinking.

Sarah, the product manager, thinks in user journeys and business outcomes. She needs to understand how features connect to customer value, competition, and revenue impact. Dense technical specifications make her eyes glaze over, but she can instantly spot when a user story misses a crucial business rule.

Marcus, the lead developer, needs enough detail to identify technical risks and understand how new features interact with existing systems. He’s been burnt by vague requirements that seemed clear in meetings but fell apart during implementation. Interestingly, Marcus has embraced the movement—he’s found that detailed story point estimation often becomes an end in itself, consuming time that could better be spent actually building software. He prefers breaking work into small, similar-sized pieces that flow predictably.

Katarzyna, the compliance officer, must ensure the product meets regulatory requirements. She needs traceable documentation that auditors can review. Conversational approaches that leave decisions undocumented create legal risks she can’t accept.

Jennifer, the customer success manager, deals with confused users when needs miss real-world scenarios. She has to understand not just what the software should do, but what users might expect it to do based on their mental models.

Each of these people has legitimate needs. The question isn’t which methodology is ‘right’—it’s how to serve all the Folks That Matter™ effectively. As the Antimatter principle reminds us, any practice that doesn’t attend to folks’ needs is waste, regardless of how theoretically sound it might seem.

When teams, and indeed organisations, focus on attending to folks’ needs rather than defending methodological positions, the endless debates about user stories versus use cases simply evaporate. The answer becomes obvious: use whatever works for the specific people and their specific needs, in your specific context.

Matching Methods to People’s Needs

When your Folks That Matter™ need exploration and alignment, user stories excel. The product manager who’s still figuring out what customers really want benefits from the conversation-starting nature of story cards. The development team discovering technical constraints needs the flexibility to evolve requirements as they learn.

Sarah’s team was building a new invoicing feature. They started with a simple story: ‘As a small business owner, I want to send professional invoices so that I get paid faster.’ This sparked conversations about payment terms, tax calculations, and branding options that no one had considered upfront. The story evolved through dialogue, and the final feature was far richer than anything they could have specified initially.

Marcus particularly appreciated this approach because it aligned with his philosophy. Rather than spending hours estimating a vague story, the team broke it into small, discoverable pieces that they could complete in a day or two. The predictable flow of small stories gave Sarah the planning visibility she needed without the overhead of detailed estimation ceremonies.

When your Folks That Matter™ need precision and accountability, use cases provide the structure they require. The compliance officer who must demonstrate regulatory adherence needs documented workflows with clear preconditions and outcomes. The offshore development team working across time zones needs detailed scenarios they can implement without constant clarification calls.

Katarzyna’s team was building patient data access controls. A user story like ‘As a doctor, I want to access patient records so that I can provide care’ was legally meaningless. They needed use cases that specified exactly which roles could access what data under which circumstances, with full audit trails. The systematic format of use cases made regulatory review straightforward.

When your Folks That Matter™ have different thinking styles, provide multiple views of the same requirements. Don’t force the visual thinker to work with text-heavy use cases or make the detail-oriented analyst guess at implementation specifics from high-level stories.

Marcus and Sarah worked together by starting with story mapping to visualise the user journey, then drilling down into detailed use cases for complex workflows. Sarah could see the big picture and business logic, whilst Marcus got the implementation details he needed. Same requirements, different representations.

Notice how none of these decisions required theological arguments about methodology. Each choice served specific people’s specific needs. Attending to folks’ needs cuts through the debate noise.

The Reality Check

The movement highlights a crucial insight: detailed requirements often become proxies for prediction rather than tools for understanding. Teams can spend enormous effort estimating user stories with story points, planning poker, and velocity calculations, but these estimates rarely improve delivery predictability and often distract from actually building software.

Marcus’s team discovered that when they focused on making stories consistently small rather than accurately estimated, their delivery became more predictable. Instead of debating whether a feature was 5 or 8 story points, they asked whether it could be broken into e.g. artefacts that could each be completed in a day or two. This shift changed how they captured folks’ needs —less focus on comprehensive upfront specification, more focus on just-enough detail to start work confidently. See also: the Needsscape.

This doesn’t mean abandoning planning entirely. Sarah still needed roadmap commitments and budget forecasts. But the team found they could provide better predictions by counting delivered stories over time rather than summing estimated story points. Their artefacts became lighter and more focused on enabling flow rather than feeding estimation ceremonies.

The endless debates about estimation versus dissolve when you ask: what do our Folks That Matter™ actually need for planning and coordination? Often, it’s predictable delivery more than precise estimates.

The Misuse Case Reality Check

Here’s where focusing on Folks That Matter™ becomes crucial: the people who deal with software problems aren’t usually the ones writing requirements. Jennifer in customer success fields calls when users accidentally delete important data. The security team deals with the aftermath when features are misused maliciously.

These voices often aren’t heard during needs capture and evolution, but they represent critical Folks That Matter™. Building ‘misuse cases’ into your process—whether you’re using stories or formal use cases—ensures you’re serving the people who have to deal with problems, not just the ones who use features successfully.

Jennifer pushed her team to consider stories like ‘As a malicious user, I want to exploit the file upload feature so that I can access other users’ data’ and ‘As a confused user, I want to understand why my action failed so that I can correct my mistake.’ These weren’t happy path features, but they prevented real problems for real people.

The Antimatter principle particularly applies here: security reviews and error handling often feel like bureaucratic overhead, but they directly serve the needs of people who deal with the consequences of product failures.

Documentation vs Conversation: Serving Different Needs

The agile manifesto’s preference for ‘individuals and interactions over processes and tools’ doesn’t mean documentation is evil—it means putting people first. Sometimes the Folks That Matter™ need rich conversation to discover what they really need. Sometimes they need comprehensive documentation to do their jobs effectively.

Conversation serves discovery. When your product manager is exploring new market opportunities or your development team is prototyping technical approaches, dialogue-heavy user stories facilitate learning and adaptation.

Documentation serves execution and accountability. When your distributed team needs to implement complex business rules or your compliance officer needs to demonstrate regulatory adherence, written specifications provide the clarity and traceability required.

The most effective teams recognise that these aren’t competing approaches—they’re different tools for serving different people at different times. The Antimatter principle’s “attend to folks’ needs” helps teams avoid dogmatic adherence to either extreme.

The endless documentation versus conversation debates end when you focus on what your specific people need to do their jobs effectively.

Timing That Actually Works for People

The ‘up front versus evolutionary’ debate often ignores the reality of how different Folks That Matter™ actually work. Product managers need enough certainty to make roadmap commitments. Developers need enough detail to minimise rework. Operations teams need enough notice to prepare infrastructure.

Instead of choosing between comprehensive upfront planning and just-in-time discovery, map your requirements approach to the actual decision-making needs of your stakeholders.

Identify architectural decisions early because they affect everyone downstream. The integration approach that seems like an implementation detail to the product manager might require months of infrastructure work from the operations team.

Keep UI and workflow details evolutionary because these benefit from user feedback and technical learning. The exact button placement that seems critical upfront often changes once users actually interact with early versions.

Document agreements when they affect multiple teams because people need to coordinate their work. The API contract between frontend and backend teams needs to be explicit, even if the user story that drives it remains flexible.

This timing approach aligns well with thinking: instead of trying to estimate everything upfront, identify what decisions must be made early and defer the rest until you have better information.

When you attend to folks’ needs, the timing becomes obvious. No more theoretical arguments about waterfall versus agile—just practical decisions about when different people need different information.

Making It Work: Practical Steps

Start with your Folks That Matter™ inventory. List the real people who need to understand, implement, test, support, and approve your software. Understand their constraints, preferences, and success criteria.

Match your methods to their needs. Use stories when stakeholders need to explore and align. Use cases when they need to implement and verify. Use both when you have both types of needs.

Question estimation ceremonies. Ask whether detailed story point estimation actually serves your Folks That Matter™ or just creates busy work. Consider focusing on consistent story size rather than accurate estimation.

Create feedback loops with the people who live with the consequences. Regular check-ins with customer support, security teams, and operations prevent requirements that look good on paper but fail in practice.

Evolve your approach as your team learns. The startup exploring product-market fit needs different requirements approaches than the enterprise team maintaining critical systems. Let your methods serve your current reality, not your methodology preferences.

Stop the methodological debates. When teams start arguing about the “right” way to write requirements, refocus on the Folks That Matter™. Ask: “Who needs this information, and how do they prefer to receive it?”

The Real Test

The ultimate test of your approach isn’t methodological purity—it’s whether the Folks That Matter™ can successfully do their jobs. Can the product manager make informed decisions? Can the developer implement features correctly? Can the support team help confused users? Can the compliance officer satisfy auditors?

The Antimatter principle provides a simple filter: does this practice attend to folks’ needs? If your user stories help stakeholders align and discover needs, they’re valuable. If they become exercises in elaborate estimation that don’t improve delivery, they’re waste. If your use cases provide necessary precision for implementation and compliance, they’re essential. If they become bureaucratic documentation that nobody reads, they’re overhead.

When you put people first, the user stories versus use cases debate becomes much simpler. You use whatever approaches help your specific stakeholders succeed in their specific contexts. Sometimes that’s collaborative story discovery. Sometimes it’s systematic use case documentation. Most often, it’s a thoughtful combination that serves different people’s different needs.

The approach matters far less than the people. Make sure your approach serves the Folks That Matter™, and the rest will follow. Can the endless debating by attending to folks’ needs—because when you focus on serving real people’s real needs, the “right” answer becomes obvious for your context.

Based on my verification, I found several issues with the citations I originally provided. Let me create a corrected Further Reading section with properly verified citations:

Further Reading

User Stories and Agile Requirements

Cao, L., & Ramesh, B. (2008). Agile requirements engineering practices: An empirical study. IEEE Software, 25(1), 60-67. https://doi.org/10.1109/MS.2008.9

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2015). Forging high-quality user stories: Towards a discipline for agile requirements. In 2015 IEEE 23rd International Requirements Engineering Conference (RE) (pp. 126-135). IEEE.

Use Cases and Requirements Engineering

Cockburn, A. (2001). Writing effective use cases. Addison-Wesley Professional.

Jacobson, I. (1992). Object-oriented software engineering: A use case driven approach. Addison-Wesley Professional.

Pohl, K. (2010). Requirements engineering: Fundamentals, principles, and techniques. Springer.

Movement

Duarte, V. (2015). NoEstimates: How to measure project progress without estimating. Oikosofy.

Killick, N., Duarte, V., & Zuill, W. (2015). No estimates – How to deliver software without guesswork. Leanpub.

The Antimatter Principle

Marshall, B. (2014, May 22). Q&A with Bob Marshall about the Antimatter Principle. InfoQ. https://www.infoq.com/news/2014/05/antimatter-principle/

Empirical Studies and Academic Research

Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015). A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior, 51, 915-929. https://doi.org/10.1016/j.chb.2014.10.046

From Dawn Till Dusk

Reflections on a 50+ Year Career in Software

The Dawn: Programming as Pioneering (1970s)

When I first touched a computer in the early 1970s, programming wasn’t just a job—it was exploration of uncharted territory. We worked with punch cards and paper tape, carefully checking our code before submitting it for processing. A single run might take hours or even overnight, and a misplaced character meant starting over. Storage was 5MByte disk packs, magnetic tapes, more punch cards, and VRC (visible record cards with magnetic stripes on the reverse).

The machines were massive, expensive, and rare. Those of us who could communicate with these behemoths were viewed almost as wizards, speaking arcane languages like FORTRAN, COBOL, Assembler, and early versions of BASIC. Computing time was precious, and we spent more time planning our code on paper than actually typing it.

The tools were primitive by today’s standards, but there was something magical about being among the first generation to speak directly to machines. We were creating something entirely new—teaching inanimate objects to think, in a way. Every problem solved felt like a genuine discovery, every program a small miracle.

The Dusk: The AI Inflection Point (2020s)

In recent years, I’ve witnessed a most profound shift. Machine learning and AI tools have begun to automate aspects of programming we once thought required human creativity and problem-solving. Large language models can generate functional code from natural language descriptions, debug existing code, and explain complex systems.

The pace of change has been breathtaking. Just five years ago, we laughed at the limitations of code-generation tools. Remember Ambase? Or The Last One? Today, junior programmers routinely complete in minutes what would have taken days of specialised knowledge previously.

As I look forward, I can’t help but wonder if we’re witnessing the twilight of programming as we’ve known it. The abstraction level continues to rise—from machine code to assembly to high-level languages to frameworks to AI assistants to …? Each step removed programmers further from the machine while making software creation more accessible.

The traditional career path seems to be narrowing. Entry-level programming tasks are increasingly automated, while senior roles require deeper system design and architectural thinking. And, God forbid, people skills. The middle is being hollowed out.

Yet I remain optimistic. Throughout my career, development has constantly reinvented itself. What we call “programming” today bears little resemblance to what I did in the 1970s. The fundamental skill—translating human needs into machine instructions—remains valuable, even as the mechanisms evolve.

If I could share advice with those entering the field today: focus on attending to folks’ needs, not on coding, analysis, design; seek out change rather than just coping passively with it; understand systems holistically; develop deep people knowledge; and remember that technology serves humans, not the other way around.

Whatever comes next, I’m grateful to have witnessed this extraordinary journey—from room-sized computers with kilobytes of memory to AI systems that can code alongside us and for us. It’s been a wild ride participating in one of humanity’s most transformative revolutions.

What Makes a Great User Story?

A great user story accurately pinpoints what people truly need from your product and translates those needs into guidance that development teams can easily understand and act upon. It’s worth noting that “user story” is actually a misnomer – these might better be called “Folks That Matter™ stories” since they centre on real people with real needs, not just abstract “users” of a system.

Core Components

While there are many formats for writing these stories, the essential components remain consistent: identifying the Folks That Matter™, their needs, and the benefits they’ll receive. The story should clearly communicate who needs the feature, what they need, and most importantly, why they need it.

The Living Nature of Stories

Folks That Matter™ stories aren’t static artefacts – they evolve, morph, and grow across numerous iterations. Like elements in a Needsscape (the visualisation of all the folks that matter and their changing needs), stories adapt as we gain deeper understanding of people’s requirements. What begins as a simple narrative might develop into a complex web of interconnected needs as teams learn more through development cycles, feedback loops and product deployments.

Essential Qualities

Great Folks That Matter™ stories share several important characteristics:

  • They can be developed independently from other stories
  • Their details remain open to discussion and refinement
  • They deliver clear value to the folks that matter™
  • Teams can reasonably estimate the effort required
  • They’re focused enough to complete in a single iteration
  • They include clear criteria for testing and validation

Focus on Needs

The most effective Folks That Matter™ stories focus on identifying and attending to needs rather than implementing specific solutions. They describe outcomes and the results foilks gain, not the technical implementation. This gives development teams space to find the best technical approaches.

Clear Acceptance Criteria

Each Folks That Matter™ story includes explicit acceptance criteria that define when the story is complete and needs have been met. Such criteria will be testable, quantified (Cf. Gilb), and agreed upon by all the Folks That Matter™.

Summary

Effective Folks That Matter™ stories serve as bridges between human needs and technical solutions. They identify the Folks That Matter™, articulate their genuine needs, and provide development teams with clear guidance – while leaving room for creativity in implementation. Rather than static requirements documents, they function as living artefacts that evolve through conversation and iteration and feedback. By focusing on outcomes rather than specifications, and by including clear, quantified acceptance criteria, these stories help teams build products that truly meet people’s needs—the essence of successful product development and the cornerstone of navigating the broader Needsscape of any organisation.

Folks Matter™: A Human-Centered Approach to Business Success

In a business world dominated by metrics, margins, and market share, one fundamental question often gets overlooked: Do folks matter? This post provides a comprehensive answer—not just affirming that yes, folks absolutely do matter, but demonstrating why human relationships form the essential foundation for sustainable business success.

Introduction

Drawing on research from organisations like Gallup and insights from management thinkers like Peter Drucker, we explore how interpersonal connections determine which strategies succeed and which fail, regardless of how brilliant they appear on paper. The Folks Matter™ framework offers a practical approach to business strategy that places relationships at the centre rather than treating them as secondary considerations, showing how this people-centred philosophy translates into tangible competitive advantage.

The 14 Principles of the Folks Matter™ Framework

1. Relationship-Centred Approach

At the core of any successful organisation lies its interpersonal relationships—the connections that enable and energise collaborative work and innovation. The Folks Matter™ approach recognises this fundamental truth, putting meaningful human bonds at the heart of strategic thinking.

True folks-centred organisations transcend simplistic “people first” slogans. They require “having a genuine intention to help each person succeed and find fulfillment at work, along with a disciplined approach to effectively choosing and exhibiting the behaviours appropriate for the individual and the context.”

Research demonstrates this approach drives tangible results. According to Gallup, “teams buzzing with engagement see a 21% boost in profitability,” while companies that excel in developing their people are “1.5 times more likely to be celebrated as pinnacle performers in their industry.”

2. Collective Mindset Awareness

Beneath the surface of every organisation lies an invisible web of assumptions, beliefs, and mental models that profoundly shapes how folks work together. This collective mindset—what Edgar Schein called the “basic underlying assumptions” at the deepest level of organisational culture—determines which strategies succeed and which fail.

The renowned management thinker Peter Drucker understood this dynamic perfectly when he allegedly observed that “culture eats strategy for breakfast.” This insight emphasises the futility of brilliant strategies that clash with an organisation’s deeply held beliefs.

When an organisation understands its current cultural paradigm, it can deliberately evolve this mindset to support strategic priorities. Only with this level of cultural consciousness can an organisation ensure its strategy has a genuine chance of success.

3. Change Facilitation Capability

Implementing effective change strategies holds crucial importance, as “some 70% of all organisational change transformations fail, according to McKinsey” while “Gartner begs to differ, with research that shows 50% of organisational change efforts are considered a clear failure.”

Effective change facilitation in a Folks Matter™ organisation includes:

  • Clear communication about the vision and rationale for change
  • Involvement of all stakeholders in planning and implementation
  • Recognition of both emotional and logical aspects of the change process
  • Systematic approach using proven change models appropriate to the situation
  • Ongoing reinforcement to prevent reversion to previous patterns

4. Inclusive Stakeholder Approach

Instead of focusing narrowly on shareholders or even just customers, successful Folks Matter™ businesses create value for all the folks in their ecosystem:

  • Customers receive products and services that genuinely improve their lives
  • Employees find meaningful work, fair compensation, and opportunities for growth
  • Suppliers engage in mutually beneficial partnerships that promote innovation
  • Communities experience positive environmental and social impacts
  • Shareholders receive sustainable returns that reflect real value creation

Companies like Patagonia and Ben & Jerry’s have demonstrated that this inclusive approach creates more resilient businesses with stronger customer loyalty, higher employee engagement, and ultimately better long-term financial performance.

5. Fellowship-Based Collaboration

Organisations that embrace the Folks Matter™ philosophy thrive over the long term by adopting collective approaches to working:

  • In non-hierarchical organisations, “teams become self-supporting, decision-making is decentralised, and leadership is shared, not imposed from above”
  • Fellowship models prioritise “shared responsibility, trust, and open communication, fostering an environment conducive to creativity, inclusion, and effective decision-making”
  • People “communicate directly with each other and are accountable to fellow members of multi-disciplined teams” with guidance emerging organically

6. Joy-Centred Workplace Culture

Folks Matter™ organisations create environments where people find meaning and satisfaction:

  • As demonstrated at Menlo Innovations, joy can exist as “the core belief of our workplace” that “defines what we do and how we do it”
  • People find joy in their work “when they feel like they are doing something meaningful” and teams provide “an inspiring vision and clear expectations”
  • Workplaces focus on creating environments “filled with camaraderie, human energy, creativity, and productivity” rather than fear and ambiguity

7. Systems Thinking Integration

Folks Matter™ organisations view themselves as interconnected systems rather than isolated departments:

  • Systems thinking examines the circular interconnections that bind enterprise functions into an integrated whole
  • Decision-makers consider how changes in one area will impact other parts of the organisation
  • Problems appear holistically rather than in isolation
  • Teams recognise that optimising individual parts may not optimise the whole system of folks working together

8. Evidence-Based Operations

Effective Folks Matter™ businesses replace gut feelings with measurable insights:

  • Consistent metrics that track both outcomes for Folks That Matter™ and business performance
  • Regular review cycles to spot problems early and adjust course
  • Transparent sharing of key information across the organisation
  • Testing of major initiatives before full rollout

9. Constraint Recognition and Removal

High-performing Folks Matter™ businesses identify and address the factors limiting their growth:

  • The Theory of Constraints views systems as a chain limited by its weakest link
  • Resources focus on identifying and eliminating the current constraint
  • Once resolved, the team moves to the next constraint in a process of continuous improvement
  • The core concept holds that “total process throughput can only improve when the constraint improves”

10. Adaptive Team Structures

Rather than traditional department silos, Folks Matter™ organisations create team structures that can adapt quickly:

  • Small, cross-functional teams with end-to-end responsibility for specific products or customers
  • Minimal management layers to speed up decision-making
  • Clear authority for teams to solve problems without constant approvals
  • Teams organised around customer journeys rather than internal functions

The Peach model provides a practical framework here – pushing decision-making to the edges of the organisation where folks interact directly with customers and markets, rather than concentrating it at headquarters.

11. Focus Management

Successful Folks Matter™ organisations carefully consider which folks and needs to prioritise:

  • Cost of Focus represents the potential consequences of failing to include all relevant Folks That Matter™
  • Unlike Cost of Delay which has incremental financial impacts, Cost of Focus often has binary outcomes
  • Organisations identify which folks hold true critical importance to success, not just those who speak loudest
  • Teams balance between including too few perspectives (risking rejection) and too many (diffusing focus)

12. Time Value Awareness

Strategic Folks Matter™ organisations understand the financial impact of time:

  • Cost of delay exists as “a prioritisation framework that helps a business quantify the economic value of completing a project sooner as opposed to later”
  • Teams calculate the potential revenue or value lost by delaying key initiatives
  • Projects receive prioritisation based on their economic impact rather than politics or tradition
  • People develop a sense of urgency around high-impact initiatives

13. Collective Decision Processes

Successful Folks Matter™ organisations adjust their approach based on:

  • Fast feedback loops from all Folks That Matter™, especially customers and front-line employees
  • Regular review of industry trends and competitive moves
  • Willingness to abandon unsuccessful strategies quickly
  • Learning systems that capture and share successful approaches across all folks

14. Collaborative Innovation Infrastructure

Folks Matter™ companies that consistently create new value build systems for innovation:

  • Dedicated processes to capture and evaluate new ideas from all folks
  • Regular testing of small experiments before large investments
  • Partnerships with outside organisations to access new capabilities
  • Focus on innovations that benefit multiple groups of Folks That Matter™

Conclusion

The Folks Matter™ approach places human relationships at the centre while balancing the needs of all stakeholders, maintaining flexible structures, evidence-based operations, systems thinking, constraint management, focus awareness, and fellowship-centred collaborative cultures.

As the saying commonly attributed to Peter Drucker reminds us, “Culture eats strategy for breakfast.” This means that “no matter how well-designed your strategic plan is, it will fall flat unless your team shares the appropriate culture” to implement it successfully. The most successful Folks Matter™ organisations don’t pit culture against strategy but ensure they work in harmony, with each supporting and reinforcing the other.

Further Reading

Further Reading

Beer, M., & Nohria, N. (2000). Cracking the code of change. Harvard Business Review, 78(3), 133-141.

Corporate Governance Institute. (2023). What does culture eats strategy for breakfast mean? https://www.thecorporategovernanceinstitute.com/insights/lexicon/what-does-culture-eats-strategy-for-breakfast-mean/

Gallup. (2018). Employee engagement on the rise in the U.S. Gallup News. https://news.gallup.com/poll/241649/employee-engagement-rise.aspx

Goldratt, E. M., & Cox, J. (1984). The goal: A process of ongoing improvement. North River Press.

Jabian Consulting. (2023). Culture eats strategy for breakfast and transformation for lunch. The Jabian Journal. https://journal.jabian.com/culture-eats-strategy-for-breakfast-and-transformation-for-lunch/

Lean Production. (n.d.). Theory of constraints (TOC). https://www.leanproduction.com/theory-of-constraints/

Marshall, R. W. (2018). Hearts over diamonds: Serving business and society through organisational psychotherapy. Falling Blossoms. https://leanpub.com/heartsoverdiamonds

The foundational text on Organisational Psychotherapy, “Hearts over Diamonds” introduces the concept of bringing psychotherapy techniques into organisational settings. Marshall argues that interpersonal relationships are at the heart of successful business, and presents a framework for transformational change that prioritises human connections over traditional management approaches. This book aims to support organisations seeking to become more humane, people-oriented, and productive.

Marshall, R. W. (2021). Memeology: Surfacing and reflecting on the organisation’s collective assumptions and beliefs. Falling Blossoms. https://leanpub.com/memeology

A self-help guide for organisations seeking to understand their culture at a deeper level. “Memeology” provides practical techniques for surfacing and examining collective assumptions and beliefs (or “memes”) that often unconsciously drive organisational behaviour. The book offers methodical approaches for unearthing these cultural patterns, helping organisations recognise how their unexamined beliefs may be limiting their effectiveness and preventing meaningful change.

Marshall, R. W. (2022). Quintessence: An acme for highly effective software development organisations. Falling Blossoms. https://leanpub.com/quintessence

Based on Marshall’s experience building and running a highly successful software development company, “Quintessence” describes a path toward becoming a highly effective software development organisation. Rather than prescribing specific practices or methodologies, the book encourages organisations to find their own path to excellence by leveraging the principles of Organisational Psychotherapy in tech business contexts.

McKinsey & Company. (2019). Why do most transformations fail? A conversation with Harry Robinson. https://www.mckinsey.com/capabilities/transformation/our-insights/why-do-most-transformations-fail-a-conversation-with-harry-robinson

Quote Investigator. (2017). Quote origin: Culture eats strategy for breakfast. https://quoteinvestigator.com/2017/05/23/culture-eats/

The Universal Discomfort of Receiving Help

The Inevitability of Needing Others

Everyone needs a little help sometimes. We can all find ourselves in moments where we simply cannot manage on our own. Whether it’s struggling with a heavy parcel, facing a complex work challenge, or navigating life’s inevitable emotional hurdles, there comes a time when even the most self-sufficient among us fells the need to reach out for assistance. This universal need for support is part of our shared human experience, transcending cultures and backgrounds.

Yet despite how common it is to need help, there exists an equally widespread discomfort when actually receiving it. That peculiar feeling of vulnerability when someone steps in to offer assistance is something most of us recognise all too well.

The Internal Struggle

When someone offers to help with a task with which we’re struggling, we often feel a curious mixture of relief and unease. “I could have managed,” we tell ourselves, even as we’re grateful for the intervention. We worry about being a burden. We fret about appearing incompetent. We mentally calculate how quickly we can repay the favour to restore some imagined balance.

This discomfort is compounded by powerful social pressures that permeate our interactions. Society repeatedly reinforces the message that neediness is somehow shameful—a character flaw rather than a normal human condition. From an early age, we’re taught to “stand on our own two feet” and that “independence is strength.” These messages create a pervasive anxiety around appearing as though we require support.

Social Pressures Against Appearing Needy

The social stigma attached to needing help manifests in countless subtle ways. We’ve all witnessed the sidelong glances when someone asks for assistance “too frequently.” We’ve heard the whispered comments about those who “can’t seem to manage on their own.” This collective judgement creates a powerful deterrent against reaching out, even when doing so would be entirely reasonable.

In workplace settings, this pressure becomes even more pronounced. Colleagues hesitate to ask questions for fear of appearing weak or incompetent. Employees work well beyond reasonable hours rather than admitting they’re overwhelmed. Managers plod on silently rather than seeking advice. The unspoken rule seems to be that success equals complete self-sufficiency—a standard that is both unrealistic and ultimately harmful.

Even in our personal relationships, the fear of being labelled “high-maintenance” or “needy” can prevent us from seeking necessary emotional support. We pretend to be coping splendidly when in fact we’re struggling, all to maintain an image of self-reliance that nobody truly achieves.

Collaborative Knowledge Work: The Paradox

Perhaps nowhere is this discomfort more counterproductive than in collaborative knowledge work (CKW). Modern innovation and problem-solving rely fundamentally on the sharing of expertise, yet our reluctance to seek help undermines this essential process.

In research institutions, tech companies, and creative industries, the most significant breakthroughs typically emerge not from solitary genius but from the pooling of diverse perspectives and skills. When researchers hesitate to consult colleagues on difficult problems, when developers avoid asking for inspections or reviews, or when writers refuse editorial feedback, the quality of output inevitably suffers.

The irony is striking: in fields where collaboration is explicitly valued, individuals still struggle with the perceived vulnerability of not knowing everything. We’ve created work environments that theoretically celebrate teamwork whilst implicitly rewarding those who appear least dependent on others’ input.

This paradox extends to our learning environments as well. Universities and professional development programmes emphasise collaboration and knowledge-sharing, yet students and participants often feel that asking questions reveals a lack of competence rather than a commitment to learning.

The Wisdom in Receiving Gracefully

Yet there’s profound wisdom in learning to receive assistance gracefully. When we accept help, we not only solve our immediate problem but also strengthen our social bonds. We create opportunities for connection. We allow others the satisfaction of being useful, of making a difference—a deeply fulfilling human experience.

The truth is that giving and receiving help creates a beautiful cycle of human interdependence. When we overcome our discomfort and accept assistance with grace, we challenge the harmful narrative that neediness is weakness. We contribute to a culture where seeking support isn’t seen as shameful but as wise.

Moving Forward Together

Learning to say “yes, thank you” instead of “no, I’m fine” might be one of the most important social skills we can develop. It acknowledges our shared humanity and creates space for authentic connection in a world that often feels isolating.

The next time someone offers you help—whether it’s carrying your shopping bags, proofreading an important document, or simply listening when you’re having a difficult day—consider accepting it with gratitude rather than reluctance. In doing so, you’re not just solving your immediate problem; you’re participating in the ancient and noble tradition of people helping people, and perhaps even challenging the unhelpful social norms that make asking for help so unnecessarily difficult.

After all, needing assistance isn’t a failure of self-reliance—it’s simply part of being human. And in acknowledging this truth, we open ourselves to richer connections, better outcomes, and a more authentic way of being in the world.

The Case for Holistic Product Development: When Good Technical Decisions Create Bad User Experiences

A recent frustration of mine with iTunes downloads offers an intriguing case study in why product development could benefit from holistic thinking across the whole product.

The observed behaviour is consistent and reproducible: when requesting a track download, the first attempt almost always fails with a fecking modal error dialogue, but a second attempt 10-15 seconds later succeeds perfectly. While we can’t know the exact implementation details, this pattern suggests how technically sound decisions in isolation can create poor user experiences when systems aren’t considered as a whole.

The Root Cause: Balkanised Development

At its heart, this isn’t a technical problem – it’s an organisational one. The issue likely stems from organisational structures where different teams own different parts of the stack, each optimising for their own metrics and concerns. The CDN team likely focuses on network efficiency and scalability. The client team handles UI and local functionality. Each team makes reasonable decisions within their domain, but no one is looking at how these decisions interact to shape the overall user experience (UX).

How the Problem Manifests

Based on observed behaviour of iTunes during downloads, we can hypothesise what might be happening behind the scenes. When we request a download:

  1. Our request likely hits Apple’s Content Delivery Network (CDN)
  2. If the track isn’t in the CDN’s edge node’s cache, the CDN would need to fetch it from origin storage
  3. Rather than make users wait for this fetch, the system appears to fail fast
  4. By the time you retry, the content seems to be cached and serves quickly

This CDN behaviour would be technically sound in isolation – failing fast on cache misses is a common strategy. The problem emerges when this technically reasonable decision meets the iTunes app’s error handling: a modal error dialogue that demands user intervention. This creates a frustrating experience where users must:

  1. Request the download
  2. Wait for the error
  3. Dismiss the fecking modal dialogue
  4. Wait 10-15 seconds
  5. Try again

The Real Solution: Organisational Integration

While there are various technical fixes available, the fundamental solution lies in how we structure our product development organisations:

Critical Organisational Changes

  • Cross-functional product teams that own complete user journeys i.e. the end-to-end UX
  • System architects empowered to look across organisational boundaries
  • UX representation in all technical architecture decisions
  • Clear ownership of end-to-end user experiences
  • Regular review of system interfaces and team boundaries
  • User-focused metrics that catch interaction issues
  • Product leadership that can bridge technical and user experience concerns

Supporting Technical Approaches

  • Silent retry logic in the client
  • Non-modal loading indicators
  • Download queuing with background completion
  • More informative messaging
  • CDN pre-warming for likely downloads
  • Progressive download starting with cached content

Beyond Technical Architecture

This example highlights how product development requires thinking beyond pure technical architecture and team boundaries. Good product development means:

  1. Understanding that technical decisions are inherently and always user experience decisions
  2. Recognising that system boundaries often reflect team boundaries
  3. Seeing that user experience emerges from organisational structures as much as code
  4. Forming teams around user journeys rather than technical components

The Path Forward

Organisations might choose to evolve beyond purely vertical team structures and embrace more holistic approaches to product development. This means:

  • Strong product awareness that looks across traditional boundaries
  • Organisational structures that mirror user journeys, not technical architectures
  • Teams empowered to attend to the overall needs of all the Folks That Matter™, not just to technical metrics
  • Regular evaluation of how organisational decisions affect user experience
  • Cross-functional collaboration as a default, not an exception

The iTunes download experience shows how even small interaction issues often reveal deeper organisational challenges. While technical solutions exist, the real improvements come from better organisational structures that prevent these issues from arising in the first place.

Key Takeaways

  1. Technical friktion often reveals organisational boundaries
  2. User experience emerges from team structures at least as much as from technical decisions
  3. Organisational “architecture” shapes product development and user experience more than technical architecture
  4. Holistic thinking requires organisational change, not just technical solutions
  5. Great products emerge from organisations structured around attending to the needs of all the Folks That Matter™, not just to technical boundaries

The next time you encounter a frustrating user experience, consider firstly the organisational structures that created it.

Postscript: Conway’s Law and Its Inverse

This entire discussion brings to mind Conway’s Law, which states that “organisations design products that mirror their own communication structure.” Our iTunes case study perfectly illustrates this – the jarring user experience at the boundary between CDN and client likely reflects an organisational boundary between teams.

Reverse Conway

But there’s also the inverse of Conway’s Law, sometimes called the “Reverse Conway Manoeuvre” – the idea that we can deliberately structure our organisations to encourage the system architecture we want. If we want seamless user experiences, we might better choose organisational structures that encourage integration and collaboration across traditional system boundaries.

Postscript 2: Product Aikido – Harmonising with Entropy

This discussion of holistic product development brings to mind the principles of Product Aikido – a philosophy that recognises entropy, not competing teams or systems, as the true opponent in product development. Just as Aikido practitioners seek to blend with and redirect force, Product Aikido teaches us to harmonise with the natural disorder inherent in complex systems rather than fight against it.

The iTunes-CDN example perfectly illustrates what happens when we fail to achieve this harmony. But viewed through the lens of Product Aikido, we can see that the real issue isn’t the clash between teams or components – it’s our collective failure to embrace entropy effectively. The fast-fail approach of the CDN isn’t inherently problematic; the friktion comes from our rigid, balkanised response to that entropy.

Product Aikido would suggest several alternative approaches. Rather than prescriptive error handling, teams could be given mission-type tactics (auftragstaktik) – clear intent like “ensure smooth user experience during cache misses” while leaving the implementation details to those closest to the problem. Rather than letting organisational boundaries dictate our solutions, we could focus on shaping the conditions that turn cache misses into opportunities for delighting users.

Most importantly, Product Aikido reminds us that product development is fundamentally a human enterprise. No amount of technical sophistication can replace the need for implicit communication, trust between teams, and a shared understanding of purpose. Those fecking modal dialogues aren’t just a UX failure -they’re a failure of organisational harmony, a sign that we’ve let our structures work against our purpose rather than with it.

In embracing Product Aikido’s principles, we might find that the path to better products lies not in fighting organisational entropy, but in learning to flow with it.

Leave Things Better Than You Found Them: A Workplace Parable

In every workplace, there’s a simple principle that can transform culture: leave things better than you found them. This timeless wisdom, which extends far beyond its origins in Native American wisdom and ancient farming stewardship, has profound implications for how we work together. A recent consulting engagement brought this principle into sharp focus through what I’ve come to call “The Parable of the Empty Kettle“.

The story unfolds at TechFlow Solutions, where a culture consultant named Sarah Willis observed a seemingly trivial yet revealing pattern. Throughout the day, employee after employee would approach the break room kettle, find it empty, and resignedly refill it themselves—each person losing precious minutes from their busy schedules. More telling still, senior team members would sometimes leave the kettle empty after using it, prioritising their immediate needs over the collective good.

The Ripple Effects of Small Actions

Consider the ripple effects of an empty kettle. Each person who encounters it faces a small but meaningful choice: refill it for the next person, or leave it empty. In choosing the latter, we prioritise our immediate convenience over the collective benefit. We say, in effect, “The next person’s time is less valuable than my own.”

The consulting engagement revealed how this mindset had permeated beyond the break room. The same self-focused behaviour manifested in poorly documented code, rushed handovers, and incomplete knowledge transfers. Each instance represented a missed opportunity to leave things better than they were found.

From Empty Kettles to Cultural Transformation

But the story takes an encouraging turn. When the leadership team recognised this pattern, they began to nurture a culture of collective care. The kettle became a symbol of their transformation. Team members started leaving it refilled, along with encouraging notes for their colleagues. This small change reflected a broader shift in mindset—one that prioritised collective success over individual convenience.

Three months later, this cultural shift had remarkable effects. Not only was the kettle consistently refilled, but sprint commitments were being met, documentation had improved, and team collaboration had strengthened. The simple act of filling a kettle had become a daily reminder of their commitment to leaving things better than they found them.

Beyond the Break Room

This principle, whether applied to a humble office kettle or complex software systems and organisational systems, speaks to a fundamental truth: organisations thrive when their members think beyond their immediate needs to the needs of others. When we consistently act to improve things for those who come after us—be it through thorough documentation, thoughtful code comments, or yes, a refilled kettle—we create an environment of mutual care and consideration. Cf. The Antimatter Principle.

A Daily Choice

The next time you encounter an empty kettle (metaphorical or otherwise) in your workplace, consider it an invitation. Will you merely meet your own immediate needs, or will you take that extra moment to leave things better than you found them? In that choice lies the seed of organisational culture, waiting to flourish or wither based on our daily decisions.

After all, as TechFlow Solutions discovered, a refilled kettle might just be the beginning of a fuller, more collaborative workplace culture.

Undeserving

Understanding Desert

Before we delve deeper, let’s clarify a crucial term. “Desert” (pronounced “dez-ert”), distinct from the arid landscape, refers to what someone deserves or merits. When we speak of desert, we’re examining the very concept of deservingness itself – the idea that certain conditions, rewards, or punishments are merited based on one’s actions, character, or circumstances.

The Treacherous Logic of Deservingness

When we speak of who deserves what, we smuggle in an entire moral framework predicated on judgement and punishment. The very notion of desert carries within it the seeds of violence – both symbolic and material. To declare someone deserving or undeserving is to position oneself as arbiter, to claim the right to determine another’s worth and consequently their access to life’s necessities and pleasures.

The Historical Weight of Desert

Throughout history, ruling classes have wielded deservingness as a weapon to justify existing hierarchies. The poor were deemed undeserving of comfort, women undeserving of autonomy, colonised peoples undeserving of their lands and resources. The language of desert has consistently served to naturalise oppression, transforming systemic violence into seemingly neutral moral assessment.

Beyond the Desert Paradigm

What might it mean to abandon the framework of deservingness entirely? To distribute resources and care not based on assessed worth but on need and relationship? Indigenous cultures worldwide often operate from principles of interdependence rather than individualised desert. When we recognise our fundamental interconnectedness, the question shifts from “What do you deserve?” to “What do we owe each other as beings whose lives are inextricably linked?”

The Violence of Self-Assessment

Perhaps most insidiously, the logic of desert turns inward. We learn to constantly evaluate our own deservingness, to question whether we merit love, rest, or sustenance. This internalised violence manifests as shame, self-denial, and the endless project of trying to prove our worth. The exhausting arithmetic of deservingness becomes a prison of our own making.

Towards Unconditional Positive Regard

Moving beyond desert requires radical reimagining. What if we treated access to food, shelter, healthcare, and dignity as fundamental rights rather than earned rewards? What if we understood care as something we offer not because it is deserved, but because we choose to be in caring relationship with others and ourselves?

The violence of deservingness lies in its false promise of justice through assessment and allocation. True justice might instead arise from refusing the entire framework of desert in favour of an ethic of unconditional care and mutual aid. In this light, we are all, always, gloriously undeserving – and that is precisely why we must care for each other without measure or merit.

Discussing the Concept of the Needsscape

Severla years ago now, I introduced the concept of the Needsscape – a real-time visualisation of the needs of all the Folks That Matter™, whether for a single product team or a whole organisation. Even for yet broader multi-organisation value chains.

Our podcast team deep dives into the concept of the Needsscape – a powerful framework for visualising and understanding how businesses attend to their stakeholders’ needs.

You can listen to this episode here.  (Apols for previously crap link.)

In This Episode

In this episode, we explore how the Needsscape, much like a landscape painting, offers a comprehensive view of an organisation’s value creation through the lens of the needs of the Folks That Matter™. We unpack:

  • The origin of the term, drawing from traditional “-scape” suffixes
  • How the Needsscape relates to the concept of Folks That Matter™
  • Why visualising needs enhances business success

Key Insights

The Essence of Business Value

We examine how all value-adding work essentially boils down to attending to folks’ needs, including:

  • Financial needs of owners, shareholders, and staff
  • Customer needs addressed through products and services
  • Supplier needs for e.g. sustainable revenues, reference customers,. interesting work, etc.
  • Broader societal needs for commerce and prosperity
  • Emotional needs across all the Folks That Matter™

Dynamic Visualisation

Our discussion delves into how the Needsscape serves as a real-time or near-real time visualisation tool for:

  • Tracking evolving needs
  • Planning re: timelines, schedules (and thence to Cost of Delay and Cost of Focus)
  • Making visible needs and progress, status on attending to them
  • Understanding the interconnections between different needs

Why This Matters

Understanding your teams’ or organisation’s Needsscape can transform how you:

  • Make strategic decisions
  • Allocate resources
  • Identify waste
  • Create genuine value
  • Find joy in accomplishment

Join the Conversation

We invite you to listen to this exploration of the Needsscape concept and share your thoughts. How might a real-time visualisation of your organisation’s Needsscape transform your approach to value creation?

Needs, Wants and Human Flourishing

Wants are innumerable, needs are numerable.

The Foundation: What Are Needs?

We often blur the lines between what we truly need and what we simply want. Yet, at its core, human needs remain remarkably constant and countable. These fundamental requirements for survival and basic well-being form a finite set of essentials that, when fulfilled, provide the foundation for human flourishing. This understanding was powerfully articulated by Abraham Maslow in his theory of human motivation, which demonstrated how basic needs must be satisfied before higher-level growth can occur. Marshall Rosenberg later expanded this understanding, emphasising that universal human needs—such as sustenance, safety, connection, understanding, and meaning—are shared across all cultures and form the basis for human connection and conflict resolution. His work showed how recognising and articulating these fundamental needs can transform interpersonal dynamics and societal structures.

The Finite Nature of Numerable Needs

Our basic needs constitute a clear, quantifiable list. Consider shelter—we require protection from the elements, but this needn’t manifest as a sprawling mansion. Similarly, whilst we need sustenance, this translates to a calculable number of calories and nutrients, not endless varieties of gourmet cuisine. Maslow’s hierarchy elegantly arranges these needs from physiological requirements through to safety, belonging, esteem, and self-actualisation.

The Infinite Realm of Innumerable Wants

Whilst our needs remain steadfast and countable, our wants represent an ever-expanding universe of desires. In the digital age, this phenomenon has accelerated dramatically. Yesterday’s cutting-edge mobile phone becomes today’s outdated technology, spawning fresh desires for the latest model. Fashion trends shift like desert sands, creating endless cycles of want and acquisition.

The Marketing Machine: Manufacturing Desires

Modern advertising has mastered the art of transforming simple wants into perceived needs. Through clever psychological manipulation, marketers convince us that the latest trainers or the newest gadgets aren’t merely desirable—they’re essential. This commercial alchemy turns mere wants into seemingly compelling needs.

Finding Balance in a Consumer Society

I invite you to consider how the key to navigating this landscape lies in understanding the crucial distinction between needs and wants. Whilst there’s nothing inherently wrong with pursuing wants—indeed, they can add colour and joy to life—we might choose to maintain perspective. By recognising that needs are finite whilst wants are infinite, we can make more conscious choices about resource allocation, both personally and societally.

The Commercial Dilemma: Profit versus Purpose

Perhaps the most challenging aspect of the needs-wants distinction lies in its commercial implications. Businesses face a stark reality: fulfilling basic needs often yields but modest profits, whilst catering to endless wants can generate substantial returns. Consider the pharmaceutical industry—developing essential medicines for widespread diseases in developing nations typically offers lower profit margins than creating lifestyle drugs for affluent markets. Similarly, construction companies often find luxury developments more lucrative than affordable housing projects.

This creates a profound ethical tension with cascading consequences. Should businesses prioritise addressing fundamental needs, potentially at the cost of their own survival? The dilemma is particularly acute because an organisation that fails while pursuing a needs-based mission ultimately serves no one—those needs then go unmet, and often no other enterprise steps in to fill the void. Yet focusing primarily on profitable wants may ensure organisational survival and provide employment, but at the cost of diverting resources and talent away from addressing essential needs. This dilemma extends beyond individual companies to shape entire economies and societies, creating a troubling paradox where the very attempt to prioritise fundamental needs might lead to their continued neglect through business failure. Maybe business (capitalism) isn’t the answer to best addressing folks’ needs at all?

The Ethical Balance

The resolution perhaps lies not in choosing one path exclusively, but in finding innovative ways to address both. Some organisations have pioneered hybrid models—using profits from want-based products to subsidise need-based initiatives. Others have found ways to make serving basic needs commercially viable through technological innovation and scale. The European model places governments much more centrally in the role of attending to society’s needs. Yet the fundamental tension remains, challenging us to reconsider how we structure our economic systems and incentives.

The Environmental Imperative

In an era of climate crisis, distinguishing between needs and wants takes on new urgency. Our planet’s resources are finite, yet our wants seem to expand exponentially. Understanding this dichotomy becomes crucial for sustainable living and responsible consumption.

Practical Applications for Daily Life

The recognition that needs are numerable whilst wants are innumerable offers practical guidance for:

  • Budgeting and financial planning
  • Product development
  • Environmental decision-making
  • Mental well-being and contentment
  • Social policy and resource allocation

Looking Forward

As we face unprecedented global challenges, this fundamental distinction between needs and wants becomes increasingly relevant. By understanding and embracing this concept, we can work towards a more sustainable and equitable future, ensuring that everyone’s needs are met whilst managing our infinite wants more wisely.

Further Reading

For a deeper understanding of human flourishing, well-being, and the nature of human needs, consider:

Maslow, A. H. (1970). Motivation and personality (2nd ed.). Harper & Row.

Rosenberg, M. B. (2015). Nonviolent communication: A language of life (3rd ed.). PuddleDancer Press.

Seligman, M. E. P. (2011). Flourish: A new understanding of happiness and well-being – and how to achieve them. Nicholas Brealey Publishing.

These seminal works explore the complex interplay between basic human needs and the achievement of our full potential, offering valuable insights into the journey from mere survival to true flourishing.

Deeper Needs

The Siren Song of Unspoken Needs

Imagine a team meeting where Sarah repeatedly questions the details of a new project. Her colleagues see her as someone being difficult; her manager grows frustrated. But beneath these surface interactions lies a deeper reality: Sarah’s unspoken and subconscious need for security in an organisation undergoing change. This scenario is one illustration of the essence of the Antimatter Principle – “attend to folks’ needs” – and reveals why attending to subconscious needs is as crucial as addressing conscious ones.

The Nature of Human Needs

Carl Rogers’ fundamental insight about human nature provides a foundation for understanding the Antimatter Principle. As he observed, “The organism has one basic tendency and striving – to actualize, maintain, and enhance the experiencing organism” (Rogers, 1961, p.11). This basic tendency manifests through both conscious and unconscious needs, driving us toward growth and fulfilment even when we’re not aware of it.

The Challenge of Hidden Needs

The complexity of human needs becomes evident in therapeutic settings. Rogers noted, “It is the client who knows what hurts, what directions to go, what problems are crucial, what experiences have been deeply buried” (Rogers, 1961, p.12). This insight reveals why attending to folks’ needs requires more than just responding to what’s explicitly stated – to be effective, we must create safe spaces for buried experiences and unconscious needs to emerge.

Understanding Patterns of Communication

Virginia Satir’s work provides crucial insight into how needs manifest in our interactions. Her observation that “Problems are not the problem; coping is the problem” (Satir, 1988, p.31) points to how our attempts to meet unconscious needs often create the very difficulties we face in relationships and organisations.

The Language of Needs

Marshall Rosenberg’s Nonviolent Communication framework offers practical tools for uncovering and addressing both conscious and unconscious needs. His insight that “What others do may be the stimulus for our feelings, but not the cause” (Rosenberg, 2003, p.49) helps us separate our interpretation of others’ actions from our own needs and responses.

Furthermore, Rosenberg observed that “All criticism, judgment, diagnosis and expressions of anger are tragic expressions of unmet needs” (Rosenberg, 2003, p.143). This understanding transforms how we view difficult behaviours and conflicts.

Creating Environments That Honor All Needs

The integration of these perspectives reveals three key principles for applying the Antimatter Principle:

  1. Empathy Before Action
    • Notice patterns of behavior
    • Look beneath surface reactions
    • Consider context and environment
  2. Connection Through Unconditional Postive Regard
    • Observe without evaluating
    • Identify feelings without judging
    • Uncover needs without jumping to strategies
    • Make requests without demanding i.e. “refusable requests”
  3. Transformation Through Attention
    • Create safe spaces for needs to emerge
    • Respond to both spoken and unspoken needs
    • Allow solutions to arise naturally

Real-World Applications

Case Study: The Transformative Team Meeting

When a software team adopted the Antimatter Principle, they transformed their daily stand-ups. Instead of just reporting status, they created space for team members to express concerns and needs. The result? Improved collaboration, reduced stress, and more innovative solutions.

Case Study: Leadership Evolution

A department head struggled with high turnover until she began attending to folks’ unconscious and unvoiced needs. By noticing patterns of withdrawal and resistance, she discovered her team’s deep need for autonomy and recognition. Her shifted approach led to increased engagement and retention.

The Path Forward

The Antimatter Principle invites us to look deeper than surface behaviors and explicit requests. By understanding that all behaviors – even difficult ones – express attempts to meet fundamental human needs, we can create environments where both conscious and unconscious needs are acknowledged and addressed.

Concluding Insights

The Antimatter Principle, enriched by these humanitarian perspectives, becomes a powerful tool for transformation. It challenges us to look deeper, listen more carefully, and respond more completely to the full spectrum of human needs. In doing so, we create possibilities for deeper connections and more effective actions in all our human interactions.


Further Reading:

Rogers, C. R. (1961). On Becoming a Person: A Therapist’s View of Psychotherapy. Houghton Mifflin.

Rosenberg, M. B. (2003). Nonviolent Communication: A Language of Life. PuddleDancer Press.

Satir, V. (1988). The New Peoplemaking. Science and Behavior Books.

The Brutal Truth About Why Companies Sell You What You Want (Even When It’s Bad for You)

The Allure of Superficial Wants

Commercial success in today’s marketplace hinges on a deceptively simple principle: give people what they want. It’s a formula that has built empires, from fizzy drinks giants to fast-fashion behemoths. These companies haven’t achieved their staggering profits by focusing on what might genuinely benefit their customers—their needs. They’ve mastered the art of fulfilling (and often manufacturing) wants.

Yet this relentless pursuit of wants creates a moral quandary. Whilst businesses rack up profits by satisfying our cravings for sugar-laden snacks, fast fashion, and endless entertainment, they often actively undermine what we genuinely need: nutritious food, sustainable clothing, and meaningful uses of our time. The painful truth is that these companies aren’t necessarily villains—they’re simply playing by the rules of a system where commercial success and moral success rarely intersect.

The Quieter Call of Deeper Needs

What we truly need—proper nutrition, meaningful relationships, physical exercise, mental stimulation—often lacks the glamour and attraction of our wants. A quiet evening reading a book rarely generates the same immediate excitement as scrolling through social media, despite being potentially more fulfilling.

Healthcare provides a stark example of this dichotomy. Private healthcare companies profit more from selling comfortable but unnecessary procedures than from providing essential preventive care. The commercial incentive often aligns with patient wants (immediate relief, cosmetic improvements) rather than patient needs (lifestyle changes, preventive measures).

A Business Conundrum

Profit vs Purpose

Businesses face a genuine ethical dilemma. Their survival depends on commercial success, yet their moral obligation might require steering customers toward choices that are less immediately appealing but more beneficial in the long run.

Consider publishing houses: Might they prioritise publishing self-help books promising quick fixes (what people want) or more challenging works that promote deeper understanding and personal growth (what people need)?

Rare Alignment

Occasionally, but oh so rarely, wants and needs do align. Consider farmers’ markets that make locally-grown, seasonal produce fashionable, responsible, ethical and nutritious. They’ve managed to transform the essential need for healthy, sustainable food into something people actively desire. However, these instances are exceptions rather than the rule.

Breaking the Cycle

To address this dilemma, both businesses and consumers might choose to evolve. Companies could invest in educating consumers about their true needs whilst making necessary products and services more appealing. Meanwhile, consumers might benefit from more mindful consumption. Fat chance.

A Personal Reflection

To better understand this tension, ask yourself: what would you rather have, today—what you want, or what you need?

In answering this question, consider your recent purchases. How many served genuine needs versus momentary wants? How often have you chosen immediate gratification over long-term benefit?

This reflection might reveal uncomfortable truths about our consumption habits, but it could also guide us toward learing about more meaningful choices in both our personal lives and our business practices.

The Attendant Role: Focussing on Folks’ Needs

Introduction: A Paradigm Shift

In an era dominated by technological advancements, organisations have long placed software developers on a pedestal. But what if this focus is fundamentally misaligned with true business needs? Is it time to challenge the status quo and consider a rethought approach: the rise of the attendant?

The Software Illusion

For decades, we’ve conflated software capability with business success. The mantra has been clear: more software equals more progress. But this equation is fundamentally flawed. Organisations don’t need lines of code; they need solutions to real-world problems and ways to serve their customers better.

As Steve Jobs famously said:

“The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs

Introducing the Attendant: The Unsung Hero of Business

Enter the attendant – not just a job title, but a mindset and approach to work. Attendants are individuals who possess an uncanny ability to understand and address the needs of the “Folks That Matter™” – customers, employees, management, and  shareholders alike.

The Attendant Skill Set: More Than Meets the Eye

Attendants bring a unique blend of skills to the table:

  1. Empathetic listening
  2. Systems thinking
  3. Adaptive problem-solving
  4. Cross-functional communication
  5. Customer journey mapping
  6. Resource wrangling

These skills enable attendants to see beyond surface-level issues and address the real needs of the Folka That Matter™.

From Code-Centric to Human-Centric: The Attendant Advantage

By prioritising attendants, organisations can achieve:

  • Deeper customer insights leading to innovative solutions
  • Streamlined processes that actually work for employees
  • Reduced waste from misaligned technology investments
  • A culture of quality and adaptation

The Vanguard Method: A Blueprint for Attendant-Led Transformation

John Seddon’s Vanguard Method provides a framework that aligns perfectly with the attendant approach:

  1. Understand customer demand in customer terms
  2. Redesign work as a system to meet that demand
  3. Embed new thinking and practice through continuous learning
  4. Defer software implementation until after business processes have been reengineered (“Software Last”).

This method forms the backbone of attendant-driven product (and process) development.

Implementing the Attendant Model: A Roadmap

To embrace the attendant model, organisations might choose to:

  1. Redefine success metrics around outcomes for all the Folks That Matter™
  2. Invest in developing attendant skills across all levels
  3. Create cross-functional “attendant teams” to tackle larger products and more complex issues
  4. Implement regular “gemba walks”and dialogues with the Folks That Matter™ to stay connected with front-line realities
  5. Establish feedback loops that prioritise customer, employee and other voices

Proving Value: The Attendant Approach in Action

Before even considering software solutions, organisations might:

  1. Conduct immersive customer research using ethnographic methods
  2. Prototype low-tech solutions and iterate based on real-world feedback
  3. Use visualisations to make system performance visible to all
  4. Engage the Folks That Matter™ in participatory design workshops

Only after these steps have yielded tangible improvements can technology be considered as a scaling tool.

Technology’s New Role: Amplifying Human Potential

In an attendant-enabled organisation, technology takes its rightful place as a supporter, not a driver, of change. Software becomes a tool to augment human capabilities, not replace them.

Conclusion: The Future is Attendant

As we stand at the crossroads of technological innovation and human-centered design, the choice is clear. Organisations that embrace the attendant model – focusing on understanding and meeting human needs before jumping to technological solutions – will be the ones that thrive in the coming decades.

The future of business isn’t about having the most advanced software; it’s about having people who can truly attend to the needs of those who matter most. By putting attendants at the forefront, we can create organisations that are not just speciously efficient, but genuinely effective in serving their purpose.

Are you ready to join the era of attendants?

Meaning and Purpose

In a world where burnout and disengagement are rampant, discovering meaning and purpose in our work has never been more crucial. But how can we transform our daily grind into a source of fulfilment and motivation? Let’s explore this vital question through the lenses of two pioneering thinkers and some practical, real-world applications.

The Wisdom of Viktor Frankl: Finding Light in the Darkest Places

Viktor Frankl (1905-1997), a renowned Austrian neurologist and psychiatrist, developed a revolutionary therapeutic approach known as logotherapy. But Frankl’s journey to this profound insight was forged in the crucible of unspeakable suffering.

As a Jewish psychiatrist in Vienna during World War II, Frankl was deported to Nazi concentration camps, including Auschwitz and Dachau. He endured three years of unimaginable hardship, losing his parents, brother, and pregnant wife to the Holocaust. It was through this harrowing experience that Frankl’s theories about the importance of meaning in human life were tested and solidified.

Logotherapy, often called the “Third Viennese School of Psychotherapy” (after Freud’s psychoanalysis and Adler’s individual psychology), is based on the premise that the primary motivational force in humans is the search for meaning. The term “logotherapy” is derived from the Greek word “logos,” which Frankl uses to denote “meaning.”

What sets logotherapy apart is its emphasis on the future rather than the past. Instead of dwelling on past traumas or subconscious drives, logotherapy focuses on the meanings to be fulfilled by the patient inow and n their future. This forward-looking approach makes it particularly relevant in our modern context, where many struggle to find purpose in an increasingly complex and sometimes alienating world.

Frankl’s experiences in the concentration camps led him to a startling observation: those who were able to hold onto a sense of meaning and purpose, even in the most dire circumstances, had a better chance of survival. He noticed that prisoners who had a reason to live – be it a loved one waiting for them, an unfinished work, or a deep-seated belief – were more resilient in the face of unimaginable hardship.

This school of therapy emphasises the importance of finding meaning in life, even – or especially – in the face of extreme suffering. Frankl argued that while we cannot avoid suffering, we can choose how to cope with it, find meaning in it, and move forward with renewed purpose. This idea is encapsulated in one of his most famous quotes:

“Everything can be taken from a man but one thing: the last of human freedoms – to choose one’s attitude in any given set of circumstances, to choose one’s own way.”

Frankl’s approach suggests that meaning can be found in three primary ways:

  1. By creating a work or doing a deed (creative values)
  2. By experiencing something or encountering someone (experiential values)
  3. By the attitude we take toward unavoidable suffering (attitudinal values)

These principles, born from the darkest chapter of human history, offer a powerful framework for finding purpose and meaning not just in therapy, but in all aspects of life – including our work.

In the context of our working lives, logotherapy invites us to look beyond mere job satisfaction or career success. It challenges us to find deeper meaning in our daily tasks, to see our work as a contribution to something greater than ourselves, and to maintain a sense of purpose even when faced with workplace challenges or disappointments.

As we delve deeper into the application of these ideas in the workplace, we’ll see how Frankl’s profound insights can transform our relationship with work, turning it from a source of stress or mere livelihood into a wellspring of meaning and personal fulfilment.

Daniel Pink’s Drive: The Surprising Truth About What Motivates Us

In his book “Drive”, American author Daniel Pink explores the elements that truly motivate individuals in the modern workplace. He argues that traditional carrot-and-stick approaches are often ineffective, particularly for complex, creative taskssuch as software development.

The Three Elements of True Motivation

Pink identifies three key components of intrinsic motivation:

  1. Autonomy: The desire to direct our own lives and work.
  2. Mastery: The urge to continually improve at something that matters.
  3. Purpose: The yearning to do what we do in service of something larger than ourselves.

Pink’s research suggests that when these three elements are present, individuals are more likely to be engaged and satisfied in their work, and thus happier and more productive. This insight challenges traditional management practices and calls for a reimagining of how we structure work and motivate employees.

The Synergy of Meaning and Purpose

While Frankl’s concept of meaning and Pink’s notion of purpose may seem distinct, they are, in fact, closely intertwined. Both emphasise the importance of connecting one’s work to a greater cause or ideal. Frankl’s logotherapy provides a philosophical foundation for understanding why meaning is crucial, while Pink’s research offers practical insights into how to foster that sense of meaning and purpose in the workplace.

Beyond the Company Mission: Expanding Our Horizons

While we might place some import on understanding our role in achieving company goals, true meaning often comes from seeing the bigger picture. Here’s some ways to broaden your perspective:

1. Connect Your Work to Societal Impact

  • Trace Your Impact: Map out how your work ripples through society. A software developer isn’t just writing code; they’re potentially improving healthcare systems or making education more accessible.
  • Share Success Stories: Collect and share anecdotes about how your work has positively affected real people’s lives.

2. Fuel Personal Growth

  • Skills Inventory: Regularly update a list of new skills you’ve gained. How have recent challenges expanded your capabilities?
  • Relationship Web: Map out the professional relationships you’ve built. How have these connections enriched your life and others’?

3. Align with Your Values

  • Values Check-In: Periodically assess how your work aligns with your core values. Where are the synergies? Where are the conflicts, and how can you address them?
  • Ethical Impact: Consider the ethical implications of your work. Are you contributing to a more just and sustainable world? Does that even matter to you?

4. Amplify Your Impact on Family and Community

  • Family Mission Statement: Create a family mission statement. How does your work contribute to your family’s goals and well-being?
  • Skill Donation: Use your work-related skills to support a local cause. A marketer could help a non-profit with their campaigns, for example.

5. Embrace Global Citizenship

  • Sustainability Audit: Assess your work’s environmental impact. Does that impact matter to you? Can you champion more sustainable practices in your role?
  • Cross-Cultural Bridges: Highlight opportunities to foster cross-cultural understanding through your work, even in small ways.

Practical Steps to Cultivate Meaning and Purpose

  1. Purpose Journaling: Spend 5 minutes at some point in each workday reflecting on moments of meaning and purpose.
  2. Impact Visualization: Create a visual representation of your work’s ripple effect on the world. Update it regularly.
  3. Value-Aligned Goal Setting: Set professional goals that align with your personal values and larger life purpose.
  4. Mentor or Be Mentored: Engage in mentorship to gain new perspectives and multiply your impact.
  5. Purpose-Driven Innovation: Propose projects or improvements that align more closely with your sense of purpose and the greater good.

The Ripple Effect: From Individual Purpose to Organisational Transformation

As more individuals connect with their sense of purpose at work, organisations transform. They become more than profit-generating entities; they evolve into forces for joy and positive change in the world. This shift not only benefits employees and companies but contributes to addressing global challenges and creating a more meaningful, purposeful society.

Remember, finding meaning and purpose is not a destination but a journey. It requires ongoing reflection, adjustment, and action. By integrating these ideas into our daily work lives, we can transform our relationship with work from a source of stress to a wellspring of fulfilment and positive impact.

What step will you take today to infuse more meaning and purpose into your work, and life?

The Elusive Quest for “Better Software”

The Mirage of “Better”

In the relentless pursuit of technological advancement, the software industry has long been fixated on a nebulous concept: “better software”. But what if we’ve been chasing a mirage? What if our definition of “better” has been fundamentally flawed from the start?

Deconstructing the ‘Better’ Fallacy

The Metrics Trap

Traditionally, we’ve measured software quality through a narrow lens:

  • Speed and performance
  • Feature richness
  • UI sophistication
  • Reliability and uptime

While these metrics have their place, they paint an incomplete picture. They’re the equivalent of judging a book solely by its cover and page count, ignoring the depth and relevance of its content.

Introducing the Needsscape™: A Radical Paradigm

To truly elevate software development, we need to shift our focus to what I call the Needsscape™—a multidimensional terrain that maps the intricate and ever-evolving web of needs, desires, and pain points across all the Folks That Matter™.

Navigating the Needsscape™

The Needsscape™ encompasses four critical dimensions:

  1. Functional Needs: The tangible, practical requirements of the software.
  2. Emotional Needs: The often-overlooked psychological and emotional impact on all the Folks That Matter™.
  3. Contextual Needs: How the software fits into and enhances existing systems, product lines, ecosystems and workflows.
  4. Hidden Needs: The unspoken, sometimes subconscious desires that, when addressed, can transform folks’ experiences.

The Forgotten Stakeholders: Expanding Our Horizon

When we talk about the Folks That Matter™, our focus often narrows to end-users and perhaps upper management. But the Needsscape™ reveals a far more complex and dynamic tapestry of individuals – and groups  -whose needs we might choose to consider:

  • Development Teams: How does the software architecture impact their work-life balance and professional growth?
  • Support Staff: Are we creating systems that empower them to provide exceptional service?
  • Operations Teams: How does our software design affect system maintenance and scalability?
  • Sales and Marketing: Does the product align with market needs and tell a compelling story?
  • Diverse End-Users: How can we create inclusive solutions that serve users across different abilities, cultures, and contexts?

From Feature Bloat to Meaningful Innovation

The industry’s obsession with feature accumulation has led us astray. We’ve created bloated, complex systems that often solve the wrong problems—or worse, create new ones.

The Power of Subtraction

Sometimes, the most significant improvements come not from adding features, but from ruthlessly eliminating unnecessary complexity. By deeply understanding the Needsscape™, we can:

  • Identify and remove features that add cognitive load without proportional value.
  • Streamline workflows to match natural human processes.
  • Create intuitive interfaces that feel “invisible”, allowing users to focus on their goals rather than the tool itself.

Empathy as a Core Competency

The most critical skill in navigating the Needsscape™ isn’t technical prowess—it’s empathy. We might choose to cultivate a deep, almost intuitive understanding of our stakeholders’ lived experiences.

Practical Empathy in Action

  • Immersive Observation: Go beyond user interviews. Spend days shadowing different stakeholders, experiencing their frustrations and victories firsthand.
  • Cross-Functional Empathy Workshops: Bring together diverse teams to role-play different stakeholders, fostering a holistic understanding of the Needsscape™.
  • Continuous Feedback Loops: Implement systems for ongoing, qualitative feedback that captures the evolving nature of stakeholder needs and the dynamics of the Needsscape™.

Redefining Success: New Metrics for a New Era

If we’re to truly create “better” software, we need metrics that reflect the multidimensional nature of the Needsscape™:

  • Stakeholder Flourishing Index: Measure how the software contributes to the professional and personal growth of all the Folks That Matter™.
  • Ecosystem Impact Score: Evaluate how the software enhances or disrupts existing workflows and systems.
  • Cognitive Load Reduction Metric: Quantify how much mental effort the software saves across different user groups.
  • Adaptability Quotient: Assess how easily the software can evolve to meet changing needs without accumulating technical debt.

The Path Forward: A Call to Action

Creating truly better software isn’t about chasing the latest technological trends. It’s about fundamentally reimagining our approach to development and truly serving the Folks That Matter™,:

  1. Embrace the Needsscape™: Make it a core part of your development philosophy and process.
  2. Cultivate Radical Empathy: Invest in developing teams’ ability to deeply understand and relate to all the Folks That Matter™.
  3. Value Subtraction: Celebrate the removal of unnecessary complexity even more than the addition of new features.
  4. Redefine Metrics: Implement holistic success measures that reflect the true impact of your software.

By shifting our focus from arbitrary notions of “better” to a nuanced understanding of the Needsscape™, we can create software that doesn’t just impress with its technical specifications, but profoundly improves the lives of all it touches. This is the true meaning of innovation—and the future of software development.

Enhancing Software Development Outcomes

A Cornucopia of Techniques

In the realm of software development, teams have at their disposal a rich array of techniques designed to raise productivity and outcomes. These techniques, evolved over decades, and championed by thought leaders in their respective fields, offer unique approaches to common challenges. Let’s explore some of the most notable ones:

Gilb’s Evolutionary Project Management (Evo)

Tom Gilb’s Evo technique emphasises incremental delivery and the use of quantification, focusing on delivering measurable value to the Folks That Matter™ early and often throughout the development lifecycle.

Goldratt’s Theory of Constraints (TOC)

Eliyahu Goldratt’s TOC encourages teams to identify and manage the primary bottlenecks in their processes, thereby improving overall system performance.

Ackoff and Systems Thinking

Russell Ackoff’s techniques promote viewing problems holistically, considering the interconnections between various parts of a system rather than addressing issues in isolation.

Seddon’s Vanguard Method

John Seddon’s Vanguard method advocates for understanding work as a system, focusing on customer demand and designing the organisation to meet that demand effectively.

Rother’s Toyota Kata

Mike Rother’s Toyota Kata is a practice routine that helps teams develop scientific thinking skills, fostering a culture of continuous improvement and adaptation.

Deming’s System of Profound Knowledge

W. Edwards Deming’s System of Profound Knowledge is a management philosophy that emphasises system thinking, understanding variation, and the importance of intrinsic motivation in the workplace. SoPK consists of four main themes:

  1. Appreciation for a System
    • Understanding how different parts of an organisation interact and work together
    • Recognising that optimising individual components doesn’t necessarily optimise the whole system
  2. Knowledge about Variation
    • Understanding the difference between common cause and special cause variation
    • Recognising when to take action on a process and when to leave it alone
  3. Theory of Knowledge
    • Emphasising the importance of prediction in management
    • Understanding that all management is prediction and that learning comes from comparing predictions with outcomes
  4. Psychology
    • Understanding human behaviour and motivation
    • Recognising the importance of intrinsic motivation over extrinsic rewards and punishments

Marshall’s Organisational Psychotherapy

My own field of Organisational Psychotherapy focuses on techniques for addressing the collective assumptions and beliefs of an organisation, aiming to improve outcomes and overall effectiveness through overhauling these shared assumptions.

The Adoption Quandary

Whilst these various techniques offer glittering avenues for improvement, many development teams find themselves at a crossroads. The crux of the matter lies in two key questions:

  1. Will the effort invested in mastering one or more of these techniques yield a worthwhile return?
  2. More fundamentally though, can we muster the motivation to make the necessary effort?

The Crux: Self-Motivation

The second question is the more critical of the two. It’s not merely about the potential payoff; it’s about the willingness to embark on the journey of learning and mastery in the first place. Crucially, this motivation must emanate from within the team itself, rather than relying on external factors.

Surmounting Inertia

Change is inherently challenging, and the comfort of familiar practices can be a powerful deterrent to adopting new techniques. Teams rarely find the inner drive to overcome this inertia and push themselves towards new horizons.

Nurturing a Desire for Self-Betterment

Fostering a culture that values learning and self-betterment is paramount. When team members view challenges as opportunities for growth rather than insurmountable obstacles, they’re more likely to embrace new techniques. This mindset shift must be initiated and nurtured by the team itself.

Peer-Driven Inspiration

In the all-too-common absence of top-down motivation, teams can look to each other for inspiration and encouragement. By sharing successes, discussing challenges, and collaboratively exploring new techniques, team members can create a supportive environment that fuels self-betterment.

Individual Responsibility

Each team member bears the responsibility for their own personal and professional development. By setting personal goals for improvement and actively seeking out opportunities to learn and apply new techniques, individuals can drive the team’s overall progress.

Conclusion

While the array of available techniques to improve development team outcomes is legion, the true challenge lies not in their complexity or the time required to master them. Rather, it’s in cultivating the self-motivation to pursue excellence and adopt such techniques.

As we ponder the question, “Can we be bothered to make the effort to improve ourselves, our capabilties and our outcomes?”, we must remember that the most successful teams are those who answer with a resounding “Yes” – not because they’re compelled to, but because they genuinely desire to excel. It is this intrinsic commitment to growth and improvement that ultimately distinguishes high-performing teams from the rest. And if the outcomes are simply making the rich (management, shareholders) richer, then none of this is likely to happen.

The journey of improvement commences with a single step, taken not because someone else pushed us, but because we ourselves choose to move forward. In the end, the power to transform our outcomes lies within our own hands. The techniques are there, waiting to be explored and mastered. The question remains: are we ready to take steps towards a better future for ourselves, our teams and our lives? Do we need it?

Postscript

By the bye, this subject was the topic of my keynote at Agile Spain, 2016 2 December 2016, in Vitoria Gasteiz.

The Antimatter Principle Definition of “Done”

When is a product truly “done”? In the world of software and product development, this question sparks endless debate. Requirements shift, stakeholders disagree, and goalposts continuously move. But the Antimatter Principle offers a refreshing perspective.

The Antimatter Principle

According to the Antimatter Principle, a product is done when all the needs of all the folks that matter have been adequately* met. Seems simple enough, right? But unpacking this requires digging a bit deeper.

Who Are the “Folks That Matter”?

The Folks that Matter™ encompass everyone with a stake in the product’s success – developers, designers, customers, business leaders, investors, regulators, and more. Identifying and prioritising their diverse needs is the primary critical effort.

Meeting Needs “Adequately”

What does it mean to meet needs adequately? This involves coming to understand what each group within the Folks That Matter™ consider adequate. Perfect is the enemy of good, so aiming for adequacy keeps efforts focused on delivering value efficiently.

An Ongoing Process

Even with this guiding principle, “done” is rarely final. Customers’ and society’s needs evolve, technology advances, and business contexts shift. So in truth, being “done” is more of an ongoing cycle of continuous delivery, iteration and adaptation.This, BTW, is a compelling argument in favour of *product* development over “projects” (and see: #NoProjects).

Embracing the Ambiguity

Ultimately, there is no universal “Definition of Done” that works for every product and context. But applying the Antimatter Principle helps teams embrace ambiguity, align efforts, and keep moving their products meaningfully forward.

By keeping the Folks That Matter™ at the centre and striving to understand and meet their core needs adequately, teams can navigate the path to “done” with clarity and purpose – even as that path keeps winding.