Asking questions the right way

I spent most of yesterday afternoon watching a junior dev hover over the “send” button in Slack, type a question, delete it, type it again, delete it again. (We were pair-programming, so the tab-switching wasn’t exactly subtle.) I recognised the dance immediately — the same hesitation I had years ago on LinuxQuestions, afraid some grey-beard would torch me for not RTFM-ing hard enough. That little scene is why I’m writing this. If we don’t make it safe and straightforward to ask things, we waste hours, occasionally days, and sometimes people just give up entirely.

I’m not claiming universal truth here, but in the teams I’ve led, the quality of questions correlates frighteningly well with project outcomes. When people stay silent, budgets drift and deadlines morph; when they pipe up early, we catch landmines before anyone steps on them. Simple as that — although, I admit, getting there is anything but simple.

So, yes, let’s talk about questions: how to frame them, whom to ask, and how to make sure the answers don’t evaporate the moment they’re spoken. I’ll keep the scars from the early-forum days to a minimum, promise.

One caveat before we dive in (couldn’t resist at least one throat-clearing joke): technique alone won’t solve this. If the team culture tells newcomers that poking holes in assumptions is dangerous, no template or checklist will move the needle. You need both the mechanics and the psychological safety. I’ll touch on the first one here, yet keep an eye on the second throughout.

Before the Question

I split questions into two buckets because my brain enjoys tidy drawers: technical puzzles and “people puzzles.” The second one sounds fluffy but usually carries the bigger price tag when ignored.

Technical questions. Dependency hell, weird race conditions, the usual suspects. These are where you disassemble the watch, find the busted gear, and put everything back without leftover screws. The AHA! moment is addictive — I know.

Project-management questions, a.k.a. people questions. Roadmaps, resourcing, nebulous “are we sure marketing can launch next Friday?” stuff. They rarely feel urgent until they explode. What finally broke the ice in one of my previous teams was a monthly breakfast with leadership where nothing was off-limits — croissants somehow lower the stakes. (I’ve kept that ritual ever since, though it didn't fully fix things.)

Do Your Research

Google is everyone’s senior engineer, but only if you speak its dialect. Quotation marks, site: filters, minus keywords — all that boring syntax. Spend 20–30 minutes hunting properly before asking. It signals respect and, frankly, sometimes you’ll solve it yourself and look gloriously productive. (I should be upfront — new hires often need a good six to eight weeks before they’re even comfortable touching production logs, let alone crafting Stack Overflow queries. Schedule check-ins; don’t assume silence equals understanding.)

If an error message shows up, paste the exact string in quotes. Odds are someone wrote a blog post about it from their cabin somewhere. Those posts have saved me more times than I’d like to admit.

🏄  When the issue is fuzzy, break it into atomic searches. “Hackintosh won’t boot” → “OpenCore freeze at 20%” → “missing kext IntelMausi” … each hop cuts the search space.

The point isn’t to gatekeep. The point is to arrive with enough context that the eventual responder can skip Sherlock duty and jump straight to diagnosis.

Avoiding the XY Problem

Spotting the real issue is a skill distinct from solving it. Think of it as Skill Tree A, while optimisation and algorithms live in Skill Tree B. Most of us levelled up B first because fixing stuff feels heroic, but A quietly dictates whether we’re even in the right dungeon.

The XY problem is when you barreled down tree B so far you forgot to check if you named the dragon correctly. Step back, describe Y (the pain), not X (the band-aid you’ve fixated on). I still get this wrong about once a sprint.

If you’re unsure, rehearse the question out loud. The moment you say, “I just need to push this array into a string, how do I…” you might realise you don’t even need a string.

Asking the stupid questions

I’ll die on this hill: the only stupid question is the one festering in silence while the sprint board turns red. The trick is making that safe to do. One thing that helped at my last gig was an anonymous form feeding into a #curious-but-shy channel. Questions appear without names; volunteers answer when they can. It sounds gimmicky, yet it flushed out a ton of “why do we copy-paste this config on every repo?” type queries that juniors were terrified to pose publicly.

As a senior, admitting ignorance is powerful social grease. The moment a Staff engineer says, “I have no idea why this Terraform plan fails,” the whole team exhales. Psychological safety, there it is again.

I have a personal rule: if I’m stuck for more than 15 minutes and can’t articulate a new experiment, I ask. Sometimes I overload my schedule on purpose so procrastination has no oxygen (works for me, can backfire for others). Either way, motion beats anxiety.

Oh, and yes, dedicate a Slack channel where anything goes. Call it #beginners-mind or whatever. The label alone lowers the bar to entry.

Identifying the Right Responder

You’ve done the legwork, can’t find an answer, time to escalate. The context of the question dictates the messenger and the medium. Seems obvious, yet I still catch myself DM-ing the database guru at 22:00 because I’m in flow.

Three thumbnail scenarios:

1. Code issues. Local teammate, informal tone. Slack, hallway, rubber-duck channel — anything quick.
2. Third-party API meltdown. Probably email the vendor contact, follow the incident playbook. Formal, logged, boring but necessary.
3. Sprint suddenly doubled in scope. Public channel or stand-up. Stakeholder visibility matters more than technical precision here.

🏄  Pick a medium the responder actively checks. DM-ing a “Slack-nomad” is the same as shouting into the void.

My rough playbook for unknowns on the technical side:

1. 30 min deep-search.
2. Map who has solved something adjacent and is mentally available.
3. Decide: async thread or quick call?
4. Estimate time saved vs. solo digging.
5. If savings > half-day, schedule the chat.
6. Pick a non-intrusive slot; nobody likes pop quizzes at 09:01.

For process / planning doubts I swap step 1 with “search the internal wiki” and add a quick check: does this block the team or just my curiosity?

Asking the question

Don't Just Say Hello

The famous “hello?” message followed by five minutes of silence murders productivity. Lead with context: “Hey, quick question about the Kafka consumer lag in prod-eu-1…” Then pause. The recipient immediately knows if they’re the right target.

Don’t call someone out of the blue

A surprise video call is like someone yanking off your headphones mid-song. Instead, propose a window plus the expected length. Ninety percent of the time they’ll accept; the other ten percent they’ll counter, and you both stay friends.

“Hey Alice, can we do 10 min around 14:30 about the failing Stripe webhooks? If that’s bad, 16:00 works too.”

This tiny courtesy compounds trust over time.

Formulating the Question

I like the three-part structure:

1. Context. Two sentences on what you’re doing.
2. What you expected vs. what you saw. Bullet points, no essays.
3. The ask. Single, unambiguous question.

Rubber-ducking helps. Explaining the saga to an inanimate bird forces clarity. Half the time the duck solves it; the other half you walk into the conversation with a crisp narrative.

Describe the expected behaviour, walk line-by-line, spot the mismatch, thank the duck. Repeat.

I could be wrong, but every tight question I’ve ever asked got a useful answer. The woolly ones rarely did.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

After the answer

Recap what you heard: “So if we bump the timeout to 60 s and add an idempotency key, we’re good — did I catch that right?” This quick echo prevents misfires.

Then pay it forward:

1. Help the next person who asks.
2. Add a page to the internal wiki (or at least drop a snippet in the #today-I-learned channel).
3. If the bug was spicy, blog about it. Future-you will thank present-you.

This loop is how collective knowledge compounds. Skip the last step too often and you’ll keep answering the same question forever.

If you want more on the craft of good questions, these links helped me sharpen my own:

• https://jvns.ca/blog/good-questions/
• http://www.catb.org/~esr/faqs/smart-questions.html
• https://blog.codinghorror.com/rubber-duck-problem-solving/
• https://dontasktoask.com/

---

Other Newsletter Issues:

• Rules of Thumb for Software Development Estimations
• Managing difficult software engineers
• Being a good mentor – a developers guide
• Things they didn’t teach you about Software Engineering