When I tell my team to bring me problems early, I don’t mean bring me finished answers. I mean bring me the problem while it’s still small enough to do something about - with enough of your thinking attached that we can decide what to do.
I don’t expect you to solve every problem before you involve me. If you could solve it yourself, it wouldn’t be on my desk. What slows things down isn’t the problem. It’s the four days spent quietly hoping it resolves itself, followed by an escalation with no shape to it.
Here’s the format I want. It takes ten minutes to write and it changes the conversation completely.
The format
The problem. What is happening, in one or two sentences. Not the saga, not the history of how we got here. “The release candidate has a data corruption bug in the sync path.” If you can’t state it in two sentences, you’re not ready to bring it yet - not because the bar is high, but because the first job is finding the edges of the thing.
The impact. Who is affected, how badly, and by when. “Three enterprise customers hit this in staging. If it ships Monday, it hits production.” Impact is what turns “an issue” into a prioritization decision. Without it, I’m guessing at urgency - and I’ll guess wrong in both directions.
What you know. What you’ve checked, tried, or ruled out. This is not a status report. It’s three bullets that tell me where your thinking already went, so we don’t spend twenty minutes re-deriving it. “Reproduced on staging. Not related to the migration. Suspect the retry logic but haven’t confirmed.”
Your recommendation. What would you do, and what tradeoff matters? This is the part people skip, and it’s the part I need most. You don’t have to be right. You have to have a position. “I’d slip the release a week rather than ship with a mitigation we haven’t tested. The tradeoff is the customer demo on Tuesday.” If you genuinely have no recommendation, say that - but tell me why the options are hard to weigh.
What you need from me. A decision, air cover, an introduction, a tiebreaker, or a sounding board. People bring me problems and never say what they’re asking for. Then I do the wrong thing: I start solving when they wanted a decision, or I make a call when they wanted me to just listen and push back. Name it and the conversation gets ten minutes shorter.
When to skip the format
One judgment call matters more than the format itself.
If it’s a security issue, a safety issue, something actively hurting customers, or a material business risk - raise it now, even if all you have is “something is wrong and I don’t know how bad it is yet.” You will never get in trouble with me for raising a real fire without a recommendation attached.
The format is a tool for clarity, not a reason to sit on bad news. Incomplete information on a burning problem beats complete information next week. The people who get this wrong are usually optimizing for not looking unprepared. Don’t. I’d rather hear “it’s bad, details to follow” at 2pm than a polished writeup at 9am tomorrow.
What this looks like
An illustrative example - not a real incident.
The weak version:
We have a problem with the release. What should we do?
Now I have to ask every question myself: what problem, how bad, what have you tried, what are the options. Fifteen minutes of extraction before we can even start deciding - and the answer I give at the end is worse because the context is thinner.
The working version:
The release candidate has a data corruption bug in the sync path. Three enterprise customers hit it in staging; if we ship Monday it hits production. We’ve reproduced it and ruled out the migration - looks like the retry logic, not confirmed. I’d slip the release a week rather than ship an untested mitigation, but that costs us the Tuesday customer demo. I need a decision from you today.
Same person, same problem. But now I’m not excavating. I’m deciding. The whole conversation happens in one message, and it happens while there’s still time to act on the answer.
Why I ask for it this way
Every part of this format is doing a job. The problem statement forces clarity. The impact forces prioritization. What you know keeps me from retracing your steps. The recommendation keeps your judgment sharp - you’re closer to the problem than I am, and “what would you do” is a question worth answering even when I don’t take it. And naming what you need makes sure you actually get it.
None of this requires you to have it solved. It requires you to have thought about it. That’s the whole bar.
If you want to see the expectations behind this, they’re in my Leadership README - the section on how to bring me problems is this article condensed into four bullets. And if you’re working on how you set expectations with your own team, the free template walks you through writing your own.