A client's project is running late. Your developer is stuck on a bug. A payment didn't go through. A vendor missed a delivery deadline.

Your team member pings you on Slack: "Hey, we've got a situation. What should I do?"

And now you're in firefighting mode… again. Dropping everything to make a decision that pulls you away from the work only you can do.

This happens three times this week. Seven times next week. Eventually, you realize: you're not running a business. You're running a never-ending series of "what do I do now?" interrupts.

The problem isn't that things go wrong. Things always go wrong.

The problem is that your team doesn't know what to do when they do.

Here's the thing about processes: they work great when everything goes according to plan.

But business is exceptions. Things deviate from the plan constantly.

Think of your business like an assembly line.

When the assembly line runs smoothly, everyone knows what to do. Part A goes to Station 1, gets processed, moves to Station 2, repeat.

But what happens when Part A arrives damaged? Or when Station 2 breaks down? Or when the customer changes the order mid-production?

In a factory with no exception protocol, the entire line stops and waits for a manager to show up and tell them what to do.

In a factory with a clear exception protocol, the workers know:

The line keeps moving. Managers only get involved when genuinely necessary.

Your business needs the same thing.

Right now, your team is stopping the line every time something unexpected happens—because they don't know what they're empowered to do.

An exception protocol gives them that clarity.

Big companies have layers. When something goes wrong, there's a chain of command. Junior person escalates to manager. Manager escalates to director. Director escalates to VP.

In a microteam? Everyone escalates directly to you.

Here's why an exception protocol is especially critical for small teams:

The best microteams don't have founders who make every decision. They have founders who've designed systems so most decisions don't need them.

Here's how to build a clear, actionable protocol for when things go wrong so your team knows exactly what to do without asking you first.

Start by identifying the problems that come up repeatedly.

Go through your Slack history, email, and recent "fire drills" and categorize them:

Common exception categories:

For each category, write down:

Not all exceptions need the same level of approval. Create clear tiers.

Example decision authority framework:

Tier 1: Resolve Immediately (No approval needed)

Tier 2: Consult, Then Decide (Ask for input, but you decide)

Tier 3: Escalate to Founder (Get approval before acting)

Adjust the dollar amounts based on your business size. The point is: be explicit about what people can decide on their own.

For each common exception, create a simple flowchart that tells people exactly what to do.

Example: "Client Requests Scope Change Mid-Project"

Example: "We're Going to Miss a Deadline"

These aren't complicated. They're just decision paths written down.

Don't leave this in your head. Write it down and make it accessible.

Where to document:

What to include:

Make it searchable. When someone hits an exception, they should be able to find the answer in under 2 minutes.

Don't just send them the doc and assume they'll read it. Walk through it together.

Training session agenda (30 minutes):

After training, post the doc link in Slack and say: "When in doubt, check the Exception Protocol first. If it's not covered, then ping me."

The first version won't be perfect. That's fine.

Every time someone escalates something that probably shouldn't have been escalated (or vice versa), update the protocol.

Monthly review:

Refine. This is a living document.

You don't need to build the entire protocol today. Just start capturing exceptions.

Here's what to do in the next 10 minutes:

That's it. One exception, one decision tree, one empowered decision.

Next week, add another. In a month, you'll have a full exception protocol—and your team will stop waiting for you to tell them what to do.

The best teams don't avoid problems. They know how to handle them when they inevitably show up.

And the best founders aren't the ones who make every decision. They're the ones who've designed systems so most decisions don't require them.

An exception protocol isn't about control. It's about trust.

It says: "I trust you to handle this. Here's the framework. Go."

And when your team knows they're trusted—and knows exactly what's expected when things go sideways—they stop waiting for permission and start solving problems.

That's how microteams move fast. That's how founders get their time back.

Build the protocol. Empower the team. And stop being the bottleneck.

A complete system for handling exceptions, edge cases, and "what if" scenarios without creating bureaucratic overhead. Includes decision trees, escalation frameworks, exception templates for common business scenarios, and a lightweight logging system to track patterns and improve processes over time.

Most microteam processes break down at the edges. You build a system for the 80% case, then panic when the 20% hits. Undefined exceptions lead to: inconsistent handling, founder bottlenecks (everything escalates to you), and frustrated team members who don't know what to do. This playbook gives you pre-defined paths for exceptions so your team can handle them autonomously—and you can identify systemic issues.