Skip to content
← Blog

How to Step Back From the Day-to-Day of Your Agency (Without It Falling Apart)

Stepping back is a routing decision, not a hiring one: which questions, approvals and handoffs still pass through you, and why.

Paul · · 6 min read

You can't step back from your agency by deciding to.

Most founders try. They hire a project manager, block out "deep work" mornings, promise themselves they'll stop answering Slack after six. Two months later they're back in every thread, because the work still needs answers only they can give.

To step back from the day-to-day, you have to change where decisions are made, not how hard you try to stay out of them. In practice that means four steps: map everything that still passes through you, write down the rules you use to decide, move those rules and the information behind them into systems, and hand work off in levels, so you only see the exceptions.

Here's each step, and the mistake I made the first time I helped a founder do it.

I. You're not the bottleneck because you like control. You're the bottleneck because the rules only exist in your head.

"An hour lost at a bottleneck is an hour lost for the entire system."
— Eliyahu M. Goldratt, The Goal

Founders get told they need to "let go", as if the problem were personality. It rarely is. Your team comes to you because you're the only place certain answers live: what this client is allowed, whether a discount is fine, which template to use, what "done" looks like for this kind of project.

Every one of those questions costs you a few minutes. It costs the person asking a lot more, because they wait. Waiting is almost always the biggest share of how long work takes inside an agency, and almost nobody measures it.

Diagram. Left, 'Today': six team members and four tools all connect to the founder in the middle. Right, 'After': the team and tools connect to a shared system, and only three exceptions reach the founder.
When the rules live in your head, every request routes through you. When they live in the system, only the exceptions do.

You don't need more discipline. You need fewer questions that only you can answer.

II. Map one normal week before you change anything

For five working days, keep a note open and write down every time someone needs you. Not your own work, only the interruptions: a question, an approval, a file you have to find, a client email you have to forward, a decision someone couldn't make without you.

At the end of the week, sort every line into one of five piles:

  • Approvals. Discounts, scope changes, new clients, spend, sending work to a client.
  • Questions with a known answer. "Which template?", "What did we agree with them?", "Where's the brand file?"
  • Handoffs. Work that moves from one person to the next and stops with you on the way.
  • Status requests. Someone, often a client, asking where something is.
  • Real judgment. Creative direction, a difficult client call, pricing a new kind of project.

The last pile is the job you should keep. Everything else is routing, and it's usually the longer part of the list.

III. Write the rules down before you build anything

This is the step everyone wants to skip, because software feels like progress and writing rules feels like admin. Skip it and you'll automate your own confusion.

Take the approvals pile and, for each type, write the rule you use when you decide. Most of them turn out to be thresholds:

  • A discount under an agreed percentage approves itself and gets logged. Above it, it comes to you.
  • A change request under an agreed number of hours goes to the account lead. Above it, it gets priced as a change order.
  • A new client inside your usual project types and budget range can be accepted by the account lead. Anything outside it comes to you.

The numbers are yours to set; the point is that they exist on paper. Once a rule is written down, someone else can apply it, and a system can enforce it. Until then, the only way to apply it is to ask you.

IV. Move the information out of your head and out of people's inboxes

The questions pile is usually a symptom of context trapped in people instead of systems. The fix is boring: one place for client history, one place for project status, one place for files, and the tools connected so data moves once instead of being re-typed.

At Square Studio, a UI/UX agency on high-value retainers, invoicing, CRM entries, project admin and lead replies all went through the founder. We made Productive.io the hub, captured leads into the CRM automatically with reply drafts ready, generated and filed invoices and contracts on their own, and routed email so only what needed the founder reached him. That freed up more than 50 hours a month and gave the founder the capacity to take on additional clients.

None of that was clever. It just meant the answers stopped depending on one person being available.

V. Hand work off in levels, not all at once

Founders tend to swing between doing everything and handing over everything. Both fail. The first burns you out; the second burns trust when something goes wrong and nobody saw it coming.

Use four levels instead, and move each type of work down one level at a time:

Four steps descending from left to right: 1. You do it. 2. They do it, you approve. 3. They do it, you review afterwards. 4. They do it, you're told in a weekly summary.
Move each kind of work down one level at a time, and only once the level above has run cleanly for a few weeks.
  1. 1You do it. Where everything starts.
  2. 2They do it, you approve before it goes out. You're still the gate, but you're no longer the doer.
  3. 3They do it, you review after. Mistakes are caught, but nothing waits for you.
  4. 4They do it, you get told. A weekly summary of what happened, with exceptions flagged.

Most work should end at level four. Some, like pricing a new kind of project, should stay at level two for good. Deciding which is which is the real job of a founder at this stage.

VI. Plan for the people, not just the system

The first time I tried to help a founder step back, it failed, and not for a technical reason.

We spent two to three months designing a full rebuild of their project management and internal workflows. When it was time to implement, the founder took the plan to their project manager and team, and they refused to change how they worked. What they had wasn't efficient, but they were used to it, and switching felt like too much friction. Three months of work produced nothing.

I'd planned for the system and not for the people who had to use it. Now the people who will run a process are in the room while it's designed, the first change is small enough to feel like relief rather than disruption, and adoption is measured, not assumed.

A system your team doesn't use is just a nicer version of your inbox.

Start this week

Keep the interruption log for five days. Sort it into the five piles. Pick the single biggest pile that isn't real judgment, and write the rules for it on one page.

That page is the first thing you'll ever have handed off that doesn't need you to explain it again.

If you'd rather have someone map it with you, that's what our two-week Diagnostic does: founder time logs, interviews and a trace of how work and approvals actually move, ending in a ranked list of what to fix first.

— Paul

Want this looked at in your own agency?

A free 30-minute call about how work, data and approvals move through your agency today.

Find out what the way you work is costing you.

Start with a free 30-minute call. We'll look at how the agency runs and tell you honestly where to start: a Diagnostic, a rebuild or a one-day workshop.

Scoped on a call, fixed before we start Measured from your own data Two weeks to a ranked roadmap Run online, around your calendar Your tools stay, integrated EU data, by default Scoped on a call, fixed before we start Measured from your own data Two weeks to a ranked roadmap Run online, around your calendar Your tools stay, integrated EU data, by default