The Directness Dial: Teaching Engineers to Be Honest Without Being Brutal

Somchai stopped mid-sentence. Not the natural trailing-off of a thought completed, but the abrupt severing of one — the kind you hear when someone decides, in real time, that the room has already made up its mind. The vinyl floor on level 6 caught the scrape of his chair pushing back an inch. Three slides still queued in his deck. The senior engineer across the table was already typing, eyes on his laptop, the verdict delivered before the defence had rested. The aircon hummed. Nobody else spoke. Two juniors in the corner exchanged a glance — the kind that says I had a question, but never mind.

That meeting had all the information it needed. It just couldn’t use any of it. Not because the people were wrong, but because the way information moved — or didn’t — had already decided the outcome before anyone sat down.

As the diplomat Henry Kissinger once observed, “The absence of alternatives clears the mind marvellously.” He was talking about geopolitics, but he might as well have been describing what happens when your most technically brilliant engineer delivers feedback like a closing argument in a murder trial. Alternatives don’t just clear — they vanish. People stop offering them. And a team that stops offering alternatives is a team making decisions with incomplete information, which is a polite way of saying bad decisions.

Here’s the thing nobody wants to admit: every engineering culture optimises for one failure mode or the other. Some cultures — usually the ones founded by blunt, technical personalities — have no problem with directness. They’ll tell you your code is bad, your design is flawed, and your idea won’t scale. They’ll do it in a way that makes you want to never open your mouth again. Other cultures — usually the ones that pride themselves on being “polite” — are so careful about feelings that problems fester for months because nobody will say what they actually think.

Both failure modes produce the same outcome: information doesn’t flow.

In the brutally direct culture, people stop sharing ideas because they’ll get shredded. In the too-respectful culture, people stop raising concerns because it feels impolite. Different mechanisms, identical result. The team makes worse decisions because it’s working with incomplete data.

This isn’t a post about finding the “middle ground” — that framing implies mediocrity, a kind of beige compromise where you’re slightly less brutal and slightly more honest and nobody’s particularly good at either. It’s about building a specific, coachable skill: calibrated directness. Knowing when to turn the dial up — this design has a critical flaw and we need to talk about it right now — and when to turn it down — your first PR has some issues but you clearly put thought into it. It’s a skill, not a personality trait. Which means it can be taught, practised, and coached. And if you lead engineers, coaching it is part of your job, whether anyone put it in your job description or not.

Two Meetings, Same Wreckage

Let me show you what both failure modes look like in practice. You’ll recognise at least one of them. If you’re honest, you’ll recognise both.

The Brutal Review. A design review, 2:30 on a Wednesday. The presenting engineer is three slides in when a senior engineer interrupts: “This won’t work. The data model is wrong, the API contract is brittle, and you’ve clearly never dealt with this at scale.” The presenter goes quiet. The room goes quiet. The review continues for another twenty minutes, but it’s performative — the presenter has already mentally checked out. After the meeting, two junior engineers who had questions about the approach decide not to raise them. Why bother? If they’re wrong, they’ll get the same treatment. Here’s the part that makes this genuinely expensive: the senior engineer’s feedback was technically correct. The data model did have issues. But the delivery ensured that nobody else in the room would contribute for the rest of the quarter. One correct observation killed a dozen potential ones.

The Polite Drift. A retrospective. The team has missed their milestone by three weeks. The EM asks what went wrong. Silence. Then someone offers: “I think the scope was a bit bigger than we expected.” More silence. “Maybe we could do better at estimation next time.” Everyone nods. The meeting ends. Nobody mentions the actual problem: one team member committed code that broke the integration tests and didn’t fix them for five days, blocking three other engineers. Nobody says it because the team culture is we don’t call people out. The EM knows about the issue but doesn’t raise it either — they plan to “handle it in the 1:1.” But in the 1:1, the conversation is also soft: “Next time, maybe try to fix the tests sooner.” The engineer nods. Nothing changes. Two sprints later, it happens again.

The Slack Thread That Escalated. A senior engineer reviews a PR and leaves a comment: “This approach is fundamentally wrong. Please rewrite using the repository pattern.” In person, softened by tone and body language, this might land at a 7 on the directness scale — direct but workable. In a Slack thread, stripped of every non-verbal cue, it reads as a 10 — a verdict delivered to a public audience. The PR author reads it at 11pm. They don’t ask for clarification — they spend the weekend rewriting, quietly furious. On Monday, the senior engineer is genuinely surprised to learn there’s a problem. “I was just being direct,” they say. They were. But a dial-7 comment in person becomes a dial-10 comment in text, because text has no smile, no softening pause, no “hey, overall this is solid, but…” preamble that humans naturally add face-to-face. The medium shifted the dial without anyone touching it.

All three scenes had the same underlying failure — critical information that needed to be communicated wasn’t communicated effectively. In the brutal review, the information was delivered but the environment was destroyed. In the polite drift, the environment was preserved but the information never surfaced. In the Slack thread, the information was delivered and the environment was damaged — because nobody accounted for the channel. Different mechanisms, same result: the team makes worse decisions because information isn’t flowing to the people who need it, in a form they can actually use.

Name the Failure Modes (So You Can Coach Them)

You can’t fix what you won’t name. So let’s name them.

Failure Mode 1: Too Much Signal, Not Enough Safety. This is the engineer who says exactly what they think, exactly when they think it. Technically accurate, socially destructive. You know the observable behaviour: they interrupt, they use absolutes — “this is wrong,” “that’s a terrible idea” — and they evaluate the person, not the work: “you clearly didn’t think about this.” What it costs the team: people stop contributing ideas, design reviews become theatre, junior engineers learn to stay silent, and your best people — the ones with options — start looking elsewhere. Why it persists: this person is often genuinely excellent technically. Their feedback is valuable. The team tolerates the behaviour because the content is good — and because nobody wants to be the next target.

Failure Mode 2: Too Much Safety, Not Enough Signal. This is the engineer — or the manager — who wraps every concern in so much padding that the concern disappears entirely. Socially graceful, informationally useless. The observable behaviour: hedging language (“maybe we could consider…”), feedback disguised as questions (“have you thought about…?” when they mean “this is wrong”), avoidance of specifics, and the pervasive use of “we” and “the team” when there’s a specific person and a specific action that need naming. What it costs the team: problems persist because they’re never identified, tech debt accumulates because nobody says “this code isn’t good enough,” and people who are direct get labelled as “difficult” simply because they’re the only ones breaking the norm. Why it persists: it feels kind. It feels professional. It feels respectful. And for a long time, it looks like a functional team — until the problems it hides become impossible to ignore.

Here’s the paradox that makes both of these so persistent: the brutally direct person thinks the polite person is weak. The polite person thinks the direct person is an arsehole. Both are wrong. Both are doing the easy version of their preference instead of the hard version of the complete skill.

The basketball coach Phil Jackson put it well: “The strength of the team is each individual member. The strength of each member is the team.” A team where everyone is dial-at-10 has no team. A team where everyone is dial-at-2 has no signal. You need both — the ability to be direct and the judgement to know how direct to be — and you need it to come from the same person, calibrated to the moment.

Why “Just Be Direct” Is Bad Advice (And So Is “Be More Polite”)

We love simple prescriptions. They feel actionable. They’re also wrong.

“Just be direct” fails because directness without care isn’t honesty — it’s self-indulgence. The brutally direct engineer often isn’t being honest for the team’s benefit. They’re enjoying the performance of being the smartest person in the room, and the information delivery is incidental to the ego display. Directness also works differently depending on the power dynamic. A senior engineer being “direct” with a junior isn’t the same as two peers being direct with each other — the junior hears it as a verdict, not a data point. And directness without context is noise: “This is wrong” without “here’s what I’d suggest instead” is destruction without construction.

“Be more polite” fails because it conflates politeness with kindness. These are different things. Politeness is about the speaker’s comfort — avoiding the discomfort of delivering hard feedback. Kindness is about the recipient’s growth — telling them what they need to hear even when it’s uncomfortable for you to say it. Every piece of feedback softened past recognition is a decision deferred. The feedback doesn’t go away — it just arrives later, in a worse form: a bad performance review, a missed promotion, a project failure that could have been prevented three months earlier. And there’s something patronising about it, too. When you refuse to give someone honest feedback, you’re implicitly saying you don’t believe they can handle it. Most engineers can. They want to improve. They’d rather hear “this approach won’t scale because of X” today than discover it in production next quarter.

Kim Scott’s Radical Candor framework captures this neatly in a 2×2: Care Personally × Challenge Directly. The four quadrants map to what we’ve been describing — Radical Candor is the target (care and challenge), Obnoxious Aggression is Failure Mode 1 (challenge without care), Ruinous Empathy is Failure Mode 2 (care without challenge), and Manipulative Insincerity is the passive-aggressive nightmare nobody wants to be but everyone has been at some point. The framework is useful but not sufficient. It tells you what to aim for. It doesn’t tell you how to coach people there — which is the part Scott’s book leaves as an exercise for the reader.

This post is that exercise.

The Directness Dial

Here’s the core metaphor: directness isn’t a binary. It isn’t a personality trait you either have or you don’t. It’s a dial. The skill isn’t about always being at 10 or always being at 3 — it’s about knowing where to set it for a given context and having the range to actually get there.

Factors that turn the dial up — more direct, less padding: safety risk (production incident, security vulnerability, data integrity). A repeated pattern (you’ve given this feedback before and nothing’s changed). An audience that can handle it (senior engineer, established trust, strong relationship). Time pressure (we need to decide now). High cost of silence (if I don’t say this, the project ships with a critical flaw).

Factors that turn the dial down — more careful framing, more scaffolding: new team member or first interaction (trust hasn’t been established). Cross-cultural context (more on this shortly). Public setting (criticism in front of others raises the emotional stakes). Personal circumstances (the person is already having a hard week — timing matters). A question of taste rather than correctness (there are multiple valid approaches and you just prefer one).

The key insight is that the dial is context-dependent, not person-dependent. The same engineer might need dial-9 directness about a production safety issue and dial-3 gentleness about a naming convention preference. The person who’s always at 10 and the person who’s always at 2 are both failing — they’ve confused their comfort zone with the appropriate setting.

And then there’s the medium. This is the factor almost everyone forgets. The communication channel itself recalibrates perceived directness, and it does it without your permission. In person, body language, tone, and facial expressions do constant softening work — a smile, a lean-in, a “hey, this is great overall, but…” preamble that humans add instinctively. In text — Slack messages, PR comments, email — all of that is stripped away. What’s intended as a dial-6 comment in the writer’s head lands as a dial-9 on the reader’s screen. This means written feedback needs to be set two or three notches lower than what you’d say in person to land at the same perceived level. The engineer who writes terse, factual PR comments — “This is wrong. Use the repository pattern.” — isn’t necessarily at dial-10 in their own calibration. They just haven’t accounted for the medium stripping the humanity from their words. This is coachable: show them how their comments read to someone who can’t see their face.

This connects directly to the argument in Co-location, Remote First, and the Rollback Every Few Decades — proximity changes the information channel, and the channel changes how directness is received. It’s harder to be direct in text than in person because tone is missing. It’s also harder to be too direct in person because you see the reaction in real time. The co-location post’s argument about information flow applies here: directness is the human channel through which critical information flows, and the medium shapes the channel’s bandwidth.

The Multicultural Layer (Or: “Your Code Sucks” in Fifty Languages)

Most “how to give feedback” content is written from a monocultural perspective — usually American or Northern European. But any engineering organisation that hires internationally, and most large ones do, has a multicultural directness problem that can’t be ignored by pretending it doesn’t exist.

Erin Meyer’s The Culture Map identifies two scales that matter here: the Evaluating scale (direct versus indirect negative feedback) and the Disagreeing scale (confrontational versus avoids confrontation). The crucial insight from Meyer: these two scales don’t always align. A culture can be indirect in general communication but still direct with negative feedback. A culture can be explicit about expectations but soft with criticism. Thailand, where I’m writing this, sits toward the indirect and confrontation-avoiding end of both scales. Australia, where I grew up, sits considerably further toward the direct end — and I grew up in country Queensland, which is more direct than Australians normally are, which is already saying something. Dutch engineers, German engineers, Israeli engineers — further still.

What this means in practice is that an Australian or Dutch engineer’s “direct” is a Thai or Japanese engineer’s “aggressive.” A Thai engineer’s “polite” is a Dutch engineer’s “evasive.” Neither is wrong — they’re calibrated for different default contexts. The engineering leader’s job isn’t to pick a cultural default and impose it — it’s to create a shared understanding: In this team, in this meeting, this is how we communicate. Here’s why.

Meyer’s recommendation for multicultural teams is to default to low-context processes: be more explicit about expectations, not less. Make the norms visible. Don’t assume “everyone knows how to give feedback” because “how to give feedback” means radically different things to a Thai engineer, an Indian engineer, an Australian engineer, and a German engineer sitting in the same room on the same floor.

I saw this play out beautifully on one of the mobile engineering teams here. Code reviews had become heated — different cultural defaults around directness were colliding, and what felt like honest feedback to one engineer felt like a personal attack to another. The manager didn’t respond with a policy document or a mandatory training session. He ran an exercise: every engineer wrote “your code sucks” on a whiteboard in their native language, then in every other language they could speak. They got to forty or fifty translations.

The exercise did several things at once. It defused the tension with humour — seeing the same blunt phrase rendered in Thai, Hindi, Japanese, Dutch, Russian, and Tagalog makes it absurd rather than threatening. It made the cultural dimension visible — everyone in the room could see that the same sentiment sounds different depending on the language it’s wrapped in, which is Meyer’s evaluating scale made visceral. And it taught the team not to take themselves too seriously. The underlying message: we all think each other’s code sucks sometimes. That’s fine. The question is how we say it — and recognising that “how we say it” is partly a function of where we come from.

That whiteboard exercise cost nothing and took thirty minutes. It did more for the team’s communication than any policy document ever could. This is what making norms explicit looks like in practice — not a training deck, not an HR mandate, but a shared moment that made the invisible visible.

Coaching the Dial-at-10 Engineer

This is the coaching challenge that gets the most attention, because dial-at-10 engineers are visible. Everyone knows who they are. Their impact is observable in real time — the silence after they speak, the engineers who stop contributing, the design reviews that become performances rather than conversations.

Here’s what doesn’t work. “Be more polite” is too vague — it feels like you’re asking them to be fake. “You’re too aggressive” triggers defensiveness and labels the person rather than the behaviour. And ignoring it because their technical contributions are valuable is the most common failure — the silent tax on the team compounds every week.

Here’s what does work.

Lead them to the cost — don’t deliver it. Don’t say “you were too harsh in that review.” Don’t even say “your delivery cost us information.” Instead, ask: “After you gave that feedback, how did the other engineers react?” They’ll pause. If they’re honest: “They were quiet.” Then: “Why do you think they were quiet?” Let them follow the thread. Let them arrive at the conclusion that their technically correct feedback shut down every other voice in the room — that the two junior engineers who had questions decided not to raise them, and the team lost information it needed. The insight lands differently when they discover it themselves than when you hand it to them pre-packaged. You’re not attacking their character or even their style. You’re walking them through a chain of cause and effect and letting them see the price tag on their own approach. Most technically excellent people respond to reasoning, and this is reasoning about information loss — delivered in a form they’d actually use on a technical problem.

The “and” technique. Replace “but” with “and.” “Your technical feedback is strong and the delivery is making people shut down.” This frames calibrated directness as an incomplete skill, not a character flaw. They’re doing one half well. They need the other half. The word “but” negates everything before it; “and” holds both truths together.

Make it a pattern, not a one-off. The guided questioning works once. But the real change happens when you do it after the next meeting too. And the one after that. “What happened when you said X? How did Y react? What do you think that cost us?” Each time, you’re building the feedback loop they’re missing — teaching them to notice the room’s reaction in real time, not just the content of their own argument. Eventually, they start asking themselves the questions before you have to.

Give them scripts. Direct people often don’t know what “softer” sounds like without being dishonest. Provide concrete alternatives. Instead of “This is wrong,” try “I have a concern about this approach — can I walk through it?” Instead of “You clearly didn’t think about X,” try “How did you think about X? I want to understand the trade-off you made.” Instead of “This won’t scale,” try “I’ve seen this pattern struggle at scale — here’s what happened. How are you thinking about that risk?” Each alternative contains the same information. The packaging changes. The information loss drops to zero.

Praise the content, then ask about the delivery. “Your observation about the data model was the most important thing said in that meeting. What do you think would have happened if you’d opened with a question instead of a statement?” Let them reason through it. They’ll get to the same place — that the room would have stayed open, that the same information would have been delivered without the shutdown — but they’ll own the conclusion.

Here’s the good news: most dial-at-10 engineers are actually the easier coaching challenge. Because they respect directness, they can engage with direct questions about their own behaviour. You don’t need to sugar-coat it — you just need to ask instead of tell. Lead them through the impact with questions, let them connect the dots, and they’ll adjust. For most, this works within weeks. They genuinely didn’t know how their delivery was landing, and once they reason through the cause and effect themselves, the insight sticks.

But some dial-at-10 engineers aren’t coachable on this dimension. Their directness isn’t a calibration gap — it’s entangled with ego, insecurity, or interpersonal patterns that run deeper than communication style. An engineering manager isn’t a psychologist, and treating a personality issue as a coaching opportunity wastes everyone’s time. The pragmatic position: it’s easier to teach technical skills than to be someone’s therapist for their personal issues. This isn’t an argument against hiring direct people — the whole post argues that too little directness is just as dangerous. It’s an argument for distinguishing at the hiring stage between “direct and calibratable” — hire them, coach them, you’ll get there in weeks — and “direct and destructive,” where the pattern is deeper than communication skills and an EM isn’t the right intervention. The screening question isn’t “are they direct?” It’s “can they modulate?”

Coaching the Dial-at-2 Engineer

This is the quieter coaching challenge, and in many ways the more damaging one, because the problem is invisible. It’s what the dial-at-2 engineer didn’t say. The meeting that looked productive but wasn’t. The retrospective where everyone nodded and nothing changed. The design review where a flaw went unchallenged because raising it felt impolite.

Here’s what doesn’t work. “Speak up more” is too vague — it doesn’t address the emotional or cultural barrier. “Just say what you think” ignores the genuine reasons they don’t. And putting them on the spot in meetings creates the exact dynamic they’re trying to avoid.

Here’s what does work.

Start in writing. For engineers who struggle with verbal directness, code reviews are the training ground. Written feedback is lower-stakes than spoken feedback — there’s time to compose, revise, and calibrate. PR comments are particularly useful because they’re expected to contain technical critique — the social permission is built into the format. A dial-at-2 engineer who would never say “I think this has a race condition” in a meeting will often write it in a PR comment, because the review process explicitly asks for exactly that. Use this as the entry point. Once they experience that direct technical feedback in writing didn’t damage the relationship, they start to believe it’s possible in other contexts too.

Give them the first move. In meetings, specifically invite their opinion before the seniors weigh in: “I want to hear from you before we go around.” This removes the barrier of having to interrupt or contradict someone more senior. It also signals that their directness is wanted, not just tolerated.

Model it. The engineering leader who says “I was wrong about X — here’s what I missed” gives everyone in the room permission to be wrong and say so. The leader who says “Somchai, I think your design has a flaw in the caching layer — let’s talk about it” shows that direct feedback can be delivered with respect, that it’s not a weapon but a tool. This is the culture-through-repetition mechanism I described in The Taste Gap — the leader’s behaviour is the norm everyone else calibrates against.

The 1:1 replay method. This is the technique that transforms quiet engineers into contributors. I learned it secondhand — from the staff of another manager who had a genuine talent for turning dial-at-2 engineers into people who could hold their own in any room. I asked one of his engineers directly: “How did he get you to speak up?”

The answer was simple and relentless. The manager came to almost every 1:1 with specific examples of moments where the engineer could have spoken up in a meeting and didn’t. Not “you should speak up more” — that’s too vague, too easy to nod at and forget. Specific: “In Tuesday’s design review, when the caching approach was discussed, you had something to say. I could see it. Why didn’t you say it? What would it have taken?”

And then he did it again the next week. And the week after. And the week after that.

The behaviour change didn’t happen from a single conversation. It happened because the manager brought it up every week, in every 1:1, with specific recent examples. The engineer couldn’t treat it as a one-off piece of feedback. It became a running thread — something the manager clearly tracked, cared about, and returned to. The message was unmistakable: I notice when you hold back, and I want you to stop.

This is the same repetition mechanism from Why Your Engineers Are Still Waiting — show the alternative, repeatedly, until the alternative becomes the reflex. A single piece of feedback is advice. The same feedback with fresh evidence in ten consecutive 1:1s is a priority. The engineer starts to understand that speaking up isn’t a personality preference — it’s an expected part of their role.

Break the complaint loop. Here’s a pattern you’ll recognise if you manage people. Many dial-at-2 engineers aren’t actually dial-at-2 everywhere — they’re dial-at-2 in group settings and dial-at-7 in 1:1s with their manager. The problem isn’t the skill. It’s the venue. The tell: your 1:1s become a running list of complaints about other engineers. “I wish X would stop doing Y.” “Z’s approach is going to cause problems.” They’re being direct — just to you, not to the person who needs to hear it.

The manager who accepts this dynamic becomes an information bottleneck, shuttling feedback between people who should be talking directly. The manager who redirects — “Have you told them that? What would it take for you to say that directly?” — builds the muscle. Every time they bring a complaint to you that should go to a peer, redirect. Don’t relay the message for them. That trains the wrong muscle. The goal is to make the indirect channel uncomfortable enough that going direct feels easier.

Meeting Structures That Create Safety for Directness

There’s no such thing as best practice here — only adequate practice given current context. And also bad practice, which is doing nothing and hoping directness emerges on its own. The right structure depends on the team: a newly formed team with low trust might need anonymous pre-reads; a team of senior engineers who’ve worked together for three years might just need an EM who asks pointed questions. Here are five structures worth having in your toolkit. Pick based on context.

The “disagree first” design review. Before presenting their solution, the presenter lists the alternatives they considered and rejected — and why. This frames the review as a conversation about trade-offs, not a defence of a chosen approach. It makes disagreement safer because the presenter has already demonstrated that alternatives exist. This connects to the I Don’t Care What You Build approach — focus design reviews on the problem being solved, not the solution being defended. The directness skill is what makes those reviews productive. A room full of people who are too polite or too brutal is a room that produces worse decisions.

The anonymous pre-read. Before a meeting, circulate the design or proposal and collect written feedback anonymously. Review it as a group. The anonymity removes the social cost of disagreement, and the group discussion normalises it. Over time, people become comfortable attaching their name because they’ve seen that direct feedback is received well.

The designated dissenter. In each design review, one engineer is assigned to argue against the proposal. This removes the social stigma from disagreement — the person disagreeing is doing their job, not being “difficult.” Red teams in security work on this principle. De Bono’s “Six Thinking Hats” formalises it. It’s artificial, and it works precisely because it’s artificial.

The “I heard” check. At the end of a feedback conversation, the recipient summarises what they heard: “What I’m hearing is that the caching layer has a risk because X. Is that right?” This forces specificity — the too-polite feedback-giver can’t get away with vagueness when the recipient is reflecting it back, and the too-blunt feedback-giver can see how their message actually landed.

Separate praise and criticism channels — with the PR exception. Public praise, private criticism. This single rule does enormous work: it makes praise visible (reinforcing good behaviour) and makes criticism safe (protecting the recipient’s dignity). But engineering has a built-in exception that needs acknowledging: code reviews are public criticism by default. When someone leaves a comment on a PR saying “this won’t scale,” it’s visible to the team. The resolution: critique the code in public (PRs), critique the behaviour in private (1:1s). “This caching strategy has a race condition” belongs in a PR comment — others learn from it. “You’ve submitted three PRs this month without tests — we need to talk about that pattern” belongs in a 1:1 — it’s about a pattern of behaviour, and that’s personal.

When the Dial Must Be at Maximum

There are moments when context, comfort, and cultural calibration all take a back seat. When the dial must be at 10, regardless:

Production safety issues. If the code is going to break in production, you say so clearly and immediately. No hedging. Not “maybe we should consider whether this could potentially cause a problem.” The users don’t care about your team dynamics. “This will cause data loss. We need to stop.”

Ethical concerns. If something looks wrong — data handling, user privacy, regulatory compliance — you speak up directly. This is not negotiable across any cultural context.

Repeated patterns that aren’t changing. If you’ve given gentle feedback twice and nothing’s changed, the third time needs to be unambiguous. Continued softness at this point isn’t kindness — it’s negligence. The CEO “What did we learn?” story I described in The Art of Failing only works because the CEO’s directness was calibrated — he named the failure and redirected to learning. But he named it. He didn’t pretend three consecutive quarters of missed targets were “a bit of a scope issue.”

During incident response. When production is down, communication must be crisp, direct, and unambiguous. This is not the time for feelings management. The war room on level 7 next to the NOC area is not a place for hedging.

The ability to be direct about what went wrong after an incident depends entirely on the safety established before the incident. Teams that can’t be direct in reviews can’t be honest in post-mortems. The feedback culture and the incident culture are the same culture — you don’t get one without the other.

What “Direct and Respectful” Actually Sounds Like

Let’s return to those opening scenes and replay them with calibrated directness.

The brutal review, rewritten. The senior engineer waits for the presenter to finish. Then: “Thanks for walking us through this. I have a concern about the data model — specifically the relationship between orders and payments. Can I walk through what I think might happen at scale?” The same information is delivered. The same issue is raised. But the room stays open. The two junior engineers with questions ask them. The design improves more than it would have in the original version — because more people contributed. The cost of the senior engineer’s six extra seconds of framing: zero. The value: incalculable.

The polite drift, rewritten. The EM says in the retro: “I want to name something specific. We had integration tests broken for five days, and it blocked three engineers. That’s not a character judgment — it happens. But I want us to talk about what our norm should be when tests are broken. What’s a reasonable window to fix them?” The issue is named. The person isn’t blamed. The team sets a norm. The behaviour changes. This is what I was describing in The Solutioneering Trap — when I had to tell Somchai that his impressive Next.js prototype was solving the wrong problem, the approach wasn’t “this is bad.” It was: “Could we achieve this without rewriting all of our server-side rendering code?” A question that let him discover the answer himself. Dial-at-5: honest, but constructed to preserve agency and dignity.

The Slack thread, rewritten. The senior engineer writes their PR comment, then re-reads it before posting. They add: “Overall this is a solid approach — the test coverage is great. One thing I’d rethink: the direct DB access here will create coupling to the Booking team’s schema. Have you considered the repository pattern? Happy to pair on it if useful.” Same technical information. Same directness. But the medium is accounted for — the written word gets the extra warmth that a face-to-face conversation would have provided for free.

Neither scene required being mean. None required being vague. All three required the skill of calibrated directness — the ability to deliver the truth with enough care that it can be heard, enough clarity that it can be acted on, and enough awareness of the medium and context to set the dial where it needs to be.

As the surgeon and writer Atul Gawande observed, “Better is possible. It does not take genius. It takes diligence. It takes moral clarity. It takes ingenuity. And above all, it takes a willingness to try.” He was talking about medicine, but the principle is identical in engineering leadership. Calibrated directness isn’t a talent. It’s a practice. You get better at it by doing it, by coaching it, by watching where the dial should have been and adjusting next time.

The Bottom Line

Every engineering team sits somewhere on the directness spectrum. Most are too far in one direction — either brutal enough that people stop contributing, or polite enough that problems stop surfacing. Both cost you the same thing: information. And information is the raw material of every good decision your team will ever make.

The fix isn’t finding the middle. The fix is building range. Teaching every engineer on your team — including yourself — to read the context, set the dial, and deliver the truth in a form the room can actually use. It’s harder than being blunt all the time. It’s harder than being polite all the time. It requires paying attention to the person you’re talking to, the stakes of the conversation, the medium you’re using, and the cultural context you’re operating in. But it’s a skill, not a gift, and skills can be taught.

If you’re the leader: model it. Be wrong in public. Be direct with care. Bring specific examples to every 1:1. Build culture through repetition, not through policy documents. Make the norms explicit, especially if your team looks like a United Nations assembly and everyone’s default dial setting comes from a different continent.

If you’re the dial-at-10: your feedback is valuable. Your delivery is expensive. Learn to keep the signal and lose the shrapnel.

If you’re the dial-at-2: your restraint isn’t kindness. It’s a decision to let problems persist because naming them is uncomfortable. The team deserves your honest assessment, even — especially — when it’s hard to say out loud.

Now, if you’ll excuse me, I need to go re-read a Slack message I sent twenty minutes ago. It was technically accurate, but I’m fairly sure it landed about three notches higher than I intended. The medium, as always, stripped the smile I was wearing when I wrote it.