A delegation loop has four beats, and most companies break at the same one every time. Work does not fall through because your people are careless, and not because you delegate badly either - it keeps happening with one person after another.
It happens in every company
You hand out a task on Monday. The person nods. Two weeks later you ask, and they say it is in progress. Another week passes before it turns out they had the wrong idea from the start.
The first time, you put it down to a careless hire. Then the same thing happens with someone else. Then with the people you trust most, the ones you hired yourself. By the third time, "it is the staff" no longer holds up.
When one fault repeats across different people, it stops being a fault of the people. It is a fault in the way work moves from one person to the next - and nobody in the company has ever sat down and designed that.
The delegation loop has four beats, not one sentence
Most of us picture delegation as a single act: I speak, you listen, you do it. In practice it is a delegation loop of four beats, and it only closes when all four are done.
The delegation loop only closes when all four beats are done.
Beat 1 - Request
You state the work. This beat looks simple but breaks most often, because it has to answer a question most instructions leave blank: what counts as done? Management literature calls that the conditions of satisfaction - acceptance criteria stated up front, not guessed at the end.
Beat 2 - Agreement
The receiver asks back, proposes a different deadline, says what they lack. Both sides commit. This beat needs people - it is negotiation, not transmission. An instruction that skips it has not been accepted; it has only been heard.
Beat 3 - Performance
The receiver does the work and reports back. This is the one beat most companies feel they have under control, because it is the easiest to see.
Beat 4 - Acceptance
The person who delegated confirms whether the result passes. Without this beat the work does not end, it merely stops being mentioned. And this is the beat skipped most often.
This delegation loop is not any software vendor's invention. It was described in research on work coordination in the early 1990s, before any task app existed on a phone.
Every company breaks the delegation loop at one fixed beat
What matters is that the break is not random. It is fixed by the habits of the organization.
Break at beat 1
Delegating without saying what done means. You argue about quality only after the work is finished. Everyone feels they are right, because there was never a shared criterion to check against.
Break at beat 2
One-way talk, nobody commits. The message goes out, the other side drops an emoji, and the two of you hold different views on whether it was taken on.
Break at beat 3
Delegate and let go. You only learn the progress when you go and ask. Which means the work surfaces only when you remember it, and whatever you forget, nobody raises.
Break at beat 4
Nobody accepts the work. It drifts into silence. No one declares it done, no one declares it failed. Six months later you find it never actually ended.
Each beat breaks in its own way, and the symptom tells you which one.
Hold your own company up against those four. Which one feels most familiar? That is the beat where you break, and it will keep breaking until something other than your memory keeps the rhythm.
Why even good managers cannot fix it
At this point someone will say: then sharpen your delegation skills. Be clearer, follow up more closely, confirm more carefully.
That works, but only for as many items as one person can hold in their head. The trouble is that an organization does not coordinate on the memory of the person at the top. Henry Mintzberg showed that organizations coordinate work in five ways, and they do not substitute for one another. Read them and you will see at once which one your current tool belongs to:
Mutual adjustment
two people side by side adjust to each other. Fast, but it only runs among a handful of people.
Managers assign work
the boss says who does what. Works up to a few dozen people, after which the boss becomes the bottleneck.
Standardized work processes
write the procedure, everyone follows the same path.
Standardized outputs
no rule on how, only on what the result must be.
Standardized skills
hire people who know the trade and they know what to do.
Five coordinating mechanisms. Each tool you use is running one of them.
Every tool you use is in fact running one of those five. A chat group is the first one: it exists so people can talk back and forth until things line up. It does that very well - and that is exactly why it cannot carry beats 1 and 4, because those two need a record that sits still to be checked against, not a stream of messages flowing past.
One detail says this better than any analysis: the popular chat platforms have all had to bolt a task list next to the chat window. If the chat window could carry delegation, nobody would have had to add that list.
You are not failing because you delegate badly. You are asking one mechanism to carry work it was never built to carry.
How it gets solved
What you need is not another place to post reminders. You need one record that travels the whole delegation loop, so that no beat depends on anyone's memory.
In Viindoo, each piece of delegated work is a task in the Project app. Set against the four beats:
Beat 1 - Request: the work has a name, a deadline and criteria
A task records the title, a full description and a deadline. For the conditions of satisfaction, Viindoo has no box carrying that name - you write them into the description, or split each criterion into a sub-task. The second way is worth it on larger work, because the system counts how many sub-tasks are closed out of the total, so how far along it is becomes visible instead of reported.
One task record: title, project, deadline, assignee, state, and the criteria written into the description.
The tool only does half the job here: it gives you a place to write the criteria. Whether you write them is your organization's discipline.
Beat 2 - Agreement: who takes it, and the conversation sits on the work
Each task has an Assignees field and can go to several people at once. The system records when the work was assigned; you do not type that in.
More importantly, every task carries its own message thread. Questions back, a request to move the deadline, agreeing the scope - all of it sits next to the work itself instead of drifting through a shared chat. And the system logs every change of assignee, deadline, priority or state. So "who gave this out, when, and how many times was the deadline moved" has somewhere to be looked up, rather than remembered.
The agreement and every change sit on the record: the conversation, the change of assignee, the two moves of the deadline, and the switch to Changes Requested.
One thing to say plainly: Viindoo has no separate field named "delegated by". Who gave the work out is read from the task history.
The thread also keeps followers apart from assignees - two different lists. An assignee automatically follows; the reverse is not true. So adding someone to keep them informed is not the same as giving them the work.
Beat 3 - Performance: progress you can see instead of chase
A deadline that has passed is shown in red on the task, so you see it rather than work it out. Each project sets its own columns to match how it works, so opening the board shows which stage every piece of work is at and who is holding it.
The board of one project: which stage each task is at, who holds it, and the overdue ones in red.
To be accurate: Viindoo has no ready-made filter called "overdue" that gives you the late list in one click. For that list you add a filter on the deadline yourself and save it for later use.
For work that runs in a chain, you switch on task dependencies for that project: the later task moves itself to Waiting while the earlier one is still open. To be clear, this is a soft block - it keeps the rhythm and tells you, but a user can still mark the work done if they mean to.
Beat 4 - Acceptance: somewhere to say passed or not passed
This is the beat most current practice leaves empty, and the most valuable one.
Besides the columns each project sets for itself, every task carries a fixed system state. Open it and you can pick five values: In Progress, Changes Requested, Approved, Done, Cancelled. There is a sixth, Waiting, but the system sets that one itself when the task is held up by another, and users do not choose it.
Acceptance written as data: Changes Requested and Approved are the two values that close - or reopen - the loop.
The two middle values are the acceptance beat written as data. Changes Requested means it did not pass: the work goes back to the person doing it, and that return is kept in the history. Approved is the person who delegated confirming it passed. The delegation loop closes with an action that leaves a trace, not with silence.
And because this is a field of its own, apart from the board columns, a task can sit in the last column and still read Changes Requested. Concretely: someone drags the card into Done, you open it, see it is not right and set Changes Requested - the card stays in Done but anyone looking can tell the work has not been accepted. That is how it really goes: finishing the work is not the same as finishing the job.
Four questions to test yourself
Before you think about tools, answer these four for your own company:
Criteria
Did your most recent instruction say clearly what counts as done?
Taken on
Do you know the receiver took it on, or only that they heard it?
Visibility
To learn the progress, do you go and ask or look in one place?
Acceptance
The work finished last week - who declared it passed?
Any question you cannot answer points at the beat where you break.
Nothing is wrong with it, it is used in the wrong place. A chat group handles the agreement beat very well - asking back and forth, then settling. Where it falls short is the request and the acceptance beats, because those two need a record that sits still to be checked against, while messages flow past.
The sign is not the headcount, it is whether you still remember everything you have delegated. When you have to go and ask to learn the progress, memory has run out of capacity.
Yes. The Assignees field of a task takes several people. But think twice: work that several people carry together is usually work that has not been split small enough, and that is the seed of nobody being accountable.
Once their account is switched off they can no longer log in and no longer receive notifications. But the tasks still carry their name in the assignee box, so you have to hand the work to someone else. That handover is manual; the system does not do it for you.
Yes, and you should. What needs to move is not the conversation, it is the record of the work.
See it on a real system
The four beats are easy to nod along to, but you only see them clearly when you watch one real piece of work travel the whole delegation loop. Book a session and we will open a task on the system and walk it with you from the moment it is given out to the moment it is accepted.
Related articles
- Should Automation Come Before or After Standardization?
- What Does Digitalization Help a Business "See" for Kaizen?
- Why Does Digitalization Sometimes Add Tasks? Does It Go Against Kaizen?
- How Detailed Should Data Be? Sales Order, BOM and Production
- Kaizen and Digitalization: How They Connect in Business Improvement
