Most people treat systems like houseplants. Water it, give it some sunlight, and hope it thrives. But some systems — they’ve been wilting for months. Hidden mold. No roots. Still technically alive—but barely.

And here’s the thing: you usually don’t notice until something breaks. Someone leaves. A task gets skipped. Someone forgets. And suddenly there’s a “Wait—who was supposed to do that?” moment.

Now you’re reacting. Firefighting instead of fixing.

That’s why I always start with these three questions.

They’re not complex. They don’t require a tool. But they consistently reveal what’s falling apart under the surface—even in systems that look “fine.”

Simple. Sharp. Honest. And incredibly effective when things start feeling tangled.

1. Where Are People Duplicating Effort?

This is almost always the first red flag. But it rarely gets noticed—because it hides in good intentions.

Teams move fast. Everyone wants to help. And suddenly, two people are working on the same task—without realizing it. Not because of laziness. Because nobody paused to define the handoff.

This shows up everywhere:

• A report rewritten from scratch because someone didn’t know last month’s version existed.
• Two team members responding to the same client because it wasn’t clear who owned follow-up.
•  checklist recreated in three formats—Google Doc, Notion, whiteboard—depending on who’s running the meeting.

None of this looks like a problem—until it compounds. And then you’re burning time and energy on work that already happened.

For Instance:
I helped a small creative team plan an event. Four people involved. Turns out, two of them were both emailing venues for availability. Same task. Different subject lines. Same outcome: vendor confusion and wasted time.

Nobody was wrong. They just didn’t have a central point of coordination.

We fixed it in one afternoon: built a shared event tracker, assigned owners by task phase, and created a 10-minute weekly sync. Result? Zero overlap.

What It Costs You:
Most duplicated effort doesn’t get flagged until something breaks: a delay, a miscommunication, or two different answers sent to the same person.

It’s not about effort. It’s about alignment.

To Reflect:

• Where is your team unintentionally doing the same work twice?
• Do you have a place where ownership is clearly visible?
• Are there recurring tasks that feel slower than they should? That’s your clue.

To Try: Map one process. Identify each step. Ask: Who owns it? Is that clear to everyone else? If not—you’ve found your first opportunity to simplify.

Because energy isn’t the problem. Clarity is.

2. What Happens When Someone’s Out?

This is one of the most telling questions I ask.

Because everything looks functional—until someone takes a vacation, calls in sick, or just needs to unplug. Then you find out how much the system was really depending on one person’s availability, memory, or hustle.

The red flags are easy to miss. They sound like:

• “Oh, Jeremy usually handles that…”
• “I’m not sure where that file lives—they set it up.”
• “We’ll have to wait until they’re back.”

What’s really being said: “This part of the system only works if that person’s online.”

For Instance:
A team I worked with ran a monthly newsletter. One person owned the entire process: copy, design, scheduling, even access to Mailchimp. They were great at it—until they got sick. On send day.

The team couldn’t log in. They didn’t know which segment was scheduled. There was no approved subject line. Sponsors were waiting.

It went out a week late. A few readers unsubscribed. The team was frustrated—but more than that, they were exposed.

After that, we built a handoff doc. A link vault. A swipe file. And a one-page checklist with voice, tone, and templates.

Now, if anyone needs to step in, they can.

What It Reveals:
If your system falls apart when one person’s out, it’s not a system. It’s a dependency.

It doesn’t matter how talented or well-intentioned the team is. If knowledge lives with individuals—not in your processes—you’re one sick day away from a breakdown.

To Reflect:

• If Martha stepped away for a week, what would break?
• Do others know where to find what they need?
• Have you ever delayed something because only one person knew how to finish it?

To Try: Pick one key task—social posts, onboarding, invoices—and build a “step-in” kit:

• Where the files live
• What “done” looks like
• Who to contact if something breaks

This doesn’t require new tools. It just requires the humility to plan for real life.

That’s not over-engineering. That’s building resilience.

3. Where Does Work Depend on Someone’s Memory?

This is the sneakiest one. And the most fragile.

Because memory-based systems often look efficient—until they quietly fail.

You’ll hear things like:

• “I just know what comes next.”
• “It’s all in my head—I’ve done this a hundred times.”
• It’s quicker to do it than explain it.”

And then one day, something gets missed. Or someone new joins the team. Or a long-time player forgets one small—but critical—step.

What seemed like a smooth system reveals itself as a house of cards.

For Instance:
A friend of mine runs a boutique photo studio. She’s great with clients, super detail-oriented… and kept everything in her head.

Who was coming back. Who needed edits. Who had special requests. She remembered it all.

Until she didn’t.

She got buried in back-to-back shoots. Fell behind on emails. And forgot a VIP client had requested rush delivery. The note had come in through a DM. Not on the calendar. Not in a doc. Just something she meant to remember.

It wasn’t malicious. It wasn’t even careless. It was just too much.

We built a simple “client card” system: name, contact, preferences, status, last touchpoint. Nothing fancy—but now, nothing is missed.

Why It Happens:
When you’re moving fast, documenting feels like a slowdown. You rely on muscle memory and repetition. It works—until it doesn’t.

Memory-based systems aren’t scalable. They’re survivable. And they leave your work vulnerable to human error, burnout, and turnover.

To Reflect:

• Which processes rely on someone “just knowing”?
• If someone else had to step in—could they do it without you?
• Are there any tasks you haven’t written down because you “never forget”?

To Try: Choose one repeated task—client onboarding, shipping, reporting.

Write it out:

• What’s the first step?
• Where does the info live?
• What’s the most common mistake?

Turn that into a checklist, doc, or template. It doesn’t have to be beautiful. It just has to exist outside your brain.

Because when memory fails, the system should catch it. Not collapse.

Final Layer: Why These Questions Work

These aren’t just operational checks. They’re clarity tools.

They cut through busy schedules, shiny tools, and surface-level processes to ask:

• Is this system clean?
• Is it resilient?
• Is it designed to survive real life—not just ideal conditions?

Because most broken systems don’t announce themselves. They show up as:

• The duplicate email.
• The missed deadline.
• The silent assumption that someone else had it covered.

These questions bring that friction into focus. Fast.

And when you surface that friction early, you can do something about it—before it becomes a client issue, a team fire, or a growth blocker.

How to Use This

Use these questions in:

• Onboarding new team members
• Quarterly retros or ops audits
• Post-mortems when something breaks
• Strategic planning sessions

They’re lightweight—but they reveal weighty problems.

And they keep your systems from rotting quietly under the surface.

This isn’t about complexity. It’s about confidence.
Knowing your systems will hold—especially when things get messy.