Software as Machinery

Sometimes I have a conversation with a client where something offhand gets mentioned and I end up thinking about it for days – this post is about one of those conversations.

The client in question had a challenge in that they were running an event and needed a piece of software to support the event. The attendees would need to be able to access the software, and if they could not a) the attendees would get annoyed, and b) the client’s client would get annoyed because the promised solution would not work.

To which I said, “no problem – it’ll cost ‘this much’, but I guarantee on the day the solution will work”.

This was a clear value proposition – it would cost £x, the solution would work on the day, everyone would be happy, and no one would be having any difficult conversations in days and weeks after the event. The value of £x wasn’t particularly cheap – but it was affordable and could translate directly into a mix of reduced anxiety and happy client-ness.

As a software engineer who’s been around the block a few times, this was an easy guarantee to make – save for really weird things happening such as 2020 finishing up with aliens landing on the xmas tree in Trafalgar Square. The risk points can be identified and then planned and implemented around. As that professional software developer/system architect/CIO, whatever hat I’m wearing, I know that as near as makes no odds the operation of a given IT system on any given day can be guaranteed.

What’s been bugging me since then though since having that conversation is how so many other things in business are not similarly guaranteed. I certainly spend considerable sums of money in my business where the chances of it working are pretty much up to the fickle hand of fate.

By way of one or two examples – it’s well known within the law profession that no one knows what a judge will say in a hearing until he or she actually says it, and so every lawyer is giving the best advice (at splendid hourly rate), but they cannot guarantee the outcome. Even the best lawyer spends a chunk of their career saying the phrase “oh well” to their client. One bugbear of mine throughout all my time in business paraphrases David Olgivy in that I know half my time and money spent on marketing is wasted, I just don’t know which half.

This comes down to fact that software – and the hardware it runs on – is a form of machinery, and machinery is not fickle. When you turn the handle on the sausage machine, sausages will come out of it. When I got to the office this morning, it didn’t occur to me that my swipe card might not open the door, or that the lights might not come on, or that my computer would not boot up. (Or in getting there Google Maps might not work, or the car might not start, or that the heating wouldn’t come on, or that the kettle wouldn’t work, etc.)

I’ve written before about how small businesses look at their IT (and attendant IT spending) in terms of supporting the core functions of email and files – i.e. the basic starting point of a) “can I send and receive emails?”, and b) “can I store and share my files”. Large businesses look at their IT (and spending) as what can be done to improve the “health” of the business – for some value of health. Health in this context can about profit, or innovation, or growth, or whatever – the business will set objectives on the principle that reaching those objectives increases health and then will consider IT in the mix as to how to get to those objectives. Part of the natural maturation of the growing business is the transformation from this one state of affairs to the other – i.e. at some point, someone starts to ask questions about how to use IT for more than just emails and files.

This transformation is easier if you consider software as a type of machine (99.9% of IT is software – the actual hardware is not hugely important), because although most of us are not engineers, we all fundamentally get how machinery works, and we all fundamentally get how processes work. Our businesses themselves can be thought of as machines – we know if we do XYZ we get ABC outcomes – that’s what a machine does. So, any of us who are business leaders may not be “Engineers” with a capital-E, but we all do do engineering in that we look at the operation of a machine (the business) an optimise by looking for things that are working well (and doing more of those) and looking for things that are not working well (and doing well of those).

The trick then is how to see how software can help – which to keep reducing this down is to look at how software can help the processes within the business. This is a mindset change – so many business owners just “handwave” over IT because they don’t understand the nuts and bolts. You don’t need to understand the nuts and bolts, you just have to understand the operation of the machine in the same way you may not know how an internal combustion engine works, but you know how to drive.

And, because software is a type of machinery, and we know that if done right machines do what they’re supposed to do day after day after day, if we bring a “software machine” into our business, we know we can get a reliable, dependable, “ROI-able” outcome.

PS: Happy xmas, and here's to 2021!

By Matthew Reynolds