Most of us work in environments where competence is assumed. In technical roles especially, you’re often surrounded by people who know a great deal — and who, at least some of the time, are looking to you to know a great deal as well. You’re expected to have an opinion, to offer a recommendation, to spot the risk, to explain the system, to steady the room when something goes wrong.
So it’s worth asking, plainly: how does it feel to say “I don’t know” in that context?
For many of us, it feels dangerous. Not because we don’t believe in learning, but because we’ve quietly built a life around being useful, reliable, and credible. We’re the people who are meant to understand. We’re the ones who are meant to deliver.
And yet, a lot of what we do involves uncertainty. Complex systems. Real-world constraints. Unfamiliar domains. Too many moving parts. Too many stakeholders. Too much history. Too much that can’t be known until you’ve tried.
That tension — between expectation and uncertainty — is where this becomes more than a soft skill. It becomes a professional survival skill. And, used well, it becomes a source of real strength.
Junior Developers Get a “Golden Ticket”
There’s an obvious asymmetry here.
Junior developers can ask basic questions and be praised for it. They’re new. They don’t yet have a reputation to protect. In fact, asking a clear, honest question often builds their reputation: it signals self-awareness and a willingness to learn.
For established developers, it’s different. Once you’ve been “the person who knows”, you start to feel you must keep being that person. Perhaps you’ve become the local oracle for some stack or domain. Perhaps people come to you because you’ve always had an answer. Perhaps you enjoy that feeling, as most humans do.
In that situation, saying “I don’t know” can feel like it threatens something you’ve quietly invested in over years. Not just your standing, but your identity at work. You may worry about looking junior. You may worry about losing credibility. You may worry you’ll disappoint someone who expects certainty from you.
The common workaround is subtle: deflecting instead of admitting uncertainty. “Read the docs.” “Look it up.” “There’s a book on that.” Sometimes those are good suggestions. But sometimes they’re also a way of saying, indirectly, I don’t actually know either.
The Real Problem Isn’t Not Knowing — It’s Pretending
The goal isn’t to normalise ignorance. It’s to normalise reality.
The danger in many technical cultures isn’t that people don’t know. It’s that people pretend to know, and the system quietly absorbs the cost. Confusion persists. Bad assumptions remain unchallenged. Work proceeds based on false certainty. Teams become hesitant to surface risk. People stop asking the questions that would have prevented the error.
And in a group setting, there’s another effect that’s easy to underestimate: when one person asks for clarity, it often turns out they weren’t the only one. You can watch it happen in real time: someone finally voices what’s been unspoken and you see nods around the room. The room relaxes slightly, because now it’s permissible to admit the thing everyone was feeling.
Sometimes saying “I don’t know” is not a personal confession. It’s a service to the group.
A Case Study in High-Stakes Uncertainty
A useful example comes from a project with TOMRA, a company that builds industrial sorting machines. In simple terms, imagine food moving at speed along a conveyor belt or down a chute. Sensors, cameras, lasers, and classification logic decide what is acceptable and what is not, and jets of air push rejects into a separate stream.
That’s already complex: hardware, software, optics, performance constraints, safety, reliability, and customers who depend on consistent outcomes.
Now add organisational complexity. Like many large companies, TOMRA has grown through mergers and acquisitions. Codebases become layered. Different teams inherit different paradigms. Not everyone is in the same office, or even the same country. Communication patterns drift. The product continues working, but the system becomes brittle; harder to extend, harder to change, harder to reason about.
Over time, people understandably start to say: “If only we could do this properly. If only we could rewrite this with what we’ve learned.”
Eventually, management agreed. They funded a major rebuild. The team was given budget, freedom, and an ambitious remit — and with it came attention. Not just local attention; company-wide attention. Eyes were on the team. Expectations were high.
And that’s where the familiar pattern shows up: the “golden ticket” becomes a weight.
Because starting from scratch is not the same as extending an existing codebase. When you can choose tools, practices, architecture, hiring, and the entire shape of the system, the space of possible mistakes expands dramatically. The need to “choose correctly” becomes intense. Teams can end up researching for months, trying to eliminate uncertainty before they begin, because the cost of a wrong decision feels enormous.
That is how analysis paralysis happens, even in very capable teams.
It’s not laziness. It’s the burden of responsibility paired with the illusion that the right amount of thinking will remove risk.
Why “We Don’t Know” Can Be the Beginning of Progress
What changed the trajectory of that team wasn’t a new framework or a perfect architectural plan. It was a shift in posture:
We don’t know. We can’t know. And we’re going to start anyway.
This is not a call for carelessness. It’s a call for honesty. It’s the recognition that you can sit for another three months doing research and still not truly know, because some knowledge only appears once you’ve built something and watched it behave.
So the move is to build something small but real: a prototype, an end-to-end slice, a tangible artefact that stakeholders can see, touch, and react to. Not because prototypes are the final answer, but because they change the conversation. It is far easier to critique a real thing than an abstract theory. Real artefacts create feedback. Feedback creates direction. Direction creates momentum.
And momentum matters more than we often admit. It affects morale. It affects stakeholder trust. It affects the team’s ability to keep going when the inevitable difficulties arrive.
Estimation, Anxiety, and the Illusion of Control
One of the most uncomfortable aspects of big, greenfield programmes is estimation. You are asked to make promises about a future you understand least at the beginning.
This becomes almost absurd when a team is given significant budget and asked to plan a year out. The pressure to present certainty grows in proportion to the size of the investment. People want to know what they’re buying. Leaders want to know what to expect. Engineers want to protect their credibility.
But the uncomfortable truth is that the earliest estimates are often the least reliable. There are ways to improve them, but they tend to be the same ways that reduce anxiety: do a small piece of real work, learn from it, and then estimate with more information. Repeat.
What looks like a planning exercise is often better handled as a learning exercise.
Psychological Investment and Why Long Plans Become Brittle
There’s another dynamic that emerges on big programmes: psychological investment.
When you commit to a long-term plan — especially one that has been reviewed, approved, and socially endorsed — it becomes emotionally expensive to change. If a customer or stakeholder later asks for a pivot, it’s no longer just a technical decision; it’s a reputational and political one.
This is why heavy upfront planning can create fragility. It makes adaptation expensive. It makes learning feel like failure.
By contrast, when you explicitly acknowledge uncertainty and commit to short, iterative steps, changing direction is no longer a betrayal of the plan. It is the plan.
Feedback Loops: The Only Honest Way to Navigate Complexity
A useful analogy here is Apollo. The mission had a clear target — the moon — but small errors early could compound into huge misses. The way the trajectory was managed wasn’t by expecting perfection upfront, but by continuous correction through feedback.
A team that can say “we don’t know yet” and then immediately ask “how do we find out?” has a fundamentally different posture from a team that pretends certainty and hopes reality will comply.
This requires a culture where asking for clarity is not treated as incompetence, and where uncertainty is not punished. That culture can be shaped. Often it starts with one person being willing to say the thing out loud.
“I Don’t Know” as a Leadership Move
It’s worth stating plainly: saying “I don’t know” is not just vulnerability. It can be leadership.
It is a way of:
- inviting collaboration rather than performance
- lowering the cost of truth
- making space for better thinking
- turning uncertainty into action through experimentation
- preventing false certainty from hardening into architecture
Used sparingly and responsibly — after doing your homework, after making a genuine attempt — it can be one of the highest-leverage phrases in a technical organisation.
Because it changes what becomes discussable. It changes what becomes testable. It changes what becomes possible.
Forcing Functions: The Practical Mechanism
The idea sounds philosophical, but it becomes real through forcing functions.
Short loops. Small slices. Tangible deliverables. Demos that happen frequently enough that you cannot hide behind theory. Prototypes that are cheap enough to throw away and real enough to learn from. Conversations structured around artefacts rather than opinions.
A surprising amount of “culture” is just the consequence of the loops a team runs. Long loops create performance and politics. Short loops create learning and adaptation. If you want a team that can admit uncertainty without fear, you don’t only change attitudes; you change the shape of the work.
A Quiet Summary
Admitting “I don’t know” is not a lack of professionalism. In many environments it’s the beginning of professionalism, because it aligns language with reality. It makes uncertainty visible, and therefore manageable. It invites feedback. It reduces the cost of correction. It keeps teams moving.
And perhaps most importantly, it creates the conditions where progress can happen without requiring anyone to pretend they have certainty they do not.
If you build systems for the real world, you will not always know. The question is whether you can admit that quickly, and then do what matters next.
Learning by doing is how we learned everything else.
It still works here.