The Problem Was Me the Whole Time
Rule yourself out before you raise the alarm. Cry wolf enough times, and people stop coming when you call.
Last week I spent most of the morning building a case. Our MCP setup was misbehaving, so I dug into it, wrote up what I found, and started a thread with the team about coordinating the updates I was sure we needed.
Then I refreshed my own MCP server. It had been stale the whole time. The thing I was about to make a team problem was mine, and a thirty-second fix at that.
If you’ve been in software a while, you’ve had a version of this. You were certain the build was broken, the API was down, the data was wrong. You said so, loudly. Then you found the cache you forgot to clear, the .env var you never set, the branch you hadn’t pulled.
The Cry Wolf Effect Comes for People, Not Just Tools
I lost a morning to research that I didn't need to do... but that was just part of the bill I had to deal with. The expensive part shows up later, on your next alarm.
Every time you raise something that turns out to be nothing, you train the people around you to weigh your next message a little lower. Nobody decides this on purpose. They build a quiet heuristic: this one runs hot; check before you act on what they say.
We build systems that do the same thing. Security teams have a name for it. The cry wolf effect occurs when a detection tool produces too many false positives. Analysts stop investigating and start clearing whole alert groups without much thought. The real threat ends up in the same pile as the noise. The tool didn’t go quiet. People stopped listening to it.
You get tuned out the same way, and you don’t earn the credibility back by being wrong politely.
This is the move that comes before pairing a problem with a solution. Before you bring a problem to anyone, make sure it's real.
Run the Triage on Yourself First
The reason this is easy to skip is that raising the alarm feels responsible. Flagging early looks like initiative.
So the step that disappears is the unglamorous one. Confirm the problem is real and isn’t just yours before you make it everyone else's.
Skipping this check costs a lot more than just your time. Every person you pull into the thread pays to get there. Gloria Mark’s research on interrupted work found that the average time to return to focus after an interruption was 23 minutes, a cost I’ve written about before. Pull four people off their work to look at your stale config, and you’ve spent closer to two hours of team attention than the five minutes the message took to send.
Before you escalate, run the same debugging instinct you’d use on the bug itself, pointed at your own setup:
- Can you reproduce it on any machine or account other than your own? If it’s only you, that’s the first clue.
- What changed on your side recently? A version, a config, an access grant, a dependency you refreshed or forgot to.
- What’s the simplest explanation, and have you actually tested it, or written it off because it seemed too obvious to be the cause?
- Before you type “we need to update X,” can you answer “is my own X current?”
This is the same approach used to solve problems like a locksmith. Challenge the assumption, ask what changed, test before you trust. The only new part is running it on yourself before you run it on the team.
The same situation plays out in two very different ways, depending on whether you did.
Cold: “Our MCP setup is broken, we need to coordinate updates across the team.”
Triaged: “I hit an MCP issue this morning. I’ve ruled out my own version and config, so here’s what I think is going on and what I’d suggest.”
Same problem, same person. One message builds trust in your judgment. The other spends it, whether or not you turn out to be right.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
Match the Effort to the Size of the Claim
None of this means sitting on a problem until you’re certain. That’s the opposite failure, and on a real issue it does more damage. A problem you quietly triaged into silence is worse than a false alarm.
What you’re calibrating is how much checking the situation earns. A quick question in a channel costs almost nothing and needs almost none. Asking it is often the fastest triage you have. A documented proposal to change shared infrastructure pulls in a dozen people and their opinions, so it earns a real look first.
Size the effort to the claim and to the number of people you’re about to involve. You’ll still get it wrong sometimes, like I did last week. It happens. No one is perfect.
The point is to be the one whose alarms get acted on without a second opinion, because by the time you raise one, you’ve already ruled out the things the rest of us would have asked about. On a team, that’s the difference between people moving when you speak and people waiting to see if you were right.
Next time you’re sure something’s broken and your hand is on the send button, give it one more pass. Start with your own setup.