Radical Candor by Kim Scott
This article is a reference for the key frameworks in Radical Candor, with commentary on how they apply to tech and product teams.
This is a book about how to give effective feedback, and it's one of the best selling books globally on the topic with good reason. The book includes many practical stories to learn from, as well as multiple frameworks and tools you can begin to use immediately.
The first thing to get out of the way is that "radical" does not mean "be a jerk, have confidence to spit out anything in an obnoxious way!". In the foreword to the latest edition, Kim clarifies "radical" simply means "a new type of candor."
Here's an exact quote from the book:
Since the term “Radical Candor” has entered the lexicon, I’m stuck with the task of rebranding the word “radical.” [...] So if you are rolling out Radical Candor, and you think there might be some confusion about what it means, here’s a way to help ensure that everyone understands the idea is not to act like a jerk: use this new version of the Radical Candor framework (see below).
You can cut it right out of this book [...], make photocopies, and put them on your refrigerator, over your desk, or anywhere for a reminder. You can also share copies with your colleagues.
The Radical Candor 2x2 framework
The 2x2 framework helps us understand what it means to be radically candid and diagnose what went wrong when feedback misses the mark. Feedback varies along two dimensions: how directly it challenges a problem, and whether the person giving it shows they care personally about the person receiving it.
Special note: "Care personally" is always in the context of the person you are talking to. Do you care about them? Do not misunderstand this to mean "care personally about the project" or some non-human entity like caring about the company or KPI.
In the book, Kim makes a reference to telling someone they have spinach in their teeth as a way to understand what it looks like. You don't have to be mean, shy, evasive, just tell them quickly in a way that shows you have their interests at heart.
-
Ruinous Empathy: When feedback is so focused on not hurting feelings or causing distress that you will not tell someone something they need to know. This is probably the most common antipattern people fall into. This is that "Everything is good" comment on peer feedback forms. This is when people are surprised to be fired after their bosses tell them everything is great.
-
Obnoxious Aggression: A direct challenge that shows someone you do not care about them. These are the annoying jerks. Sometimes they have the best of intentions which are poorly worded, and other times they might really be out trying to hurt you. Not always easy to tell, and often hard to care about the feedback delivered regardless of the giver's motivations.
-
Manipulative Insincerity: This is both non-specific and insincere praise, as well as unclear and unkind criticism. For example, if you say "Hey, good job!" but you didn't really mean it this is not really an indication of caring personally or a direct challenge. Similarly, vague complaints about someone like "their work is not very good" is avoiding directly explaining the problem and does not show evidence of care. The "feedback sandwich" lives here, which is why nobody likes those.
-
Radical Candor / Compassionate Candor: Challenge directly and care personally. This is our gold standard for feedback which is effective.
To make these clearer, I've added several case-studies for situations that warrant feedback, along with examples of feedback in each quadrant. Click through to read the examples.
Case Study
Situation: Designer presents 3 design options for new dashboard.
Behavior: Founder says 'These are fine, but here's what I sketched out' and overrides the designer's work with their own Figma mockup they made at 2am.
Impact: Designer stops proposing ideas. Design quality drops. Designer leaves after 8 months saying 'I'm not learning anything here.'
Personally
Personally
Directly
Challenge
Philosophy
Radical Candor is not a step-by-step process like "building a feedback sandwich" is. It is a way to think about how to navigate this complex and chaotic space of giving people feedback that resonates with them, instead of having feedback ignored or upsetting someone who then dismisses it. It is also a mindset that helps you understand why you have to be brave enough to really give the feedback instead of avoid it.
Furthermore, Radical Candor is not a leveling system. It's a compass to tell you where a feedback statement itself is (not a person). Every person will drift around all 4 quadrants as they go through their day, the goal of using this framework is to be mindful of feedback and have the mental framework to keep it in the radical candor quadrant. Kim directly warns readers not to think of this as a framework for measuring people. It is possible to tell someone they can improve their feedback skills, but that is not the same as ranking someone as "obnoxious" on the 2x2. In the book and this article we touch on why.
To make Radical Candor work, there are some foundational pillars that need to be in place first.
Bring whole self to work
In this section, Kim uses "Boss" to mean many things: bosses, managers, leaders, and anyone with a sort of position of power over others in their organisation. Sometimes it is not so clear who is a "boss", but she means all these types of people. Some organisations call this "being a leader".
- Being a boss is exhausting. If you are not taking care of yourself enough you will not have enough endurance to give feedback correctly, which will make everything worse. Make sure you take care of yourself.
- Bosses guide people, they don’t do the work of other people (micromanagement). This is a hard lesson for many new bosses and it ends up creating a lot of conflicts which could have been easily avoided and never needed to happen in the first place.
- Relationships are foundational to good feedback. You need to build strong relationships with people on a personal level so there is legitimacy behind showing you care personally about the person you are giving feedback to. It also makes things easier when you have a base rapport.
- “Keeping things professional” is a trap. There's a strange myth out there that managers need to be cold and aloof, and keep their distance from "the workers". All this does is minimize the delivery of your own feedback. It's not just Kim saying this either. This point is also echoed strongly throughout the book "The 5 Dysfunctions of a Team" which is another well known management book every manager should read at least once.
Feedback, not weapons
Giving feedback responsibly requires guardrails. Without them, even well-intentioned feedback can cause harm, and poorly intentioned feedback can weaponize the framework itself. The following principles help ensure that feedback stays constructive.
Radical Candor provides some important guidance on how to avoid abuse or misuse of feedback, which will always backfire:
- Cruel feedback is a weapon, not a tool, and definitely not radical candor. Giving cruel feedback is to take a weapon out and use it on the culture and development of your own organization.
- Do not “personalize” feedback, because that turns feedback into an attack. Personalizing feedback is when we turn a problem into an attribute of a person. For example, "your presentation was bad" is different from "you are a bad presenter". Being a bad presenter is a personal attribute, while the presentation being bad is a statement of fact. Personalizing can create unfortunate labels for people ("Jack is a bad presenter") which limits your interest in giving feedback and limits their opportunities to improve.
- Don’t label people. Especially outside of feedback conversations, and especially not in private 1:1s with other leaders. It may be tempting to "vent", but you spread labels around which limit perceptions of what someone is capable of. Calling someone "lazy", "not smart", or the all too common "not good" also create a problem for you the feedback giver with operationalizing feedback. Once you type-cast someone it becomes much harder for you to care personally about the individual, which will alienate them and make it hard for the message to connect, as your feedback dips into the Manipulative Insincerity region of the 2x2 framework.
- Articulate the why. This one seems the most obvious and easiest in hind-sight but is all too often the missing component that holds back feedback quality. When we do not explain the why, we are shying away from the specific details that would have made feedback meaningful. Explain why something is a problem. Explain it in the context of it being a problem for the work, and for the person.
Articulate why: Situation-Behaviour-Impact ("SBI")
SBI allows you to stay authentic and structured in 3 simple steps:
- Describe the situation that happened, don't include judgemental statements, just statements of fact.
- Describe the behaviour that the person you want to give feedback to displayed. Again, just factual, not judgemental.
- Explain what the impact of the behaviour in that situation was. Make it direct, and make sure you show you care about the person you are giving it to.
You don't need to make this feedback either aggressive or cover it up with flowers. It's just a direct recap of what happened.
SBI was developed by the Center for Creative Leadership and is a solid framework, however, it is not the only way to structure feedback and the mention of SBI does not mean your feedback needs to rigidly fit the template. It is a guide to help you think of one way to frame feedback that challenges directly and cares personally. In fact, it is better to combine other techniques (such as understanding motivations of people) and layer them together for even more effective feedback.
In practice
Imagine your colleague is meeting one of your software vendors. Your colleague regularly makes fun of them and actively yells at them with the deeply misguided idea that it will "knock them off balance" and give an advantage when it comes to price negotiation. The vendor is so upset that they decide after the encounter not to work with your company due to lack of respect.
Situation: You would explain why the vendor was important to the company. What you need them for, what work gets done because of them, and what that helps the business do. Even better if you can connect that software vendor to their personal benefit such as building their reputation as someone who can manage vendors with respect.
Behaviour: Next you would state they were regularly insulting the vendor. Make it specific where possible. Explain the vendor's earlier reactions that signaled they were not pleased.
Impact: Lastly, you would connect the two and explain that because the vendor was so upset and decided to not work together, multiple parts of the business will be disrupted and your colleague's reputation as someone who can be trusted with work with vendors has taken a serious hit.
Understanding motivation
- Clear motivation helps make the work meaningful. When you attach direct feedback to something that motivates the person you are giving it to, it becomes more meaningful.
- People find their own motivations, you do not “install” yours into them. Some leaders tell themselves a myth that the motivations of the leader somehow get put into everyone else in their circle of influence. This is not true. Everyone has different things they care about, and trying to push something onto another person when they do not actually care about, it will just block your feedback. You need to figure out what each individual cares about and speak to that to motivate them. You are not trying to give the feedback to yourself, so don't speak to your own motivations.
- You want a partnership so you can maximize for caring personally about someone. This can be a challenge for leaders who do not see their reportees as partners but they must overcome this in order to improve the effectiveness of their feedback.
Below is an interactive tool which helps you practice matching motivations with feedback, give it a try!
Motivation Mapper
Radical Candor means caring about what THEY care about, not what YOU care about. Different people are motivated by different things.
Scenario: New Code Review Process
Your team needs to adopt a new code review process. It will slow things down initially but improve quality long-term. Each team member cares about different things. Craft your message to resonate with what motivates THEM.
I've been asked how I figure out what motivates people on my teams. While observing is useful, getting notes from previous managers, surveys, feedback, all these methods exist. But I found you can simply ask people in a 1:1 setting and they'll tell you, which ends up being very helpful for demonstrating you care personally about them and building up rapport.
Collaborate with Radical Candor
Figuring out how to "get stuff done" in tech companies is extremely common, especially when it comes to figuring out who decides important topics. Often teams fall into one of two extreme traps: one benevolent dictator makes the decision and calls the shots, or the decisions get discussed in endless circles until the heat death of the universe. A variant of this that tries to blend both extremes is when "the boss" will let debates run until a time window expires and then make the real decision at the end.
The "boss decides after team debates" is common and a step up over the two bad extremes. There's a sense among leaders that this is a middle-ground that lets people feel heard. However, it leaves you with many problems to constantly clean up after (including people not feeling heard):
The boss's initial instincts and existing mental models tend to carry disproportionate weight in their own minds, making it difficult for novel ideas or contrary perspectives to break through. The power dynamics mean the boss lacks peers who can effectively challenge their biases, and the team learns to optimize for what the boss wants to hear rather than debating the underlying facts and trade-offs. This shifts the dynamic from collaborative problem-solving to "convince the boss," or even "whatever the boss says" where the goal of the way the team works is something other than finding the best answer together.
In the short term, each decision cycle wastes team time and energy. The team invests effort in debate, but most of that cognitive work doesn't materially influence the outcome. You're paying multi-brain costs for one-brain decisions. The dynamic shifts to "how do we present this to convince the boss?", changing how people prepare and engage. Without clear signals about when their input genuinely matters versus when the boss has already decided, the team experiences confusion about the purpose of the collaborative process.
Over time, the organizational costs compound from what the process has trained the team to do. People with strong judgment will want to leave and seek out teams where their thinking matters more, while those who remain have fewer opportunities to develop real decision-making skills. The boss becomes an ever-expanding decision bottleneck (not just for critical decisions, but increasingly for routine ones too) as the team learns to defer to the boss rather than decide. If the boss has excellent decision making skills it only masks a deeper dysfunction: nobody else knows how to make decisions and there is minimal/no growth towards more people making quality decisions together. The organization is slowly losing its capacity to scale, learn, and function independently. It ends up building a dependency on the boss exactly where it needs autonomy to move fast.
Telling people what to do does not work. The book contains a concrete example of how it didn't work like that at Google, and another story about how it didn't work like that for Steve Jobs either. Stories like VPs pushing hard to have "just a few people work on my idea" and the teams successfully saying no.
Get Stuff Done
Radical Candor gives us a method Kim calls "Get Stuff Done" (GSD) which escapes the dictator method, death by committee method, and the broken "boss decides" paradigm.
The collaboration failures that make "boss decides" look attractive are messy, unnamed human problems. We don't listen, ideas stay half-formed, debates go sideways, and buy-in never happens. These individual failures blur into one mess. GSD unpicks them and structures what Kim Scott saw work first-hand at Apple and Google into a seven-step intentional process to guide thinking.
::: info A Process != Heavy Process In product/tech, teams have learnt (rightfully so) to be scared of anything that looks like a process. I think anything more than 2 or 3 steps maximum freaks people out because often these "steps" take hours or days. I am certain someone (incorrectly) will read this 7-step decision making process and think they need 7 meetings booked in the calendar. You don't. This is a map to the modes/phases in the decisions cycle.
These should be seen as a conversation guide to allow multiple people to facilitate the flow of the conversation and make sure the team is not getting stuck or skipping stages. Skipping stages will only waste time at the end of your process.
When it feels like the team is stuck on a stage, we should shake up the format the conversation takes place in. Here are some thing to try when facilitating the decision:
-
Ensure there is an obligation to dissent in the debate stage. If everyone agrees right away this should be seen as a red flag that the team is stuck in passive agreement and the decisions are a form of theater.
-
Read the room. If people are tired, burnt out, or just not in the head space for it, they can't engage properly. Remember the section from earlier: being a boss is hard. We have to bring our whole selves to the room, and we have to care personally about our team that they can bring their whole selves to the decision making table. In these moments, call a time-out instead of encouraging people to use a fraction of their brains and energy to come to a bad decision.
-
Change meeting types. Not all meeting structures work for all stages. Kim outlines multiple examples (described later) such as "1:1s", "big debate", and "big decision" to name a few.
The key is to work the environment and factors related to the stage in the cycle, not to demand or pick a conclusion. These are not simply stages, but skills for the team to collectively deepen and practice over time.
The seven steps are: Listen, Clarify, Debate, Decide, Persuade, Execute, and Learn.
1. Listen
Listening is where ideas enter the system. Your team members (including you) speak up with ideas about what goals to pursue, what problems need solving, and things that are broken that you might not even know about.
Listening isn't just the boss listening to the team, or the team listening to the boss, it's about a culture where team members listen to each other. When people genuinely listen to one another, they start fixing things the boss never even knew were broken.
Kim provides us with two styles of listening:
-
Quiet listening: Being silent to give people room to talk. Using silence and neutral body language to hear things people might not say if you were reacting. One key challenge to manage: people may waste time trying to guess what you think, and some feel uncomfortable with silence.
-
Loud listening: Putting a strong point of view on the table to get a reaction. Stating your position clearly and insisting people challenge you back. The key challenge to manage: requires building confidence in people who may be intimidated, and doesn't work unless people feel safe pushing back.
You'll know it works when you surface great ideas from across the team, not just funnel information to the boss for decisions.
2. Clarify
Ideas start fragile, half-formed, and easily squashed. They might come out as vague what-if statements or generic complaints. Clarify is about helping people sharpen their thinking and elevating ideas to something we can bring into a debate.
Squashing ideas early ("don't bring me problems without solutions") ensures most ideas never reach their potential. Instead, create a space where people can enhance their ideas with you.
Clarifying works both ways:
-
Help others clarify: Don't throw the burden of understanding onto the speaker. You're a thought partner trying to bring ideas out. It doesn't have to be entirely safe, sometimes poking holes in ideas actually helps clarify them rather than squash them. Asking "what about X?" can sharpen the thinking. The key is that you demonstrate you want the idea to come out strong and this is obvious to your thought partner.
-
Clarify your own thinking: Don't throw the burden onto the listener. You're talking to someone you care personally about, not vomiting words at them until they yield. Avoid common traps like including lots of unrelated information. Take the time to make your own thinking clear.
Mark Twain once wrote: "Sorry for such a long letter, I did not have time to write a short one." Clarifying can often feel like writing the short letter.
Clarifying is not a free pass for bad ideas. They do exist and need to be challenged, but that comes in the debate, after we fully built our ideas and understand them properly. Our job in this stage is to make sure everyone understands what's being discussed. Debating it prematurely is debating a poorly understood and incorrect version of the idea: a waste of everyone's time and a waste of a potentially great idea.
Kim Scott places this "Dirt under your fingernails" point in the Execute section of her book, but I really believe it makes more sense in Clarify (and throughout Listen/Debate as well).
The advice: Stay connected to the actual work your team does. If you manage plumbers, fix faucets sometimes. If you manage sales, go on calls. If you're a conductor, keep playing your instrument.
Why this belongs in Clarify, not Execute: Kim herself explains it -"If you get too far away from the work your team is doing, you won't understand their ideas well enough to help them clarify, to participate in debates, to know which decisions to push them to make."
This isn't about execution as much as it is about maintaining the competence to be a useful thought partner when ideas are still fragile and half-formed. If you don't understand the domain deeply, you can't help someone clarify a rough idea - you'll either ask useless questions or accidentally squash something promising because you don't understand its potential.
Keeping dirt under your fingernails is the prerequisite for everything before Execute. By the time you reach execution, it's too late to gain this understanding.
3. Debate
Debate rigorously tests ideas. As a leader, you don't need to be in every debate, but you have to ensure they happen. Many bosses think their job is to turn off debates and save the team from the "awkwardness" of healthy conflict. This is a mistake. This is a form of ruinous empathy (as described by the 2x2 framework) and it invites all the well-documented problems into your team.
Keep debates focused on ideas, not egos:
- This is about all brains focused on solving the problem together, not a high school debate club where we score points. There is no win/lose, we will not impress judges scoring us, this is not an adversarial game.
- When people slip into "my idea vs your idea" or "I will win this argument" or "my team feels...," redirect them to focus on facts and the problem itself.
- Don't allow ownership of ideas ("this is Bob's idea"). It might feel like giving credit, but it sets the stage for a debate about Bob instead of the idea.
- Don't let ghosts debate in the room. If someone calls upon the spirit of someone not in the room ("well, the VP thinks...") they frame the debate away from the idea and set the scene for everyone to debate the unknowable opinions we cannot verify in the room. If you want to know what the VP thinks, bring them into the room. Invoking their name leads to many unhealthy debate antipatterns such as using "absent authority" to win a debate without merits, can't prove or disprove, speculating based on what "powerful" people think instead of the idea's merits, and generating overall fear, uncertainty and doubt ("FUD") with no way to challenge or clarify it. Nobody gets to "channel the spirits" of other people in the debate room like it's a seance.
Techniques for healthy debate:
- Obligation to dissent: If everyone agrees immediately, the debate is invalid. We're not thinking hard enough.
- Role switching: If you expect a long debate, warn people you'll ask them to switch sides and argue for the opposite position. This nudges people away from digging-in on one view and encourages them to explore the other side.
- Pause for emotions: Call time-outs when people need to recover. Debate takes energy. Make sure your team is fit for it.
- Use humor and playfulness: Launch debates with an open, playful spirit. You can do that without minimizing importance of the outcomes. People will key off your tone. If you start a debate with grim seriousness, the debate atmosphere is set up to feel painful and drawn out.
Explain the process upfront: Some people find debate unnatural or frightening. Make it clear this is a positive space for debate, explain why we're doing it, and be explicit that the debate will also have end time. This isn't "boss decides" or "debate forever" situation, but we will have a known end time for debate.
Announce debate end dates early so people know how to pace themselves.
For big, complex decisions with charged emotions, use separate debate meetings and decision meetings. Don't pick a decision just because the debate is painful. Keeping the debate going despite adversity is the boss's job.
4. Decide
Decide moves from divergent exploration (Listen, Clarify, Debate) to converging on a choice. Debate opens up all possibilities and tests ideas rigorously. Decide closes down other paths and someone explicitly calls the end of debate and commits to a direction.
Decisions should live close to the facts. The people making the decision need direct access to the information, not purified re-structured facts filtered through multiple layers or shaped by political considerations. When decisions get distanced from facts, when senior people decide without understanding the details, or when information passes through too many hands, you can only get poor decisions out of the system.
Designate the decider(s) before the debate begins. Make it explicit: who will make this call? Ideally, it's the person or people closest to the facts, not defaulting to the most senior person in the room. Set a "decide by" date so debate doesn't drag on forever.
The decider collects facts, not recommendations. Facts are less infected by politics than recommendations. When people offer recommendations, they (knowingly or not) leave traces of their egos in it. Facts can still be inflected but not to such a degree as recommendations, are easier to work with and keep the focus on what's actually true and away from "who's winning".
Have the liberty to go directly to the source. The decider should be able to talk to the people facts originate from, not limit themselves to getting information filtered through multiple layers, summarized, truncated, and sanitized. If you're making an important decision and need to understand some aspect more deeply, go directly to the person with that knowledge. Nearly every culture has a name for this problem so it should be instantly recognizable. In my part of Canada we called it "broken telephone", in Germany it is "quiet mail", in Turkey they call it "from ear to ear", in 1400s Florence it was "the game of the ear", and some of the younger generation in the UK calls it "the whispering game". Whatever you call it, don't play this game when making decisions.
Push decisions into the facts, keep egos out. The decision should emerge from what's actually true, not from political maneuvering or who's loudest. Once the decision is made, the decider takes responsibility for the outcome.
Decision-Making Models - other ways to structure who decides
There are multiple ways to structure how a decision gets made. Kim Scott's GSD process primarily focuses on consultative decision-making (one designated "decider" who collects input and facts), but other models exist (and can even overlap):
- Autocratic - One person decides without input. Fast, but the riskiest due to poor information flows and lack of challenge.
- Consultative - One person decides after gathering input. Balances speed with getting diverse perspectives.
- Delegation - Different from Consultative as it often comes with guardrails.
- Consent - Group decides when no one has a "paramount objection" (objections must show harm, not just preference). Aims for "safe to try" rather than perfect.
- Consensus - Everyone must genuinely agree to support the decision. Slow but it can potentially create strong buy-in.
- Democratic - Majority vote wins. Simple but creates winners and losers.
- Stochastic - Random choice (coin flip, dice). Good for low-stakes decisions when options seem equally good.
- Avoidant - Explicitly decide not to decide yet. Strategic when the situation is uncertain and may resolve itself.
In Radical Candor, Kim Scott emphasizes consultative decisions with an explicit "decider". Ideally the person closest to the facts, not defaulting to the boss. The key principle: push decisions to people with the best information. Naming the decider before debate begins provides clarity, but different situations may call for different models.
No single mode is best, different situations can call for different modes including ones not listed here. Situational context determines if the method is an anti-pattern or not.
5. Persuade
Persuade is about getting broader buy-in for the decision. Only a few people were in the Listen/Clarify/Debate/Decide stage. Now you need to bring the wider team along so they'll actually execute effectively with proper motivations, understanding, and alignment.
The common trap most people fall into is to immediately "decide and broadcast". You've spent all this energy building the decision through debate. You're ready to move and highly convinced of what to do. So you dump the decision on everyone else. It can look like announcing it cold via email or slack posts, or a big announcement meeting, but it can also look like an archaeological dig going back and explaining all your thinking and work in one single moment, and somehow expect a broad audience with different motivations and understandings to arrive at the same conclusion. This "decide and broadcast" method doesn't work.
What happens without buy-in? A lot of really undesirable things. People execute half-heartedly or not at all. They undermine the decision passively or actively. They don't understand why it matters, so they deprioritize it when things get hard. Even if the decision is perfect, poor execution makes it fail.
You went on the journey, they didn't. You've been through Listen, Clarify, Debate, Decide, and the decision feels obvious to you and your peers now. But others weren't there. They don't have the context, don't know what was considered and rejected, don't understand why this matters broadly or specifically to them. You have to meet them where they are, not expect them to catch up instantly. You have to care personally and provide a direct message about what is changing (as per the Radical Candor quadrant from the 2x2).
Address their emotions, not yours. Like it or not, you're attached to this decision after you spent all that energy on it. But persuasion isn't about marketing your passion for the solution. Success requires understanding how others feel, think, and care about. Are they exhausted? Worried about their workload? Excited about a different direction? Speak to their situation, not your enthusiasm.
Caring personally and challenging directly will help you build credibility. When you show your work well in the context of a problem someone actually has, you demonstrate both expertise and that you understand their world. Use "we" not "I", as this is collective, not personal glory. Explain the trade-offs to show your decision has come after doing the hard work of looking from multiple perspectives.
Different stakeholders need different messages. The reason that resonates with engineering might not work for sales. The logic that convinces your manager might not land with your team. Each group needs to understand what they win from this change. This is not about telling competing stories, but rather a relevant view on the same story. For a deeper exploration of framing messages for different stakeholders, see Framing Change.
Getting persuasion right means the difference between a decision that executes well and one that dies quietly through passive resistance or active sabotage.
6. Execute
Execute is when the actual work happens. After all that listening, clarifying, debating, deciding, and persuading. Now people need to actually do the thing.
Clear the deck for your team. Your job as a boss is to absorb the "collaboration tax" so your team can focus on execution. Kim Scott provides examples of her former boss defusing political situations, remove obstacles, shield the team from organizational nonsense, never be late to meetings, and stopping debates when they get tedious. All of this protection gave her team more time to execute.
Block time to execute. One key role of the boss here is to explicitly make sure that meetings and competing priorities do not consume all time available, otherwise the change will never happen.
The book focuses on three points: don't waste your team's time, do enough of the work your team does to retain situational context, and block time to execute.
These are important but don't capture what actually makes execution hard or what leaders need to do during this phase.
The book doesn't mention these, but I've found they would be helpful to most software/product companies if they were here:
-
Resolve blockers in real-time. Decisions get made, then something changes. Dependencies emerge, assumptions are proven incorrect, external factors change. Your job is to detect, remove, re-structure, or adapt around these blockers quickly. You can also empower your team to proactively do this work if you have done the work to build up that skill in your team.
-
Maintain momentum. Execution takes time, and enthusiasm degrades. When the team hits a lull part-way through implementation, you need to reconnect them to why this matters and celebrate small wins. Constantly re-affirming the reason why the change is important and celebrating wins while the work takes place.
-
Protect scope/goals/outcomes. As execution progresses, new ideas emerge ("while we're at it, we should also..."). Your job is to help the team distinguish between genuine course corrections and scope creep that will prevent shipping.
-
Stay close enough to reality to know if persuasion failed. Did everyone nod in the meeting but then execute half-heartedly? Are people undermining the decision passively? You need to detect this early and address it, not discover it at the end.
7. Learn
You've executed something - now you need to honestly look at what happened, accept it really happened, and let that inform the next turn of the wheel.
The human default to negative outcomes: defend and deny. By the time you reach Learn, you and your team have invested enormous time and energy. You're attached to what you built. The natural response when results fall short is to defend the work, make excuses, or simply not look too closely. One manager Kim worked with couldn't admit his team was getting terrible results. When finally confronted: "It's unbearably painful to admit it when you have an ugly baby!" (referencing his team, not an actual baby)
It's okay to be wrong. When the facts change, change your mind. Yes, some people may call you a "flip-flopper" or "erratic" if you change course. The key is communication. When you learn something that changes your direction, explain clearly and convincingly what you learned and why it matters. Call out the change explicitly. Often you'll need to go back through earlier wheel stages with your inner circle, then Persuade the broader team again.
"Staying centered" is what makes learning possible. When you're burned out, defensive, or overwhelmed, learning is the first thing to go. You don't have the emotional capacity to admit mistakes or face uncomfortable truths. Mental toughness can be bolstered by maintaining space for reflection, or eroded by grinding through denial.
Learning should have consequences for future decisions and behaviours. This isn't performative retrospection where you nod solemnly and then do the same thing next time. If you learned that you rushed Debate, set a longer "decide by" date next time or figure out how to facilitate a more effective debate. If you learned Persuade failed because you didn't address people's real concerns, change how you approach the next Persuade step. If you learned the decision was wrong given what you knew, examine what information you were missing and how to get it earlier.
Operationalizing Feedback
This section covers tools and techniques from the book that help you "operationalize" feedback. Operationalizing feedback means getting the behaviours and practices to shift. These are more inter-day tactical tools that can just be used quickly to check or improve things, and not the birds-eye-view strategic or philosophical level which the first half of the book discussed.
Relationships
Relationships are a requirement for creating a productive feedback culture. Kim Scott tells us in the book: "You can't fulfill your responsibilities without good relationships, but the way in which you fulfill your responsibilities is integral to those relationships."
Before anything else, you have to take care of yourself so you can "stay centered":
- If you are not in a good state (stressed, lack of sleep, whatever), it will be very challenging to care personally about other people to the level you want to. Therefore, make sure to take care of yourself first.
- Aim for work-life integration, not "balance". This does not mean working in your private life, it means things like making sure you're getting the sleep you need to do the work, and the work you do should find a way to help you energize yourself by helping you express yourself as a human. It's about making sure you get out of life what you need to do work well, and getting what you need out of work that you have a good life. More than just trading sleep, stress, free time, and money around. (Kim is light on this section, I think much more guidance can be found in this area elsewhere).
- Make time in your life for whatever keeps you "centered". For some people this is going to the gym, others it is sleep. The point is to find out what keeps you centered in life and make space for it.
- Make sure there is time to take care of yourself. Book important things you need to do for yourself in your calendar if you need to. Don't let other people make you cancel meetings where you take care of yourself.
Next, you have to consider how to generate the environment that lets your people "stay centered" and bring their best selves to work. You can't ensure they all sleep 8 hours, but there are many other things you can influence that change the work environment.
Core to this are two main pillars:
- Build a trusting relationship with each person reporting to you (via 1:1s and constantly showing you care in all encounters)
- Relinquish unilateral authority. For many managers they have too much fear of releasing control and not enough discipline to keep control distributed. Kim argues (and I agree) that "power and control are illusory" and will not get you the things you really want. Relationships are more effective. Kim describes the reasoning behind this in much more detail in the book along with examples of what a Google CEO said on this topic.
The trap many fear they would fall into if they relinquished unilateral authority is "anarchy" in the team. Self-interests run wild and shared outcomes vanish and someone will politically maneuver to become a "war lord" over some critical topic in the team. Kim also warns us that the leader themselves can become this "war lord", creating an environment where the team is not simply disengaged, but wants to escape from their jobs. Kim's advice is to guide the environment to a better one through relationship forming, and establishing processes and practices that distribute authority (one example was a hiring process that made the team's input more important than any one boss's viewpoint).
Building trust with your team can be done through normal socializing activities like getting lunch together, a holiday party, off-sites, walking somewhere, etc. Just be careful that events do not feel mandatory (even if you say it is "non-mandatory" it can still feel that way), and not everyone wants to (or should) drink alcohol.
Relationships have boundaries
-
Trust is built over time, many people do not warm up to being asked personal questions straight away.
-
Show your values instead of sharing them (like writing them down or asking everyone to write theirs down). Get people to show you what they really value.
If the actions of your people show you they value honesty, figure out how to show that you also value honesty (if you do [...and I hope you do]). Don't ask everyone to write down "honesty" on a flip chart in a meeting and move on.
-
Open yourself to the possibility of connecting with people who have different worldviews than you do. You might not agree with someone about politics, religion, or whatever... but it should not prevent you from caring personally about them. You can disagree with their views and still care about them.
-
Some people are open to physical contact like a hug or a pat on the back, others are not. Moreover, it can be that a person A in your team is fine with being hugged by their colleague B but not anyone else C-Z, or maybe just you.
The general rule is you can push yourself out of your comfort zone, but you cannot violate someone else's physical comfort zone. Things can go very wrong here.
-
You have emotions and different moods, but that should not set the tone for your team. You can't (and should not) try to hide what you feel because it won't work, but you can let people around you know what is going on so they don't think your mood is their fault.
Work-life integration also means some days you don't come in to work if you are so far off-centered that you would end up taking your mood out on the team.
-
Other people's emotions are not yours to manage and control. You can acknowledge them, react compassionately, and react the best way you can. Focus on being a good listener to understand what is going on instead of over-directing.
You also cannot simply tell someone how to feel ("don't be so sad", "don't be offended"), it will backfire every time.
-
People can react negatively to what you say, and it can make you feel bad. It may be you did something wrong, it could be that you did everything perfectly and there was no way to avoid the negative reaction.
Put your insecurities and guilt aside for a moment if you want to help the person in front of you. If you however cannot bear the reaction, you need to step out to bring yourself back to center (for example, acknowledge the charged emotions and excuse yourself to get water, offer to get water for your colleague too).
Relationship building is not easy, it requires serious time and energy.
Guidance
The core operational habit of Radical Candor is getting, giving, and encouraging both praise and criticism. Everything in this section is about building that habit and making it stick. Like any habit, it helps to track it. If you don't pay attention to how often you're giving praise versus criticism, soliciting feedback versus avoiding it, or encouraging your team to guide each other, the default is to drift toward whatever feels comfortable, which for most people is silence.
Use this widget to improve your feedback game.
Click here to open a stand-alone version of this app
Radical Candor Tracker
Today · Fri, Apr 3
| Action | Praise | Criticism |
|---|---|---|
| Get | ||
| Give | ||
| Encourage (of myself) | ||
| Encourage (between others) |
If you want more examples of guidance in practice, chapter 6 of Radical Candor is full of stories and detailed context for each of these techniques.
Getting & Giving Feedback
Getting, giving, and encouraging guidance (both praise and criticism) is the core operational loop of Radical Candor. Soliciting comes first: if you don't demonstrate that you genuinely want criticism directed at you, nobody will believe you when you say you want to give it to help them.
Soliciting feedback
When you become a boss, you inherit assumptions that have nothing to do with who you actually are. People will see you differently regardless of how approachable you were before, and you have to actively work against that if you want honest feedback.
Come up with a "go-to question" (Kim's term), something you can use repeatedly to solicit feedback easily. For example: "What could I do or stop doing that would make it easier to work with me?" The specific words matter less than having a question you're comfortable asking consistently.
Often, people will instinctively respond by telling you everything is fine. But if you allow some silence and space for thought, and perhaps a bit of awkwardness, you give them room to say something important. If they can't think of anything on the spot, come back to it later rather than letting it drop.
When criticism does come, listen with the intent to understand, not to respond. Repeat what you heard back to confirm you understood it. Avoid critiquing the criticism or defending yourself. If you agree, make a visible change as soon as possible. If you disagree, explain why thoughtfully.
Track how often you receive criticism versus praise. If it's all praise and no criticism, that's a signal you need to work harder. You are also the exception to the "criticize in private" guideline. When you encourage public criticism of yourself, you show the team that candor is genuinely welcome and set a standard for everyone.
Meet people where they are. You may have a clear diagnosis of a problem and be able to explain it perfectly, but if you're using language that sounds like buzzwords or jargon to the person in front of you, nothing lands. A manager who just read Radical Candor and starts asking for "radically candid feedback" will get blank stares from a team that has no idea what that means. Use their words, not the framework's words.
The goal is to create an environment where people can feel not only safe giving you feedback, but like it is a normal and expected part of the culture. Provide visual signals that reinforce this: socialize the idea of Radical Candor with your team, put a copy of the framework somewhere visible, or even just leave the book on your desk. Small cues that signal openness to feedback help normalize it over time.
Giving feedback
If you don't have the courage to give Radically Candid guidance, the people who report to you won't believe you really want it from them either. And if you don't lead by example, the people on your team are unlikely to guide each other.
When you deliver criticism, the person receiving it will naturally be defensive. If your delivery signals that you might be wrong and are open to hearing their side, that defensiveness drops. When you deliver praise the same way, it sounds genuine instead of like a performance review checkbox. A common concern people raise is "What if I'm wrong?" You may well be. Telling somebody what you think gives them the opportunity to tell you if you are, and that exchange is where misperceptions on both sides get corrected.
The Situation-Behaviour-Impact framework (covered earlier in this article) is a core tool for keeping feedback specific and grounded. It applies equally to praise: saying "In this morning's meeting, the way you presented the trade-offs helped everyone understand why we chose this direction" is far more useful than "Great job." Blanket judgements, whether positive or negative, tend to land as if you're making a pronouncement about who someone is rather than what they did. That makes feedback harder to act on and easier to dismiss.
Another useful technique is the "left-hand column" exercise from Chris Argyris. After a frustrating conversation, draw a line down a page. Write what you actually said on the right and what you were thinking on the left. The gap reveals where your assumptions may have leaked into your words, or where you held back something you should have said. The point is not to blurt out everything in the left column, but to question whether your thinking was fair.
Notice that the second example, "Nice work on the fix", is positive feedback that still lands in Manipulative Insincerity. That can feel counterintuitive. The issue isn't whether feedback is positive or negative; it's whether you actually engaged. The person genuinely thought the debugging was impressive but said something generic instead. That gap between thinking and saying is the tell. If you don't care enough to say what you actually observed, the praise is just noise. It doesn't challenge and it doesn't show you were paying attention. Radical Candor applies to praise just as much as criticism.
When delivering feedback:
- State your intention to be helpful up front. It lowers defences immediately.
- Be specific. "Your presentation was unclear" is less helpful than pointing to the specific moment where the audience lost the thread. Same goes for praise. "She's really smart" teaches nothing. "She gave the clearest explanation I've heard of why users don't like that feature" shows what to do more of.
- You don't have to have all the answers. Sometimes the most helpful thing is connecting someone with the right person, not solving the problem yourself. And sometimes the conversation itself is the help. Don't let the fact that you can't offer a solution make you reluctant to offer guidance.
Encouraging feedback
If someone on your team comes to you with a complaint about a colleague, do not play diplomat. Insist that they talk to the person directly. If they can't work it out, offer to facilitate a three-way conversation, but never let yourself become a go-between. Shuttle diplomacy between your reports creates politics, not resolution.
You can also build lightweight rituals that make praise and mistake-sharing a regular part of team life. The book describes a practice where team members nominate each other for great work and self-nominate when they screw up, turning all-hands meetings into a space where both recognition and honest mistakes get airtime. The format matters less than the habit: when people see that surfacing problems early leads to help rather than punishment, they stop hiding things.
Making Feedback Effective
Feedback is only effective if it actually lands. The same feedback can be received as a gift or as an attack depending on timing, medium, and audience.
Guidance has a short half-life. If you notice something on Monday and wait until your Friday 1:1 to mention it, the moment is gone and the details have blurred for both of you. Say it right away. This applies equally to praise and criticism. Saving up feedback for a scheduled meeting or a performance review turns small observations into heavy conversations and robs the other person of the chance to adjust in real time. If you find yourself thinking "I'll bring this up later," that's usually a signal that you're avoiding discomfort, not being strategic.
In-person is almost always the best channel. Tone and body language carry information that text cannot, and misunderstandings are easier to catch and repair on the spot. But there is a real tension between "do it in person" and "do it now." If someone is remote or you won't see them for days, a quick video call beats waiting. What you want to avoid is delivering criticism over email or chat, where it tends to read harsher than intended and gives the other person no way to respond in the moment. Praise is more forgiving of medium, but even then, hearing it spoken tends to feel more genuine than reading it typed.
The general rule is to praise in public and criticize in private. Public praise reinforces the behaviour for the whole team and makes the person feel recognized. Private criticism protects dignity and keeps the other person from feeling cornered. But there's a useful nuance here: corrections are not criticism. If someone makes a factual error in a meeting, pointing it out on the spot is a kindness, not an attack. The line is between "your numbers on slide 3 are off" (a correction everyone benefits from hearing) and "your analysis was shallow" (a judgement that belongs in a private conversation).
Feedback Across the Organization
Feedback has to work in every direction, not just manager-to-report. Each direction carries its own friction.
Start by adapting to the person in front of you. Not everyone receives feedback the same way. Some people process criticism best when you're direct and immediate; others need a moment to sit with it. Build a baseline: pay attention to how each person reacts over time, and adjust your delivery accordingly. The framework covered earlier in this article (don't personalize, use SBI) gives you the structure, but calibration to the individual is what makes it stick.
Managing up is where most people stall. Giving your boss honest criticism feels risky, and it is. Start small, be specific, and frame it around what would help you do your job better. If your boss has explicitly asked for feedback, take them at their word. If they haven't, you're essentially doing the work of Radical Candor without the safety net, which takes more courage but is no less important.
Gender and feedback is a common uncertainty for leaders figuring out how to deliver it. Women giving Radically Candid feedback often face a penalty that men don't: the same directness that reads as "confident" from a man can read as "aggressive" from a woman. Don't pull punches anyway, but be aware that the cost is real and unevenly distributed. If you're a man managing women, the most useful thing you can do is not water down your feedback. Treating someone differently because of their gender is its own form of failing to challenge directly.
One of the most underestimated problems in organizational feedback is the middle manager who acts as a reality-distorting membrane. Sometimes this is well-intentioned: they smooth things over out of too much empathy or fear of directness, filtering out anything uncomfortable in either direction. Other times it's political: they want to be a bidirectional puppet master, controlling what flows up and what flows down to maintain their position. Either way, the result is the same: messages don't cascade down and information doesn't flow up. Leaders are not there to trickle down value. They guide it. When you have someone in the middle distorting reality, both the team and the leadership above them are operating on fiction.
The fix is structural, not just conversational. Skip-level meetings help, but more broadly, forming a "team onion" where front-line employees have regular contact with higher-ups breaks the membrane and allows faster flow of information. When people at every level can see and talk to people two levels above and below them, no single person can monopolize the narrative.
For managers of managers, skip level meetings are one of the most effective tools for ensuring feedback culture survives below you. These are meetings where you sit with your direct reports' teams, without the manager present, and ask what their boss could do better. Done well, they surface problems early and support your managers' growth. Done poorly, they become gripe sessions or feel like a disciplinary action.
The operational details matter here. Get the manager's consent first. Make it not-for-attribution. Project your notes live so people can see what you're writing. Share them with the manager immediately after. And most importantly, ensure visible changes follow. If people give you honest feedback and nothing changes, they won't do it again.
Performance Reviews
Performance reviews are where Radical Candor either becomes real or gets exposed as lip service. If you've been caring personally and challenging directly throughout the year, the review is a formality. If you haven't, no amount of process will save it. Your feedback should have also included legitimate mentoring and coaching of people to help them grow.
When the book was written, the trend was moving away from doing performance reviews: the company GE (which Kim tells us "pretty much invented annual reviews") replaced them with a continuous feedback app. Companies like Adobe, Deloitte, and Accenture followed.
If your company doesn't do formal reviews, it is critical you do regular impromptu guidance (covered earlier in this article) and make sure the logic behind compensation and promotion decisions is transparent some other way.
The "abolish performance reviews" narrative peaked around 2015. By 2025-2026, the trend reversed at several major companies. Amazon formalized accomplishment-based stack ranking across its entire corporate workforce. Meta mandated that 15-20% of employees be rated "below expectations" and shifted reviews to reward output over effort. GE itself split into three companies in 2024, making it unclear whether the original continuous feedback system survived the restructuring.
If your company does do them, put in an honest effort. A formal review with a rating can land a message in a way that impromptu feedback doesn't. You may have told someone their negativity is hurting their cross-functional relationships multiple times, but they may not understand how seriously you mean it until they see a low rating. If you've been doing impromptu guidance well, the review should feel like a summary. If anything in it is a surprise, that's a failure of your ongoing guidance, not a problem with the review.
Performance reviews should be evidence-based. The most effective reviews happen when there are no surprises because you and your reportee have been building and documenting evidence throughout the year. If you are doing this well, your reportees basically know their review before they walk into the meeting. You should have spent considerable time aligning on what "good" looks like at each level and mentoring them to reach those levels. The review meeting then becomes a confirmation of shared understanding, not a reveal.
Do not use 360 feedback as justification to change someone's level, block a promotion, or build a case for removal. 360 feedback is a development tool, not a leveling tool. Leveling decisions should come from a real skills matrix that evaluates collected evidence of ability to meet the expectations of each level. When people discover that peer feedback was used against them in a review, trust in the entire feedback system collapses. Nobody will give honest feedback if they think it will be used as ammunition.
One of the most common organizational pathologies is forcing every department through a monolithic, synchronized review cycle on a tight deadline. Yes, leadership wants to know where to allocate budget, but that does not mean every manager needs to write 5-10 reviews in a two-week window while simultaneously running planning and strategy sessions. Reviews require deep thinking about individual people. Planning requires deep thinking about team direction. Doing both at the same time guarantees you do neither well. Stagger them.
How to not waste them:
- Don't rely on your judgment alone. Even without a formal 360 process, run a check. One method Kim suggests: ask each team member to rate their peers and follow up only on the outliers.
- Solicit feedback on yourself first. Ask your direct reports to review you before you review them. Makes the whole thing feel two-way instead of a judgement handed down from above.
- Write it down. Writing forces you to be more nuanced than you'd be otherwise. It also makes it harder to avoid saying something difficult. And it gives the person something to revisit later after some time to cool down.
- Think about when to hand over the written review. Some people do better reading it the night before so they can come prepared. Others will stress out if left alone with the document. Knowing your people better lets you better judge what to do.
- Schedule at least fifty minutes and don't stack them back-to-back. These conversations are draining. Your review quality drops quickly if you try to knock them out back-to-back.
- Spend half the time looking back, half looking forward. The diagnosis matters, but the plan matters more. Ask them what they'll do differently, don't come in with the plan yourself. This also doubles as a comprehension check: if their plan doesn't address what you raised, they didn't understand you.
- Schedule follow-up check-ins. A review without follow-up is a conversation that evaporates. Even if it's just an agenda item in a couple of future 1:1s, mark it in your calendar.
If your company ties ratings to compensation, deliver the rating after the development conversation, not before. When people hear their rating first, they tune out everything else you say.
Team
Everything in this section is the infrastructure that makes Radical Candor possible. You can't care personally about someone's career if you've never asked about it. You can't challenge directly in a hiring decision if you don't have a rubric. The feedback framework gives you the mindset; what follows gives you the organizational machinery to act on it.
Career Conversations
If you do one thing from this chapter, do this. Career conversations are probably the most impactful thing you can do to show your team you care about them as individuals.
The biggest career development failure mode is not a bad conversation - it's the absence of any conversation at all. Most people sleepwalk into their careers because a path happened to be in front of them, or they wait for someone else to do career development for them. Your job is to interrupt that pattern. Not by telling them what to do, but by helping them figure out what they actually want and then working backward from there.
Kim Scott proposes a structured series of three conversations that build on each other over a few weeks. You don't need to follow this rigidly, but the progression from past to future to plan gives each conversation a foundation to build on.
Conversation 1: Life Story Ask the person to walk you through the major transitions in their life, starting as far back as they're comfortable. The goal isn't therapy; it's understanding what motivates them. When someone describes why they left one job for another, or why they picked up a new discipline, values surface naturally. Write down the motivators you hear and check them with the person.
Conversation 2: Dreams Use the word "dreams" deliberately, not "career goals" or "aspirations." Those phrases invite people to say what they think you want to hear. Ask for three to five versions of what the pinnacle of their career might look like, and you create room for honesty. Even if someone's dream seems disconnected from their current role, mapping out the skills needed often reveals that their current job is a meaningful step toward their actual goal rather than a dead end.
Conversation 3: Eighteen-Month Plan Now that you understand what someone values and where they want to go, work backward from those dreams to identify what skills they need to build next. The output is a concrete list: projects that develop those skills, people to learn from, classes or reading. Each item gets an owner and a deadline. This is the part that turns a good conversation into real career movement.
A particularly common challenge in tech is people who aren't sure whether they want to go down the technical track or the people/management track. If you treat job titles as a lagging indicator of growth (which you should be doing anyway), this creates space for people to try elements of different roles and understand what they actually enjoy before committing to a track. Let people experiment with mentoring, leading a project, or running a meeting before they have to decide whether "manager" is the right next title.
Growth
Once a year, step back and look at your whole team. The book introduces a framework for thinking about people along two dimensions: the quality of their results (from poor to exceptional) and their growth trajectory (gradual and stable versus steep and ambitious).
I'm not a fan of this particular model. People are more multi-faceted than a two-dimensional grid can capture, and unpicking specific skill gaps and motivation gaps can radically change where someone sits on it. Someone who looks "gradual trajectory, good results" might actually be a person with steep potential who is bored, blocked, or in the wrong role. The framework is a starting point for thinking, not a diagnosis.
What matters more than the framework is how you approach growth day-to-day. The most common mistake managers make is looking at who they can promote based on gut feel at the start of the review cycle. By then it's too late. You should be working with your reportees regularly throughout the year to help them collect or build evidence of the next level. Set challenges that let them demonstrate those skills. When promotion time comes, the evidence should already exist.
Calibrating assessments with peers is valuable in theory. In practice, it can become a popularity contest. I've had one of my best reportees rejected as a promotion candidate during a calibration session because my peers "hadn't heard his name before." Cross-team calibration works when the people in the room have meaningful interaction with each other's teams. When they don't, you're asking people to evaluate strangers based on a manager's pitch, which is exactly the kind of filtered information the Decide section of GSD warns against. If you use calibration sessions, make sure the participants have real context, not just opinions about names they've heard in passing.
Hiring
The hiring manager, not a recruiter, should write the job description. Define "team fit" explicitly using three or four words that describe your culture, things like "detail-oriented" or "blunt" or "collaborative." If you don't write it down, interviewers will fall back on their instincts, which are often just bias wearing a different hat.
The single biggest hiring mistake is treating interviews as an adversarial guessing game. Too many interviewers think they need some superstar who guesses all the things the interviewer likes to hear. Without a standard interview grading sheet and script, each interviewer evaluates candidates against different, unstated criteria and the hire decision becomes a debate about feelings rather than evidence. The grading sheet is critical: decide what you're evaluating before you meet anyone, and score every candidate against the same rubric.
- Blind skills assessments before interviews filter out false positives and false negatives. If someone looks great on paper but can't do the work, a skills test surfaces that fast. If someone looks unremarkable on paper but is excellent at the job, a skills test gives them a way in. The now-famous example is orchestras implementing blind auditions and increasing the percentage of women hired fivefold.
- Same interview committee of about four people for all candidates applying to the same role. Mix the committee: different backgrounds, at least one person from outside the team to guard against desperation hiring.
- Write your feedback immediately. Schedule an hour, interview for forty-five, write for fifteen. If you can't articulate what bothered you about a candidate until you sit down to write it, you would have missed it entirely in a verbal debrief.
And when the committee meets to decide: if you're not dying to hire the person, don't make an offer. But make sure "dying to hire" is grounded in the grading sheet, not in charisma or pattern-matching to your own background.
Even when it's clear a candidate isn't the right fit, make them feel valued throughout the process. You want them to walk away thinking "I liked those people and I wanted that job." They will get better and come back. They will tell their friends about the experience. And when they're sitting on a competing offer from a company that only knows how to talk numbers, the fact that they felt genuinely wanted by your team becomes the differentiator on the table.
Hiring is a funnel, and it needs to be managed like one. When hiring is disconnected from the teams that will absorb the new people, you get surprise hires: people assigned to your team that you never interviewed, never requested, and whose skills don't match what the team needs. The management chain becomes too embarrassed to address it because they've already made the offer. This is a systemic failure, not a people failure. The hiring manager must be the team's manager, and the team must have meaningful input into who joins.
Firing
Firing is going to be emotionally hard, and it should be, even when it's the right thing for everyone involved.
Waiting too long makes it harder on everyone. The person struggling deserves to know early enough to course-correct. The team doing great work deserves not to carry someone who isn't contributing. And you deserve not to blindside someone with a termination that your own performance reviews didn't predict.
Kim frames firing as "this job is wrong for them" rather than "they are bad at their job." Both things can be true individually and combined. A business is not a charity, it has to work. At the same time, if it doesn't work for the business, the chances are this person's career has stalled and they could do better elsewhere. Sometimes excellent people cannot work together, or cannot work well in a specific environment. It's not always about the individual - the context they are in influences a lot. That person will always continue to grow and evolve, but the business must function as a business, not a club.
When it's time, don't make the decision alone. Get input from your boss, calibrate with peers, and work with HR to document properly.
Don't write a Performance Improvement Plan by yourself. Have someone experienced edit it. Most managers write PIPs that are too easy to pass without addressing the core issue, which just drags the problem out another quarter.
Leveraging historical feedback as justification to fire someone is a way to absolutely destroy all trust in feedback working at your company for at least a year, if not more. If people discover that the candid feedback they gave (or received) was later used to build a termination case, nobody will participate honestly in feedback again. Trust arrives on foot and leaves on horseback. If you want a healthy feedback culture, keep feedback and termination processes completely separate. The evidence for termination should come from documented performance against clear expectations, not from recycled peer feedback.
Promotions
Title promotions should be a lagging indicator of growth, not a goal in themselves. If someone is already consistently operating at the next level and has the evidence to prove it, the promotion is a recognition of reality. If the promotion is aspirational - "we'll give you the title and hope you grow into it" - you've set up both the person and the team for a difficult situation.
The biggest risk with promotions is that it's not clear why someone was promoted over another, especially when there is competition for a role. If one manager promotes faster than another, or if promotions are driven by who the boss likes rather than what the person has accomplished, the whole team loses trust in the system.
The book highlights Google's engineering promotion committees as a model: an off-site panel debates promotions of other people's direct reports based on documented accomplishments, not the manager's advocacy. This committee approach works well and can be scaled down with less formality for smaller organizations. The core principle holds at any size: promotions should be evaluated against documented evidence by people other than just the direct manager. No one gets promoted by flattery alone.
The committee model addresses the "promoted by optics" problem, but introduces others. Promotion reviewers might not have enough context to correctly evaluate the work. For example, in some setups a backend engineer could be reviewing the packet of a UX designer, with no real ability to evaluate the quality of the work of the individual. Flawed implementations (which are easy to accidentally build) reward people who are good at writing promotion packets over people who are good at their actual discipline. Moreover, committees tend to over-emphasize technical complexity of work over impact and outcome, because complexity is easier to see on a document that covers activities instead of if a project actually moved a metric. The core principle of independent review is sound, but the implementation needs guardrails to prevent it from becoming a paperwork exercise that rewards self-promotion over contribution.
For these reasons, I structure reviews such that impact of a project is not a direct criteria for job title promotion. It may be criteria for a bonus or salary bump, but job levels are driven by evidence of doing the work. If the impactful project does generate durable evidence of ability at the next level, it can be counted towards job role promotions.
If we don't follow this process, we end up promoting everyone who introduces a very complicated project to the business, and our incentives create a gold-rush towards complexity.
Salary promotions are trickier than title promotions and are subject to many variables that can't easily be reduced to a simple rule. Market conditions, internal equity, budget constraints, retention risk, and individual circumstances all play a role. What matters is that the logic is transparent enough that people trust the system, even if they don't love every individual outcome.
Rewards
What gets recognized gets repeated. This is the most important thing to understand about rewards. Recognition should be public, specific, and timely. If you recognize someone for staying late to fix a production incident, you'll get more of that. If you recognize someone for writing documentation that saved the team hours, you'll get more of that too. Choose deliberately what you recognize, because you are shaping the culture every time you do it.
Not everyone wants a promotion, and not everyone should get one. If promotion announcements become your primary form of recognition, you're signaling that the only way to be valued is to climb the ladder. That's demoralizing for people who are doing essential work and have no interest in a different role.
Say thank you. Write it down. A thank-you goes beyond praise: it explains not just why the work matters, but why it matters to you personally. These stick around longer than you'd expect.
If someone is the best on the team at something, make that visible. Put them in charge of teaching it. Give them a platform to present their work to colleagues. One of the most common complaints from people doing excellent work on a gradual growth trajectory is that they feel invisible. A teaching role, a presentation slot, a written note - these cost almost nothing and solve that problem directly.
Rewards that incentivize bad situations can be entirely non-obvious. Something as seemingly benign as giving an award for zero sick days can lead to real health issues going unaddressed, people coming to work sick and infecting others, or misreporting in the HR system. Before establishing any reward or recognition program, think carefully about what behaviour it actually incentivizes - not just the behaviour you intend to reward, but the second-order effects of people optimizing for it.
Avoiding Micromanagement and Absentee Management
These are the two failure modes for managers who care about results but lose the balance. A micromanager controls the how: they prescribe solutions, demand constant updates, and treat every decision as one they need to make. An absentee manager avoids the how entirely: they rubber-stamp everything, offer no guidance, and only show up when something breaks. Both produce the same outcome, a team that stops thinking for itself, but through opposite mechanisms.
Three Management Styles, Same Engineer
Watch how identical messages get different responses. Switch channels to compare, scroll to see 12 weeks of progression.
The partner model sits between these extremes. A partner is curious about what their team is doing, explains the reasoning behind decisions, asks about risks without demanding daily status reports, and helps solve problems without taking them over. The distinction shows up in small moments: when someone brings you an idea, do you ask questions or hand them a solution? When someone reports a problem, do you help them think through it or assign them steps? When someone gives you an update, do you engage with it or ignore it?
Watch for the signals:
- Your team stops bringing you problems. Either you're a micromanager (they've learned you'll just take over) or an absentee manager (they've learned you won't help).
- Your team brings you everything, including decisions they should be making on their own. You've probably been a micromanager long enough that they've stopped trusting their own judgment.
- Your team only brings you good news. Same dynamic as not soliciting criticism from your reports. If nothing is ever wrong, something is definitely wrong.
The fix in all three cases is the same: be a partner. Stay engaged without taking control.
Calendar & Time Management
The GSD model only works if the meeting types it depends on actually exist on your calendar. 1:1s, debates, decisions, think time - if these don't have protected slots, they get squeezed out by whatever feels most urgent that week. Kim walks us through different types of meetings and shows us how each format does something different related to the Get Stuff Done model or the environment that supports it.
| MondayMon | TuesdayTue | WednesdayWed | ThursdayThu | FridayFri | |
|---|---|---|---|---|---|
| 8AM | |||||
| 9AM | 1:1 Engineer A | 1:1 PM C | All-Hands | 1:1 Engineer D | Staff Meeting |
| 10AM | Execute Time | ||||
| 11AM | Big Decision Q2 Roadmap | ||||
| 12PM | |||||
| 1PM | Think Time | Execute Time | |||
| 2PM | 1:1 Designer B | Big Debate Product Direction | 1:1 Designer E | ||
| 3PM | |||||
| 4PM | |||||
| 5PM |
This is not the "default calendar suggestion", simply a way to give you a sense of what kinds of calendar events are here and how they might be mapped out. The book does not tell you how to play calendar tetris, that's your own choice.
1:1s
You must have 1:1s, these are not optional if you want to establish Radical Candor. These give you deep situational awareness, and an ability to build the trust needed to care personally.
Do's:
- Listen with the intention of understanding or clarifying, not just responding
- Mix up the format to see what works, try walking, over lunch, early, late, figure it out together.
- Your reportee sets the agenda, not you. You should however explain your expectations around the agenda (structured, free-flowing, whatever).
- Ask follow-up questions like "How can I help?", or "What are they not doing that you wish they would do?" (Kim has a list of these in the book, chapter 8).
- Encourage new ideas: "Can you tell me more about that?", "I think you're on to something but XYZ might miss this explanation, how can we frame it for them?" (again, a list of these are in the book).
Don'ts:
- Save up and vomit out all your feedback for the 1:1 meeting
- Force your preferences for the 1:1 time and location on someone, like meeting at 5am for a jog when the other person isn't interested.
- Cancel or ignore cancellations. These are often (but not always) a signal that something is going wrong in your partnership.
- Use 1:1s for "updates" that can just be a simple slack message.
- Get comfortable with "only good news to report", there's always something to work on, this can often be a signal there is not enough trust to share their problems
- Similar to the last item: if they never criticize you, it means you are not getting guidance from your team
- Allow no-agendas to persist for long. It often signals your reportee is overwhelmed and you can work with them to help them.
1:1s creates a practical (and useful) bottleneck for being an effective manager. You need to have them, but if you have too many you won't be able to do the rest of your work, so your reporting line will be constrained naturally. You will have to find a balance depending on the specific situation you are in, but if it gets too much, chances are that you manage too many people directly. Time to delegate.
Staff meetings
These meetings are about building context and awareness, not about making decisions. Kim separates the informing from decision making meetings following the reasoning established in the Get Stuff Done model where Clarify, Debate Decide are different stages.
There are three major activities in these meetings:
- Review how the previous week went
- Allow people to share important updates
- Clarify the important upcoming debates and decisions next week (but do not decide or debate it here).
To correctly implement this, you'll need a view of some sort with metrics and information relevant to your team that might change on a weekly basis. A simple spreadsheet updated weekly is a viable solution, and so is a complex software tool. Ideally it is in a place where everyone can see it.
Collecting important updates on a shared document helps everyone in the meeting know what everyone else is doing so they can not only stay informed but flag problem areas early. Things that don't come up in the dashboard belong here like "person XYZ will be on leave for a month", or "product vendor ABC will retire their software in a month".
Lastly, describe the top two most critical decisions or debates the team needs to take on this week. For really small decisions it might be worth it to just solve those in an ad-hoc way in the meeting. For larger topics, moving them to a "big" meeting so the present meeting can continue/end and the most relevant people to the big debate/decision can move on to that meeting without the entire group.
Think time
These are meetings with yourself. A space where you can clarify your own thinking without jumping from one complex topic to the next with no time to organize your thoughts or come up with answers. You should book them so you can be of use to your team in those big debate and big discussion meetings.
Kim Scott also presents an "execute time", which is for the hands-on task clearing time instead of time spent deep in thought.
Big debate
The debate's core output is a thoughtful summary of facts and issues that emerged, a clear definition of the choices that need to be made, and a recommendation of if more debate is needed or the topic should move on to the decision stage.
Make it clear this is a debate, not a decision. This helps lower the tensions in the room and set expectations.
Tactically, you can also use big debates to slow down something that is being rushed despite many issues, and allow time to resolve logical disagreements about how to proceed instead of rushing to a quick solution.
Having these debates regularly fosters a culture of healthy debate and maintains healthy debating skills. Having regular debates prevents explosive fights from built-up tensions.
See the Debate section of Getting Stuff Done for more ideas on how to set expectations and guide behaviours in these meetings.
Big decision
The main purpose of this meeting is to signal we are going to make a decision, the debates have come to a close and enough information has been surfaced that we can and will make a decision.
If the decisions are re-opened it wasn't really a decision but an unresolved debate. Some of the times this can happen is purely a cultural bug where people will defy a decision simply out of preference or self-interest, which is a cultural and personal feedback issue to solve rather than a decision making process design challenge.
The decider should be chosen well before the meeting starts.
All-hands
These meetings are meant to show information that persuades your people the company is making good decisions and provide an opportunity for Q&A to address dissent directly.
These meetings can easily fall into two major traps.
First, getting bogged down with an effort to showcase something from every department/team instead of sticking to a relevant topic that is persuasive and weaving together a story that is inclusive. We typically see a "show and tell" presentation of each department in a row, like a very expensive stand-up meeting.
The other way this meeting becomes burnt time is when leaders dodge the question. I've frequently seen tough questions avoided with phrases such as "well, there was nothing really concrete in that so we can't address it". If you cannot think of a good answer on the spot, at least make a commitment to follow up in the next all-hands or in summary notes sent after all-hands. Do not broadcast to your team you are unwilling to take tough questions, because that's how it will be read.