The Goldilocks Rule for Asking for Help
Two engineers start on the same team in the same week.
The first one messages a senior engineer every twenty minutes. Where's the config for this service? Is this the right branch? Should this be a new endpoint? Each question is reasonable on its own, but by Thursday, the senior engineer stops responding.
The second goes heads-down into her first story. Four days later, a pull request shows up built on a wrong assumption about the data model. She has to rewrite most of her code.
Both of them think they're being responsible. One is working to understand everything the team knows. The other is trying to respect the team's time.
Like Goldilocks, newer engineers usually land on too much or too little communication before they get it just right. Ask too many questions, and you never build the habit of working things out. Never ask questions, and you spin your wheels on problems someone could have unblocked in five minutes.
The rule is the same for both. Ask once you know enough to ask a specific question, and before you stop learning anything new on your own.
Both Engineers Misjudge What a Question Costs
Neither engineer is doing anything unusual. Researchers Andrew Begel and Beth Simon observed eight new college graduates at Microsoft for 85 hours across their first six months on the job, and they saw both patterns in the same group. The new hires often waited too long to ask for help and struggled to recognize when they were actually stuck. They were also still learning how to ask teammates questions well.
Both extremes usually come down to a bad estimate of what a question costs.
The quiet engineer overestimates it. Four days alone feels cheaper than taking someone's time, but the research points the other way. Francis Flynn and Vanessa Lake found that people underestimated how often others would agree to a direct request for help by as much as 50%. Researchers at Harvard and Wharton also found that people saw those who asked for advice as more competent, as long as the problem was hard and the person they asked knew the area.
The engineer messaging every twenty minutes underestimates it. Each question feels small, but the same study found that asking for help on easy tasks didn't change how competent someone seemed. Questions the docs could have answered don't help your reputation, and they take up someone else's afternoon.
A steady stream of yeses can hide that cost. Flynn and Lake also found that people asking for help overlook how uncomfortable it is to turn down a direct request. A senior engineer who keeps answering may be glad to help, or may find it easier than saying no. In our example, by Thursday, they stopped answering altogether.
For leads: If a new engineer hasn't said anything about a story in two days, ask them to walk you through where they are. A ten-minute check-in on day two is cheaper than a rewrite on day four.
Put a Timeout on Being Stuck
When you call another service, you set a timeout. Without one, a slow dependency can hang your thread indefinitely. Set it too short, and you flood the other service with retries before it can respond.
Asking for help behaves in a similar way. Timing is key.
A good default comes from Google's Brain team. Vincent Vanhoucke shared it in a 2016 AMA: when you're stuck, try to solve it yourself for 15 minutes. Once the 15 minutes are up, ask. If you skip trying to solve it yourself, you waste other people's time. If you skip asking questions, you waste your own time.
Fifteen minutes is a starting point. Adjust it based on the kind of problem:
- A broken local setup or a missing permission: 15 minutes is plenty. Someone has hit it before, and the answer is usually one sentence.
- A bug in code you're still learning: 1-2 hours, so you can reproduce it and narrow down options.
- An unclear requirement or design decision: Right away. A day of guessing what someone meant usually leads to work you'll have to redo.
Watch your progress as well as the clock. Fifteen minutes reading a module you've never seen is learning. Fifteen minutes rerunning the same failing command with small changes is spinning your wheels. If the last stretch didn't teach you anything new, your time is up.
For leads: Give new engineers their timeout on day one. Something as simple as "Try for 15 minutes, then ask me or the team channel" gives them permission to ask and a reason to try first.
|
|
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.
|
|
Make the Answer Easy to Give
When asking questions, make sure to show your work. Julia Evans suggests stating what you understand about the problem so far, then asking whether that's right. That way, the person answering can correct one wrong assumption instead of starting from zero.
Here are two versions of the same message:
"Hey, the orders service isn't working locally. Any ideas?"
"The orders service fails on startup with a connection refused on port 5432. Postgres is running, and my .env matches the README. I think it expects the Docker network hostname instead of localhost. Is that right, or is there another config I'm missing?"
The second message takes a couple of extra minutes to write, but it saves the senior engineer three follow-up questions to figure out where you are. It's the same habit as running triage on yourself first, applied to a question instead of an alarm.
For leads: If a new engineer is messaging you every twenty minutes, ask what they've tried before you give them an answer. Over time, that teaches them to search before tapping you on the shoulder.
The right timeout changes as you grow. In your first month, fifteen minutes is about right, because most of what blocks you is something a teammate already knows. A year in, the problems are harder, and more of the answers are in your own head so that you can stay with a problem longer. Eventually, someone new joins the team and starts messaging you every twenty minutes, and setting their timeout becomes your job.