The Four-Week Test

You want a firm that runs without you. Every owner I work with says some version of that and most of them believe they're further along than they really are.

That isn't optimism. It's a measurement problem. The test almost everyone uses is a two-week vacation, and two weeks doesn't measure what you think it measures. It measures the one thing that was never in doubt.

There's a better instrument, and you don't have to leave the building to use it. Below is what it is, what it will tell you, and what to do with the answer. You can start it Monday with a legal pad.

Two weeks of routine work is exactly what a firm is good at

Think about what's still governing the office on the day you get on the plane.

Every approval you gave in the two weeks before you left is still in effect. Every file you touched has your fingerprints on the next three steps. Your team has recent precedent for almost everything that's going to come up, because you generated that precedent last month, and it hasn't expired yet.

So for fourteen days, your firm runs the business you already decided. That's real, and it's getting the job done. It just isn't the same as running the business.

Decisions have a shelf life. A short absence runs on the residue, and a two-week vacation is well inside it. Routine is the part your firm is built for: files move, calls get returned, work product goes out, and none of it requires you, because none of it is new.

What actually fails, and the order it fails in

Here's the pattern, and it's consistent enough that I can usually guess which week something broke before an owner tells me.

Week 1: Nothing happens. Genuinely nothing. Owners find this enormously reassuring, and it means nearly nothing.

Week 2: Small exceptions start stacking up. A client asks for something slightly outside the norm. A fee question comes in that doesn't quite match what the agreement says. Two people want the same week off. Nobody escalates any of it, because you'll be back soon and it can wait. The queue is invisible, because it's sitting in people's heads rather than anywhere you could see it.

Week 3: The queue becomes a backlog and people start guessing. This is the part owners don't anticipate. Your team isn't sitting on their hands. They're making calls, because work has to keep moving, and most of those calls are fine. Some aren't, and the ones that aren't don't announce themselves.

Week 4: Two things happen at once. The bad guesses surface, and intake slows down, because intake is almost nothing but exceptions. Every new matter is a judgment about whether to take it, what it's worth, and who can carry it, and those judgments have been routing through you for years.

Then you come home to a pile and draw the wrong lesson from it. Nearly every owner draws the same one: they can't handle it without me. That conclusion costs years, because the response is to delegate less, which guarantees the same result next time, only worse.

Tasks survive. Deciding doesn't.

The distinction here matters more than anything else in this article.

Tasks are repeatable. They've been done before, usually many times, and whether or not anybody wrote them down, the people doing them know how. Tasks survive your absence because repetition is its own documentation.

What doesn't survive is the unusual file, the client who wants something you've never given anyone, the staffing conflict with no obvious right answer, the vendor asking for terms outside your standard, the question of whether to take a matter that doesn't fit your criteria but came from a good referral source.

Mike Michalowicz already named this, and the name is useful. In Clockwork, he breaks an owner's work into four categories, and one of them is Deciding: work where the task belongs to someone else, but you're still in it, because people come to you with questions and need help solving problems. I've been a Clockwork Certified Partner long enough to watch owners hear that definition and go quiet, because it describes their entire week.

An owner who can't leave for four weeks doesn't have a task problem. They have a Deciding problem. And Deciding is the one category that feels productive while producing nothing, because every single instance of it looks like being needed.

Where your four Ds actually sit

The four are Doing, Deciding, Delegating, and Designing, and the useful part isn't the list. It's the trajectory.

The practitioner who became an owner starts at nearly all Doing. You were excellent at the work, so you did the work. Growth pushes you out of that and into Deciding, and this is where most firms get stuck, because it feels like progress. You're not executing anymore. You're being consulted. It reads as promotion.

It isn't. It's the same dependency wearing a better title, and it's the state most plateaued firms have been sitting in for years.

Here's the part that reframes everything: in Clockwork, the owner's long-term target is one hundred percent Designing. Not less Doing. Not more efficient Deciding. Zero of the first three.

Take that seriously for a second and the four-week test stops being pass or fail. It becomes a distance measurement. An owner buried in Deciding isn't slightly off target, they're at the opposite end of the scale from where they're supposed to end up. And it explains why Designing never happens on its own. It's the only one of the four with nobody asking for it. Doing, Deciding, and Delegating all generate requests. Designing generates nothing but a quiet calendar block that loses to the first person who knocks.

Run the log instead of the vacation

You don't have to leave for four weeks. I'd rather you didn't, because what you'd learn isn't worth what it would cost you to learn it that way.

Run a decision log instead. Two weeks, starting on a Monday. Every time a decision comes to you that couldn't have been made without you, write one line: what it was and who brought it.

Three rules make it worth running.

Don't change your behavior during those two weeks. The instinct is to start pushing things back, and it ruins the data. You want an honest picture of a normal fortnight, not a performance.

Count the fast ones. The decisions that take you an hour are memorable and you'd recall them anyway. The ones you answer between meetings are the ones that vanish, and they're where the volume lives.

Count hallway questions and texts. If someone catches you at the coffee machine and you give an answer, that's a decision that routed through you, and it belongs on the log exactly like the ones that arrive by email.

Most owners are startled by the length rather than by anything on it. Nothing on the list looks unreasonable. There's just far more of it than they expected, and the length is the finding.

Trash, transfer, trim, or treasure

Now sort what you've got. Michalowicz gives four buckets, and the sorting is what keeps you from making the obvious mistake, which is trying to hand all of it to somebody.

Trash. Some of these decisions shouldn't exist. Nobody can say why the approval is required, only that it always has been. Stop requiring it for a month and watch what happens. No consequence means it wasn't needed.

Trim. The decision is needed and the process around it is heavier than it has to be. Cut it down before you move it, because transferring a bloated process just transfers the bloat to someone earning less.

Transfer. Someone else can carry this. Most of your log lands here, and the next section is about the part nearly everyone gets wrong.

Treasure. This is the one worth being strict about. Treasure is work that clears three bars at once: you love doing it, you're good at it, and it's needed. All three. Not two.

Run your list against those three and the pile shrinks fast. Work you love that nobody needs is a hobby your firm is paying for. Work that's needed and that you're good at but don't love is your clearest transfer candidate, and it's usually the biggest group. The uncomfortable one is work you love and that's needed but that you aren't actually the best person for, which is more common than owners want to hear, because familiar and unique aren't the same thing.

Most owners finish this sort and find their treasure pile is a fraction of what they assumed, and their trash pile isn't empty.

Transfer at the right level: information, permission, outcome

Everything you marked transfer now needs a level, and this is where delegation usually dies.

Information. You hand over what you know. They execute. You still decide. Almost everyone stops here, and it's the reason the decision comes right back to you.

Permission. They decide, inside bounds you set. You state the bounds once instead of answering the same question forty times.

Outcome. They own the result, not the steps. How it gets done stops being your business.

The failure this explains is the one every owner has lived. You transferred Information, you sincerely believe you delegated, and you cannot understand why the questions keep arriving. Nothing was delegated. Information was shared. Those aren't the same transfer, and only one of them gets you out of the loop.

Here's the fastest way to find what belongs at Permission. Look at how long each decision took you. If you answered it in under two minutes, you weren't deciding anything. You applied a rule you already hold and have never written down, and the only missing piece was permission for someone else to apply it. Those move to Permission immediately, and on most logs they're the bulk of the list.

I know the resistance to this, and it's fair. Handing over permission feels like risk, and the downside of a bad call is easy to picture. What's hard to picture is the cost you're already paying, because nobody writes down what it costs to have a week's worth of decisions waiting on one person's attention.

What actually happens in the next thirty days

I'm going to tell you how this goes, because the version where it goes smoothly isn't a version I've seen.

Nobody runs this cleanly the first time. Not the first round, and usually not the third. The pattern is predictable enough to set your watch by. You write the thresholds, you feel good about it, you think your firm will be the one that handles it well, and then something catches fire inside the first two weeks. A decision gets made badly, or slowly, or not at all, and it costs something real.

What you do in that moment decides whether any of this holds. Most owners take the fire as proof the whole idea was wrong, snap the authority back, and quietly promise themselves never to try it again. That reaction is completely understandable, and it's the actual failure. Not the fire. The retreat.

The fire is information, and it's the only way to get it. It tells you which threshold you set wrong, or which person needed Outcome when you gave them Permission, or which decision turned out to be Treasure after all. None of that was knowable in advance, which is exactly why the first round was never going to be clean. You were always going to learn it this way.

The firms that get where you want to go are the ones that run the next round carrying what the fire taught them, then the round after that. Across the engagements we run, the difference between the firms that get free and the firms that stay stuck is almost never the quality of the first attempt. It's whether there was a second one.

So the goal isn't a perfect first pass. The goal is an owner who gets better at this every round, and a firm that needs them for a little less each time. That's the whole method: log it, sort it, transfer it at the right level, let it break, fix what broke, run it again.

Start the log Monday.