Learning to Think Again: Rethinking Lessons from Adam Grant for Technical Leaders

This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development

There is a particular kind of confidence that a technical team earns over years, and it is dangerous precisely because it is earned. The deployment process everyone trusts. The architecture that has held up so far. The “we tried that in 2019 and it didn’t work”. These are hard-won conclusions, and the people holding them are usually right. The trouble starts when right hardens into permanent, and a team stops asking whether the thing that was true three years ago is still true today. The skill that stops that calcification has a name, and it is rethinking.

Adam Grant’s “Think Again: The Power of Knowing What You Don’t Know” is a book about that exact failure mode, and about the antidote to it. Grant is an organisational psychologist, and his argument is deceptively simple: we spend an enormous amount of effort learning how to think, and almost none learning how to rethink. We treat changing our minds as a sign of weakness rather than a sign of work being done well. His case is that rethinking is a skill in its own right, one that can be practised and taught, and that the people and teams who get good at it consistently outperform the ones who simply get more certain.

This sits naturally alongside the lessons I drew from Oscar Trimboli’s How to Listen. Listening is how new information reaches you; rethinking is what you are willing to do with it once it arrives. The two are useless apart. There is no point hearing a colleague out if your mind was made up before they opened their mouth, and there is no point being open to changing your mind if nothing new ever gets through. Where Trimboli looks at the receiving end of a conversation, and Charles Duhigg’s Supercommunicators looks at connection across it, Grant looks at what happens inside your own head afterwards.

This post draws on the ten quotes I found most useful from Think Again, and what they reveal about leading technical teams well.

Why Expertise Can Work Against You

The brighter you are, the harder it can be to see your own limitations. Being good at thinking can make you worse at rethinking.

If you only take one idea from the book into a technical organisation, take this one, because it inverts something we usually treat as obviously good. We hire for intelligence, we promote for depth of knowledge, and we assume that the smartest person in the room is the one most likely to reach the right answer. Grant’s point is that intelligence is a tool for reaching conclusions quickly, and a tool that is very good at reaching conclusions can become very good at defending the wrong one.

I see this most clearly in senior engineers, and I say that as a compliment to them. The deeper someone’s expertise runs, the more confidently they can pattern-match a new problem onto an old one, and the more reluctant they become to entertain the possibility that this time the pattern does not hold. Their track record is the very thing that makes them slow to update. The junior developer who knows they do not know asks the naive question that turns out to matter; the principal engineer who has seen it all before is the one most likely to skip it.

For a leader, the implication is uncomfortable. The voices you are most inclined to trust are not always the ones most willing to be wrong, and a team made entirely of confident experts can march very efficiently in a direction nobody has reexamined.

The Person You Are Most Likely to Mislead

You must not fool yourself, and you are the easiest person to fool.

Grant borrows this line from the physicist Richard Feynman, and it belongs on the wall of every engineering team I have ever worked with. We are exhaustive about validating other people’s reasoning. We have code review, design review, and the healthy scepticism we apply to a vendor’s benchmark. We are far less rigorous about the assumptions we have quietly made ourselves, because those assumptions do not feel like assumptions. They feel like facts.

The technical version of fooling yourself is rarely dramatic. It is the load test you ran once, eighteen months ago, and have cited as gospel ever since. It is the “users never do that” that was true of the users you had in 2022. It is the estimate you anchored on in the first five minutes of a planning meeting and then spent the next hour rationalising rather than revisiting. None of these feel like self-deception in the moment; they feel like knowing what you are talking about.

The defence Feynman points to is not cleverness but suspicion, aimed inward. The questions that keep a team honest are the ones it asks of its own confident statements: how do we actually know this, and when did we last check?

Rethinking Is a Skill You Already Have

Rethinking is a skill set, but it’s also a mindset. We already have many of the mental tools we need. We just have to remember to get them out of the shed and remove the rust.

This is the encouraging part, and it matters because the rest of the book could easily read as a catalogue of ways your brain betrays you. Grant is clear that rethinking is not a rare gift possessed by unusually open-minded people. It is something every one of us already does, often without noticing, every time we let a good argument move us or revise an opinion in the face of better evidence. The work is not learning a new capability; it is doing an existing one on purpose and more often.

For a team, that reframing changes where you look for improvement. You do not need to recruit a different sort of person. You need to build the habit into the way the team already operates, so that revisiting a decision is a normal part of the process rather than an admission that the first decision was a mistake. The retrospective that genuinely changes how you work next sprint is rethinking with the rust knocked off. So is the design document that gets meaningfully rewritten because someone raised a point in review, rather than rubber-stamped because changing it felt like backtracking.

The Most Useful Question in the Room

How do you know? It’s a question we need to ask more often, both of ourselves and of others. The power lies in its frankness. It’s nonjudgemental, a straightforward expression of doubt and curiosity that doesn’t put people on the defensive.

Here is the first of two questions from the book that you can start using this week, at no cost and with no ceremony. “How do you know?” is disarming because it does not contain an accusation. It does not say you are wrong; it asks where the belief came from, and it works just as well turned on yourself as on a colleague.

What makes it powerful in a technical setting is how often it surfaces that nobody actually knows. Asked gently in a planning meeting, it separates the things the team has measured from the things the team has assumed and then repeated until they sounded measured. “The third-party API is too slow for this” is a perfectly reasonable thing to believe, right up until “how do you know?” reveals that the figure everyone is quoting came from a single test on a bad afternoon two years ago. The question is also the natural partner to listening well; it is an invitation for the other person to think out loud, and your job, as I explored in the companion piece on listening, is to leave enough silence for the real answer to arrive.

Knowing When to Stop Arguing

In a heated argument, you can always stop and ask, ‘What evidence would change your mind?’ If the answer is ’nothing’, then there’s no point in continuing the debate. You can lead a horse to water, but you can’t make it think.

The second question is the one I wish I had learned twenty years earlier than I did. Technical disagreements have a habit of running in circles, two capable people restating their positions with increasing precision and decreasing progress. “What evidence would change your mind?” cuts straight to whether the conversation is worth continuing at all.

If both people can name the evidence that would move them, you have a productive disagreement, and you have also just written the experiment that will settle it. Build the spike, run the benchmark, ship the test behind a flag, and let reality decide. If one person cannot name anything that would change their mind, you have learned something equally valuable: this is not a technical debate, it is a preference being defended as a fact, and no amount of further argument will resolve it. Recognising that early saves a great deal of everyone’s afternoon.

ℹ️ Note

Try this in your next architecture discussion. Before the debate gets heated, ask everyone in the room to write down the one piece of evidence that would change their position. If anyone writes “nothing”, you have found a value or a preference rather than a technical question, and it needs a different sort of conversation. If everyone can name their evidence, you have just turned an argument into a short list of things to go and measure.

Disagreement as Fuel, Not Friction

That’s the beauty of task conflict. In a great argument, our adversary is not a foil, but a propeller. With twin propellers spinning in divergent directions, our thinking doesn’t get stuck on the ground; it takes flight.

Grant draws a distinction that is worth holding onto: the difference between relationship conflict, which is personal and corrosive, and task conflict, which is about the work and is one of the healthiest things a team can have. The image of the propeller captures it well. Two people pushing in different directions are not cancelling each other out; if the disagreement is about the task rather than about each other, they are generating lift.

The practical risk in most technical teams is not too much conflict but too little of the right kind. We are conflict-averse by training, and we mistake the smooth meeting where everyone agrees for a sign of health, when it is often a sign that nobody felt safe enough, or cared enough, to push back. A team that never has a good argument about its architecture is not a team that has found all the right answers; it is usually a team that has stopped looking. The leader’s job is not to suppress the disagreement but to keep it pointed at the problem rather than at the people.

What Silence Costs a Team

In psychologically unsafe teams, people hid their mishaps to avoid penalties, which made it difficult for anyone to diagnose the root causes and prevent future problems. They kept repeating the same mistakes.

Rethinking is not only an individual discipline; it is an environmental one. A team can only reconsider a mistake it is allowed to talk about, and Grant’s point here is that fear does not make mistakes disappear, it only makes them invisible, which is far worse. A hidden mishap cannot be learned from, so it gets repeated, and the same outage rolls around every few months wearing a slightly different hat.

This is the same ground covered by Amy Edmondson’s research, which I wrote about in Embracing Failure, and it connects directly to the practical work of building psychological safety in a development team. The link to rethinking is what I want to draw out here. A blameless post-incident review is, at its core, an act of collective rethinking. It takes a shared assumption about how the system behaves, holds it up against what actually happened, and updates the team’s model of reality. A team that punishes the messenger never gets to do that work, because the messages stop coming. Across nearly twenty years of working with more than fifty organisations, I have rarely found a team that repeats the same failures because it is incapable of learning. Far more often, it is because the information needed to learn never made it safely into the room.

The Leadership Blend That Actually Works

In rigorous studies of leadership effectiveness across the United States and China, the most productive and innovative teams aren’t run by leaders who are confident or humble. The most effective leaders score high in both confidence and humility. Although they have faith in their strengths, they’re also keenly aware of their weaknesses. They know they need to recognise and transcend their limits if they want to push the limits of greatness.

We tend to treat confidence and humility as opposite ends of a single dial, as though to gain one you must give up some of the other. Grant’s evidence says they are separate dials entirely, and that the best leaders turn both up at once. He calls the result confident humility: faith in your ability to figure something out, paired with an honest read of what you do not currently know. It is the difference between “I have no idea” and “I do not know yet, but I am confident we can find out”.

This blend is exactly what makes the rethinking habit safe for a leader to practise in public. A leader who is all confidence cannot change their mind without appearing to have been wrong, so they double down. A leader who is all humility cannot commit to a direction, so the team drifts. The leader who holds both can say “this was my best call with what we knew, and here is the new information that changes it” without it costing them an ounce of authority. I explored a close cousin of this idea in Leading with Ownership; owning an outcome and being willing to revise your approach to it are the same instinct seen from two angles.

The Quiet Power of the Beginner’s Mind

The label ‘impostor’ puts us in a beginner’s mindset, leading us to question assumptions that others have taken for granted.

This is one of Grant’s more surprising arguments, and it reframes a feeling most of us treat purely as an affliction. The sense of being an impostor, of not quite belonging in the room, is usually filed under things to overcome. Grant suggests it has a hidden upside: the person who is not sure they belong is the person most willing to ask the question everyone else assumed had an obvious answer.

I have written before about why a degree of impostor feeling can be a healthy thing, and this is the mechanism behind it. Expertise breeds assumptions, and assumptions go unquestioned precisely because they feel settled. The newcomer, or the person quietly convinced they are out of their depth, has not yet learned which questions you are not supposed to ask, and those are frequently the questions worth asking. The most useful thing a leader can do with this is to make it cheap and respectable to ask them, so that “this might be a daft question, but why do we do it this way?” is met with a real answer rather than a raised eyebrow. Often the honest answer is that nobody can quite remember, which is the most valuable finding of all.

Why This Belongs at the Heart of CPD

Ultimately, education is more than the information we accumulate in our heads. It’s the habits we develop as we keep revising our drafts and the skills we build to keep learning.

I have closed a lot of these CPD posts with some version of “keep learning”, but Grant gets at something more precise here, and it is why his book sits so well in this series. Continual professional development is not, at its best, the accumulation of more facts to set in concrete. The half-life of a specific technical fact is short, and a head full of certainties from five years ago is a liability dressed up as expertise. The durable skill is the habit of revising, of treating your own understanding as a draft that is never quite finished.

That is what unites the ten ideas above. Questioning your most confident conclusions, asking how you know, naming the evidence that would change your mind, arguing well, making it safe to admit mistakes, pairing confidence with humility, keeping a little of the beginner’s willingness to ask: none of these require a different sort of mind. They require deciding that rethinking is part of the work, and then doing it on purpose. For a technical leader, that decision matters more than it first appears, because a team takes its permission to change its mind from whether it ever sees its leader change theirs.

The strongest teams I work with are not the ones that are right most often. They are the ones that notice fastest when they have stopped being right, and have built the habits to do something about it. That is rethinking, and the good news from Grant is that it was never a talent you either had or lacked. It is a practice, and you can start it in your next meeting with a single question.

If the ideas in this post resonate with challenges you are navigating in your own team, let’s talk.