Where the Hours Really Go in a Ten-Person Company

Where employees spend time in a ten-person company is mostly on work that nobody planned, nobody owns and nobody can see from the top of the business. The calendar shows meetings. The payroll shows salaries. Neither shows the forty minutes a week somebody spends rekeying orders from one system into another because an integration broke in March and the workaround became the process.

That gap is the whole problem. A founder with ten people has a fairly accurate picture of what everyone is supposed to do, and a poor one of what they actually do. Not through carelessness. It is simply that at ten people the founder is still doing a job of their own, and the only way the real picture surfaces is if someone asks.

Why the assumption is always wrong in the same direction

Founders overestimate how much of the week goes on the core work and underestimate everything wrapped around it. Ask a founder what their operations person does and you get the four things that person was hired for. Ask the operations person and you get those four things plus eleven others that accumulated because they were the nearest available human when something needed doing.

The error runs one way. Nobody discovers that their team is doing less admin than they thought.

There is a structural reason. Work that was designed gets described. Work that accreted does not, because there was never a moment where anyone wrote it down. The Slack message that became a weekly report. The client who wants their invoice in a particular format. The Tuesday check on a sync that fails silently. None of these has a name, so none of them appears in any account of how the business runs.

The six places the hours actually go

Rekeying is the first and the worst. Moving the same information between two systems by hand is the single most common time sink in a small company, and it hides well, because it happens in five-minute slices rather than blocks. Five minutes, eight times a day, is a fortnight a year.

Then there is chasing. Waiting for an answer, then asking again. Approvals, missing information from a client, a decision that only one person can make. The person doing the chasing usually does not count it as work, because they are not producing anything while they do it.

Checking is the third. Somebody verifies that an automated thing worked. Every fragile automation in a small business has a human quietly babysitting it, and they almost never mention this, because from their side it is a small thing they do on the way to something else.

Rework is the fourth, and the least reported. Doing it twice because the first version was wrong, incomplete, or aimed at the wrong brief. Admitting to rework feels like admitting to a mistake, so the hours go into whatever category sounds better.

Fifth, context switching. Not the tasks themselves but the cost of moving between them. In a ten-person company almost everyone is interrupt-driven, and that fragmentation is invisible in a way that a two-hour meeting is not.

Last, answering the same question. One person holds knowledge that has never been written down, so they get asked. Every time. Their real job is increasingly to be a search engine for everyone else.

None of these appear on an org chart. Most do not appear in a time-tracking tool either, because when you ask someone to categorise their day they pick the category their job title suggests.

Why time tracking does not answer this

The obvious response is to make everyone log their hours for a fortnight. It rarely works, for three reasons.

People log what they think the exercise is measuring. Timesheets reward legible work and punish the shapeless stuff, so the shapeless stuff gets absorbed into whatever category is nearest. The observation itself changes the week: nobody does their normal messy Tuesday while recording it. And the output is a list of categories, not a map. You end up knowing that eleven hours went to "admin" without knowing which specific handoff created them or what to change.

Tracking tells you the size of the problem in a shape that does not tell you what to do.

Ask about last Tuesday, not about the process

The question that works is not "how does invoicing work here". That prompts the official version, the one from the document, delivered in the tidy order somebody would describe it to a new starter. The useful question is "walk me through the last time you did it, specifically, and tell me every point where you had to stop".

Recent and specific beats general and idealised every time. People are bad at describing their processes and very good at describing an afternoon.

The other thing to listen for is hesitation. When somebody says "and then I just…" they are about to describe a workaround they have stopped noticing. That is the sentence worth interrupting for. Pull the thread. Ask what happens if that step is skipped, and who else knows about it.

Do this across everyone, and one more thing falls out: the places where two people describe the same process differently. Those disagreements are more useful than the answers. A handoff that both sides describe identically is usually working. A handoff where each side believes the other owns a step is where things fall on the floor.

This is the work abi. FDE runs as AI interviews, by voice or by text, turning what people say into a working model of how the business operates, with the hours attached and the quick wins ranked. The map itself, built by hand, is free on any account. The interviews are the paid part, because they are the part that costs anything to run.

What to do with the answer

Once you have the real distribution, resist the urge to fix everything. Most of what you find is genuinely fine. Small businesses run on workarounds and a good number of those workarounds are cheaper than the systems that would replace them.

Rank by hours per month, then by how contained the fix is. The best first target is usually a rekeying task with a clear boundary: one input, one output, one person, no judgment involved. It is measurable, it is unglamorous, and finishing it buys you the credibility to look at the harder things.

Leave anything that requires a person to make a decision. Those look automatable and are not, and the failed attempt costs more than the manual version ever did.

The honest limits of this

Asking people has a real weakness, and it is worth saying plainly. People are unreliable narrators of their own time. They round up on the tasks they resent and forget the ones they enjoy. Nobody produces an accurate breakdown of their week from memory, and a set of interviews gives you a directionally right picture rather than a precise one. If you need precision to the hour, you need instrumentation, and if the work genuinely lives inside one system that logs everything, go and read the logs instead. That will be more accurate than anything a person tells you.

The second limit is timing. Under about five people, do not bother with any of this. You can see the whole business from where you sit, and the mapping exercise costs more attention than it returns. This becomes worth doing at the point where you can no longer name what each person did last week without asking.

The third is the uncomfortable one. Asking your team where their time goes only works if it is safe to answer honestly. If people suspect the exercise is really a headcount review, you get the official version of everything, which is worse than not asking, because now you have a document that looks like evidence and is not. Say what it is for before you start, and then act in a way that matches.

The company that knows where its hours go is not necessarily better run than the one that does not. It is just able to choose. Everyone else is guessing, and the guess is always biased in the same direction.