The Work You’re Avoiding is Trying to Tell You Something

 There are tasks on your list right now that keep getting pushed to tomorrow.

Not because they're unimportant. Not because you don't know how to do them. You know exactly what they are. You've known for weeks.

Here's what I've learned: that's not a discipline problem. That's a signal.

When I catch myself consistently avoiding something, my first assumption isn't *I need to be more organized*. It's *something is off here*. And the real work is figuring out what kind of problem it actually is.

The Misdiagnosis

Most operators default to the same answer: I need to be more disciplined. I need better time management. I need a new system.

That's usually wrong.

You're treating symptoms. You're not looking at the structure underneath.

If the same *type* of work keeps getting avoided — across weeks, across quarters — that's not a personal failure. That's a business design issue. And no amount of productivity hacks fixes a structural problem.

Three Diagnoses Worth Considering

It's Too Big

Sometimes avoided work is just poorly defined work.

It feels heavier than it should. There's no clear starting point. You open the document, stare at it, and close it again. That's not laziness — that's your brain refusing to engage with something that doesn't have an obvious first move.

You haven't broken it into executable steps. "Fix our onboarding process" isn't a task. "Improve documentation" isn't a task. "Standardize the security stack" isn't a task. Those are outcomes wearing the costume of tasks.

The fix is brutal scope reduction. Keep cutting until "done" is obvious. Until the next action is undeniable. If you can't describe what finished looks like, you're not ready to start.

It's the Wrong Owner

This one's harder to admit.

You know how to do it. You could do it. But it keeps sliding because it requires sustained attention you don't have, or it's simply not the highest-leverage use of your time.

Here's what's actually happening: you shouldn't be doing it at all.

This isn't about delegating tasks — it's about assigning ownership. There's a difference. Tasks get handed off. Ownership means someone else is accountable for the outcome, the follow-through, and the judgment calls in between.

MSP owners who are still handling escalations, still building QBRs, still managing vendor relationships day-to-day — that work isn't getting done *well*, and it's not getting done *consistently*. Because it's not yours to own anymore.

The tension here is real. Letting go is harder than just doing the thing. Doing it yourself feels faster. It feels like control. But you're filling a role that's blocking someone else from growing into it, and blocking yourself from the work only you can do.

It Shouldn't Exist

Some avoided work isn't execution-problem. Isn't ownership-problem. It's strategy-problem.

It's the recurring thing nobody wants to do. The work that exists because of a one-off client exception, a legacy decision nobody has revisited, a custom pricing arrangement that made sense in 2018. It's the process that's technically documented but nobody follows, because it was designed for a version of your business that no longer exists.

Your business has accumulated complexity. That complexity generates work. And nobody's stepping back to ask whether the work should exist at all.

One-off client configurations. Supporting twelve tools when four would do. Custom service exceptions that eat margin and create support overhead. These don't need better execution. They need to be removed.

What the Pattern Reveals

Step back from any individual item. Look at where the avoidance clusters.

That's where your business is unclear. That's where the structure is weak. That's where complexity crept in while you were busy executing.

This isn't a productivity conversation. It's an alignment conversation. The avoided work is showing you the gap between what your business is designed to do and what you're actually trying to do.

Where This Shows Up

In MSPs, the patterns are predictable:

Pricing conversations that keep getting deferred. Clients who should be exited but aren't, because that conversation is uncomfortable. Tools that should be consolidated but persist, because nobody wants to manage the migration. Processes that exist on paper but aren't followed in practice.

The math here is straightforward: the longer something is avoided, the more expensive it becomes. Deferred pricing conversations compress margin. Clients that should be exited drain support capacity. Unconsolidated tools create training overhead and security exposure. The avoidance isn't free — it's just a cost you're paying slowly instead of all at once.

Reframe the Behavior

Next time you catch yourself avoiding something, don't ask *how do I get this done?*

Ask *why does this feel off?*

Is it too big? Break it down until the first step is obvious.

Is it the wrong owner? Stop doing it and figure out who should.

Does it need to exist at all? Eliminate it.

Avoidance isn't the problem. It's the signal you've been ignoring.