Your team is busy. Why is nothing getting finished?

You ask how a project is going. Everyone has been busy, several tasks are nearly done and the next meeting should clarify the remaining dependencies. Two weeks later, the answer is strangely familiar. The team may be working hard. The work may still be moving slowly.

Before asking people to increase their effort, inspect how work becomes a finished result. A task can receive attention from six capable colleagues and spend most of its life waiting between them. A team can also finish many tasks while leaving the customer problem untouched. These are different problems and need different interventions.

Follow one real piece of work

Choose a recent request, feature, proposal or customer change. Trace it from the first request to the point where someone could use the result. Record when active work happened, when it waited, what information was missing and who had to make a decision.

Do this with the people involved. The goal is an accurate picture, including the inconvenient bits that a dashboard may conceal. A request labelled “in progress” might be waiting for access. Another might be awaiting a customer's answer. A third may have been interrupted five times by urgent requests.

Ask: “What prevented the next useful step?” This is more productive than asking who caused the delay. You can discuss accountability once you understand what happened. Starting with blame gives everyone a strong incentive to produce a timeline in which the problem belongs to someone else's calendar.

Count unfinished work honestly

Teams often count the items assigned to each person, then miss the organisation's total unfinished commitments. Include work awaiting approval, testing, customer input and release. Include the “small” executive requests that never reached the planning board.

The Kanban Guide treats work between its defined start and finish as work in progress, and includes explicit control of that work in a workflow. It also identifies measures such as throughput, work-item age and cycle time. These provide a useful vocabulary for discussing movement rather than activity alone.

You do not need a sophisticated tool to begin. Write the current commitments on a page. Mark which can proceed, which are blocked and which no longer deserve to exist. It can be surprisingly useful to discover that the team is still carrying a project whose sponsor left three months ago.

Use simple flow maths with clear assumptions

Imagine a stable workflow as a hypothetical example. It completes six comparable requests per week and holds eighteen requests in progress on average. Dividing eighteen by six gives three weeks as a rough average time in the system under the assumptions of stable flow and consistent boundaries. It is an illustration, not a forecast for a particular request.

If that workflow starts another twelve requests while completion stays at six per week, adding starts has not created completion capacity. The larger queue is a reason to investigate, not proof that every task will take an exact number of weeks. Mixed task sizes, interruptions and changing demand can make a simple average misleading.

Keep the operational question close to the numbers: which waiting items are ageing, why are they blocked and what can the team finish next? An impressive chart that cannot help answer this has mainly improved the meeting's visual atmosphere.

Define what finished means

A designer may mean “the file is ready.” Engineering may mean “the code is merged.” Operations may mean “the customer can use it.” All three can describe genuine achievements. If the organisation reports all three as delivery, leadership may believe the problem has been solved before the customer sees anything.

Agree a finish boundary appropriate to the work. For a customer workflow, it might include deployment, access, documentation and a way to verify use. For a proposal, it might include the approved version being sent and the next customer step being clear. Keep the boundary useful rather than ceremonial.

Distinguish a finished deliverable from the outcome it is meant to influence. Shipping an onboarding change does not establish that onboarding improved. Check the intended effect separately, at a sensible interval and with enough context to interpret it.

Protect finishing capacity

Try a short experiment in one team. Pause new starts except agreed urgent cases. Choose the most valuable near-finished work and resolve the obstacles around it. Set a limit on concurrent commitments that the team can actually respect. Review it together rather than announcing a universal magic number.

Some blocked work may need to stop or return to a queue. Keeping it “active” cannot make unavailable information arrive faster. Explain the reason to the sponsor and agree what would justify restarting. This clears attention while preserving a record of the commitment.

Leave capacity for genuine incidents and essential maintenance. A limit that ignores the real operating environment invites hidden work. The experiment should reveal the load the team carries, including the requests that leadership previously treated as weightless.

Repair the handoffs that keep repeating

In a hypothetical agency, projects repeatedly wait for client approval because nobody agrees which person can approve the work. Sending reminders does not settle that question. Naming the client decision owner at kickoff and agreeing a review window may be more useful than employing another coordinator to send more reminders.

In another example, a product team waits for a specialist review near every release. Earlier specialist input or a clearer acceptance checklist may reduce rework. Retaining expert review can still be important. The tradeoff concerns when and how the expertise enters the process.

Use the repeated pattern to choose a change. Moving every colleague into every meeting may shorten one handoff while consuming everyone's available time. A useful improvement should make the work easier to complete and remain affordable to operate.

Have the management conversation the evidence supports

Try: “We have twelve active commitments and three recurring approval delays. For the next two weeks, I propose we finish these two items and route new requests through one owner.” This gives leadership a choice they can assess.

Also state the consequence: “If the new request must start today, which existing commitment moves?” Without this question, priority discussions can become a polite method for giving the same team several incompatible promises. Document the answer where everyone affected can see it.

Review completion, quality, ageing work and customer impact together. A higher completion count achieved by splitting tasks into tiny pieces may improve the number while leaving delivery unchanged. Metrics need stable definitions and conversations about what they represent.

For the decision queue, see the founder bottleneck guide. For competing commitments, see the overloaded roadmap discussion. I help teams trace delivery, clarify ownership and connect product work to a useful result. Bring one stalled initiative, its intended outcome and the last few steps it has been waiting on.

Questions people ask

Why is my team busy but not productive?

Busy people may be carrying too many simultaneous commitments, waiting for decisions or finishing tasks that do not address the customer problem. Trace a real piece of work from request to use. Record active work and waiting separately. Then choose a specific improvement rather than assuming the team needs longer hours or another productivity tool.

How can I measure whether work is actually moving?

Define the start and finish of the workflow, then observe completed items, the age of unfinished items and the time work takes between those boundaries. Keep definitions consistent and interpret the numbers alongside quality and customer impact. Counts alone can be misleading when task sizes change or when “finished” means different things to different departments.

Should I limit how many projects a team starts?

A limit can help when unfinished commitments accumulate faster than the team completes them. Set it with the people doing the work, allow explicit treatment of incidents and maintenance, and review the effect. The useful number depends on the workflow. The aim is to preserve attention for completion and expose tradeoffs when a new request arrives.