A Practical Guide to Managing Client Work Across a Growing Team

What actually breaks

When an owner does client work themselves, an enormous amount is held in their head and never written down. What this client is sensitive about. Which parts of the brief matter. What "done" looks like for this deliverable. Why the thing that seems obvious is wrong for this account.

Delegation moves the work and leaves the context behind. The output is technically correct and somehow wrong, and the owner concludes the person is not good enough. Usually the person was fine and the brief was three sentences plus assumed knowledge.

The instinct at this point is to add process: more approvals, longer briefs, a weekly meeting. That treats the symptom. The actual fix is to make the work itself carry the context, so it travels with the task instead of living with a person.

Define the unit of work

Before anything can be delegated it has to be a thing. "Handle the Henderson account" is not a unit of work; it is a relationship. What can be assigned is a specific deliverable with a definition of done.

Two levels usually do it:

• The engagement. The commitment you made to a client. A campaign, a retainer month, a build. It carries the agreed value, the deadline and the team.
• The task. One deliverable inside it, assignable to one person, with a state you can look at and know whether it is done.

The test for whether a task is a task: could you hand it to somebody who has not been in any meetings, and would they know what to produce? If not, it needs splitting or it needs context, and usually both.

Context belongs to the work

Once work is a unit, the question is where its context lives. There are three common answers and only one of them survives a busy month.

• In a person. Whoever briefed it knows. Works until they are on holiday.
• In a channel. The conversation is in chat, somewhere, in a thread from three weeks ago. Technically recoverable, practically not.
• On the work. The discussion, the files, the client's original request and the decisions made all hang off the task itself.

The third is the only one where somebody picking up a task in six weeks can reconstruct what was intended. It also has a side effect worth having: when the discussion is attached to the work, nobody has to decide which channel a question belongs in.

Keep internal discussion and client conversation separate, though. Not because clients cannot be trusted, but because internal discussion is where people say "I think this is wrong" and "we underquoted this", and those are true, useful and not for sharing.

Standardise the work you repeat

Most service businesses do a handful of things over and over, with a long tail of one-offs. The repeatable part is where standardisation pays.

For each kind of work you do regularly, decide once:

• What it is called, in language the whole team uses.
• How it is measured, if it is countable.
• What information the person doing it must record every time.
• Whether the client should see it at all.

That last question is worth asking explicitly rather than by default. Plenty of internal work has no business appearing on a client's screen, and deciding per kind of work is far more reliable than deciding per task while busy.

One caution: standardise what recurs, not everything. A template for work you do twice a year costs more to maintain than it saves.

One owner, one reviewer

Every piece of work needs exactly one person responsible for producing it and one person responsible for deciding it is good enough. Not a team, not a channel. Two names.

Setting these per engagement rather than per task removes most of the daily decisions: new work in this engagement defaults to these two people, and you override when it matters. The routine case costs nothing, and the exception is still available.

Keeping the two roles separate is what makes review mean anything. When the person who did the work is also the person who signs it off, you do not have a review step, you have a habit of saying yes.

Review is a step, not a message

"Looks good to me" in a thread is not a review. It cannot be counted, cannot be reported on, and cannot be pointed at six months later when a client asks how something went out in that state.

A review worth having records four things: who reviewed it, when, what they decided, and what they said. That is a small amount of structure and it changes what the record can tell you.

It also matters commercially. Approval is the natural moment for work to become payable, because it is the moment somebody with authority accepted it. If your review step is a message, you have no clean trigger for anything downstream.

Three distinctions to hold on to, because collapsing any of them causes trouble later:

• Submitted is not approved. Handed in is not accepted.
• Approved is not delivered. Work can pass review and sit waiting to go out. The client's view should follow delivery, not approval.
• Approved is not paid. What you owe and what you have paid are different numbers, and the gap between them is worth being able to see.

Blockers need a record

Work stops for reasons that are usually somebody else's to resolve: the client has not sent the assets, the access does not work, a decision is outstanding. In most teams this becomes a message, and the message becomes silence.

A blocker should be a thing with a reason, an owner and a resolution, attached to the work it is blocking. The benefit is not tidiness. It is that blockers become countable, which means you find out that a third of your delays come from one client, or that access problems cost you two days a month.

Keep the history when people change

People turn work down, hand it over, go on leave, and leave. In a growing team this is routine, and the naive way to handle it destroys information.

Reassigning a task should add to its history, not replace it. When a piece of work has been through three people, you want to be able to see what each of them did, what they submitted and how it was reviewed. Overwriting the assignee loses all of that and leaves you with a task that appears to have always belonged to whoever holds it now.

The same applies when somebody leaves the business. Remove their access immediately and keep every record of their work. Deleting a person to tidy up deletes the history of everything they touched, which is exactly what you need when a client queries something from four months ago.

Ending work properly

Engagements end early. Clients change direction, budgets are cut, priorities move. Handled badly, this leaves a trail of half-finished tasks that nobody closes and that quietly distort every count you have.

A decent close-out asks three questions:

• What was delivered, and what was approved but not delivered? The second group often still needs to reach the client.
• What is in progress? Each item needs a decision: stop now, let them finish, let them submit. Defaulting to letting people finish is usually least destructive.
• What has not started? Cancel it, with the reason recorded.

And the rule underneath all three: nothing already earned disappears. Somebody who did work before the engagement was cut short is still owed for it, and an ending that quietly deletes that is the fastest way to lose the goodwill of the people you rely on.