Case Study: Paying for people vs paying for technology
Why "just pay someone to do it" is slowly rotting your organisation.
So much has been made of the software boom over the last twenty years (“software is eating the world”) that the idea of not using technology is anathema to many. However, it’s not that simple.
At the root of any operational process in business is an inherent tension between the cost of automation and the cost of staff to run it.
How it starts
To give one example, a complicated process - using paper forms to collect and update customer information in a database, for example - might require a handful of people to manage. 3-4 people might cost somewhere between $150,000 and $300,000 in all-in annual cost.
To automate this process, for example by building an online portal for customers to self-manage authentication and updating their information, might take a team of 5-6 specialists the better part of a year. The cost of this team will be somewhere in the vicinity of $1-$1.5 million. Following creation, this dashboard requires some modest maintenance and server costs as well as infrequent reworks every 5-10 years as technologies change and improve. Let’s call it $50k a year maintenance and assume the rework costs net off against the costs of churn from recruiting and managing people in the competing scenario (they don’t, but for the sake of argument).
In principle we have a simple decision. $300k a year in perpetuity vs $1.5m up front and tiny ongoing cost. Plug some numbers in and work out the ROI and automate it. A lot of companies work this way.
It’s not that simple…
There are two important catches. One is simply that many companies do not employ large amounts of tech talent and those that do have tech teams, usually have them quite siloed and heavily manage the workflow so that they are prioritising org-wide.
This means that for everyday automations, many teams simply haven’t got a chance of getting on the priority list because the work pales in comparison to The Most Important Thing going on in the company at that time.
As a result, companies make the decision to “just hire someone to do it” and, because these companies are better set up for hiring than they are for automating, hiring becomes the default and easy option.
Unfortunately, over time what this does is shift your centre of gravity and lowers your productivity. Your staff and org focus shift inexorably from “achieving outcomes” to “doing stuff” (e.g. “read customer forms and enter the data in a database"). Over the course of a decade, you end up with a sluggish, insular and closed-minded organisation that is not used to changing. High energy and motivated employees leave.
The price of this is almost always - ignominy and failure.
(Offsetting this, a team of spreadsheet monkeys is more easily redeployable within the business when times change, relative to the sunk costs of capex.)
An example
Here is a quick example of a real situation from a prior role. We needed to send a certain type of communication to a subset of customers. To get this, the Senior Business Analyst went to the technology team and ask them to run a query from the organisation’s two customer databases.
The analyst then combined the results of the two queries into a spreadsheet, and changed all the column names to something that would be understood colloquially (e.g. $COLUMN1 renamed to “Customer ID”).
This combined spreadsheet was then sent to our Fairytale Hero (yours truly) to prepare and send the communications. I separated out the spreadsheet back into two files for two separate uploads because of the requirements of the email system database we used. I renamed all the columns to align with the schema in the email system database.
Later, when I downloaded a report to show the analyst the results of the mailout, I had to do the above operation in reverse, changing all the column names to align with her original file.
This took the better part of two days and resulted in two highly paid staff essentially just downloading spreadsheets, changing column names and sending them back and forth. The job got done but the value added was negative.
Now imagine making 100 decisions like this over time and envisage what that organisation looks like in ten years.
Key Questions:
Why would you pay millions of dollars for software to do work that could be done by a half dozen people?
How can you shape your offering to put people at the centre and make the lack of automation part of the service offering?
Why is your organisation rotting under the weight of “doing stuff”?
These tensions never go away.
The consequence
The invisible cost of “just doing stuff” adds up. There needs to be an intentful discipline of reworking operational processes, including deciding to *simply not* do things, and teams with highly manual workflows need to be supported to do this periodically.
Make a first-principles decision to optimise for productivity where possible, and you will notice the difference.
If you found this post useful, please share it, or consider subscribing.