Revenue, utilisation, headcount — most SMBs watch all three and miss the one metric customers actually feel.
Most growing businesses watch a familiar set of numbers: revenue, utilisation, headcount, pipeline. Very few watch cycle time — how long a piece of work actually takes to travel from requested to done. It is a strange blind spot, because cycle time is often the number that customers feel most directly, and the one that reveals problems the others hide.
The metric your customers actually feel
A customer never experiences how busy your team is. They experience how long things take — how many days to get a quote, to resolve an issue, to deliver the thing they paid for. Internally, you might track how fully booked everyone is; externally, all that reaches the customer is the wait.
That gap matters, because a business can look healthy on its internal metrics while delivering slowly. High utilisation and a full pipeline can sit right alongside long, frustrating cycle times — and the internal dashboard will never show it. Cycle time closes that gap by measuring the thing the customer is standing on the other side of.
Little’s Law, in plain English
Cycle time isn’t a vague feel-good metric; it obeys a well-known relationship called Little’s Law. In plain terms:
> The average time work takes to get through a system depends on how much work is in > progress at once, divided by how fast the system finishes things.
The practical implication is the part most teams miss: the more work you start at the same time, the longer each individual item takes to finish. Piling more into the system doesn’t make it faster — it makes everything queue. This is why a team that says “yes” to everything often delivers everything late, and why limiting work in progress can speed up delivery without anyone working harder.
Why busyness misleads
The reason cycle time surprises people is that most of it is invisible. In process after process, when you actually map how long work takes, the time it spends being worked on is a small fraction of the total; the rest is spent waiting — in queues, for approvals, for someone to pick it back up. In lean practice this is called flow efficiency, and in typical knowledge work it is far lower than anyone expects.
That is the trap of measuring busyness. Utilisation tells you people are occupied. It says nothing about whether work is moving. You can raise utilisation to 100% and slow delivery down, because the fuller the system, the longer everything waits behind everything else. Speed comes from flow, not from load — the same reason automating a busy but broken process just produces faster queues.
How to start measuring cycle time
You do not need a heavy system to begin. A useful first pass:
1. Pick one important flow — a sales quote, a support resolution, an order fulfilled. 2. Record two timestamps: when it was requested, and when it was genuinely done. 3. Look at the spread, not just the average. The slowest 20% is where customers churn and where the real bottlenecks live. 4. Find the waiting. Ask where each item sat idle. That waiting — not the working — is almost always where the time went. 5. Limit what’s in progress. Starting less at once, counterintuitively, finishes more.
Do this and you will usually find the same thing: the delay isn’t in how hard people work, it’s in how work waits. That is precisely the leverage point that lets a smaller business operate with the responsiveness of a larger one without simply hiring more.
The takeaway
Cycle time is the metric most SMBs ignore, and one of the most revealing they could adopt. It measures what customers feel, exposes what busyness conceals, and points directly at the waiting that quietly lengthens everything. You don’t need to measure everything — but if work feels slow and you can’t say why, cycle time is where to look first.
Sources
→ Little’s Law (queuing theory) — foundational operations-management relationship linking work in progress, throughput and cycle time.
→ Flow efficiency / value-stream mapping — Lean Enterprise Institute, “Value-Stream Mapping” — lean.org
Related reading
