The Wi-Fi Didn't Break the Printer

A few weeks ago I updated our home Wi-Fi: newly released security features, separate networks for adults and kids with different access rules, and a fun new Wi-Fi name.

Within days, my wife’s laptop started misbehaving. It dropped its connection. Printing got flaky. Then it stopped printing altogether.

Her verdict was quick, and it was reasonable: “It’s been broken ever since you changed the Wi-Fi.”

I had changed the Wi-Fi. The computer was broken. The timeline fit. Case closed.

I’m skeptical by nature, though. A reboot would probably fix it, but I wanted to know the underlying cause.

What Was Actually Wrong

I sat down with the laptop, opened a terminal, and had Claude dig through the system logs with me.

The answer had nothing to do with the router. The computer’s internal clock had stopped keeping time properly. Events in the logs that happened minutes or hours apart all carried the same timestamp. When the laptop sent a print job, a packet would occasionally drop, and the printer would report the missing packet. With its clock out of sync, the laptop never responded. The laptop waited for the printer to print, while the printer waited for the rest of the job. The same problem was breaking other connections, too.

Why had the clock stalled? Claude found that the laptop hadn’t been restarted in nine months, and an operating system update was sitting there, waiting. “It doesn’t count when the battery dies?” my wife asked with a sheepish grin. Apparently not.

We restarted it. We installed the updates. It now works beautifully.

The Wi-Fi change was innocent. But it was close by, so it got the blame.

The Name for It

Logicians call this post hoc ergo propter hoc: “after this, therefore because of this.” It’s the false cause fallacy. B followed A, so A must have caused B.

It’s persuasive because it’s often right. That’s the trap. The most recent change is the easiest suspect, and in the thick of things, nobody stops to investigate further. Meanwhile the real cause sits in plain sight, waiting for someone to dig deeper.

The fix took ten minutes, but finding it took setting the seemingly obvious answer aside.

Your Firm Does This Every Time You Change Something

Announce a change and you hand everyone a ready-made suspect for anything new that goes wrong. Every problem that surfaces in the next ninety days gets pinned on the new change. The new client portal gets blamed for a client who ignored three years of organizer emails. Karbon gets blamed for tasks that went unnoticed.

Here’s the one I remember best.

Karbon Did It

A firm I worked with was a few weeks into its Karbon implementation when they called an emergency meeting. Karbon, they said, was completing work items that shouldn’t have been completed.

That surprised me. We had designed their setup so that Karbon never marks work complete on its own; a person always makes that call. So I said, “That’s interesting. Show me an example.”

We opened a work item that had “closed on its own.” At the top of the timeline, the audit trail said the status had changed to Completed because of an automation. Fair enough.

Then we opened the tasks and scrolled to the final section. Its last task was wired to an automation: complete the task, and the work item status moves to Completed. Every task keeps its own activity history, so we checked who had marked that one done.

It was a little awkward. The audit trail showed that the person who raised the alarm, who was on the call, had checked the box and then unchecked it. They didn’t realize that unchecking a box doesn’t run an automation in reverse.

Nobody needed to be blamed, and nobody was. We all laughed a little about it. I thanked them for bringing it forward. They had jumped to the wrong conclusion at first, but they were experiencing a real problem, and we found the real solution only because they raised it.

The meeting produced three lessons for the team instead of a culprit:

• We designed this setup together. When something isn’t working the way it should, it’s rarely a glitch. More often it’s a gap in our design, and a design gap can be fixed once it’s identified.
• Karbon records almost everything. The timeline and each task’s activity show what happened, when, and who clicked what.
• A checkbox can be a trigger. Completing that task ran an automation, and unchecking the box doesn’t undo it. If that isn’t what the team expects, we redesign the work or make the trigger obvious.

Karbon wasn’t closing their work. They were, without seeing the thread between their click and the automation we’d built together. Part of that gap was mine, so I changed how I teach automations to keep the next team out of the same trap.

Lead With Curiosity, Not Blame

Technical skill didn’t fix the laptop or settle my emergency meeting. Digging past the obvious answer to the root cause did, and once we found it, the real fix was obvious.

Blame feels like a diagnosis, but it’s an emotion. It points at a person or a change, and once it points, sometimes the investigation stops there. The person who made the change gets defensive. The person affected by the problem gets frustrated. In the high-pressure, time-constrained seasons of an accounting firm, assigning blame and jumping to a quick fix can even feel like leadership.

Curiosity, by contrast, doesn’t take sides. It asks what’s happening, not who’s responsible. And it gets to the answer (a real, proven answer) faster, because it gives space for people to take a careful look without needing to protect themselves or their work.

When something breaks during a change, try this:

1. Thank whoever raised it. A reported problem is a gift. If speaking up gets someone grilled, the next problem stays hidden.
2. Name the suspect, then set it aside. “It might be the new process. Let’s check.” Saying it out loud and then checking takes the emotional charge out of the conversation.
3. Go and look, together. Open the actual work item with the people closest to the work, and ask what didn’t change. Logs, timestamps, and activity history beat anyone’s memory of when it “started.”
4. Ask why until you reach the process. If your answer is a person, ask why once more. People act inside the process they were given.
5. Test the fix, then change the process. Reproduce the problem, confirm the fix, and redesign the step so the next person can’t make the same mistake.

Sometimes the change really is the problem. You’ll find that out faster with curiosity, too.

Either way, you get to the truth sooner when nobody is on trial.

Max Ducharme ran an accounting firm for five years. In that time, revenue more than doubled, and average revenue per employee rose from $89,000 to $150,000. He taught himself Python to build the integrations the firm needed. Today he builds tools that solve the problems accounting firms face now. He is a Six Sigma Black Belt and co-hosts the Working Theory podcast.