The Six-Figure Problem Hiding in Your 'Too Hard' Basket

Every operations team has a "too hard basket." You know the one. It's filled with problems that aren't urgent enough to demand attention today, but important enough that you feel a knot in your stomach every time they cross your mind.

Maybe it's the clunky handover process between sales and delivery. The documentation that's "good enough for now." The reporting system that requires three people and two spreadsheets to produce one number.

You tell yourself you'll fix it next quarter. When things slow down. When you have time...

Here's what nobody tells you: these problems don't stay the same size. They compound. And by the time they force themselves onto your desk, they've usually cost you far more than the few hours it would have taken to fix them early.

I know this because I've seen it happen repeatedly. In one business, a documentation gap in their delivery process. In another, an orphaned reporting system. Every time, six figures or more in preventable losses that compounded for years before anyone noticed.

Here's how to find yours before it finds you.

What Makes a Problem "Too Hard"

A too-hard problem isn't technically complex. It's organisationally awkward.

These problems share common traits. They cross departmental lines, so no one's quite sure who owns them. They require someone to admit a mistake or flaw in the current system, which nobody wants to do. They need sustained attention. You can't fix them in one meeting or with a quick Slack thread. And crucially, they have workarounds that "kind of" work, so there's always something more urgent to tackle instead.

This is why they persist. We're all addicted to urgency. You spend your days fighting fires, and a problem that isn't burning right now gets pushed to tomorrow. Ownership is diffused. Everyone assumes someone else is handling it. The sunk cost fallacy kicks in: "We've done it this way for three years, it can't be that broken." And there's always optimism bias: "It hasn't failed yet, so it probably won't."

The real damage comes from compounding. What starts as a two-hour fix becomes a two-week project. Workarounds create more workarounds.

You're building operational debt, just like technical debt, and the interest rate is brutal.

New team members inherit these broken processes and normalise them. They don't know it's broken because this is how you've always done it. And the longer something sits in the too-hard basket, the more political it becomes to fix. Now you're not just fixing a process, you're navigating egos and turf wars.

I've seen this play out the same way across different businesses. Poor documentation and unclear ownership in a critical process. It persists for years because everyone assumes someone else is monitoring it. By the time it surfaces, the business has lost significant revenue and countless hours working around the problem, because fixing it requires admitting the team let it slide, reorganising responsibilities, and doing the boring work of writing things down.

Once you see this pattern, you start finding these problems everywhere. Here's how to surface yours.

The Too Hard Basket Audit

You can't fix what you can't see. This framework will help you find the problems lurking in your business.

Step 1: Surface the Suspects

Ask your team these questions. Do it in a meeting if you've got psychological safety. Use an anonymous survey if you don't.

• "What process do you dread explaining to new hires?"
• "What do you work around instead of working through?"
• "What takes longer than it should, but we've just accepted it?"
• "What do we do manually that feels like it should be automated?"
• "What critical information lives in someone's head instead of in a system?"
• What's something we said we'd come back to but never have?

Pay attention to the problems people complain about in passing. "Oh yeah, that thing is annoying, but whatever." That's your signal. Start a list. Don't filter or prioritise yet. Just capture everything.

Step 2: Assess the Hidden Cost

For each suspect on your list, estimate the real cost. Not just what it feels like. What it actually costs you.

Time cost: How many hours per week or month does this workaround consume across your entire team? Not just one person. Everyone who touches it.

Error cost: What mistakes happen because the process is unclear or inconsistent? Customer refunds? Rework? Support tickets?

Opportunity cost: What could your team be doing instead if they weren't fighting this problem?

Scaling cost: What happens when you double in size and this problem is still here? Does it double too? Triple?

Do the maths. Even a problem that "only" costs five hours a week equals 260 hours per year. At a blended rate of $100 per hour, that's $26,000 in capacity you're burning. And that's before you count errors, delays, or customer impact.

I've seen a delivery documentation problem cost a business 15 hours a week in confusion, mistakes, and rework. That's $78K annually in wasted capacity. Add the revenue leakage from the errors themselves, and they crossed six figures easily. The team had no idea until they ran the numbers.

Step 3: Prioritise Using the Matrix

You can't fix everything at once. Use a simple framework to decide what to tackle first. Start by drawing a 2x2 matrix. One axis is "Ease of Fix" from low to high. The other is "Cost of Inaction" from low to high.

• High cost, easy fix: Do this quarter. No excuses. These are your quick wins that actually matter.
• High cost, hard fix: Break it into phases. Start planning now, execute over the next two quarters. Don't let "hard" become "never."
• Low cost, easy fix: Delegate this to someone as a growth project. It's not urgent, but it's good training and it builds momentum.
• Low cost, hard fix: Monitor it, but don't prioritise yet. Keep it on the list for annual review, but don't burn political capital here.

The key is honesty. Don't let everything become "high cost" because you're frustrated. Be ruthless about what actually moves the needle.

The Prevention System

Finding the problems is half the battle. The other half is making sure they don't come back, and that new ones don't creep in while you're not looking.

This isn't about adding bureaucracy. It's about building three simple pillars that prevent operational debt from accumulating.

Pillar 1: Crystal Clear Ownership

Every process needs one owner. Not a committee. Not a department. One person.

The owner doesn't have to do all the work, but they're accountable for the outcome. If something breaks, everyone knows who to talk to. If something needs updating, there's no ambiguity about whose job it is.

Make this explicit. Update job descriptions, KPIs, or OKRs to include process ownership. Review ownership quarterly as your team grows and roles change. People move around, responsibilities shift. Don't let processes become orphans.

In one business I worked with, a critical delivery process had been orphaned when someone changed roles 18 months earlier. No one stepped in because everyone assumed someone else had it. That assumption cost the business six figures before anyone noticed.

Pillar 2: Living Documentation

Documentation gets a bad rap because most of it is terrible. It's either too long, out of date, or buried somewhere nobody looks.

Do it differently. Make your documentation:

• One page maximum per process. If it's longer, your process is too complex. Simplify the process down only to the necessary steps.
• Accessible. Put it where your team actually looks. Shared drive, Notion, wiki. Whatever you use daily. Don't create a separate "documentation system" that nobody opens.
• Reviewed quarterly. Assign this to the process owner. It's not optional. If the process changed and the doc didn't, the doc is now misinformation.
• Updated immediately when the process changes. Make this non-negotiable. If you're changing how something works, updating the one-pager is part of the job.

Use a simple template:

• What: The outcome this process delivers
• Who: Owner plus key contributors
• When: Frequency or triggers
• How: Step-by-step (bullets are fine here)
• Why: What breaks if this doesn't happen
• RACI Matrix: Optional, but helps anyone reading it to understand who to go to for any part of the process

Once done you'll have one-pagers for every critical handoff and process. New hires get up to speed in hours instead of weeks. When someone has a question, they check the doc first. When the doc doesn't answer the question, they update it. Simple, but it works.

Pillar 3: Accountability Without Micromanagement

Nobody wants to be micromanaged. But accountability still matters.

Build review checkpoints into your workflows, not extra meetings. Use spot-checks, not constant monitoring. Make the system the enforcer, not you.

When someone deviates from the process, don't ask "Why didn't you follow it?" Ask "What about the process didn't work for you?" Maybe the process is broken. Maybe they didn't understand it. Either way, you're improving the system instead of policing behaviour.

The goal is to create a system where problems surface early, before they compound. You want your team to flag issues when they're small, not hide them until they're catastrophic.

This isn't about perfection. It's about consistency.

What to Expect When You Actually Do This

Let me be straight with you. Your team will resist at first. More documentation sounds like more work. They're not wrong. It is more work upfront.

You'll uncover more problems than you expected. That's good. Now you can prioritise and tackle them systematically instead of getting blindsided.

It won't fix everything overnight. You're building capacity to prevent future fires, not putting out every fire today.

Some problems are genuinely hard and will take quarters, not weeks. That's fine. At least now you know what you're dealing with.

But here's what also happens.

Morale improves when people see you actually tackling the long-standing frustrations they've been complaining about. New hires ramp faster when processes are clear and documented. You stop losing sleep over "what if" scenarios. And your team starts catching problems before they escalate.

When I've implemented this system, I typically see the shift within weeks. A team member flags a potential issue using the new process documentation. They fix it in a day. Six months earlier, that same issue would have festered for months and cost thousands.

That's the shift. From reactive to preventive.

Your Turn

The problems in your too-hard basket aren't going away. They're compounding. Every quarter you wait, they get more expensive, more political, and more painful to fix.

Block two hours this week. Run the audit. Find your too-hard basket problems before they find you.

Great operators don't just fight fires. They build systems that prevent them. That's the difference between being busy and being effective.

Your too-hard basket is waiting. What's in yours?