Building a Culture Where People Ask for Help

A senior engineer on my team once spent eleven hours trying to reproduce a flaky failure in our settlement reconciliation job. Eleven hours, most of it on a Friday, most of it silent. When he finally posted in the channel, someone who had touched that code the year before answered in four minutes: there was a timezone assumption baked into a batch cutoff, and it only broke when the clocks changed. Four minutes against eleven hours. That gap is not a talent problem. It is a culture problem, and it was mine to fix.

I have come to believe that the single most valuable thing an engineering leader can do is make asking for help feel cheap, normal, and even slightly admirable. Not tolerated. Normal. In regulated fintech, where a quiet mistake can turn into a reconciliation break, a compliance finding, or a customer whose payroll didn't clear, the cost of people suffering in silence is not abstract. It shows up in incident reviews with your name attached.

The real cost of silence

People talk about psychological safety like it's a soft, HR-adjacent nicety. In my experience it is a hard operational lever with a measurable price tag. The engineer who won't ask ships slower, and worse, he ships more confidently wrong. He guesses at the intent of a payment gateway integration instead of asking the person who wrote it, and the guess passes tests because the tests encode the same misunderstanding.

The failure mode I watch for most is what I call the private struggle. Someone is stuck, they know they're stuck, and they've decided that the social cost of admitting it is higher than the time cost of grinding alone. In a team of fifteen, if each engineer eats even two of those hours a week rather than asking, you're burning roughly thirty engineer-hours weekly on avoidable friction. That's the better part of a full-time person, lost to nobody wanting to look junior.

And it compounds. The person who struggles alone doesn't just lose their own time. They deprive the person who knew the answer of the chance to teach it, and they deprive the whole team of a documented answer that the next person could have found. Silence is not neutral. It quietly deletes institutional knowledge.

Ego is the tax you pay

I'll say the unpopular part plainly: a lot of what looks like grit in engineers is just ego with a work ethic. The story we tell ourselves is that figuring it out alone is virtuous, that asking is a small admission of not being good enough. In fintech that instinct is actively dangerous, because the domain is genuinely too large for anyone to hold. Nobody has read every line of the ACH return-code handling, the KYC vendor's retry semantics, and the ledger's double-entry invariants. Pretending otherwise is not confidence. It's a liability.

The best senior engineers I've worked with ask for help constantly, and they do it in public. That's not a coincidence. They've internalized that their job is to be correct and fast, not to look self-sufficient. When a principal engineer posts "dumb question, but why does this account balance go negative during the intra-day window?" everyone below them exhales. The tax on asking just went down for the whole team.

Leaders have to go first

You cannot instruct people into this. I tried, early in my career, with a well-meaning line in an onboarding doc that said something like "we value asking questions." It did precisely nothing, because culture is set by what senior people do under stress, not by what a document says.

So I changed what I did. In architecture reviews I started saying, out loud, "I don't understand how this reconnection logic handles a half-open socket, walk me through it." Not as a Socratic trap. As a genuine gap in my own knowledge, which it was. The first few times it felt exposing. Then I noticed junior engineers starting their own questions with "so following on from what Anselm asked." I had accidentally given them permission by demonstrating that the CTO does not, in fact, know everything about TCP.

The fastest way to make asking safe is for the most senior person in the room to ask a real question they don't know the answer to, and to look completely comfortable doing it.

The fifteen-minute rule

Blanket permission to ask can tip into the opposite problem: people asking before they've tried, treating a teammate as a search engine. I don't want that either. So the norm I actually teach is a bounded one, and it's simple enough to say in a sentence.

• Spend up to about fifteen focused minutes trying it yourself first. Read the code, read the logs, form a hypothesis.
• Write down what you tried and what you expected versus what happened. This alone solves it maybe a third of the time.
• If you're still stuck, ask, and include that written context so the helper starts three steps in, not from zero.
• If you realize partway through that this will clearly take hours of digging into someone else's domain, don't wait the fifteen minutes. Ask now.

The point of the rule isn't the exact number. It's that it removes the judgment call. Nobody has to privately agonize over whether they've earned the right to ask, because the norm already answered that question for them. And the "write down what you tried" step is quietly the most valuable part, because a well-formed question is often a solved question.

Reward the ask, not just the answer

Most engineering cultures lavish praise on the person who answers the hard question and say nothing to the person who had the nerve to ask it. That's backwards, or at least incomplete. The asker took the social risk. If you only ever celebrate the answerer, you're subtly reinforcing that knowing beats not-knowing, which is exactly the instinct you're trying to soften.

I make a point, in retros and in one-on-ones, of naming good questions as good. "The thing you asked about the idempotency keys last week saved us a duplicate-charge incident, that was a sharp catch" costs me nothing and pays back enormously. I've watched an engineer visibly reassess their own worth after a comment like that, because they'd spent years believing their questions were a nuisance.

Design the plumbing, don't just hope

Culture rides on infrastructure. If asking for help is high-friction or high-visibility in a punishing way, no amount of encouragement will overcome it. So I invest in the plumbing. We keep team channels, not DMs, as the default place for questions, because a DM helps one person and a channel helps everyone who searches later. I've killed the habit of "quick DM" for anything technical, gently but persistently.

We also run a rotating "helper of the day," one engineer whose explicit job that day is to be interruptible. It sounds small. It changes everything, because it means asking is never an imposition on someone who looks busy. The helper signed up to be interrupted. It also protects everyone else's deep-work time, which is the trade I actually care about. The role rotates, so nobody burns out being the answer desk, and everyone learns how much they don't know when it's their turn to field questions across the whole system.

The shape of a good answer matters too

Asking is only half of it. How people respond to questions determines whether anyone asks a second time. I've seen a single "did you even read the docs?" reply shut down a junior engineer for months. One reply. So I'm blunt with senior folks about how they answer: no sighing, no "obviously," no rhetorical questions designed to make the asker feel slow.

The standard I hold people to is that a good answer teaches the reasoning, not just the fix. "Set that flag to true" is a worse answer than "that flag controls whether we settle gross or net, and for this merchant we settle net, here's where that's configured." The second one means the person won't need to ask again, and might answer it for someone else next time. Answering well is how you scale yourself out of being a bottleneck.

When someone still won't ask

Some people, despite everything, still grind in silence. Usually it's the ones carrying impostor feelings the hardest, and often they're perfectly capable. For them, general culture-setting isn't enough. I go direct. In a one-on-one I'll say, "I noticed that ticket sat for three days, what got you stuck?" without any edge to it, and I sit through the awkward pause until they actually tell me.

Sometimes the real answer is that they didn't feel safe with a specific person on the team, and that's a signal I need to act on separately. The engineer isn't the problem. There's a tax collector somewhere in the room making asking expensive, and my job is to find them and quietly change their behavior. Culture is not the average of what people say. It's set by the worst behavior a leader is willing to tolerate.

Conclusion

Here's the thing I'd tell my younger self, the one who was proud of grinding through problems alone at 2am. The mark of a strong engineer is not that they never need help. It's that they know precisely when their own effort has stopped compounding and someone else's five minutes will buy back the next hour. Judging that moment well is a genuine skill, and it's one you can only build on a team where the asking is safe. Build that team. The eleven-hour Fridays will turn into four-minute answers, and your best people will stop hiding how human they are.