‘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 manageTheir team size depends on code that needs maintainingTheir importance depends on systems that require oversightTheir 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 problemsSuccess metrics based on system performance rather than user outcomesResource allocation favouring engineering elegance over customer valueDecision-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 codeSenior Simplification Specialist: Removes unnecessary software from existing processesVP of Manual Excellence: Proves complex processes can work with simple toolsChief 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.