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

‘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.

#NoSoftware

@andrebuilds As Saint-Exupéry wrote, ‘Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away’ (1939.

And, take away the code too (see #NoSoftware)

The Ocean

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.

#NoSoftware

The Ocean

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.

https://flowchainsensei.wordpress.com/2025/04/29/the-ocean/

The Ocean

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.

https://flowchainsensei.wordpress.com/2025/04/29/the-ocean/