Who Should Assign the Work, the Manager or the Team?

There is a moment in most growing teams when someone says the manager has become a bottleneck, and the suggestion is made that people should just pick up work themselves. It sounds sensible. It is sometimes right. And done without the conditions in place, it produces a team where the eager are overloaded, the cautious are underused, and the unglamorous work sits untouched for a month.

The choice between assigned work and pulled work is not a choice between control and freedom. It is a choice about where the judgment sits, and each option needs different things to be true.

Push and pull, defined

Push assignment means someone decides who does what. A manager, a lead or a project manager looks at the work and the people, and allocates. The judgment about capacity, fit and priority is made centrally.

Pull assignment means work is made visible and people take it on. The judgment about capacity and fit is made by the individual, against a shared understanding of priority.

The terms come from manufacturing, where a pull system means work is drawn forward by downstream demand rather than pushed in by upstream scheduling. The parallel is closer than it sounds: in both cases the argument for pull is that the information needed to make good local decisions is held locally, and moving the decision to where the information is produces better outcomes than moving the information to where the decision is.

What push is genuinely better at

Worth stating properly, because the case for pull is usually made against a straw man.

Push is better when the work is unfamiliar to the people doing it. Pull assumes someone can assess their own fit for a task, and a person new to a domain cannot. Handing a junior engineer a carefully chosen task is not paternalism, it is the only way they get the right sequence of stretch.

Push is better under hard deadlines with no slack. The coordination overhead of collective prioritisation is real, and when a date is immovable, someone deciding quickly beats a team deciding well.

Push is better when the work distribution is politically sensitive. Pull systems reliably concentrate the interesting work with the confident and the routine work with the conscientious, and this compounds. Left alone for a year it produces a hierarchy nobody chose and nobody can point to.

What pull assignment is genuinely better at

Pull assignment is better when the people doing the work know more about it than anyone allocating it, which in most skilled work is the normal case rather than the exception.

It is better for capacity accuracy. A manager estimating what someone can absorb is guessing, usually optimistically, and usually without visibility of the three other things that person has committed to. The individual is not guessing.

It is better for motivation, though this is the argument that gets overstated. The effect is real and it is not primarily about doing enjoyable work. It is that choosing creates ownership, and ownership changes how someone behaves when the work turns out to be harder than expected.

And it is better for throughput at scale, because a push system routes every allocation decision through one person, and that person becomes the constraint. This is usually what triggers the conversation in the first place.

The four conditions pull assignment actually needs

Most failed transitions to pull assignment skipped one of these. All four are addressable, and none are cultural.

The work has to be legible without a briefing

In a push system, the person allocating the work explains it. Remove them and the description has to carry the explanation on its own. This raises the standard considerably: a task that reads "fix the onboarding thing" is pullable only by the person who wrote it.

This is the condition most often missed, and it manifests as a pull system where the same three people take everything, because only they can decode what the items mean.

Priority has to come from somewhere other than a person

If a manager is no longer sequencing, something has to. Usually a stated objective for the cycle, a work-in-progress limit, or a customer commitment with a date attached. Without it, priority reverts to whoever is most persistent, which is a worse arbitrator than the manager was because it is unaccountable.

Agreeing that constraint is itself a decision worth recording, because every subsequent prioritisation argument will refer back to it.

The unpleasant work needs a mechanism

Pure pull assignment leaves the dull, difficult and politically awkward items sitting. This is not a character flaw in the team, it is what a voluntary system does.

The usual answer is that recurring or unattractive work stops being a task and becomes a responsibility held by a named role. A responsibility is not pulled, it is held, and holding it is a visible commitment with an owner. This distinction does a surprising amount of work.

Someone has to watch the distribution

Not to allocate, but to notice. Who is taking what, whether the stretching work is spreading, whether one person has quietly absorbed everything nobody else wanted.

This can be a rotating role, and it usually should be, but it cannot be nobody. Pull assignment does not self-correct on equity, and assuming it will is the most common way a well-intentioned transition produces an unfair outcome.

Most teams should run both

The framing as a binary is the mistake. In practice the healthiest arrangement in most teams is mixed, and the mix follows the conditions above.

Familiar work, well described, within a person's domain: pull. Development work chosen for someone's growth: push, deliberately, with the reasoning said out loud so it does not look like allocation. Recurring commitments: neither, they are responsibilities held by roles. Genuine emergencies: push, without apology, and back to normal afterwards.

Stating which mode applies to which category, once, removes most of the confusion. The teams that struggle are usually the ones where the mode is ambiguous and people cannot tell whether waiting to be asked is appropriate or passive.

The tooling problem

Almost every project management tool assumes push. The central interaction is assigning a task to a person, the reporting is organised around what each person has been given, and the permission model inherits from a project manager role.

You can run a pull system inside these tools, and many teams do, but you are working against the grain and the grain reasserts itself whenever anyone is under pressure. The assignee field sits there, waiting to be filled in by whoever feels responsible.

Autono's Tasks is built the other way round. Anyone can create a task list without admin rights, ownership is claimed rather than assigned, and Kanban boards let teams pull work when they are ready instead of receiving it. The distinction between a task, a responsibility and a role is structural rather than a naming convention, and the decision that set the team's priorities is recorded where anyone can refer to it when work competes.

If you are trying to move a team towards genuine self-organisation and finding the tooling keeps pulling you back to allocation, we would like to help. Get started with Autono.

For the wider practice this sits inside, see bottom-up project management. For the distinction that makes pull work at all, see task, responsibility or role.