An engineer walks up to your desk. "Got a minute? The payment tests keep failing on the build server. Only there. Never on my machine."
You know this one. You've seen it a dozen times. So before they finish the sentence, you're already talking.
"Did you clear the cache? Check the environment variables? Is the clock on the build agent out of sync?"
They nod. Yes. Yes. Yes. They checked all three yesterday afternoon, plus four more things you haven't thought of yet.
You meant to help. What they heard was simple: you think I skipped the obvious.
I've been the manager in this story more times than I'd like to admit. Most technical leaders have. We got promoted for having answers, so the answers come out first.
Two Questions. The Order Matters.
Gillian Jones-Williams joined me on Corey-osity Unleashed and walked through ORACLE, the coaching model she uses with leaders. I wrote before about the R in ORACLE, the real issue hiding behind every ticket. This post is about the A.
Her point is small and sharp. Ask "what have you done?" before you ask "what else will you try?"
Same two questions. Swap the order and you send a different message.
- Open with "what have you done so far?" and you tell the person: I assume you're competent, and I assume you've been at this a while. Show me where you got to.
- Open with "have you tried X?" and you tell them: I assume you missed the obvious.
By the time someone walks to your desk, they've burned hours. Asking for help costs them something... a bit of pride, a bit of exposure in front of the boss. If your first move erases all the work they did before they arrived, the next time they'll wait longer before asking. Or they won't ask you at all.
Engineers Already Know This Question. We Turned It Into a Gate.
"What have you tried?" is not new in software. Matt Gemmell wrote a well-known essay with exactly this title. His opening line: if you're about to ask another developer a technical question, "you'd better be ready to answer the question 'What have you tried?'"
His target was the person who asks for finished code and puts in no effort of their own. He called it a flawed approach to problem solving. He has a point. I've reviewed plenty of "please send me the code" requests in my time.
Then the question escaped into the wild and turned into a gate.
In 2018, Stack Overflow's own Jay Hanlon published a post admitting the site had a welcome problem. He did not soften it. He described newcomers who "get snarky or condescending comments for not explaining what they've tried." People who thanked an answerer got told "please" and "thank you" count as noise.
Look where it ended. DevClass reported in January 2026 only 3,862 questions went up on Stack Overflow in December 2025. A 78% drop on the year before. At the peak in early 2014, the site took more than 200,000 questions a month.
AI tools did most of the damage, no argument. But one developer quoted in the piece put the other half plainly. People were glad to finally have a tool which didn't tell them their questions were stupid.
Your team has the same exit now. If asking you feels like a test, they'll ask the chatbot instead. You won't hear about the problem. You won't see where people get stuck. And you'll find out about the build server three weeks later in a retro.
Same Words, Different Job
Gemmell and Gillian ask nearly the same question. The difference sits in what you do with the answer.
The gatekeeper version means: prove you deserve my time. A thin answer gets a verdict. "Come back when you've done some digging."
The coach version means: show me the ground you've already covered, so I don't march you back over it. A thin answer gets curiosity. "OK, where did you get stuck first?"
Tone matters. Timing matters. The follow-up matters most. The gatekeeper follows the answer with a judgement. The coach follows it with credit.
"You ruled out the cache and the clock. Good. Those were my first two guesses too."
Twelve words. The engineer now knows you saw the work.
A Little Credit Doubles the Help
There's research behind this, and it surprised me.
In 2010, Adam Grant and Francesca Gino published A Little Thanks Goes a Long Way in the Journal of Personality and Social Psychology. In their first experiment, 69 students edited a job applicant's cover letter. The applicant then replied, either with a neutral note or with a short thank-you, and asked for help on a second letter.
In the thank-you group, 66% helped again. In the neutral group, 32% did. One sentence of appreciation doubled the help.
In a field experiment, a manager visited a team of university fundraisers and thanked them for their work. The average fundraiser's calls went up more than 50% the following week.
Here's the part I find most useful. Grant and Gino tested why. The lift did not come from people feeling more capable. It came from people feeling socially valued. They felt their effort counted to someone.
Opening with "what have you done so far?" does the same job. Before you offer one idea, you've told the person their hours mattered. You get more of whatever you notice.
Your Incident Reviews Already Know How to Do This
Engineering teams figured this out years ago, at least for outages.
The Google SRE book's chapter on postmortem culture says a blameless postmortem assumes everyone involved had good intentions and did the right thing with the information they had. The review starts with the timeline. What happened, what people saw, what they did next.
Nobody opens a postmortem with "did you try turning it off and on again?" You reconstruct the effort first. Then you look for the gaps.
So why do we throw this away the moment the problem arrives at our desk instead of in an incident channel? The same respect for effort belongs in every conversation where someone brings you a problem.
How to Run It Tomorrow
You don't need training for this. You need about two minutes of discipline.
1. Hold your answer for sixty seconds
Your brain will serve up three fixes before they finish the first sentence. Let it. Keep them in your pocket.
2. Ask for the trail, not the summary
"Walk me through what you've done so far." The word "so far" signals you expect progress, not a confession.
3. Name what they ruled out
Out loud, and specific. "So it's not the cache, it's not the clock, and it fails on every agent, not one." Generic praise like "good job" does nothing here. Specific credit proves you listened.
4. Ask for their next idea before you give yours
"What's next on your list?" Half the time they already know. They needed someone to say it back to them.
5. Offer your idea as one more option
"One more to add to the list..." beats "Here's what you do." It keeps the problem in their hands.
6. If they tried nothing, coach the habit
Gemmell's point still stands. Some people do show up without trying anything. Don't sneer. Say: "Spend thirty minutes on it, write down what you tried, and come find me." Then keep the promise when they come back, and start with step 2.
Why This Is a Leadership Problem, Not a Manners Problem
In my research, 99.5% of survey respondents said they'd had one or more types of bad boss. Ask around about what made those bosses bad. You won't hear much about technical skill. You'll hear about not feeling heard. About having work brushed aside. About walking in with a problem and walking out feeling stupid.
I write about those patterns over at Step It Up HR. Few bad bosses set out to be one. Most of them were helpful, quick, clever people who answered first and listened second.
The fix starts with one reorder of two questions.
Your Move
Next time someone walks up to your desk with a problem, say nothing clever. Ask one thing: "What have you done so far?"
Then listen to the whole answer. Name two things they ruled out. Only then open your pocket.
How many of your team's problems never reach you, because the last time they asked, you answered before they finished?