
Retail. Farm equipment manufacturers. Airlines. Online ads. Hospital networks. Consumer banking. Charities.
These industries are completely different. Some make their money on selling as much of their product as they can. Others rely on selling just enough of their expensive equipment to the right consumers to make a profit. Others still don't sell anything at all and rely on turning their good will into feelings and turning feelings into donations.
All of these industries do have one thing increasingly in common, however: they are all software companies.
Let me translate the list above in hopes of clarifying this:
Shopping for clothes and office supplies on my smartphone. Massively sprawling and complex systems to handle flight operations, reservations and more. Online ads. Putting patient histories into the hands of doctors and nurses. Everything that goes into ensuring that one dollar goes from place to place. Building software to help children in developing countries learn how to read and write.
The mobile phone became the dominant way of using the Internet a little under a year ago. In the same year, over 62% of the world's population owned at least one mobile device. Never in the history of computing has it been easier or quicker to reach consumers. Any company that has a web presence and makes a significant portion of their revenue from it is a software company.
Many will look for a gut-wrenchingly thorough postmortem of the devastating series of unfortunate events that plagued TSB a few weeks ago. As they should: being unable to access your money or run your business for days is an incredibly stressful and damaging experience.
Like Equifax earlier this year, they will probably come through. Also like Equifax, they will probably pay fines and be on the receiving end of a long list of civil and private lawsuits.
Smaller versions of incidents like these happen every day at companies large and small. The reasons for these failures will be different, but as long as businesses take the (massive) risk of cost-optimizing their technology organizations to the max, and as long as technology organizations remain siloed and lacking in software and platform best practices, the root cause will always be the same.
Fortunately, the solutions are the same, too.
Transform Your Software Delivery with DevOps
Download our briefing to discover how to scale DevOps in the enterprise
If your software is the beating heart of the company, then your engineers are the blood that keeps it pumping. Engineers will know whether that feature your customers are demanding is viable and how long it will take to make it a lasting reality. Engineers know the quirks within your systems that will cause problems down the line. While engineers care greatly about their compensation, they care much more about solving hard problems correctly.
Trust them.
The alternative is to push feature work to your engineering organization with a timeline and a whip. That's how you pump blood into the heart faster than it should. That causes heart attacks.
The less that your engineers have to do and remember to maintain your online presence, the easier it is for them to maintain it. Google said it best in their widely acclaimed book on Site Reliability Engineering: "We don’t want our programs to be spontaneous and interesting; we want them to stick to the script and predictably accomplish their business goals."
The only way to achieve operational simplicity is to focus on software and infrastructure quality and automation in every aspect.
The great thing about code is that it can be tested, so why not test as much of your software as possible? Your business requires hundreds or thousands of systems and components, internal and external, to function; why not automate the runbooks and monitoring required to keep them up and running?
What is a software company besides the software that they provide? Nothing. What is software without code? Not software.
If your business runs on code, then would it not make sense to communicate through code as well? Instead of using email to resolve problems in the codebase, why not use pull requests instead? Instead of using runbooks to guide your releases, why not use pipelines-as-code instead?
The closer the communication channels are to the code that makes your business money, the less information people have to remember when making decisions.
Tools are great. I love tools. Tools don't solve everything. Tools alone certainly will not transform your organization into the world-class software company it should be.
In my experience, the solution to most big operational issues isn't solved with tools at all.
Changing people is hard. Getting people to do new things that are the right things is repetitive, and the conversations aren't fun. Doing different things without an immediate positive result is scary.
Changing people is slow. And then it's not.
Microservice platforms are, rightfully, all the rage now. But how much longer would it have taken to get here if Jeff Bezos didn't make it a company mandate in 2002?
Would Netflix be as addicting as it today if it stuck to mailing DVDs instead of pivoting to streaming video?
Big changes are risky. But deprioritizing the software in your software company is even riskier, and, maybe, even more expensive.
At the end of the day, everything we do is done for one reason: to make our customers happy. Happy customers means more and "stickier" customers, and more customers means more revenue. Everything done within companies should start and end at making this positive feedback loop more positive.
Recognizing that your company is a software company in an ever-increasingly mobile world is the first and most important step in this process. Software companies are all about the software, and you cannot have good software without putting quality and automation at the forefront of everything.
You can create this.
Or you can create this.
What's it going to be?
Join thousands of your peers and subscribe to our best content, news, services and events.