Archive

NoSoftware

‘Head of Software’ is the Most Ridiculous Job Title in Tech

August 31, 2025
Action, Antimatter principle, Article, NoSoftware
Leave a comment

‘Head of Software’ is the Most Ridiculous Job Title in Tech

‘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

Steve Jobs understood something that most tech companies today have never grasped: software isn’t the solution—it’s the problem we’re trying to avoid.

So why are we hiring people whose entire job is to create more of it?

The Fundamental Absurdity

Appointing a ‘Head of Software’ is like hiring a ‘Chief of Pollution’ or ‘VP of Bureaucracy’. You’ve just put someone in charge of expanding the very thing you’re trying to minimise.

Every line of code is technical debt waiting to happen. Every feature is a maintenance burden. Every interface is a potential point of failure. The most productive thing any programmer can do is attend to folks’ needs whilst writing less code, not more.

Yet here we are, creating management positions dedicated to producing more software. It’s organisational insanity.

Who Actually Needs Less Code?

Here’s where it gets interesting. Almost everyone in your organisation benefits from less code:

Users don’t care about code at all—they want their problems solved simply and reliably. Every additional line of code is a potential source of bugs, slowdowns, and confusing interfaces.

Future developers (including your current team six months from now) need less code because they’re the ones who have to understand, debug, and modify what gets written today.

Operations teams need less code because simpler systems break less often and are easier to troubleshoot at 3 AM.

Support teams need less code because fewer features means fewer ways for users to get confused or encounter problems.

Finance teams need less code because maintenance costs scale directly with codebase size.

Security teams need less code because every line of code represents potential attack surface.

Management needs less code because simpler systems deliver faster, cost less to change, and are easier to understand and plan around.

Executives need less code because it means lower operational costs, faster competitive response, and fewer technical risks that could derail business objectives.

So who actually wants more code? Primarily the people whose careers depend on managing complexity: consultants who bill by the hour, developers who equate job security with irreplaceable knowledge of arcane systems, and—you guessed it—Heads of Software whose organisational importance scales with the size of their technical empire.

The incentive misalignment becomes crystal clear when you realise that almost everyone in the company benefits from less software except the person you’ve put in charge of it.

What the #NoSoftware Movement Gets Right

The smartest companies are embracing what Seddon (2019) calls ‘software last’—the radical idea that maybe, just maybe, we try solving problems without software first.

Post-it notes don’t have bugs. Paper processes don’t need security patches. Manual workflows don’t crash at 3 AM. When you implement a #NoSoftware solution, you get:

  • Immediate deployment (no months of development)
  • Zero maintenance costs (no code to update)
  • Perfect flexibility (change the process instantly)
  • No technical debt (because there’s no tech)

But if your organisation has a ‘Head of Software’, this person’s career incentives are most likely completely misaligned with these benefits. Their success is measured by building more software, not by eliminating the need for it.

The Perverse Incentives Problem

A ‘Head of Software’ faces a career-ending dilemma: if they’re truly successful at their job, they work themselves out of a job.

Think about it:

  • Their budget depends on having software to manage
  • Their team size depends on code that needs maintaining
  • Their importance depends on systems that require oversight
  • Their promotion prospects depend on shipping new features

Every line of code they don’t write threatens their organisational relevance. Every problem they solve without software makes their department smaller. Every process they streamline through manual methods reduces their empire.

This creates the most backwards incentive structure imaginable. Invitation: reward the person who eliminates software, not he or she who maximises it.

A Different Approach

The problem isn’t just the titles—it’s also the incentives.

Any technology leader, regardless of their title, can be measured by outcomes that matter: needs met, customer satisfaction, business agility, time-to-market, operational efficiency. Not by lines of code shipped or systems deployed.

The best CTOs and VPs of Engineering already understand this. They’re constantly asking ‘do we really need to build this?’ and ‘what’s the simplest solution?’ They default to buying instead of building, to manual processes instead of automation, to elimination instead of addition.

The Real Problem: We’re Solving for the Wrong Thing

Successful businesses do best when they focus on attending to folks’ needs. Not technology needs. Not organisational needs. Not even business needs in the abstract—but the actual needs of real people.

When you create a ‘Head of Software’ role, you’re explicitly organising around technology instead of around folks. You’re saying that software is important enough to deserve dedicated leadership, whilst the people who use that software get… what? A ‘Head of Customer Success’ buried three levels down in the org chart?

This backwards prioritisation shows up everywhere:

  • Product roadmaps driven by technical capabilities rather than user problems
  • Success metrics based on system performance rather than user outcomes
  • Resource allocation favouring engineering elegance over customer value
  • Decision-making that asks ‘can we build this?’ before asking whether we have a customer problem worth solving

The most successful companies flip this entirely. They organise around customer needs and treat technology as a servant, not a master.

The Hidden Costs of Technology-First Thinking

When you organise around a ‘Head of Software’, you’re committing to a worldview where every problem looks like a coding opportunity:

  • New process needed? Build an app.
  • Communication breakdown? Create a dashboard.
  • Data scattered? Write integration scripts.
  • Users confused? Add more features.

This technology-first thinking ignores what folks actually need and the true costs:

  • Development time (months before you can even test the idea)
  • Maintenance burden (forever ongoing costs)
  • Complexity debt (every feature makes the next one harder)
  • Opportunity costs (whilst you’re coding, competitors are executing)

The Post-it Note Test

Here’s a simple test for any ‘Head of Software’ candidate: ask them to solve their three most recent workplace problems using only Post-it notes, conversations, and manual steps.

If they can’t even conceive of non-software solutions, they’re exactly the wrong person for the job. You’re hiring someone whose only tool is a hammer in a world full of problems that aren’t nails.

What Steve Jobs Would Do

Jobs didn’t revolutionise technology by hiring software heads—he revolutionised it by eliminating software complexity. The original iPhone succeeded because it made smartphones feel simple, not because it had more features than competitors.

If Jobs were running your company, he’d probably fire the ‘Head of Software’ and replace them with someone whose job was to remove features, simplify workflows, and make technology invisible.

The #NoSoftware Career Path

Instead of promoting people for building systems, consider promoting them for eliminating systems:

  • Junior Process Designer: Makes workflows efficient without code
  • Senior Simplification Specialist: Removes unnecessary software from existing processes
  • VP of Manual Excellence: Proves complex processes can work with simple tools
  • Chief Elimination Officer: Responsible for company-wide software reduction

Watch how this changes everything. Suddenly your best people are incentivised to solve problems the fastest, cheapest, most flexible way possible—which is almost never more software.

The Bottom Line

Every successful ‘Head of Software’ will eventually eliminate their own position. If they’re doing their job right, they make software so unnecessary that the company doesn’t need someone to manage it.

But that will never happen as long as we reward people for creating software instead of eliminating it.

The next time someone suggests hiring a ‘Head of Software’, ask them this: ‘What’s the #NoSoftware solution we’re trying first?’

If they don’t have an answer, you’ve found your real problem.

The most productive programmer is the one who writes no code. The most valuable software leader is the one who makes software unnecessary. And the smartest companies are the ones brave enough to commit to #NoSoftware.

Further Reading

Seddon, J. (2019). Beyond command and control. Vanguard Consulting.

The Ocean

April 29, 2025
Antimatter principle, Article, Attendants, Metaphors, NoSoftware, Software development
Leave a comment

The Ocean

An Alternative Metaphor to the Forest and Desert

Never one to take an idea as-is, here’s my extension to the Forest and Desert metaphor: the Ocean. On the ocean, landlubbers are all at sea. And it takes some time to find one’s sea legs. More prosaically, the Ocean suggests land-oriented metaphors miss the point: #NoSoftware, attendants attending to folks’ needs, rather than developers developing software, etc.

The Limitations of Land

The Forest and Desert metaphor, conceived by Beth Andres-Beck and her father Kent Beck, offers us a powerful way to understand the divide between different software development approaches. The Desert (working inside a joyless analytically-minded organisation) represents the harsh reality many teams face: scarce resources, plentiful bugs, uncultivated skills, and difficult communications with users. The Forest, meanwhile, depicts the lush environment of well-run teams using practices like Extreme Programming, where changes flow swiftly into production, protected by tests, code is nurtured, and there’s regular contact with The Customer.

Yet I wonder if land-based metaphors, however illuminating, ultimately constrain our thinking? Actually, I’m dead certain they do.

Setting Sail for New Horizons

What if we ventured beyond the confines of land altogether? What if the most advanced software development approaches weren’t about making better forests but about learning to navigate an entirely different element—the Ocean?

The Ocean isn’t merely an extension of the Forest; it represents a paradigm shift where the very notion of “software development” begins to dissolve.

The Ocean Paradigm

Leaving Land Behind

In the Ocean paradigm, we’re no longer Forest Dwellers trying to convert Desert Dwellers. Instead, we’re sailors who’ve recognised that the most progressive teams have left the constraints of land entirely. The Ocean represents a radical alternative to any kind of software development—where software itself is downplayed or even disappears in favour of attending to folks’ needs directly. The true challenge isn’t converting Desert to Forest; it’s helping land-dwellers understand that the future lies offshore, beyond software altogether.

Landlubbers All at Sea

When Desert Dwellers visit a Forest, they may feel uncomfortable, but they still recognise the ground beneath their feet. When they encounter an Ocean team, however, they’re utterly disoriented—they’re “all at sea.” The language, practices, and mindsets seem not merely different but alien.

The Ocean team doesn’t talk about “developing software” but about “attending to folks’ needs.” They don’t discuss “requirements” but “who matters?” They don’t “deploy code” but “deliver value.”

Finding Your Sea Legs

Just as sailors need time to adjust to the constant motion of a ship, newcomers to Ocean teams need time to develop their “sea legs.” This adaptation isn’t merely about learning new practices; it’s about fundamentally changing one’s relationship to stability, certainty, and control.

In the Ocean, change isn’t a disruption to be managed but the medium in which we exist. Uncertainty isn’t a risk to be mitigated but a reality to be embraced.

Ocean Practices: Beyond Software Development

#NoSoftware

As Steve Jobs observed

“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.”

In the Ocean paradigm, this insight takes on profound significance—the best software is often no software at all.

In this worldview, software is no longer the product; it’s merely the medium, and oftentimes an unnecessary one. Ocean teams don’t focus on “building better software” but on “better meeting folks’ needs”. Software is merely the water through which value flows, and the less of it needed, the better.

When a team reaches true Ocean-thinking, they paradoxically care less about the software itself and more about the needs it meets. They’re ruthlessly people-focussed, willing to discard elegant code or sophisticated architecture if a simpler approach better serves the need—or to eliminate code entirely when a non-software solution would work better.

Attendants, Not Developers

In this paradigm, we’re not “developers” but “attendants“—our role isn’t to build things but to attend to needs. We’re not constructing a product but facilitating a service.

This shift in identity is profound. The attendant doesn’t ask, “How do I build this feature?” but “How do I attend to folks’ needs?” The first question assumes that software is the answer; the second remains open to all possibilities.

Fluid Architecture

Ocean architectures aren’t rigid structures but fluid arrangements that flow and adapt. They’re not designed once and built to last; they’re constantly evolving, components washing in and out as needs change.

In the Ocean, microservices aren’t an architectural style but a natural expression of fluid boundaries. Systems aren’t “decomposed” into services; they naturally arrange themselves around folks and their needs.

The Ocean’s Challenges

The Vastness

The Ocean is vast and can be overwhelming. Without the familiar landmarks of land, newcomers often feel lost. The freedom that comes with Ocean thinking can be paradoxically paralyzing—with so many possibilities, where does one begin?

The Storms

The Ocean isn’t always calm. Market changes, emerging technologies, and evolving user needs can create perfect storms that test even the most seasoned crews. Unlike Forest teams, who can find shelter under the canopy, Ocean teams must learn to sail through storms, sometimes changing course entirely.

As John Shedd observed:

“A ship in harbor is safe — but that is not what ships are built for.”

i.e. A developer writing code might feel safe, but that’s not what developers are for.

The Depths

Beneath the surface lie depths that few explore. The technical implications of truly embracing the Ocean mindset go far beyond conventional practices. Concepts like joy in work, social dynamics, and collaborative knowledge work take on new meanings in this context.

Navigating Between Worlds

As someone who’s sailed these waters, I find myself in an interesting position. I can speak the language of Desert Dwellers and Forest Dwellers, but my heart is with the Ocean. I work to help teams not just to create better Forests but to prepare for their voyage to sea, where they might discover that the most elegant solution is often the absence of software itself—a recognition that the best line of code is frequently the one never written.

The journey from Desert to Forest is challenging but well-documented. The voyage from Forest to Ocean is less charted and requires not just new practices but new metaphors, new language, and new ways of thinking and being.

Conclusion: Beyond Metaphors

Perhaps the most profound insight from the Ocean metaphor is that we might choose to hold all metaphors lightly. The Desert, Forest, and Ocean are not realities but lenses through which we view reality. The most advanced teams know when to use each lens and when to set them all aside.

The true masters aren’t wedded to being Desert Dwellers, Forest Dwellers, or even Ocean Navigators. They’re simply pathfinders, using whatever metaphor best illuminates the way forward.

As for me, I’ll continue to help cultivate healthy Forests and prepare those who are ready for their Ocean voyage. After all, the tide is rising, and the future belongs to those who can navigate these new waters.

The Mirage of Progress in Software Development

October 2, 2024
Article, Attendants, Business, Community, NoSoftware, Organisational Therapy, Product development, Progress, Quintessence, Software development
Leave a comment

The Mirage of Progress in Modern Software Development

Introduction

In an era where technological advancements seem to occur at breakneck speed, one might assume that software development practices and approaches are evolving just as rapidly. Yet, a sobering reality emerges upon closer inspection: meaningful progress in software development has been remarkably scarce since the dawn of the new millennium. This post aims to challenge the status quo and invite a dialogue about the future of the craft.

The Agile Paradox: Revolution or Regression?

The Curse of Snowbird

The 2001 Snowbird meeting, which birthed the Agile Manifesto, is often lauded as a watershed moment in software development history. However, two decades later, we might choose to critically examine whether this event truly catalysed innovation or inadvertently led us into a dead-end, a comfort zone of pseudo-progress.

The Agile Adoption Scam

While Agile practices promised a new era of flexibility and efficiency, their widespread adoption has often yielded unexpected consequences:

  • Cargo cult Agile: Rituals without understanding
  • The illusion of productivity: Mistaking movement for progress
  • One-size-fits-none: The fallacy of universal applicability
  • Promise unrealised: Most organisations are irredeemablly barren ground for key agile practices and principles

The Illusion of Progress

The Rebranding Con

Many purported ‘innovations’ in software development approaches over the past two decades have been mere repackaging of existing ideas. We’ve witnessed a parade of buzzwords—Scrum, Kanban, DevOps, and beyond—creating noise rather  than genuine advancements in how we build software. This constant rebranding often serves to refresh marketing materials rather than fundamentally improve the way the work works.

The Siren Song of Tools

Our industry’s obsession with tools and technologies has diverted attention from fundamental issues in development approaches. While tools can sometimes amplify productivity (counter-examp[le: JIRA), they often serve as a convenient smokescreen, concealing deeper systemic problems.

The Inertia of the Establishment

The Comfort of Complacency

Key players in the software development arena appear blithely content with the status quo. This inertia can be attributed to:

  • The lucrative nature of existing frameworks and certifications
  • Risk aversion: The path of least resistance
  • Organisational ossification: The challenge of implementing radical change at scale (well, any kind of meaningful change, really)

Charting a Course for Genuine Progress

Rekindling the Spirit of Innovation

To break free from this quagmire of stagnation, our industry might choose to:

  • Foster a culture of constructive dissent (Hah! As if that’ll ever happen)
  • Prioritise needs-driven development over process conformance (Cf. the Antimatter Principle)
  • Invest in reflection that challenges our fundamental assumptions about software creation and the role of software in attending to folks’ needs. (Cf. Organisational Psychotherapy)

Cross-Pollination: Learning from the Wider World

Software development stands to gain immensely from interdisciplinary insights:

  • Embracing design thinking’s user-centric approach
  • Applying lean product development principles Cf. “Product Development for the Lean Enterprise: Why Toyota’s System is Four Times More Productive and How You Can Implement It.” – Michael Kennedy
  • Leveraging systems thinking to tackle complex software ecosystems (Cf. Meadows, Beer, Senge, Weinberg, Deming, Ackoff, Goldratt, etc.)
Further Reading in Systems Thinking for Software Ecosystems

Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.

Senge, P. M. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization. Doubleday/Currency.

Ackoff, R. L. (1974). Redesigning the Future: A Systems Approach to Societal Problems. John Wiley & Sons.

Beer, S. (1981). Brain of the Firm: The Managerial Cybernetics of Organization. John Wiley & Sons.

Deming, W. E. (1982). Out of the Crisis. MIT Press.

Weinberg, G. M. (2011). An Introduction to General Systems Thinking (Silver Anniversary Edition). Dorset House.

Conclusion: A Call to Action

The software development community stands at a critical juncture. While the early 2000s saw the seeds of innovation planted, we’ve since watched our field calcify around those initial ideas. Is it yet time for practitioners, thought leaders, and organisations to shatter the illusion of progress and push for genuine advancements in how we approach software development and its role in businesses more generally? Only by acknowledging and addressing this stagnation can we hope to usher in a new era of progress in our field.

The future of software development lies not in clinging to the past, but in daring to imagine—and create—truly transformative approaches to our craft. As my own contribution, allow me to offer: Organisational Psychotherapy.

The #NoSoftware Perspective

May 30, 2024
Actionable Insights, Article, Attendants, NoSoftware
Leave a comment

The #NoSoftware Perspective

The Digital Delusion

For too long, we’ve been sold the lie that software makes our lives easier and more productive. The truth is, this so-called “technological progress” has shackled us to unreliable, glitchy programs and software-driven services that cause way more headaches than they solve (from the poor put-upon users’ perspective). Is it time to break free from the digital delusion and embrace a #NoSoftware (a.k.a. software last) existence?

Constant Frustration

Using software is an exercise in frustration. Buggy code, crashing apps, and infuriating user interfaces have become the norm rather than the exception. Why do we accept this as an inevitable part of modern life? The constant compatibility issues, updates that break more than they fix – it’s a vicious cycle of aggravation.

Productivity Paradox

Proponents claim software boosts our productivity, but how productive can we truly be when we’re constantly battling technical hiccups? The time wasted on debugging, troubleshooting, and fighting with clunky programs eats away at any potential productivity gains. It’s a paradox that has us spinning our wheels.

Reclaiming Simplicity

Before software invaded our lives, things were simpler. We did calculations on paper, wrote letters by hand, talked to real people to get things done, and kept organised with physical calendars and files. While perhaps less flashy, these analogue methods were straightforward and reliable. By ditching software wherever possible, and putting it last when it’s not, we can reclaim that simplicity and avoid the headaches of the software hegemony.

#NoSoftware for Freedom

The #NoSoftware movement isn’t about being a Luddite; it’s about prioritising folks’ wellbeing over the vapid promises of the tech industry. By unplugging from this flawed software-driven reality, we free ourselves from the shackles of constant frustration. Who’s ready to join us in promoting this perspective and declare “enough is enough”?

See also: #NoSoftware + Attendants

Challenging Assumptions: How #NoSoftware Echoes the Degrowth Ethos

September 2, 2023
Antimatter principle, Article, Culture change, NoSoftware
Leave a comment

Challenging Assumptions: How #NoSoftware Echoes the Degrowth Ethos

A Fresh Look at #NoSoftware

For those scratching their heads over what #NoSoftware means, it’s not an outright rejection of software. Rather, it challenges the knee-jerk response that defaults towards a software-centric solution for every problem. In essence, #NoSoftware encourages a rethink of how we meet people’s needs. By considering other, potentially more effective means to address these needs, the approach invites us to break free from the ‘software first’ assumption.

The Many Facets of #NoSoftware

  • Time and Cost Savings: Writing fewer lines of code saves time, effort, and money.
  • Reduced Maintenance: Fewer lines of code mean fewer potential bugs and less ongoing upkeep.
  • Happier Customers: People generally prefer human interaction to dealing with software systems. They’re not after a software solution; they’re after a solution, period.
  • Cultural Shift: Software can lock an organisation into existing ways of thinking, making it difficult to evolve or adapt.

The Overlapping Ideals with Degrowth

Degrowth, too, urges us to question our instinctual push for ‘more’. Just as #NoSoftware questions our reliance on technology, degrowth questions our dependence on economic expansion. They’re not anti-progress; they’re pro-intentionality.

Reframing ‘Success’

In both cases, the goal is to redefine what success means. It’s not about having the most advanced software or the biggest economy. It’s about meeting essential needs in a meaningful way.

Sustainable and Intentional Choices

Sustainability in degrowth parallels the reduced maintenance aspect of #NoSoftware. By focusing on what is truly necessary, both movements reduce long-term costs—whether that’s environmental or developmental.

Real-world Implications: The Portsmouth Example

The case of Portsmouth City Council’s housing repairs is illustrative. An expensive, cumbersome IT system was replaced with manual controls, only reintroducing limited software after understanding the actual needs of stakeholders. In short, Portsmouth adopted a #NoSoftware approach to better meet the needs of their community.

What Businesses Can Learn

  • Assess the Real Needs: Before diving into software development, assess whether a software-based solution is truly the best answer.
  • Think Holistically: Don’t simply consider cost in monetary terms. Think about the environmental, social, and cognitive costs as well.
  • Challenge the Status Quo: Existing systems might be the biggest obstacle to change. Breaking free from them may open up new, more effective solutions.

Confronting Blockers to Change: “When His Salary Depends on His Not Understanding It”

As Upton Sinclair’s Dictum poignantly states, “It is difficult to get a man to understand something when his salary depends on his not understanding it.”

The Financial Incentive of Ignorance

The challenge both #NoSoftware and degrowth movements face isn’t just about changing minds; it’s also about overcoming an economic structure that rewards the maintenance of the status quo.

Overcoming Institutional Inertia

Sinclair’s quote hits the nail on the head: people have financial and emotional investments in continuing to create software-centric solutions. It’s this very inertia that makes it so hard to even consider alternatives, let alone implement them.

Future Adoption Challenges

As with any counter-mainstream idea, both #NoSoftware and degrowth face significant inertia. Many are reluctant to shift from the familiar, even when it’s to their detriment.

The Final Word

#NoSoftware and degrowth, though rooted in different sectors, echo each other’s calls for thoughtful reflection on our automated responses. They both ask us to be more intentional, whether in coding or in consuming. In pausing to consider the actual needs at hand, we open the door to more effective, sustainable solutions.

#NoSoftware + Attendants

August 6, 2023
Antimatter principle, Article, Attendants, Capability development, Culture change, Improvement, Innovation, Needs, NoSoftware, Organisational effectiveness, Quintessence
1 Comment

#NoSoftware + Attendants

Adding more developers to a team for more throughput seems like a no-brainer. But, just as theory of constraints teaches us that increasing capacity at non-bottleneck stations won’t improve overall throughput, simply hiring more developers does not address the throughput challenge when, as in most cases, development is not the constraint.

Enter the #NoSoftware approach – a perspective that challenges the typical software-centric thinking. The premise, that we should reduce or eliminate unnecessary software to achieve greater efficiency, echoes another emerging trend in tech leadership: the idea of “Maximising the Amount of Work Not Done.” Also known as “software last of all“.

At first glance, this might seem counterintuitive. After all, isn’t productivity about doing more? However, when applied strategically, focusing on what doesn’t need to be done can pave the way for streamlined operations and better outcomes. And no role embodies this concept better than the role of “Attendant” (NB. Role, not Job).

The Attendant’s Impact

While software developers are integral to translating requirements into code, Attendants focus on discerning and addressing the genuine needs of a wide range of Folks that Matter™, from customers and fellow team members to senior management. The role isn’t to delve deep into the intricacies of code (they can do that too, when necessary) but to simplify, streamline, and ensure that the tech team’s efforts are genuinely needs-driven. Here’s how Attendants make the difference:

  1. Prioritising Genuine Needs: Amidst a sea of potential features, Attendants ensure that only those bringing significant value are pursued, eliminating unnecessary work.
  2. Enhancing Communication:In the role of Attendant, developers act as conduits of clear communication between various parties, reducing misunderstandings and the subsequent need for rework.
  3. Championing Simplicity: Attendants continually advocate for the simplest solution that effectively addresses the needs of the Folks that Matter™. And communicate and track them via trhe Needsscape. This philosophy speeds up development, minimises bugs, and ensures more reliable product delivery.
  4. Curbing Over-Engineering: By always aligning solutions with the genuine needs of the Folks that Matter™, Attendants act as guardians against the pitfalls of over-engineering, ensuring products and their features remain focussed, relevant, user-friendly and cost-effective.

The #NoSoftware Synergy

The Attendant’s perspective on streamlining work resonates with the #NoSoftware approach. Both focus on the needs of the Folks that Matter™. By understanding and embracing the principles behind these ideas, organisations can focus on what truly matters, eliminating unnecessary noise and ensuring the delivery of impactful solutions.

Summary

Whether it’s the #NoSoftware approach or the invaluable role of Attendants, the tech world is shifting towards a more thoughtful, needs-oriented paradigm – and it will be a game changer.

Unlock the Untapped Potential of ChatGPT: Beyond Coding!

May 5, 2023
AI, Article, Chatbots, NoSoftware
Leave a comment

Unlock the Untapped Potential of ChatGPT: Beyond Coding!

Isn’t it a bit disheartening to see software developers using ChatGPT primarily for writing code? It’s true that ChatGPT can indeed churn out code, but we can ask much more of it. If only developers would realise the potential for quicker, cheaper, and more valuable #NoSoftware solutions, they, their bosses and their customers would surely be amazed.

Imagine the possibilities. It’s high time we tapped into ChatGPT’s innate ability to provide creative, intelligent solutions that don’t just stop at code, but bypass it entirely.

What’s more, ChatGPT can even offer a hand in strategic planning, brainstorming innovative ideas, and making data-driven decisions.

We’re all missing out by limiting such a versatile tool to coding when there’s so much more on offer. It’s not that coding isn’t important, but let’s not forget the bigger picture. There’s a world of opportunities waiting to be explored if we’d only broaden our horizons.

So, let’s not be too quick to commit the heinous sin of pigeonholing ChatGPT as just a code-writing automaton. Why not embrace its full potential and reap the rewards of its remarkable capabilities? After all, it’s not every day that we come across such a powerful, transformative technology

#NoSoftware: Prioritising Business Flow Over Premature Software Implementation

March 21, 2023
Article, Culture change, Improvement, Innovation, NoSoftware
Leave a comment

#NoSoftware: Prioritising Business Flow Over Premature Software Implementation

Also known as “Software Last Of All”.

Businesses are often tempted to jump into implementing software solutions to optimise their operations. However, the #NoSoftware movement advocates for deferring software implementation until the business flows have been settled. This approach emphasises the importance of understanding and streamlining business processes before introducing any software solutions.

The primary objective of the #NoSoftware movement is to ensure that businesses have clear and effective workflows in place before integrating software into their operations. By doing so, companies can avoid the common pitfalls of premature software adoption, such as wasted resources, misaligned priorities, overblown costs, delays, and the need for constant readjustments.

One of the core principles of #NoSoftware is to place human interaction and creativity at the center of business operations. This involves designing and implementing business processes that cater to the needs and strengths of the workforce and customers, fostering collaboration and innovation. Once a solid foundation has been laid, businesses can then consider (minimal) software solutions to enhance their operations.

By prioritising business flows over software, organisations are better equipped to identify and address inefficiencies and bottlenecks in their processes. This ultimately leads to more effective and resilient business operations.

Furthermore, the #NoSoftware movement encourages businesses to choose software solutions that complement and enhance their established workflows, rather than disrupting them. This not only helps companies avoid the risk of adopting software that fails to meet their needs but also ensures that technology serves as an enabler of growth, rather than an obstacle.

In summary, the #NoSoftware approach promotes the idea of refining business processes in vivo before incorporating software solutions. By prioritising business flows and human-centric approaches, organisations can create a robust foundation for growth and innovation, ultimately leading to more sustainable and successful outcomes.

Girls Who Don’t Code

March 20, 2023
Antimatter principle, Article, Careers, Coding, Community, NoSoftware
Leave a comment

Girls Who Don’t Code

Girls and women are ideally placed to become real developers (by my definition*) and yet they want to CODE?

*My definition:

A real solutions developer is not so much someone who possesses technical expertise, but rather has the ability to connect with people and truly understand their needs.This requires a high level of emotional intelligence and empathy, as well as excellent communication and interpersonal skills. A real solutions developer builds relationships with clients, collaborates with team members, and creates solutions that meet the unique needs of each individual and group. By putting people first and prioritising human connections, a real solutions developer is able to deliver truly transformative solutions that make a difference in people’s lives.

See also: #NoSoftware

Quickie: Not A Software Developer

July 3, 2022
Antimatter principle, Coding, NoSoftware, Quickies
Leave a comment

I’ve not called myself a software developer for at least thirty years. That’s not to say I’ve stopped coding. Far from it. But the end in mind has changed. From “developing software” to “attending to folks’ needs”. Seems to me that latter frame offers far more potential for satisfaction – both for me and for those I serve – than coding ever did. See also: #NoSoftware and the Antimatter Principle.

Quickie: Write Code Like…

June 18, 2022
Alien tech, NoSoftware, Quickies, Quintessence
Leave a comment

Write code like the sound of one hand clapping…

Quickie: Muntzing

June 18, 2022
History, NoSoftware, Product development, Quickies, Quintessence, Software Delivery, Software development, WhatIf
Leave a comment

Hardware design / development has had Muntzing since the 1940’s. How about importing the idea into software design / development?

Could this facilitate the spread of #NoSoftware?

Or are programmers too self-indulgent to cut out much of their crap?

 

Quickie: Love Of Coding

June 18, 2022
Alien tech, Coding, Culture change, Lamentation, NoSoftware, Organisational effectiveness, Quickies, Quintessence, Technical
1 Comment

Coding

After all these years, I still love coding (as in writing software).

It’s just that it’s tainted by the certainty that there’s so many other more effective ways of adding value and meeting folks’ needs.

Spending time coding feels so… self-indulgent.

The #NoSoftware Option

May 25, 2022
Alien tech, Article, Business, Culture change, Innovation, NoSoftware, Organisational effectiveness, Product development, Software Delivery
Leave a comment

The #NoSoftware Option

One of the many things that distinguishes The Quintessential Group from the Software Delivery also-rans is that our Quintessential Teams service provides our clients and prospective clients with a #NoSoftware option. John Seddon and his company, Vanguard Consulting, advise deferring software automation of new business processes and process steps at least until those steps have been trialed and proven through manual implementations – Post-its, paper-based processes, manual steps, etc. For those organisations that buy into this perspective, our #NoSoftware option means our teams will deliver these non-software solutions quickly and cheaply.

Also known as “software last”, a #NoSoftware solution is one that minimises the amount of software in a solution – in particular minimising the amount of custom-written software – ideally to the exclusion of software from the solution entirely.

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

The Benefits of #NoSoftware

  • Less maintenance overhead

The fewer lines of code in any given solution, the less needs to be spent on keeping that code up to date in line with e.g. changing requirements and discovered defects.

  • More flexibility

Did you know that the term “software” was first coined back in the 1950’s to reflect the idea that software could be changed more easily, quickly and at lower cost than the hardware solutions that then predominated? It was supposedly easier to change a line of code than to reroute traces on a PCB, or swap out soldered components. Nice wishful thinking, but it hasn’t turned out that way. Software is notoriously expensive, inflexible and difficult to change. Less software means increased flexibility and business agility.

  • Savings on up-front costs

Software costs money to write, even before it goes into service. Not only to pay for ever more expensive programmers and their friends, but also the opportunity costs of having to wait for the software to be ready to deploy. In most organisations this can mean months or even years of waiting.

  • Minimal automation

When a new business process or process step is implemented, it’s rare for the implementors to fully understand what’s needed, and to anticipated the unintended consequences of their choices. Premature automation can lock in inappropriate or suboptimal design choices. Once a process or process step has been up and running live in a manual form for some time, it’s generally easier to see where (limited) application of software-enabled automation may bring benefits. Hence “software last”.

  • Try before you buy

Use a #NoSoftware solution live in your business to prove your process or process steps to trial the solution before committing to implementing a software-based solution. You may actually find that a software-based solution is in fact unnecessary, or can be much more limited in scope – and cost – than originally imagined.

Attending To Folks’ Needs

Implicit in the idea of #NoSoftware is the imperative of attending to folks’ needs – the primary focus of The Quintessential Group. Generally speaking, folks have little need for software per se. As the old adage goes; folks don’t need a 1/4″ drill so much as they need a 1/4″ hole. When considering the means for attending to – and meeting – folks’ needs, software is often the default, but rarely the optimal means.

Chat More?

We’d be delighted to discuss the idea of our #NoSoftware solution option and how it will be suitable for your business or organisation. Curious? Please get in touch.

– Bob

Further Reading

Seddon, J. (2019). Beyond Command And Control. Vanguard Consulting.

Quickie: Value Engineering And #NoSoftware

April 14, 2022
Engineering, Improvement, NoSoftware, Organisational effectiveness, Product development, Quickies, Quintessence, Software development
Leave a comment

Invitation to discuss:

#NoSoftware is the acme (or logical extreme) of Value Engineering in software development?

Quintessential Product Development

January 13, 2022
Article, Culture change, Doctrine, Flow, Flow•gnosis, Flowchain, Metaflow, NoSoftware, Organisational effectiveness, Prod•gnosis, Product development, Quintessence, Risk, Value
Leave a comment

Quintessential Product Development 

In my most recent book “Quintessence” I map out the details of what makes for highly effective software development organisations.

As fas as software development organisations are concerned, it’s a bit of a moot point – as software is generally something to be avoided, rather than sought (see also: #NoSoftware).

“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 

Foundational Concepts

There are just a few complementary concepts that mark out the quintessential product development company. These are:

  • Whole Product.
  • Systematic Product Management.
  • Whole Organisation (systems thinking).

Whole Product

The quintessential product development organisation embraces the concept of “whole product”. Which is to say, these organisations emphasise the need to have every element of a product i.e. core product elements plus a range of “intangibles” – everything that is needed for the customer to have a compelling reason to buy (Mckenna 1986).

Systematic Product Management

Quintessential product development organisations take a systematic approach to flowing new product ideas and features through a number of stages – often in parallel (Ward 1999) – to predictably arrive at a successful new product in the market:

  • Inception – spotting a gap in the market, a.k.a. some (potential customer) needs going unmet, interesting enough to do some discovery.
  • Discovery – uncovering and proving the real needs of customers, the things they value, the likely usability of possible solutions, the feasibility of meeting everyone’s needs, and the viability of a product as a means to these ends. In essence, the key risks facing the proposed product. 
  • Implementation – building a whole product solution, i.e. both core elements and “intangibles”.
  • Launch – Placing the product on sale (or otherwise making it available to customers).
  • Feedback – Seeing how the market responds.
  • Pivot or Augmentation – Acting on feedback to either reposition the solution (in response to unfavourable feedback) or to incrementally update / extend the “whole product” offering to continually strengthen the product’s value proposition and appeal.
  • Cash Cow – Reap the commercial rewards of a strong product and market share.
  • Sunsetting – Wind down the product in a way that meets the ongoing needs of all the Folks That Matter™️ (e.g. continued support, spare parts, etc.; easing customers’ transition to newer products; etc.). 

Whole Organisation

It’s common for organisations to think in terms of silos. A Product Management or Product Development silo being but one more silo in a long and ever-lengthening list. 

In the quintessential organisation, the whole organisation is geared around – amongst other things – the task of regularly and predictably getting new products and new product features/updates out the door and into the hands of customers. In the longer term, new products are the life blood of most organisations, especially in the technology industries.

We only have to look e.g. Toyota and their TPDS (Toyota Product Development System) to see both an example of how this works in practice, and the huge benefits of the whole-organisation approach.

Quintessential product development organisations embrace a range of progressive ideas such as Prod•gnosis and Flow•gnosis.

– Bob

Further Reading

Marshall, R.W. (2013). Product Aikido. [online] Think Different Available at: https://flowchainsensei.wordpress.com/wp-content/uploads/2013/04/productaikido041016.pdf [Accessed 13 Jan. 2022].

Mckenna, R. (1986). The Regis Touch: New Marketing Strategies for Uncertain Times. Reading, Mass.: Addison-Wesley Pub. Co.

Perri, M. (2019). Escaping The Build Trap: How Effective Product Management Creates Real Value. O’Reilly.

Ward, A.C. (1999). Toyota’s Principles of Set-Based Concurrent Engineering. [online] MIT Sloan Management Review. Available at: https://sloanreview.mit.edu/article/toyotas-principles-of-setbased-concurrent-engineering/. [Accessed 13 Jan. 2022].

The Quintessential Developer

December 30, 2021
Antimatter principle, Article, Culture change, Improvement, Learning, Needs, NoSoftware, Organisational effectiveness, Quintessence
Leave a comment

The Quintessential Developer

In my recent book, “Quintessence” I write, of the Quintessential organisation, that “everybody does things differently”. By which I mean, every role in a quintessential organisation looks very different from its counterpart in more conventional organisations, even though the name of the role may be similar, or the same..

This post looks at the role of the developer, and how – in quintessential organisations – this role differs markedly from the role in more conventional organisations.

Here’s a contextualising excerpt from Chapter 2 of Quintessence:

Everybody Does Things Differently

The quintessential organisation invites everyone involved to surface and reflect on their individual and collective assumptions and beliefs about work and how work should work. Progress towards the quintessential depends on progress with respect to changing these assumptions and beliefs.

This is the foundational reason why we see so few quintessential organisations, and why making the transition to a quintessential organisation is so difficult, and so rarely achieved successfully.

Here’s a brief outline of roles that look very different from the quintessential perspective:

The Manager’s role looks very different. So different, in fact, that the term “manage” ceases to be relevant. Managers in a quintessential organisation have relinquished ideas of control, and embraced a role of enablement, resourcing and support.

The Developer’s role looks very different. So different, in fact, that “software” and “technology” cease to be relevant. Developers in a quintessential organisation have downplayed a focus on “hard” technical skills, such as coding, and embraced and learned social skills, including skilful dialogue, empathy, self-organisation and compassion.

The Tester’s role looks very different. So different, in fact, that “testing” a.k.a. “inspection” ceases to be relevant. Testers in a “quintessential organisation have have relinquished a focus on inspection skills, and embraced means of preventing defects, and ensuring that attending to the need of the Folks That Matter™️ is “baked in” to how the work works.

The Customer’s role looks very different. Customers of a quintessential organisation get to have conversations about their needs, and have those needs attended to, more often and with more clarity than customers of more traditional organisations.

Even though a rational explanation of these differences serves little purpose, and will convince no one, we’ll take a more detailed look into the rationale later in this book.

Quintessence presents my experiences from over forty years of leading, working in, and advising software development shops and companies. I invite you to find inspiration, motivation and connection from my journey. Quintessence presents an ideal approach to making money (and other things) via attending to folks’ needs

Note: I say an ideal, not the ideal. There may well be other ways of achieving the same ends.

The Quintessential Developer Role

Note: This section describes the role of developers in a quintessential organisation. That is, the adjective “quintessential” applies to the organisation within which developers work, rather than the developers themselves.

In a quintessential organisation, developers pay much less attention to “technical” competencies such as coding, and much more attention to identifying the Folks That Matter™️, and understanding their (evolving) needs (cf. the Needsscape).

Developers in a quintessential organisation (being self-organising, self-managing and self-directing) focus on understanding what needs to be done (and for whom), compared to developers in conventional (poorly effective) organisations.

Necessary developer skills, in order of significance (most significant first): 

  • Dialogue skills – for conversations with the Folks That Matter™️ about their needs, and identifying other folks that may also matter.
  • Empathy – for establishing and maintaining humane relationships with all the Folks That Matter™️. Assuming, of course, that the organisation permits developers to actually talk with e.g. customers. A fairly rare scenario, to be sure.
  • Self-organisation – absent middle managers, project managers, etc., organising the work and then assigning work items to individual developers (and teams), developers in quintessential organisations have the freedom to to organise the work, and their assignments, themselves. This can range in scope from a single work item of a few hours, all the way through to new product features and indeed whole new products.
  • Risk Management – cultivating awareness of risks, their likely impact, and identifying and implementing active mitigations.
  • Opportunity Management – one step further than risk management.
  • System thinking – for reflecting on how the work works, with a view to continuous improvement.
  • Quality – building quality into the way the works works (as contrasted with hand-offs to e.g. testers and other QC personnel).
  • Researching and Learning – to discover and apply new ideas and techniques, both regarding how the work works and new technical skills/tools..
  • Investigating solutions – especially #NoSoftware solutions. 
  • Technical skills – including various implementation technologies, such as human systems (solutions staffed by human beings), paper prototypes and implementations, and, in extremis, writing software (a.k.a. programming, coding).

To recap:

Working/playing for/with a quintessential organisation is a fabulous experience (both literally and metaphorically). But the developer role is awesomely different from the conventional developer role. Can you grok it?

– Bob

Further Reading

Marshall, R.W. (2012). So You Really Want to be an Agile Developer? [online] Think Different. Available at: https://flowchainsensei.wordpress.com/2012/05/22/so-you-really-want-to-be-an-agile-developer/ [Accessed 30 Dec. 2021].

Quickie: Coding to Other Things Ratio

October 20, 2021
NoSoftware, Quickies
1 Comment

When building a software-based product or service (not in itself a sound thing to do, see #NoSoftware), how much time and effort goes into coding vs other things like:

  • Requirements gathering
  • Architcture
  • Design (of various sorts)
  • Wranging tools
  • UI and UX
  • Testing
  • Documentation
  • Meetings
  • Marketing-related
  • Debugging
  • Etc.?

I’ve long held the view that 10% is a sound number. Your view/experience?

How Much Do You Care?

September 3, 2021
Article, Caring, Community, Compassion, Culture change, Ethics, Improvement, Nonviolent Communication, NoSoftware, Organisational effectiveness, Software development
Leave a comment

How Much Do You Care?

In recent times I have noted an upswing in the frequency of conversations about the ethical dimension of software development. Although still early days, many aspects of the social implications of software are beginning to receive more attention.

Effective Software Development

The dog’s breakfast that is Agile in the real world today exemplifies, for me, a key aspect of these ethical questions. Not that ethical questions are at all limited to the software industry.

What am I talking about? I’m talking about how people with a clear understanding of e.g. Agile software development (yes, there are some) tolerate, even support, a pallid, ineffective version in their workplace because their jobs and livelihoods depend on not rocking the boat. I’m talking about how folks go along with an ineffective and crippled approach for an easy life. Although how easy is it to stand by and watch project after project fail or limp along, with the consequent frustration and angst for all concerned?

With the oft-reported woefully low levels of employee engagement in most organisations, it’s hardly surprising that people just let such things slide by with little or no comment, complaint or action.

Satyagraha

We might take a leaf out of Gandhi’s nonviolent campaign playbook. He placed the idea of satyagraha at the heart of his toolkit of civil resistance. What is satyagraha? Online references describe it as “truth-force” or “the force that is generated through adherence to truth”.

Note: In this context, I choose to regard “truth” as referring to ethical imperatives such as justice, fairness and righteousness, and not simply factual truth. And yes, everyone has their own “truths” a.k.a. assumptions and beliefs. As do groups, such as organisations.

At the core of satyagraha is the willingness to suffer for the truth. Spiritual, emotional and physical suffering, borne in public, serves to emphasise the degree to which the satyagrahi care about the issue upon which they are campaigning.

Do You Care Enough to Suffer?

In the case of Agile, as with other aspects of how organisations run themselves today, it’s fair for folks to ask:

“Is it any of my concern? Don’t senior people with much higher pay grades than me hold the responsibility for these things?”

How is this any different from the old defence “I was only following orders?” 

Do you care? Do you care enough to start to say “No.”? In a civil and polite way, of course.

Are you prepared to suffer to see things become better for all concerned?

– Bob

How To Predictably Deliver Great Software

August 18, 2021
Antimatter principle, Article, NoSoftware, Organisational effectiveness, Product development, Software development
2 Comments

How To Predictably Deliver Great Software

What is “Great Software“?

Great software is software that meets the needs of the Folks that Matter™. The more needs met, and the more comprehensive the coverage of all the Folks That Matter, the “greater” the software.

Aside: I invite you to consider how the Needsscape plays into the above definition.

Ironically, when we dig into the needs of all the Folks That Matter, we find that great software often means no software. Strange?

Further, we regularly find that the needs of the developers and ancillary development staff trump the needs of the users and other customers. So we get software, even though users and other customers rarely need it.

Predictability

Let’s assume for a moment that predictability (e.g. due date performance) is among the needs of some of the Folks That Matter. In this case, predictability is part of the “great” we were just talking about.

Predictability comes from anticipating and managing risks – actively, deliberately and competently. Formal approaches such as set-based concurrent engineering (SBCE) help manage the risk of finding oneself unable to bring a particular aspect of the solution to completion, for a variety of reasons. Identifying the Folks That Matter and their needs helps manage the risks involved in building the wrong thing, as does consideration of the Cost of Focus. Predictability demands we keep on top of all significant risks. (See: the All Holes in the Boat principle Cf. Gilb).

Approach

Know what needs you’re attending to. And whose.
This is not always possible, a priori. So identify as many of the Folks That Matter as you can (expect more to come to light as you proceed). Concurrently, investigate their needs through quickly delivering early exploratory things such as mock-ups, paper-prototypes, sketches of various kinds, and conversations. “Quickly” here means in a few hours, or days at most. Expect to have to iterate on this.

Many developers assume that someone else will be handing them a list of the Folks That Matter along with a definitive statement of the needs of those folks. If that other party is competent and sufficiently resourced, this can work. I’ve never seen it. I prefer to have the developers own this crucial information, and the gathering and updating thereof too. This is not popular in many organisations, shining a light as it does on the inadequacies of the way the work works, the management, the analysts, the product owner(s) and so on.

In parallel with these investigations, make a start on building the solution. In particular, those parts of the solutions which seem relatively stable, and where you feel the needs are relatively well understood. This can even involve writing some software – if you really must. Manage the risk of not knowing how to build certain things through e.g. “Spikes” and other risk mitigations.

Done

“Surely there’s more to it that this?’ I hear you ask.
Well, actually, no. We’ve been hoodwinked into thinking that software development is “the most complex endeavour known to man” ~ Jim McCarthy

Actually, if tackled appropriately it’s quite a pussy cat. People make it much more difficult than it really is. Will the industry ever grow up?

– Bob

Further Reading

Waltzing With Bears ~ Tom Demarco and Tim Lister
Sketching User Experiences ~ Bill Buxton
Principles of Software Engineering Management ~ Tom GIlb
Beyond Command and Control ~ John Seddon