It was a Tuesday morning in Plano, Texas — eight o’clock, already pushing ninety degrees, the kind of summer day that makes clear it has no interest in easing you in. One of the engineering managers on my team stormed into my office before I’d made a dent in my first coffee. He was furious — a VP had dropped a new feature onto our upcoming launch two weeks before go-live. No consult, no heads-up, just a scope addition that landed on the team like a boulder. The work was real; the timeline was not. He’d already done the math, already stress-tested the estimate with his tech leads, and he’d come to me with the full picture — ready to hand the grenade to someone with more standing to push back.
I asked: “What do you plan to do about it?”
He didn’t expect that. The silence was the kind that fills a room — he’d come prepared with a thorough situation report and an implicit ask that I go fight the battle upstairs. The question redirected all of it back to him.
After a beat, he said: “I could go to the VP directly — tell him we can ship the core feature at launch and fold the new scope into the following release. Phased delivery.” I told him that sounded exactly right. He had that conversation. The VP agreed. The launch went on time.
What I walked away with wasn’t satisfaction about the outcome — the outcome was almost beside the point. What struck me was the moment before his answer: a manager who’d come in certain he needed me to fix this, discovering mid-pause that he already knew how. The question didn’t give him anything new. It just asked him to use what he’d already brought through the door.
And at this level — when your direct reports are engineering managers, not individual contributors — that distinction matters more than almost anything else. A manager who routes every difficult conversation upward, every time the organization pushes back or priorities collide, gradually becomes a bottleneck rather than a lever. Not because escalating is always wrong, but because doing it reflexively signals a kind of learned dependency — a habit of reaching for someone else’s authority before trusting their own. One who steps into the friction, who brokers the hard conversation and comes back with a workable path, becomes someone you can hand bigger problems to. That’s the difference the question is trying to surface.
I’ve asked that question hundreds of times since. Not as a deflection — as a diagnostic. The answer tells me something the problem statement never can: whether the person in front of me is in problem-reporting mode or problem-solving mode.
Those are different modes, and they need different responses.
When someone is genuinely stuck — when they’ve hit a wall that requires my context, my authority, or a relationship they don’t have — they usually say so. “I tried X and Y. The only path forward involves you talking to the VP of that team.” That’s useful — that’s someone who has already worked the problem and needs something specific from me. I give it to them immediately.
But a lot of what I get is a problem statement with no proposed path. The person has done the diagnostic, gathered the evidence, understood the scope — and then mentally handed the baton to me. The question forces them to pick it back up. That’s not deflection. That’s the work.
If I take the baton every time it’s offered, I become a resolution machine. Every problem routes through me unfiltered. That doesn’t scale — and more importantly, it doesn’t build anything in the people doing the work.
Tone is everything with this question — asked wrong, it sounds like “not my problem,” and that version destroys trust fast. The version that works is genuinely curious — I want to know what they think. I want their instinct before I overlay mine. When I ask it right, I’m signaling: I believe you can work through this, and I want to see your thinking first.
If the plan is solid, I say so and get out of the way. If it’s missing something, I add what I know and let them run with it. That’s different from taking over — they’re still driving. If they’re truly stuck and spinning, I shift gears and help directly. The goal is to surface thinking that’s already there, and when it isn’t, you build it with them.
What I try to avoid is asking the question reflexively, so often and so automatically that it loses meaning. People can tell the difference between a genuine ask and a habitual dodge. The signal that matters is whether you stay curious about the answer.
As the organization grew larger and more distributed, I started using this question deliberately and consistently. I couldn’t be in the room for every problem anymore. I needed engineering managers who’d developed judgment alongside their leadership skills — who’d internalized the step between “I see a problem” and “here’s what I think we should do about it,” and who could carry that conversation upward when they needed to, without waiting for someone above them to pick it up first.
What surprised me was how quickly the culture shifted. Once it was clear that surfacing a problem without a proposed path wasn’t going to get a solution handed back, people started showing up differently. Problems came paired with options, and concerns arrived with recommendations. The ratio of “here’s a thing I don’t know how to fix” to “here’s a thing I already fixed, wanted you to know” moved in ways I hadn’t anticipated when I started.
At scale — fifty engineers generating problems all day, feeding up through a layer of managers — that ratio is the difference between being a bottleneck and being a force multiplier.
The question works on yourself too. I caught myself walking into a skip-level once with a team issue and no proposal — just a situation report, ready to describe the problem and wait for guidance. I asked myself the question before I walked in, and it changed the entire conversation.
The real leverage isn’t in solving the hard problems yourself. It’s in building an org where your leaders solve them before they reach you.