Delegation in a Law Firm: How to Push Work Down

Summary

Every lawyer knows they should delegate more. Almost nobody needs convincing of the principle. And yet the same work keeps landing back on the same desks, week after week, in firms full of capable people with spare capacity.

That's not a discipline problem. It's an arithmetic problem that most firms have never actually done.

Your firm's output isn't capped by how hard your lawyers work. It's capped by how much of their work only they can do. Professional hours are the scarcest resource in the building. Every task that stays at that level when it didn't need to is capacity spent at the wrong altitude, and capacity taken from work nobody else could have done.

This guide covers why the instinct not to delegate is rational in the short run and expensive in the long run, the capacity argument that makes the business case, the three things that must exist before delegation works at all, and how to push work down without lying awake wondering whether it got done.

Contents

• Why lawyers don't delegate, and why the instinct is sound
• The capacity argument
• The first-pass problem runs both ways
• Three things that must exist before delegation works
• Treat delegating like drafting: build precedents for it
• Delegate the work, not the worry
• Start lite: the fastest way to kill adoption
• What happens when nobody junior is on the matter
• Key takeaways
• Frequently asked questions

Why lawyers don't delegate, and why the instinct is sound

It's worth being fair about this, because the usual framing is unfair.

Lawyers are trained to produce the work themselves. Years of education and supervision reward personal craft: your name on the advice, your judgement, your responsibility. Nothing in that training is about getting the same outcome through somebody else. Delegation is a management skill, and management isn't on the syllabus.

So when a task appears, the calculation runs quickly and lands in the same place: by the time I explain this, I could have done it.

And that calculation is correct. For that task, on that day, doing it yourself genuinely is faster. Everyone telling you otherwise is quietly ignoring the explaining, the chasing, the reviewing and the fixing.

The problem isn't that the sum is wrong. It's that it's the wrong sum. It's right per task and disastrous across a hundred of them, because every time it comes out that way, the firm's capacity stays exactly where it was.

"What's easier today is what caps the practice tomorrow."

— Ashley Kelso, Hivelight

Key point: "Faster to do it myself" is true for any single task and false for the firm. The trap is that you only ever feel the first one.

Most misallocation isn't a decision at all

That's the deliberate version, and it gets all the attention. But a good deal of work sits at the wrong level for a much duller reason: nobody ever allocated it.

Without a shared view of what a matter needs, work doesn't get assigned so much as it gets noticed. It lands on whoever saw the email, whoever the client rang, whoever happened to be in the room. That's not a judgement about who should do it. There was no judgement. A senior lawyer picks up a task not because they decided to, but because it arrived, and dealing with it was quicker than working out who else might.

Meanwhile support staff sit on capacity nobody knows is available, because there's no place where "what needs doing" and "who has room" can be seen side by side.

This is why delegation can't be fixed by exhortation. Telling people to delegate more doesn't help if the information required to allocate well doesn't exist anywhere. First make the work visible; the allocation conversation becomes possible after that, and often answers itself.

The capacity argument

Here's the arithmetic that changes how this looks.

Step one: you can afford more support staff than lawyers. That's simply what the cost structure of a firm allows. For the cost of one senior practitioner you can carry several support staff.

Step two: everyone has the same number of hours in a day. A paralegal's Tuesday is exactly as long as a partner's.

Step three: therefore the firm holds a bigger pool of support hours than professional hours. Not slightly bigger, but structurally bigger, and it grows as the firm grows.

Step four: professional hours are the constraint. Some work can only be done by a lawyer. That work is finite in supply, and it's the work that gates everything else.

So every task moved out of a professional hour and into a support hour lifts the ceiling on what the firm can produce. Not by making anyone work harder. By spending the scarce resource on the things only it can do.

Figure 1 — The scarce pool sets the ceiling. Moving work across raises it without anyone working harder.

"You can afford more support staff than lawyers, and everyone has the same number of hours in a day. So the firm always holds more support hours than professional hours. The more work you can get done in those support hours, the higher the firm's output. It really is that simple."

— Ashley Kelso, Hivelight

This is what people mean by leverage, though the usual framing (rates and margins) misses the more interesting half. Leverage isn't only about work costing less when someone else does it. It's about the supply of hours you have available to sell at all. A firm that uses its support hours well has more capacity than an identical firm that doesn't, with the same headcount and the same wage bill.

The net effect is that effective delegation lowers the average wage cost the firm carries to get its work done, while simultaneously raising how much work it can carry.

Key point: Leverage isn't cheaper work. It's more available hours, and the firm that uses them well simply has a higher ceiling.

The first-pass problem runs both ways

Most delegation advice pushes in one direction: get work off the partner's desk. That's half the picture, and following only that half creates a second, quieter problem.

Upward drift is the familiar one. Work that a paralegal could have first-passed sits with a senior lawyer instead, because it arrived in their inbox, or because explaining felt slower. Capacity spent at the wrong level, and output capped as a result.

Downward drift is the one nobody talks about. A support staffer spends half a morning agonising over a judgement call that a lawyer would have made in four seconds and not got wrong. They're being conscientious. But the cost lands twice:

"Visibility catches the reverse problem too. A support staffer agonising over a decision a lawyer would make in seconds and never get wrong. That costs you twice: the time they spent worrying about it, and the cost of fixing it if they guessed."

— Ashley Kelso, Hivelight

So the goal isn't "push everything down". It's each task at the level that handles it correctly and most cheaply, which sometimes means up. You can only see either problem if you can see who's actually doing what, which is why delegation and visibility are the same project.

Three things that must exist before delegation works

Delegation fails when any one of these is missing. Most failed attempts are missing two.

1. A clear task. Not "have a look at the Hendricks file", but a specific piece of work with a definable finish. Vague delegation is just worry transfer.
2. An instruction attached to it. What good looks like, any firm-specific requirements, the things you'd have said if you were explaining it. Attached to the task itself, not delivered verbally and then forgotten.
3. A way to see it's been done. Without this, you delegate and then spend the next three days wondering, which feels worse than having done it yourself, and teaches you not to delegate next time.

Miss the third and delegation becomes chasing. That's the actual reason it felt slower: you didn't hand the work over, you added a monitoring job to your week.

Treat delegating like drafting: build precedents for it

Here's the shift that makes delegation genuinely cheap, and it's one your firm already understands in a different context.

Nobody drafts a lease from a blank page. You keep a precedent suite and a clause bank, because composing the same document from scratch every time is obviously wasteful, and because the precedent carries accumulated judgement from everyone who improved it along the way.

Delegating is composition too. Every time you hand work over, you assemble a scope, an instruction, a standard and a deadline. And almost every firm assembles it fresh each time, from memory, usually while busy. We built precedent banks to stop drafting from scratch, then kept delegating from scratch and wondered why it felt so expensive.

A workflow template is a precedent for delegating: the tasks a matter type requires, with the instructions already attached, ready to be applied rather than written. Do it once for a matter type and you've done it for every matter of that type you'll ever run.

That directly attacks the calculation from the start of this guide. "Faster to do it myself" is true when explaining costs a fresh conversation. It stops being true when the explaining is already done and sitting on the task.

Two further benefits fall out of it. Staff are trained at the moment of need, reading how the thing is done at the point they're doing it, rather than in an induction three months ago. And the process improves cumulatively: refine the template once and every future matter inherits the improvement, including matters run by people who weren't there when you learned the lesson.

In Hivelight these come in two shapes. A task-list workflow is a set of tasks for a small repeatable piece of work or an internal process. A Roadmap is the larger structure for a matter type: milestones, each with its own tasks and instructions. Either can be applied to a matter at any point, and you can apply more than one as a matter reveals what it actually needs.

There's also one respect in which a workflow precedent beats a document precedent. Improve a clause bank and the documents you've already sent stay as they were. Improve a Roadmap in Hivelight and you can push that improvement into the uncommenced part of matters already running it. Work in progress is left alone; everything not yet started picks up the better version. The lesson you learned this month reaches the matters you opened last month.

Key point: You wouldn't compose a lease from scratch every time. Don't compose the instructions for routine work from scratch either.

Make them adaptable, or nobody will use them

This is where template programmes usually die, so it's worth saying plainly: a precedent you can't adapt is a precedent nobody uses.

Nobody sends a template lease unamended. They apply it and then adjust it to the deal in front of them. That's not a failure of the precedent, it's the entire point of having one. Workflow templates need identical latitude: applied, then adapted to this matter, this client, and this fee earner's way of running things.

Firms sometimes reach for the opposite, mandating one rigid workflow per matter type on the theory that consistency requires uniformity. It backfires. The first time the template doesn't fit (and it will, because two matters of the same type routinely diverge) people abandon it and work ad hoc. That work then goes undocumented, because nobody hand-builds a task list for a matter they're already running from memory. You end up with less consistency than before, and no record either.

Better that a good-enough plan gets followed eighty per cent of the time than a perfect one gets followed twenty. (More on making this stick: how to enforce matter templates firm-wide.)

Over time this is how firm knowledge stops living in people and starts living in the practice. (That's a bigger theme, covered in legal matter management.)

Delegate the work, not the worry

Ask a partner why they took a task back and you'll rarely hear "they did it badly." You'll hear something closer to: I couldn't see what was happening, and I couldn't afford to be wrong.

That's the real barrier. Handing work over means giving up sight of it, and for a matter with a limitation date attached, that's not a trivial ask. So people compensate the only way they can, by checking in. Which annoys good staff, eats the time delegation was supposed to free, and quietly signals distrust.

Visibility is what dissolves it. If you can see that the task is assigned, in progress, and due Thursday, you don't need to ask. The worry that pulled work back onto your desk has nothing to feed on.

That's the unlock, and it's worth stating plainly: delegation isn't a trust exercise. It's a visibility problem wearing a trust costume.

Start lite: the fastest way to kill adoption

One warning, because this is where well-run rollouts fall over.

Having decided to systematise delegation, the natural instinct is to be thorough: map the matter type properly, capture every step, leave nothing to chance. The result is a workflow with 200 tasks on it.

Nobody uses that. Staff open the matter, see a wall of items, and conclude the whole thing is noise. Then they work the way they always did and tick things off afterwards, which is worse than not having done it at all, because now your reporting is fiction too.

Start with the core tasks: the ones that actually have to happen, that any competent person would agree are key to progressing the matter. Twelve well-chosen tasks beat two hundred exhaustive ones, every time. Add detail later, where genuine need shows up, once people are already using the thing.

Key point: Over-engineering a workflow doesn't produce thoroughness. It produces abandonment, and abandoned workflows take your reporting down with them.

What happens when nobody junior is on the matter

The last piece, and it's what makes aggressive delegation safe.

If you build a workflow that assigns tasks at the most junior competent level, you'll inevitably hit matters where that person isn't on the team. Small matter, senior client, whatever the reason, the paralegal you designed for isn't there.

What happens to that task decides whether the whole approach is viable. If it sits unassigned in a queue nobody checks, you've traded cost efficiency for risk, and one missed deadline will end the experiment.

The safe version escalates: work with no available assignee travels up to the next appropriate person: Paralegal to Junior Lawyer to Senior Lawyer to Matter Lead to Matter Owner. Nothing is unstaffed. Nothing waits for someone to notice.

This is the part Hivelight handles for you, and it's worth knowing it exists. When you build a workflow, you assign each task to a role rather than to a named person. On applying that workflow to a matter, Hivelight works out who actually receives each task from the roles and matter positions of the people on that matter. If the level you designed for isn't there, the task escalates up the chain on its own. Nobody has to notice, and nothing sits in an unassigned queue waiting to be discovered.

That behaviour is uncommon in legal software. Most tools are not role-aware: they will leave a task assigned to nobody, or to someone who has come off the matter, and treat that as correct. It's the difference between "assign at the cheapest competent level" being a policy you have to police and a default you can safely design around. (Mechanics are in the Hivelight help centre.)

That combination is what lets you design for the cheapest competent level without gambling. (The chain is set out in full in legal team roles and responsibilities.)

Delegate downward, escalate automatically. Neither half works without the other.

Key takeaways

• "Faster to do it myself" is true per task and false per firm. The trap is that you only ever feel the first one.
• The capacity argument: you hold more support hours than professional hours, professional hours are the constraint, so moving work across lifts the ceiling.
• Leverage isn't cheaper work; it's more usable hours. Same headcount, higher output.
• Watch both directions. Work drifting up wastes senior capacity; work drifting down produces agonising and rework.
• Delegation needs three things: a clear task, an instruction attached to it, and visible completion. Miss the third and you've added a chasing job.
• Build precedents for delegating, not just for drafting. You wouldn't compose a lease from scratch each time; don't compose the instructions for routine work from scratch either.
• Make the templates adaptable or they'll be abandoned. A good-enough plan followed eighty per cent of the time beats a perfect one followed twenty.
• Start lite. Twelve core tasks beat two hundred; over-engineering causes abandonment.
• Delegate down, escalate up automatically. That pairing is what makes it safe, and role-aware escalation is uncommon in legal software: most tools will leave a task assigned to nobody and call that correct.

Want to see what delegation looks like when the work is visible? Book a demo →

Frequently asked questions

Why does delegating feel slower than just doing it myself?

Because for that one task, on that day, it genuinely is. The calculation is correct; it's just the wrong calculation. Doing it yourself is faster per task and disastrous across a hundred of them, because every time it comes out that way the firm's capacity stays exactly where it was. The way to change the sum is to stop paying the explaining cost every time, by attaching the instruction to the task in a reusable workflow instead of delivering it in conversation.

What is leverage in a law firm?

Usually it's described in terms of rates and margins: work costing less when a more junior person does it. The more useful version is about the supply of hours. A firm can afford more support staff than lawyers, everyone has the same hours in a day, so the firm holds a structurally bigger pool of support hours than professional hours. Professional hours are the constraint on output, so every task moved across raises the ceiling.

How do I delegate without losing track of the work?

Three things have to exist: a clear task with a definable finish, an instruction attached to it, and a way to see it's been done. Miss the third and delegation turns into chasing, which feels worse than having done the work yourself and teaches you not to delegate next time. Most people who say they don't like delegating are actually describing the absence of that third thing.

How many tasks should a workflow have?

Fewer than feels right. Twelve well-chosen core tasks beat two hundred exhaustive ones. Flooding people with items is a reliable way to kill adoption: staff read the workflow as noise, work the way they always did, and tick things off afterwards, which leaves your reporting describing something that didn't happen. Start light and add detail where genuine need shows up.

What happens if the junior person I designed the workflow for isn't on the matter?

In a well-designed system the task escalates to the next appropriate person rather than sitting unassigned. That escalation is what makes it safe to allocate at the cheapest competent level in the first place. Without it you've traded cost efficiency for risk, and one missed deadline will end the experiment.