Where the time actually goes

Ask a company where its time goes and you will usually be handed an org chart. Ask where the money goes and you get a profit and loss statement. Neither document answers the question. One shows you who reports to whom. The other shows you what you bought. Neither shows you where the work actually happens, or where it gets stuck.

This is a small gap in theory and an expensive one in practice, because it makes a whole category of decisions impossible to make well. Every tool you are offered is a claim about time. It says that this will take less effort than what you do now. You cannot evaluate that claim without knowing what you do now costs. Most companies, including very well run ones, do not know.

The measurement problem hiding inside the tool problem

Consider what it takes to say yes or no to a piece of software with any confidence. You need to know which process it touches. You need to know how long that process takes today, including the parts nobody logs. You need to know how often it goes wrong and what happens when it does. You need to know how many people touch it, and how many times the same information gets typed in again along the way.

Almost nobody has this, and not because they are careless. Nothing in the normal running of a business produces it. Accounting measures money leaving. Project tools measure tasks assigned. Time sheets, where they exist, measure hours against a customer or a project, which is a billing question rather than an operational one. None of these instruments are pointed at the thing you need to see.

So when a vendor arrives with a number, and they always arrive with a number, you have nothing to check it against.

Chasing the new thing is a rational response

It is common to describe companies chasing new tools as suffering from shiny object syndrome, as though the problem were a lack of discipline. That is unfair, and more importantly it is unhelpful. If you cannot rank opportunities by size, you have to rank them by something else. What is left is vividness.

A demo is vivid. It is designed to be. Watching something that used to take a morning happen in four seconds is genuinely persuasive, and it is persuasive in a way that a spreadsheet full of your own unmeasured processes is not. So the tool with the best demo wins, and the process that costs you the most, which usually has no demo attached to it at all, stays exactly as it is.

The same logic explains why so many companies end up with a lot of tools and very little change. Each individual decision was defensible. None of them were comparable.

The costs that do not look like costs

When you do go looking, the surprising thing is where the time turns out to be. It is rarely in the task everyone complains about. The task everyone complains about is visible, which means someone has already tried to improve it.

The expensive parts tend to be the connective tissue between tasks. Waiting for an approval. Chasing someone for a missing detail. Typing the same customer information into a third system. Checking whether something that was supposed to happen actually happened. Redoing work because the brief changed and nobody told the person doing it. Handling the case that does not fit the standard path.

None of these appear as a line item anywhere. They are distributed in small pieces across many people, which is exactly what makes them large in aggregate and invisible individually. Nobody experiences twenty minutes of chasing as a problem worth reporting. Two hundred instances of it a month is most of a full time role.

How to actually see it

The instinct is to run a survey or ask department heads for estimates. This does not work, and it fails in a specific direction. People report the work they consider to be their job. They do not report the work they consider to be friction, because friction does not feel like work, it feels like the annoying part around the work. So what comes back is a description of the official process, which is the thing you already had.

What works better is to follow a single unit of work all the way through. One order. One quote. One claim. One new customer. Start when it arrives and stay with it until it is finished and paid. Write down every time it changes hands, every time it waits, every time information about it is entered somewhere it already exists, and every time it leaves the standard path.

You will need to do this a handful of times to see the pattern, and you should deliberately include one that went badly. Exceptions are where a lot of the cost lives, and they are always missing from the official description of the process.

This is unglamorous and it takes a few days. It is also the only version of the exercise that tends to produce numbers people actually believe afterwards.

What changes once you can see it

The first thing that happens is that most of the tools in your inbox disqualify themselves. Not because they are bad, but because they address a step that turns out to be a rounding error in the total. That is a real result, and it can save you a year.

The second is that the question changes shape. It stops being whether the technology is any good and becomes something far easier to answer. Does this remove a handoff. Does this mean the information is entered once instead of three times. Does this let the person who finds the exception be the one who resolves it. Those are questions you can settle in an afternoon, and they do not require you to hold an opinion about the technology at all.

The third is that you get a baseline, and this matters more than it sounds. The most common reason a pilot is quietly abandoned is not that it failed. It is that nobody could say what it was supposed to improve, so when it was over, nobody could say whether it had. A project with no baseline cannot succeed. It can only fail to obviously fail, which is a different thing, and it does not survive the next budget round.

The uncomfortable part

There is a version of this argument that ends by recommending you buy something. This is not that. Almost everything described here costs nothing except attention. Following six jobs through your own business from start to finish is not a project. It is a week.

The reason it does not happen is that it is nobody's job, and the people who understand the process well enough to do it properly are the same people the process depends on to keep running. That is a real constraint rather than an excuse. But it is worth noticing what is sitting there unused. A company twenty years old has something a two year old competitor cannot buy at any price: a real process, running at volume, with its exceptions and edge cases already discovered and absorbed. That is an enormous amount of information. It has simply never been written down.

The companies that do well over the next few years will not be the ones that adopt the most tools. They will be the ones that can tell you, precisely, where their time goes. Most of the rest follows from that.