The Thing You're Best At Isn't in Any of Your Systems

Try the question on your own business before reading further, because the pause is the whole point.

Ask somebody what their company is genuinely better at than its competitors and the answer arrives immediately and with confidence. It is usually specific and slightly surprising, and it is rarely the thing on the website. Then ask which system it lives in.

That second answer takes much longer, and it is usually a list of places rather than a system. A spreadsheet somebody maintains. A message thread. The way a particular person quotes a particular kind of job. A checklist that exists but that everyone has slightly personalised. Quite often the honest answer is that it lives in one or two heads and nowhere else at all.

Ask a business what it is best at and you get an answer straight away. Ask which system it lives in and it goes quiet.

Because of what standard software is for, and this is a feature of the arrangement rather than a failure of any particular product.

A vendor’s economics require selling the same product to a great many businesses. That is what makes it affordable, well-maintained and reliable, and those are real virtues that this series is not arguing against. But it has a consequence that follows directly: a product built to be sold to everyone can only hold what everyone has in common.

Invoicing is invoicing. A contact record is a contact record. Those things generalise, which is precisely why buying them is the right call. The way one business assesses a difficult job, or decides what to quote, or knows which customer is about to become a problem, does not generalise. It cannot be in the box, because if it were in the box it would be in everybody’s box.

So it ends up in the gaps. In spreadsheets, in threads, in heads. Not because anyone was careless, but because there was nowhere else for it to go.

No, and the distinction is worth more than it sounds.

“We are good at this” is a statement about the people currently employed. “We are reliably good at this regardless of who is working” is a statement about the business. The first is a talent-dependent fluke that happens to be going well. The second is an asset.

Where the way you work lives in heads, output quality varies with who is on shift. That variation is invisible in a good month and expensive in a bad one, and it is almost never measured, because the businesses that would benefit most from measuring it are the ones with the least capacity to.

Putting the process into a system does not remove anybody’s judgement. It removes the lottery of whose judgement. That is what the Medeq work does when the right checklist for a particular class of device appears without being chosen, and the line in that write-up worth stealing is: consistency no longer depends on what a field agent remembers.

It walks out with them, and a folder of procedures does not stop it.

The reason documentation fails here is not laziness. Process knowledge written into a document decays from the day it is written, because nothing exercises it. Within a year it describes a version of the business that no longer exists, and everybody knows it, so nobody reads it, so it decays faster.

The same knowledge encoded in a working system is exercised every day by definition. If it were wrong, the work would not come out right, so it stays true without anybody maintaining it as a separate task.

We have watched the useful version of this happen twice. Armand, one of ReadyRun's founders, left for reasons that had nothing to do with the work. The API design and the clustered renderer pattern on the Folio platform are his, and they carried on without him. The same thing happened on Medeq. Nobody outside noticed either, which is the outcome you want and also the reason nobody ever gets credit for it.

Not what most businesses do, which is to reach for one big system that will hold everything.

The thing you are best at cannot go in the box. But almost everything else in the business can, and should, and probably already is. So the useful question is not what to build. It is what should happen to each of the things you already run.

There are three answers, and the next chapter is about how to tell which one applies.