Every engineering team I've worked on has carried some amount of feedback debt. Not the dramatic kind — no shouting, no politics. The quiet kind. The senior engineer everyone routes around. The design review where four people privately think the approach is wrong and nobody says so until the rewrite. The performance review that surprises someone who has been doing the same thing, unremarked, for eleven months.

Feedback debt compounds exactly like technical debt: cheap to service early, brutal to pay off late. And like technical debt, you don't fix it by declaring that you value paying it down. You fix it with a practice.

A book club is a surprisingly good practice for this, and Radical Candor is a surprisingly good book for it. Not because the book is profound — the core idea fits on a napkin — but because the book gives a team a shared vocabulary and a socially safe excuse to talk about how they actually treat each other. "I think I was being ruinously empathetic in that review" is a sentence a person can say out loud. "I was too much of a coward to tell you your design was bad" is not.

Radical Candor publishes a discussion guide for exactly this, chapter by chapter. What follows is how I'd run it with an engineering team — the format, which questions actually crack a room open, what happens in the awkward middle weeks, and the failure modes to watch for.

The Napkin Version

So nobody has to wait for week three: the whole framework is two axes. 

                  Challenge Directly
                            ▲
      Obnoxious            │            RADICAL
      Aggression           │            CANDOR
                           │
    ───────────────────────┼───────────────────────▶
                           │              Care Personally
      Manipulative         │            Ruinous
      Insincerity          │            Empathy
                           │

Care Personally on one axis, Challenge Directly on the other. Do both and you get Radical Candor. Care without challenging and you get Ruinous Empathy — the nice, warm, deeply unhelpful place where most engineering teams actually live. Challenge without caring and you get Obnoxious Aggression, which is what people think Radical Candor means when they've only heard the phrase. Do neither and you get Manipulative Insincerity, which is where politics comes from.

The single most useful thing the book does for a technical team is name Ruinous Empathy. Engineers are trained to be merciless with code and gentle with people, which sounds correct and quietly produces teams where nobody knows where they stand. Almost every feedback problem I've seen on a strong team is a Ruinous Empathy problem. Almost none of them are Obnoxious Aggression problems. Bias your discussion accordingly.

The Format

Nine sessions, one per chapter, 45 minutes each, every other week. Ten weeks of reading, eighteen weeks of calendar. That's long enough for the ideas to hit real situations at work and come back into the room, and it survives the on-call rotation.

  • Cap it at six to eight people. Above that, a book club becomes a lecture with an audience. Two groups of six beats one group of twelve.
  • Don't mix a manager with their own reports if you can avoid it. This is the one structural decision that most changes what people are willing to say. Cross-team groups — an EM from platform, a staff engineer from product, a TL from infra — get to honesty in about a third of the time. If your team is too small to avoid it, go anyway, but read the next point twice.
  • Whoever holds the most power in the room answers first, and answers badly. Every session, the facilitator opens with their own story, and it has to be a real one where they came off poorly. This isn't a nice touch — it's the entire mechanism. A room calibrates its honesty to the most senior person's worst admission. If the manager tells a sanitised story, everyone else will too, and you'll spend nine sessions on book report.
  • Three chapter questions per session, not fifteen. Pick three and let them run long. A guide with forty-five questions is a menu, not a schedule.
  • No notes, no recording, no AI notetaker, no summary in Slack. Say this out loud at the start of session one. If people think their stories about their worst boss are being transcribed, you're getting the sanitised version.
  • End every session with one commitment. Each person names one specific thing they'll do before the next meeting, with a name attached: "I'll ask Priya for feedback on how I ran the migration review." Discussion without an action item is just a podcast you had to prepare for.

The Questions, Session by Session

These are adapted from the official guide, with the ones I've found land hardest with engineers pulled to the front. The full list is on radicalcandor.com — grab it, it's free.

Session 0 — Introduction. Before anyone has read a chapter. Three questions, and they set the tone for everything after:

  • Describe a time you didn't give someone direct feedback and wish you had. What did it cost?
  • Who's the best leader you've worked for, and what specifically did they do?
  • Tell us about the worst boss you've had. What made them so bad — and which of those things could you plausibly do yourself on a bad quarter?

That last clause is my addition and it's the important one. "Worst boss" stories are fun and useless on their own; the room bonds over a villain and nobody changes. Forcing everyone to find the version of that behaviour they're capable of turns a war story into a mirror.

Session 1 — Build Radically Candid Relationships. What are a manager's actual responsibilities, per the book? What separates Radical Candor from brutal honesty? How do you show you Care Personally at work? And the one that produces the most useful silence: Is Challenging Directly a strength or a weakness for you? Nearly everyone claims it as a strength. Ask for the last three examples and watch the claim get more honest.

Session 2 — Get, Give, and Encourage Guidance. Describe feedback you received that you actually learned from. Now describe feedback you couldn't learn from because of how it was delivered — what specifically got in the way? Have you ever been so nice it worked against you? For engineering teams I add one: what's the harshest thing you've written in a code review comment, and would you have said it out loud in a room? Async text is where most engineering Obnoxious Aggression actually lives.

Session 3 — Understand What Motivates Each Person. This is the rock star / superstar chapter, and it's the one with the most direct payoff for a technical team. Superstars are on a steep growth trajectory and want the next thing; rock stars are on a gradual one and are the reason your system stays up. Both are excellent. Only one of them is legible to most promotion processes.

  • Have you ever undervalued someone's contribution because they weren't gunning for a promotion?
  • Have you ever clipped the wings of someone on a steep trajectory? What happened?
  • Are you more at risk of being an absentee manager or a micromanager, and what pushes you into that mode?
  • Which trajectory are you on right now — and is that a choice or a default?

Expect this session to run long. It's usually where someone realises they've been quietly penalising the most reliable person on the team for not wanting a title.

Session 4 — Drive Results Collaboratively. The Get Stuff Done wheel: listen, clarify, debate, decide, persuade, execute, learn. Which steps do you skip? (Most engineering orgs skip persuade — they debate, decide, and then act baffled that nobody's bought in.) Are you a quiet listener or a loud one? Do you want a culture of debate, and if so, what would you have to stop doing to get one?

Session 5 — Relationships. What keeps you centred? Describe a time you couldn't bring your best self to work. How do you build trust with your reports, and how do you know it's working? This is the softest session and the one most likely to be skipped for a sprint deadline. Don't skip it — it's the session where people find out things about each other that make the rest of the feedback land differently.

Session 6 — Guidance. The practical one. Have you actually solicited feedback from your reports? What's your go-to question? (The book's is "Is there anything I could do or stop doing that would make it easier to work with me?" — the value is in having a question you always ask, not in which one.) How have you rewarded criticism when you got it? And: what's one thing you could do tomorrow to offer someone Radical Candor?

The rewarding-criticism question is the load-bearing one. Soliciting feedback is easy. What people are actually watching is what happened to the last person who gave you some.

Session 7 — Team. Career conversations, growth trajectories, hiring and firing. Can you start running real career conversations with your reports — the past/dreams/plan version the book lays out, not the "where do you see yourself in five years" version? Do you know your team's balance of rock stars and superstars? Which of the book's hiring and firing suggestions actually apply at your company's size?

Session 8 — Results. How do you run 1:1s, and how does that compare to the book? How do you nurture new ideas? Would a dedicated Big Debate or Big Decision meeting help your team? And the question every engineering org needs on a recurring calendar invite: how do you keep meeting-creep from eating the time the team needs to actually execute?

Session 9 — Performance Reviews (bonus chapter). What's the formal review process here, and is it working? Are you having development conversations with everyone, or only with the people who ask? Time this one four to six weeks before your actual review cycle so it's a rehearsal rather than a post-mortem.

The Awkward Middle

Sessions one and two are enjoyable. Everyone likes the framework, everyone has a bad-boss story, the quadrant diagram gets screenshotted into Slack.

Then somewhere around session three or four, someone uses the vocabulary for real. Usually it goes: "Can I be radically candid for a second?" followed by something that is, in fact, just criticism with a badge on. The room tightens. Someone gets defensive. The facilitator wonders if this whole thing was a mistake.

This is the point of the exercise, and it is worth being ready for it.

  • "Can I be radically candid?" is a red flag, not a green light. The framework describes how feedback lands, not a mode you announce. If you have to invoke the brand to say the thing, the caring half probably isn't there yet. Kim Scott has written about this herself — the phrase gets weaponised as a licence for exactly the Obnoxious Aggression it was coined to prevent.
  • Radical Candor is measured at the listener, not the speaker. You don't get to decide you were being radically candid. The person who received it does. This one line resolves about half of the arguments that come up in the middle sessions.
  • Do it in the right order. Solicit feedback before you give it; give praise more than criticism; and make criticism humble, helpful, immediate, in person, and about the work rather than the person. A team that starts by giving candour has skipped straight to the part that requires trust it hasn't built.
  • Someone will cry, or nearly. Statistically, over nine sessions of talking about the worst bosses people have had, this happens. Don't manage it away. Let it be a normal thing that happened, take the break, keep going.

If you get through the middle, sessions six through nine are where the value is — that's when the conversation stops being about the book and starts being about your actual 1:1s, your actual review process, your actual promotion committee.

Translating It for Engineers

The book's examples are mostly from Google and Apple management contexts. A few translations make it land harder with a technical team:

  • Code review is your highest-bandwidth feedback channel, and it's already running. Every engineer on your team gives and receives written, specific, work-focused feedback several times a week. Most teams have quietly agreed to be Ruinously Empathetic in review comments — LGTM with a nit, when the real note is "this abstraction is going to hurt us in six months." Fixing the culture in code review moves more than anything you'll do in a 1:1.
  • Incident reviews are a candour test with the safety already installed. Blameless post-mortems are a well-established norm, which makes them the safest place to practise. If your incident reviews can't surface "we knew this was fragile and deprioritised it twice," your 1:1s definitely can't.
  • The superstar/rock star split maps directly onto your ladder problem. The engineer who wants Staff and the engineer who wants to keep shipping reliable systems for another five years both deserve a real career conversation. Only one of them is going to get one by default, and it isn't the one holding your production system together.
  • "Debate" is the step engineers do well and "persuade" is the step they skip. An RFC with nine comments and a decision is not the same as a team that's bought in. The GSD wheel makes this failure legible.

Did It Work?

Book clubs are notoriously hard to justify, so decide up front what you'd accept as evidence. Not a survey score. Something you can observe:

  • Does anyone on the team routinely ask you for critical feedback, unprompted? Before: probably nobody. That number moving from zero to two is a real result.
  • Time from noticing a problem to saying it. If the team's honest answer to "how long did you sit on that?" drops from weeks to days, the debt is being serviced.
  • Surprise rate at review time. Nobody should learn something new about their performance in a written review. Count the exceptions; aim for zero.
  • Do design and code review comments get more specific and less hedged? You can literally read this one in your pull requests.

And the honest caveat: a book club can't fix an environment where candour is genuinely punished. If people who speak up here get quietly sidelined, nine sessions of discussion questions will teach your team a very precise vocabulary for describing a situation they still can't change — and that's worse than not running it. The prerequisite isn't enthusiasm. It's that the most senior person in the room can be told they're wrong, in front of others, and visibly reward it.

Start there. Everything else in the book is downstream of it.