How Often the Answer Is "I Don't Know"

Tech projects always have more questions than answers.

Will this migration work? Will users actually use this feature? Is this architecture the right choice? Will it scale?

And the all-time favorite: how long will it take?

The list never ends.

Will this be automated by AI in three months? What breaks if I change this? Who's even responsible for this part?

The honest answer to most of these is "I have no idea." So the response begins with I guess, probably, hard to say — or the classic it depends, without ever saying what it depends on. Sometimes people say nothing at all, keep their fingers crossed, hope for the best, and move on.

Not knowing is uncomfortable. But high uncertainty is the natural state of tech work. Once you start looking at engineering through that lens, a lot of practices you already know reveal themselves as uncertainty-management techniques.

And this technical part of uncertainty, at least, is solvable — there's a known move for almost every situation. So it's worth tackling this one before stepping into the far more mysterious world of human behaviour in organizations.

Principles of Managing Tech Uncertainty

Most engineers already manage uncertainty. They just don't think of it that way. The daily standup, the spike ticket, the prototype nobody's sure will work — these are all responses to not knowing. Here is a set of principles behind these practices, which will help you understand their true purpose.

Reduce scope. When uncertainty is high, make the problem smaller. Break a large project into smaller ones. Break a difficult question into simpler ones. This is the logic behind MVPs, sprint planning, and incremental delivery. Smaller scope means fewer things can go wrong in ways you didn't anticipate.

Communicate and gather information. Sometimes the fastest path forward is simply asking. You don't know whether another team depends on the API you're about to change. You don't know whether a legal constraint exists that nobody mentioned. Well, have you asked? Communication isn't an overhead cost on top of the "real work." On tech projects, it often is the work: the fastest, cheapest way to close a gap that no amount of solo thinking will close.

Experiment instead of debate. A team can spend days debating whether users need a feature. These conversations tend to go in circles, because nobody has evidence. When the answer isn't already in the room, more thinking won't surface it — you need to go and find it. Build a prototype. Run a spike. Test with users. A/B tests, benchmarks, and proofs of concept all replace debate with data.

Make uncertainty visible. One of the most dangerous things a team can do is sound too certain when they're actually not. We give a single-number estimate when a range would be more honest. We say "this should work" when we mean "I have no idea how this component behaves under load." Uncertainty that's named can be managed, so make it visible: say it out loud, write it down, put question marks on your architecture diagram. Assumption logs, risk registers, estimate ranges instead of single numbers, callouts on your artifacts — these all do the same job.

Shorten feedback loops. The faster reality talks back, the faster you can adjust. Demos, reviews, retrospectives, CI/CD, frequent releases, small pull requests, feature flags, monitoring — these allow you to identify problems quickly and correct the course. A long feedback loop lets errors compound before you see them.

A word on assumptions

Assumptions deserve a special mention because they work differently from the other practices. They don't reduce uncertainty — they let you move forward despite it.

Consider a client asking how long an integration will take. You often genuinely don't know: the API documentation is incomplete, access hasn't been granted, data quality is unknown. You have three options: refuse to answer, make a hidden guess, or state your assumptions. The third is usually best.

Instead of three weeks, you say: three weeks, assuming API access is available on day one and data quality issues are not affecting the workflow. You haven't eliminated the uncertainty — but you've made it visible. You've turned a guess into a conditional commitment.

That's what makes assumptions both powerful and dangerous. Powerful because they let work move forward. Dangerous because teams often forget they made them. A stated assumption that never gets validated starts being perceived as a fact.

A mature team treats assumptions as temporary placeholders. The job isn't just to state them, but to track them and eventually confirm or replace them.

Name your uncertainty

Assumptions are one move. But first you need to know what kind of unknown you're dealing with. What is the hottest question on your project right now? Click on a card and see what helps.

The difficulty of asking the right question

If only projects were as simple as getting answers to these 12 questions. The reality is much more tangled than that. A simple question may hide several layers of uncertainty.

Imagine a client asks a question like this: how long will it take to build a churn prediction for my customer database?

Even though it sounds straightforward, the unknowns start swirling in your head immediately. Is churn even predictable in this dataset? What signals exist? How clean is the data? You haven't seen it yet.

You automatically say it depends. But the client pushes for a number. You say three weeks, but the client can't comprehend why it should take more than one.

So what happens here?

The problem wasn't the estimate. There are several layers of uncertainty here — whether churn is predictable, whether the data is in good shape, which approach makes sense, and only finally, how long implementation will take.

You skipped straight to the last one because that's the question you were asked. But a better answer might have been: one week to assess the data and confirm whether a usable signal exists, then one or two weeks to build and integrate. It's a commitment that's honest about what it depends on.

There are often several strategies needed to deal with uncertainty at the same time. In this example, we would start by reducing it: break the question down and tackle each unknown separately. Not sure about the quality of the data? Schedule a time-boxed spike to assess it. Not sure which model to use? Run a quick comparison on a small sample and see which approaches show promise.

At the same time, we can still move forward despite the remaining uncertainty — through phased delivery, estimate ranges, and explicit assumptions. Good uncertainty management usually requires both: shrinking the unknown and continuing to make progress while some of it still remains.

This was mostly technical uncertainty and decision-making. But the more senior you become, and the more complex the projects you deal with, another type of uncertainty starts becoming more and more prominent. Who owns it? Why did this person make that call? What is the client not telling us about their goals? What is the hidden agenda here?

But this is a subject for another article.