Thinking on Purpose: Critical-Thinking Lessons 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

Picture the first twenty minutes of an incident. The dashboards have gone red, the support queue is filling up, and six people are now in a call that started with two. Someone says it is probably the cache. It sounds right, it fits the last time this happened, and within a minute somebody is already writing the change to flush it. Nobody in the room has yet asked the one question that matters: is that actually what is happening this time, or is it just the first explanation that felt familiar enough to act on?

Sometimes the cache really was the problem and the room looks clever. Sometimes it was not, the flush makes things worse, and an hour disappears chasing a fix for a fault that was never there. Here is the uncomfortable part: from the inside, those two situations feel identical while you are in them. The only reliable difference between a good decision and a lucky one is whether somebody stopped, for the thirty seconds it costs, to examine the assumption everyone was about to act on.

That habit of stopping has a name. It is critical thinking, and it is a skill you can practise, not a fixed quantity you were issued at birth. I picked up a short primer on it a while ago, Critical Thinking In A Nutshell: How To Become An Independent Thinker And Make Intelligent Decisions by the Thinknetic team. It is a plainly written book that does not pretend to be philosophy, and that is exactly why its ideas travel so well into a technical setting. Across almost twenty years in this industry, more than fifty organisations, and nearly 190 episodes of The Modern .NET Show, the best decision-makers I have watched were rarely the fastest or the most obviously brilliant people in the room. They were the ones who had disciplined how they think. Here are ten quotes from the book, read through the lens of leading software teams.

Thinking on Purpose

It is worth starting with what the book actually means by the term, because “critical thinking” gets used to mean everything from scepticism to simply disagreeing with people.

Critical thinking is the ability to think through connected ideas thoroughly and independently based solely on reason and evidence. It is the focused and disciplined act of turning our mental abilities towards the resolution of the real-world problem.

The two words I keep returning to in that definition are “focused” and “disciplined”. Critical thinking is not a mood you drift into when a problem looks hard. It is a deliberate act, and like any act it can be done well or badly, practised or neglected. The phrase “based solely on reason and evidence” is the demanding bit, because most of the decisions a technical leader makes under pressure are not made on reason and evidence at all. They are made on precedent, on whoever spoke first, on what would be least awkward to say in front of the room. None of those are reasoning. They are shortcuts that occasionally land on the same answer reasoning would have reached, which is precisely what makes them so easy to mistake for it.

Examine the Assumption Before You Commit

The incident I opened with is really a story about an unexamined assumption doing the driving. The book is direct about where the work has to happen.

To foster critical thinking, we must be willing to examine our assumptions critically to see if they are accurate and serve a practical purpose. Remember, you cannot assume anything is true unless you have reviewed it thoroughly.

Every significant technical decision sits on a foundation of assumptions, and most of the expensive mistakes I have seen were not failures of intelligence but failures to check that foundation. We assumed the traffic would grow the way last year’s did. We assumed the third-party service had the uptime its marketing page claimed. We assumed the requirement meant what we thought it meant, and shipped six weeks of work before anyone tested that assumption against the person who wrote it. The assumption was invisible precisely because everyone shared it, and a belief that everyone in the room holds does not get argued, it gets built on.

There is a cost to this discipline, and the book is honest about it, as a companion quote makes clear:

When we make an important decision, it is worth taking time to examine our assumptions and act based on accurate information and valid arguments. Yes, it involves a bit of extra work. But after all, Socrates died for his right to question falsehoods.

The Socrates line is a little grand for a sprint planning session, and I suspect it is meant to be. The serious point underneath it is that questioning the comfortable, agreed version of events is genuinely uncomfortable work, and it is the first thing a busy team drops. The “bit of extra work” is the cheapest insurance you will ever buy. Thirty seconds of “wait, how do we actually know that” up front is worth more than the hour it saves you at the far end, and far more than the reputation cost of a confident decision that turned out to rest on nothing.

You Will Be Wrong, Often

If examining assumptions is the practice, this next quote is the mindset that makes the practice bearable.

A genuine critical thinker knows they will be wrong about things. Often. They also possess the cognitive maturity to re-examine their assumptions and get it right the second time.

I appreciate the bluntness of “Often.” It is not “a genuine critical thinker is occasionally mistaken in edge cases”. It is a plain statement that being wrong is the normal condition, and that the skill is not avoiding it but noticing it quickly and correcting course without drama. This is difficult for technical leaders specifically, because so many of us were promoted on a reputation for being right. The higher you climb on that reputation, the more expensive it becomes to admit a mistake, and the more tempting it becomes to defend a bad call rather than revise it.

The phrase “cognitive maturity” is doing real work there. It frames the ability to say “I was wrong, here is the better answer” not as a weakness to be hidden but as a sign of a mind that has grown up. I have written more about this idea, and where it comes from, in my post on Adam Grant’s “Think Again”, which makes the same case at book length: that rethinking is a skill you can build, and that the confidence to hold your own conclusions loosely is a strength rather than a wobble.

Humble Enough Not to Be the Expert

The book is clear that being a good thinker is less about horsepower than about a particular kind of humility.

A critical thinker is humble enough to confess they are not experts on every issue, nor can they be. You should be willing to listen openly to the ideas of others, even (or especially) if they challenge your conceptions.

The “nor can they be” is the merciful part. Nobody can be an expert on everything, and the sooner a leader stops performing that they are, the sooner their team can actually help them. The tell, in a technical organisation, is what happens when someone junior challenges a senior person’s design. In a healthy team, the senior person gets curious. In an unhealthy one, they get defensive, and everyone watching quietly learns that challenging the expert is a bad career move.

The deepest critical thinker is not necessarily the smartest person. Rather, critical thinkers tend to be smart, talented individuals with certain personality traits. These include open-mindedness, humility, and empathy.

Open-mindedness, in practice, is not a vague willingness to hear people out. It is the concrete act of letting your view actually change when the evidence tells you to, which is much harder and much rarer. I have written a whole post on the willingness to have your mind changed, because the failure mode here is so common: leaders who listen politely, wait for the other person to finish, and then do exactly what they were always going to do. That is not open-mindedness. It is patience wearing open-mindedness as a disguise, and teams see through it fast.

Do Not React Immediately

Two of the book’s quotes are really about the same enemy, which is speed dressed up as decisiveness.

When things do not go according to plan, do not react immediately. This is how we make mistakes. Take a walk outside. Meditate if you are into that. Then go back to the planning stage.

Our industry has a complicated relationship with this advice, because so much of the culture rewards the fast responder: the person who is first into the incident channel, first with a theory, first to push a fix. Speed is sometimes exactly right. But the instinct to react immediately when things go wrong is also how a team turns a small problem into a large one, and the book is right that the antidote is often just a pause. “Go back to the planning stage” is a lovely, unglamorous instruction. It says the fastest route through a problem is frequently to stop moving towards it for a moment.

Anger is incompatible with critical thought. When we are angry, we tend to lash out to relieve ourselves from uncomfortable emotions. The trouble is that we do not weigh the consequences of our actions. When we act out of anger, we end up in a worse situation than before.

This is where the stakes stop being purely technical. The most damaging decisions I have watched leaders make were not made in ignorance; they were made in anger, in the heat of a failure, reaching for a person to hold responsible rather than a process to fix. I have written before about what happens when a team reaches for blame instead of a cause, and the mechanism the book describes is exactly it. Anger wants relief, and the fastest relief is to lash out. It almost never weighs the consequences, and it almost always leaves you somewhere worse than you started. A leader who can feel the anger, name it, and decline to act on it until it has passed is worth a great deal more than one who is merely quick.

Judge the Argument, Not the Person

This is the quote I would most like to see pinned above every architecture debate and every code review.

Intellectual integrity is the ability to treat the arguments of others fairly. Other people may indeed be ill-informed or biased in their analysis. However, if we are honest, our analysis is also not wholly pure.

The last sentence is the one that stings, in the good way. It is very easy to spot the bias in someone else’s argument and very hard to grant that your own is not “wholly pure” either. In a technical setting, this shows up as the quiet weighting we apply to who is speaking. The same design suggestion is received completely differently depending on whether it comes from the principal engineer or the person who joined six weeks ago, even when the words are identical. That is a bias, and it is expensive, because the six-week joiner is often the only person in the room who has not yet learned which questions are not supposed to be asked.

When we practise true intellectual integrity, we put aside our biases about the other person’s intellectual or moral inferiority. Instead, we judge the argument on its own merits.

Judging the argument on its own merits sounds obvious until you try to do it consistently, at speed, about ideas you did not come up with, proposed by people you find difficult. It is one of the disciplines that separates a team where the best idea wins from a team where the highest-status idea wins, and those two teams produce very different software over time. This is also why it matters so much who feels safe enough to bring the dissenting idea in the first place; intellectual integrity in the leader is what makes it rational for everyone else to speak up.

Connect the Parts Into One Framework

Scrutinising individual claims is only half of critical thinking. The other half is assembling them into something coherent.

Critical thinkers gather and categorize evidence data relevant to their problem to gain relevant knowledge. As different elements of the problem and its potential solution are understood, critical thinkers connect an issue’s disparate parts into one workable framework.

This is systems thinking described from the inside. A hard technical problem is rarely a single fault with a single cause; it is a set of related pressures, constraints, and half-facts that only makes sense once you can hold them together as one picture. The skill the book is pointing at is the move from a pile of observations to a framework that explains them, and it is a genuinely different activity from collecting the observations in the first place. I have written more about this way of seeing a system as a whole rather than as a heap of parts in my post on “Thinking in Systems”. The leaders who are good at it tend to ask, early and often, “how do these pieces fit together”, while everyone else is still arguing about the pieces one at a time.

Be Willing to Challenge Common Sense

For anyone whose work involves inherited systems, this one lands hard.

A disruptive plan is an exercise in critical thinking. To replace a current model, you will first examine it and assess its weaknesses and strengths. Next, you will design a more efficient plan, disregarding traditional "common sense" models.

Notice the order the book puts things in. Before you design the replacement, you first examine the current model and assess its strengths as well as its weaknesses. That sequence is the difference between thoughtful modernisation and the far more common urge to tear something down because it is old and unfamiliar. “Common sense” in a legacy system is often a set of decisions that made complete sense in a context nobody remembers any more, and the critical-thinking move is neither to worship those decisions nor to sneer at them, but to understand why they were made before you overturn them. I have written at length about doing this well, rather than destructively, in my post on “Kill It With Fire”. The strong version of disruption is not “this is old, so it is wrong”. It is “I understand exactly why this was built this way, and here is a better answer for the world we are actually in now”.

Empathy Is Not Sympathy

This is the quote I did not expect to find in a book about critical thinking, and it turned out to be the one I have thought about most.

In the context of critical thinking, empathy refers to your ability to understand how others think and why.

Empathy, framed this way, is not a soft skill bolted onto the side of good thinking. It is a thinking tool. Understanding how another person reasons, and why they hold the view they hold, is how you stress-test your own conclusion against the strongest version of the opposing one rather than a strawman. But the book then draws a careful line that I think a lot of leaders get wrong:

Sympathy involves identifying with another individual or group to the point that you can feel what they do. A deep sympathy may indeed impinge on your critical thinking by forming an emotional bias. Instead, you should cultivate the ability to understand what another is feeling and why.

The distinction is that empathy understands the other person’s state, while sympathy climbs inside it, and once you are inside it you have inherited its bias. This maps almost exactly onto something Brené Brown argues in “Dare to Lead”, where she describes empathy as connecting to the feeling under an experience, and warns that jumping into the hole with someone who is struggling just leaves two people stuck in a hole. A leader who over-identifies with an upset team, or with a single loud customer, or with the engineer who is convinced the rewrite is the answer, has quietly handed their judgement to someone else’s emotional state. The skill is to understand what the other person feels and why, completely, while keeping enough distance to still think.

I have spent more time on this particular distinction than most, because it is a topic I have explored on The Modern .NET Show more than once. It was the whole subject of an episode on empathy, sympathy, and compassion for our users, and it came up again in a conversation with Safia Abdalla on compassionate coding in open source. The through-line of both, and of the book, is that caring about people and thinking clearly about them are not in tension. They only feel like opposites when you confuse understanding someone with surrendering your judgement to them.

A Strong Idea Needs a Strong Strategy

The book saves one of its shortest lines for a point that undoes a lot of technical decision-making.

A strong idea is successful if fitted into a strong strategy.

Our industry is not short of strong ideas. It is short of strong ideas that were carried through by a strategy good enough to make them real. I have lost count of the technically excellent decisions I have seen fail, not because the thinking behind them was wrong, but because there was no honest plan for how the organisation would actually adopt them, resource them, and live with them a year later. A brilliant architecture with no migration strategy is a brilliant way to get stranded halfway. The clearest thinking in the world still needs somewhere to land.

That, in the end, is most of what a good technical decision is: examine the assumption, expect to be wrong sometimes, refuse to act out of anger, judge the argument rather than the person, and then wrap the resulting idea in a strategy strong enough to survive contact with a real organisation. It is unglamorous, learnable, and far more valuable than being the fastest person in the incident channel. If you are weighing up how your own team makes its most important technical decisions, and whether the thinking behind them is as disciplined as the code, a consultation might be a useful place to start.