Your Business Is Growing. Why Does Everything Feel Slower?

The work around the work

Consider a team that has doubled in size but still waits for the founder to confirm every unusual request. More people can prepare the work. Only one person can release it. Everyone looks busy, yet the customer waits just as long, perhaps longer.

It is tempting to call this a productivity problem. Look more closely and it may be a coordination problem. The team is spending time checking status, forwarding context, reconciling records and asking who is responsible. That activity is necessary under the current arrangement, but it does not move the customer’s request forward by itself.

A useful warning sign is a calendar filling with meetings whose main purpose is to discover the status of work. Another is the same information being requested in several channels. Neither proves that the team is inefficient. They suggest that the way people coordinate may no longer fit the volume or complexity of the business.

Measure the waiting, not only the doing

Choose a piece of work that feels slow and follow its timeline. Separate time spent actively doing it from time spent waiting for information, a decision or the next person. If the task itself takes twenty minutes but sits between teams for two days, making the typing faster will not address most of the delay.

Those numbers are an illustrative example, not a benchmark. Your own pattern matters. Record why each wait happened: an incomplete request, unclear ownership, a busy approver or an update that never reached the right place. Different causes need different fixes.

Follow a recent request all the way through rather than asking each department how quickly it completes its own step. Sales may respond promptly, operations may process promptly and finance may approve promptly, while the gaps between them consume most of the week. The customer experiences the whole timeline. Your measurement should do the same.

Watch how a small queue becomes a busy week

Here is a deliberately simple example. An approval desk receives twelve complete requests each working day and can finish ten. Starting with no backlog, it ends a five-day week with ten unfinished requests: sixty arrived and fifty were completed. Everyone at the desk can work diligently and the queue will still grow. The issue is the mismatch between incoming work and capacity.

Real work is less tidy. Some requests need clarification, urgent jobs interrupt the queue and demand varies. But the example shows why telling people to follow up more often cannot, by itself, solve a persistent capacity gap. It may instead add interruptions to the person already limiting the flow.

Possible responses include changing the approval rule, increasing capacity where it is needed, reducing incomplete submissions or adjusting what the business promises. Measure which constraint is actually present before choosing the response. Hiring elsewhere in the process may only deliver work to the same queue faster.

Adding people can add handovers

When a role becomes more specialised, an activity that once happened at one desk may move through several. That can improve expertise and control. It also creates new moments where context can be lost. A request that seems obvious to the sender may be incomplete to the receiver.

Define what a ready-to-work handover contains. It might be an agreed brief, the correct customer record and a named owner for exceptions. A short, reliable handover can be more useful than another meeting to explain what each team is waiting for.

Connect the decisions that repeat

Not every decision belongs with the most senior person. Identify the ordinary cases that can follow an agreed rule and the exceptions that still need judgement. Make the boundary visible. If nobody knows what they can approve, the safest response becomes asking someone else.

Software can support this by routing work, keeping the relevant record together and showing what is blocked. But it cannot resolve an authority question the business has never answered. Automating a request for approval is of limited use if the approval should not have been required in the first place.

Make the rule specific enough to use. A team might be permitted to approve a standard service change when it does not alter the agreed fee, deadline or scope; anything outside that boundary goes to a named decision-maker. The exact rule belongs to the business. What matters is that staff can distinguish a routine case from an exception without repeatedly asking for permission to use their judgement.

Be careful about starting more work

When a customer asks for progress, beginning another part of the job can feel reassuring. But an operation with many half-finished tasks also needs to keep track of many missing details, promises and dependencies. Work can appear active while little reaches a finished state.

Try agreeing what should be completed before the team starts the next routine item. Keep an explicit route for genuinely urgent work, with someone responsible for deciding what it displaces. If every request becomes urgent, the priority system no longer tells people what to do first.

This is not a universal instruction to run one job at a time. Some activities need parallel work. The question is whether starting another task moves delivery forward or merely gives a waiting request the appearance of progress.

A dashboard should help someone make a decision

A colourful overview of total orders is pleasant to look at. An operational view becomes more useful when it reveals the oldest unresolved item, its owner, why it is blocked and what needs to happen next. Choose information that prompts action rather than collecting every number the system can produce.

For a first review, compare new requests, completed requests, unresolved work and the age of the oldest items over the same period. Add a simple reason for rework. A team that closes work quickly but sends much of it back for correction has not necessarily improved the customer’s experience.

Keep the definitions consistent. Decide what counts as received, complete and reopened. Otherwise, a change in reporting can resemble an improvement in performance, and different departments can end up arguing about figures that describe different things.

Remove one bottleneck, then look again

Pick a recurring delay with a clear owner and test a change for a short period. Compare end-to-end completion time, rework and the number of follow-up messages needed. Ask the people doing the work whether the change reduced uncertainty or simply moved it elsewhere.

Once one constraint improves, another may become visible. That is useful information. You do not need to redesign the entire company at once. Start by asking where a customer’s request spends the most time doing nothing, and what would allow the next person to act with confidence.

Write down the expected effect before the trial. For example: complete requests should spend less time waiting for approval, without an increase in corrections. Review the result with the people who receive the work as well as those who send it. That keeps a local improvement from becoming someone else’s new bottleneck.