A powerful thing a tech lead can say isn't an answer. It's an honest admission — about your team's code, about AI's trajectory, about a world in crisis — followed by the only thing that matters: what you do next.
There's a version of tech leadership that never actually exists but haunts every leader anyway: the person who has seen every edge case, knows where the technology is heading, understands the macro forces shaping the business, and fields every question with calm, grounded certainty.
It's a fiction. And quietly chasing it is one of the most corrosive things a leader can do.
The real job — leading developers through ambiguous problems, positioning teams in the face of transformative technology, making business decisions while the world keeps breaking in unpredictable ways — requires a completely different posture. It starts with saying three words without flinching: I don't know.
Why Leaders Resist Saying It
The fear is understandable. You got the role because you were sharp. Your team looks to you. Admitting ignorance feels like handing back your credentials in front of everyone who gave them to you.
But engineers are a perceptive group. They know when an answer is being improvised. They can feel the difference between grounded confidence and performed certainty. And nothing erodes trust faster than a leader who bluffs — especially when it costs the team direction, time, or morale.
Faking knowledge doesn't protect your authority. It slowly transfers it to whoever actually knows.
Admitting "I don't know" is one of the highest-signal things a leader can do. It tells your team that you operate in reality — that their trust is well-placed because you won't lead them off a cliff to protect your ego.
But the admission isn't the end. It's an opening move. Three areas, in particular, are where honest not-knowing is most consequential right now.
Your Team: The Daily Not-Knowing
At the most immediate level, this is about the problems that land on your desk every morning: the architectural decision someone needs a call on, the production incident whose root cause is unclear, the technical direction your team is asking you to set on a system you haven't touched in six months.
In this context, "I don't know" is a team-safety tool. When a lead normalises it, developers stop pretending too. They surface problems earlier. They ask questions instead of grinding silently for two hours. They admit blockers instead of heroically absorbing them.
When you don't know → concrete alternatives
| # | Move | What it sounds like |
|---|---|---|
| 01 | Name who does know | "I don't know, but Sarah has been closest to that service — let's pull her in." Directing to expertise is leadership, not deferral. |
| 02 | Define the investigation | "I don't know, but I think the answer is in the caching config. Can we spike on it this afternoon?" Turn fog into a task. |
| 03 | Reason out loud together | "I don't know — walk me through what you're seeing and let's think it through." Your value isn't always the answer; it's the thinking process. |
| 04 | Surface the systemic gap | "I don't know — and that's a signal we have a documentation problem worth fixing." Use your ignorance diagnostically. |
The whole team starts operating in reality rather than in the performance of competence — and reality, however uncomfortable, is a much better place to build software.
AI: The Impact No One Can Honestly Quantify
Then there's the larger question your CTO, your board, your reports, and your peers are all asking — the one that gets dressed up in confident slides and frameworks but remains stubbornly, genuinely open: what does AI actually do to how we build software, and how we work?
The honest answer, right now, is that nobody knows.
We have data points. AI coding assistants measurably change output velocity in some contexts. Some categories of junior tasks look automatable; others that seemed automatable turned out to require more human judgment than assumed. Certain roles are being restructured; others are being amplified. The second and third-order effects — on team structure, on the value of different skills, on how we hire and what seniority means — are genuinely unresolved.
Any leader who tells you they know exactly what AI will do to their team in two years is either guessing confidently or selling something.
This is not a reason for paralysis. It's a reason for a particular kind of leadership: one that acknowledges the uncertainty explicitly, moves deliberately rather than reactively, and builds in the organisational capacity to adapt as clarity arrives.
What "I don't know" looks like on AI strategy
- Run time-boxed experiments with clear hypotheses instead of committing to wholesale transformations based on hype
- Tell your team honestly: "We're going to try this, observe what changes, and adjust — we're not doing a big bet we can't reverse"
- Resist pressure to make confident AI roadmap calls purely for optics; say "we're still learning" to stakeholders when that's true
- Watch the teams two years ahead of you on adoption and study what they're actually saying now vs. what they said then
- Invest in the capabilities that remain valuable regardless of how AI develops: systems thinking, communication, judgment under ambiguity
The leaders doing the most honest, useful work on this right now are the ones who've stopped trying to predict AI's impact and started building teams good at navigating whatever it turns out to be.
The World on Fire: Crises That Reach Your Sprint Board
And then there's everything else.
Tech leads used to be able to bracket the world's problems at the office door. That boundary has been dissolving for years — and in the current moment, it's essentially gone. Supply chain shocks affect infrastructure budgets. Geopolitical instability affects where you can hire and what data sovereignty rules apply to your systems. Economic turbulence reshapes what your company thinks the engineering team should be building. Social crises affect your team members directly, and expect leadership to notice.
None of this has clean answers. The honest position is that most leaders — most people — don't know how these crises resolve, what the downstream business effects will be, or exactly what the right response is. Pretending otherwise doesn't help your team. It insults their intelligence.
Your team doesn't need you to have solved geopolitics. They need to know you're not pretending it isn't happening.
Crisis uncertainty → alternatives to false confidence
| # | Move | What it looks like |
|---|---|---|
| 01 | Name the uncertainty in planning | Build explicit contingency into roadmaps. "This timeline assumes current conditions hold; here's our branch if they don't." Uncertainty acknowledged is uncertainty managed. |
| 02 | Separate "I don't know" from "we're watching" | Distinguish between things you're genuinely uncertain about and things you're actively monitoring. Give your team a sense of the signals you're tracking even when you can't give conclusions. |
| 03 | Acknowledge impact without performing solutions | When crises affect team members directly, you don't need a policy or a fix. Sometimes "I see this is real and I don't have the answers" is more valuable than a five-point plan. |
| 04 | Influence decisions above you with honest data | When the business is being steered by false certainty about external conditions, your job is to put accurate uncertainty on the table — even when that's unwelcome. Especially then. |
| 05 | Prioritise reversibility | When the environment is genuinely unpredictable, bias toward decisions that can be undone. Make "how reversible is this?" a standard question in planning when the context is volatile. |
The Second Half of the Sentence
Across all three registers — your team, the technology, the world — the structure is the same. "I don't know" is never the complete sentence. It's always followed by momentum.
"I don't know — but here's how we're going to move anyway."
That pivot is everything. You're not outsourcing the problem or performing helplessness. You're modelling how a technically mature, psychologically honest person handles uncertainty: they acknowledge it, then they act on it. They find what they can know. They reduce the blast radius of what they can't. They keep moving.
There's a kind of confidence that doesn't depend on having the answers. It's the confidence that comes from trusting your ability to navigate uncertainty — to find information, connect people, ask the right questions, and make reasonable calls under ambiguity. That's the confidence your team needs from you. Not omniscience. Not a human forecast engine.
Just someone who can say "I don't know where we are" without panicking — and then get out the compass.
The best leads I've worked with share one trait: they made it feel completely ordinary to not have an answer. And they made it equally obvious that not having one was never the end of the story. Just the beginning of figuring it out together.
That combination — honesty first, momentum second — is what leading a team looks like when the world keeps changing faster than any of us can confidently predict. Which, as far as I can tell, is the world we're in now.
Top comments (0)