Photo by John Thomas on Unsplash

Don’t Build Software

An unorthodox but whole-hearted message to all C-level people everywhere.

Software is eating the world. — Marc Andreessen, “Why Software Is Eating the World” (2011)

In business, survival is neither guaranteed, nor mandatory.

Does your organizational strategy clearly include the production of novel software and realizing value through it? No? Don’t build software.

Is your market de facto software? No? Don’t build software.

Do you have a current strategy that kind of implies the production of new software? Refine it, and slant towards not building software. If you can avoid it, then don’t build software.

Did a consultancy firm say you should be making software? Fuck them. Don’t build software.

Is your payroll full of consultants (not even your own employees) making software? Fire them right now. Don’t build software.

Do you have a lot of people in your organization who know how to write software? Unless you also have the strategy to support software as a first-grade part of your business, go ahead and fire them. Don’t build software. And don’t worry about them, as there are still lots of businesses that are building software and making money from it, unlike yours.

Are you struggling with transforming your IT (or similar) departments for better alignment and agility in terms of digital/software production? Don’t be a sorry and impoverished victim of Conway’s Law—abort the transformation program, as you won’t be building any more software.

Do you ever feel like maybe, just maybe, the folks lower down in the hierarchy, in middle management and Business, never really got the hang of software and how it fundamentally differs from traditional industry and manufacturing? Don’t worry anymore, there is no more software being built in your organization.

Software as liability

The answer for software (in terms of quantity) is not more, it is less. All code (and hence, software) is a liability. Every system, line of code, implementation, and unknown detail, is like one more of those pesky child regents in Game of Thrones that are just waiting to murder you in some terrible way. Except you don’t have one or a few of those—you have so many you don’t have a number anymore, at all.

Thus, what you want is less software and better software.

When we build software in organizations that do not understand the materia and stuff of software we often have mistaken beliefs about how it evolves, behaves, and lives its full lifecycle. It quickly becomes alien (“What is IT doing?!”), terrifying (“Why the hell does it cost so much and why are they so behind schedule?!”), and intimidating (“Why is their budget growing more than anyone’s else’s…!?”).

For a technologist like myself, it has been a convenient lie that perhaps we can simply play the ukulele and try to be friends with the business counterparts. Perhaps they will attempt to like us if we are didactic about what we do, and how we play. It doesn’t work. They don’t want to be told by some doof elsewhere how that thing they hate works. No more ukulele.

Notice how the word “build” has been used a lot above, rather than, say, “run”. There is no way around the fact that software is a huge constituent part of our global economy and daily reality. But that doesn’t have to mean that every organization (for-profit, non-profit, privately held, communal…) has to build any software whatsoever.

Given that you will have to deal with running software then some better options would include:

  • Buying a good SaaS tool for your specific need, a market that is only growing and can greatly increase the innovation speed of organizations. Don’t however underestimate the amount of time and haggling and bullshit it takes your organization to just buy a fucking tool and what a waste that is.
  • Using smart integration platforms to wire together behaviors, for example with Autocode, Pipedream, or Zapier.
  • Using low-code/no-code tools, letting “citizen developers” in your company connect integrations and widgets as well as create full applications using something like Glide, Bubble, or the more advanced Retool.
  • Using AI to generate applications and integrations is an option that is rapidly becoming more feasible.

All of these would rapidly accelerate most non-tech companies leagues ahead of where they might be today. Even just a few well-placed technologists could make a sea change happen, but we would still not, in earnest, be building any software in the traditional, slow, expensive way.

Note: We could spend thousands of words or even pages going into many more details here; the point is that running software can be done extremely efficiently these days with no or few experts, in ways that were simply not possible a few years ago. And options are bubbling up to also build, for example, internal applications that you might need in the org, without software development expertise.

An honest moment

If your strategy does indeed include software, then establish an organization and people who can drive that; else cut it out like a cancer. Let’s be honest: Non-tech companies have neither explicit intent nor strategy, skills, leadership, or culture to build software. So why do you think you have it? Why take this hard, expensive, and frictional road? For what?

Truly, I don’t get it, and I am literally one who gains from your misery. That doesn’t mean I want you to stay miserable!

Unless you make big changes, accept that your existing organization will have no chance in hell to attract or retain the quality of staff you need if you want to be a company making money off of technology, and therefore fighting with actual tech companies. You can’t be a ball-bearing company, automaker, or shipping company and attract that talent if what you offer is not at least on par—and this is not primarily about perks and compensation, in fact, the thing you need to solve is that most smart people with a tech skillset won’t tolerate even one hour in meetings with “the business” if they are not attuned whatsoever to how we work culturally in an effective and contemporary way. It becomes pathetic at best when an automaker like Volvo gets a “techy” guy from Dyson as their CEO and he wants to make a hundred-year-old car company into a tech company overnight just using some magic words—an idea that lacks all sense of reality. Words don’t change reality unless you are deranged or one of those funny presidents we get these days. Plus these particular words come from a guy who was just recently peddling vacuum cleaners. 🤷

Your move

Now, before we end:

Read books and be inspired by those who succeeded

I find it unacceptable with illiterate management, basing decision-making and strategy on decades-old “truths”. How would you feel?

Given the vast library of literature available at less than €30 a pop—all with brilliant research, experiences, and ideas—see if you can’t make the tiny investment, take the hours, and see how your organization will need to change if this is truly what you want. Let me pick some favorites for you:

These are what the community would most likely recommend you. They are all as good a starting point as any.

Take a position

You now have two options.

  1. Just say no to building software, if you don’t want it in the org and you can’t give it adequate traction in the strategy. You are the C-level folks, aren’t you? Just say no to software if that’s the case.
  2. On the other hand, if you start drawing the lines for how a real, actual, tangible change in your strategy can happen where software is indeed a key part of delivering on the strategy, then see if you can make some of the ideas from the above literature real and powerful and felt in your organization. Don’t go for half-measures. You’ll only ruin your budget and reputation.

So, what’s your move?

This advice has cost you nothing, but it will most likely save you enormous money, I am sure of it. And we can finally start putting the tech talent where it needs to go: Either somewhere else, or in your organization where you can now truly leverage technology and the skills of all the good technologists out there. Everyone wins.

Don’t build software—unless you know that is indeed exactly what you should do.