Leading without pretending to know

The first instinct most new CTOs develop is to project certainty. The team is looking to them, the board is looking to them, and uncertainty feels like weakness. So they learn to perform confidence even when they do not feel it.

What takes longer to learn is that the performance is usually counterproductive. The teams that perform best over time are almost never the ones whose leader claimed to have all the answers. They are the ones whose leader was honest about what they did not know, and built an environment where that honesty made things work better rather than worse. After thirty-five years across technical leadership roles, this is the position I have arrived at: not a personality trait, but a considered approach.

---

Uncertainty is not the problem

I have never worked in a period that felt stable and fully mapped. Dot-com crash, financial crisis, Covid, the AI shift. Every era has its version of the ground moving. Uncertainty is not a temporary condition to be managed until things settle down. It is the permanent context for the work.

The problem is the leader pretending not to be uncertain, because the pretence closes down exactly the channels that would help them navigate it. People stop raising the things they are not sure about. Dissenting information gets filtered before it reaches the top. Decisions get made on a narrower picture than the situation requires.

---

Create the conditions, not the answer

I am on the less dogmatic end of the leadership spectrum, and I mean that as a deliberate position rather than an admission. When I involve people in a decision, I am not being collaborative for its own sake. I am trying to surface the thing I do not know yet.

In my experience, the person with the critical insight is rarely the most senior person in the room. It is often the engineer closest to the specific problem, the support person who has been listening to customers, or the junior developer who asked the question nobody else thought to ask. A CTO who has stopped being genuinely curious about what those people think has started making decisions on incomplete information without realising it.

This does not mean treating every decision as a committee exercise. It means building an environment where better information reaches the decision-maker before the decision is made, not after.

---

Hold the direction, not the solution

A team needs something to navigate towards. That is a real leadership function, not a formality. Without a clear direction, people make locally sensible decisions that pull in different ways at the system level. The CTO’s job is to hold that direction clearly enough that people can make their own decisions in line with it, without checking every time.

But holding the direction is not the same as holding the specific solution. I have changed how we were going to get somewhere many times without changing where we were going. Rigidity about method, when the evidence is moving, is not strength. It is a refusal to update. A team can absorb a change of approach far more easily than a leader who will not acknowledge that the current approach is not working.

One version of this played out early in building a connected vehicle platform. The original connectivity architecture used the operator’s mobile application as a relay: BLE to the phone, phone to cloud. The direction was clear: reliable remote control and monitoring across a deployed fleet. The implementation was clean in the test environment and straightforward to build.

As the deployment approached real operational scale, it became apparent that requiring a phone to be physically near each vehicle to relay commands was not viable for a fleet operator managing dozens of units across a site. The architecture was redesigned around a vehicle-mounted cellular module, with BLE retained for short-range direct interaction. The rework took several months and was not what anyone had planned for. What made it manageable was that the team understood exactly what the direction was and why the original approach no longer served it. The redesign was a correction, not a crisis, because the destination had not changed.

---

Make the downside survivable

Encouraging innovation without managing risk is not bold leadership. It is negligence with good intentions.

My approach has consistently been to push for new ideas and new approaches while keeping a clear eye on what happens if a particular bet is wrong. The goal is not to avoid wrong bets. They will happen, and a culture that punishes them will simply stop taking the bets that matter. The goal is to make them survivable:

• Small enough in their initial commitment that the company can recover.
• Staged enough in their execution that problems get caught early.
• Honest enough in their review that the team actually learns from them rather than rationalising what happened.

In practice that usually means trying a new technology in one product line, one market or a small pilot fleet first, with an agreed point at which the results are reviewed and the decision is taken again. If it works, scaling it is straightforward. If it does not, the company has lost a few months and a modest budget rather than its flagship product or a key customer. The discipline is not in avoiding the risk. It is in deciding in advance how large the downside is allowed to be.

The CTO’s specific contribution is understanding the technical downside before committing. Not just whether an idea is good, but what the failure modes look like, how detectable they are, and how reversible the decision is. That is the risk management function, and it belongs in the room at the same time as the innovation conversation, not after it.

---

What this looks like in practice

It looks like asking more questions than giving answers, particularly early in a problem. It looks like a CTO being visibly comfortable saying “I don’t know yet” and then showing they will find out. It looks like changing one’s mind when the evidence warrants it, and being clear about why rather than hoping nobody noticed. It looks like the habit of examining the downside before committing to the upside, not to avoid action but to make action more deliberate.

None of this is comfortable, particularly early in a leadership role when the pressure to project certainty is strongest. But the CTOs I have seen lead well through sustained uncertainty (markets shifting, technologies changing faster than plans can track, organisations that needed rebuilding rather than managing) are almost always the ones who built trust by being honest rather than by performing confidence. The trust compounds. The performance erodes.

---

Four things worth taking seriously

For new CTOs: say “I don’t know yet” when it is true, and then show that you will find out. Performed certainty closes the channels you most need.

For engineering leaders: separate the direction from the method. Hold the first firmly, change the second openly when the evidence moves, and explain why.

For boards: judge a CTO’s appetite for innovation by whether the downside of each bet is sized and agreed in advance, not by whether every bet succeeds.

For anyone leading through uncertainty: the person with the critical insight is rarely the most senior in the room. Build routes for their information to reach you before the decision, not after.

---

I would be interested to hear about a time you changed how you were getting somewhere without changing where you were going, and how your team took it.