Learning Starts With “I Don’t Know”

Brian Manwaring

“I don’t know” may be one of the most useful sentences in an organization. Not because it demonstrates humility, and not because leaders are supposed to be comfortable appearing vulnerable. It matters because, when it is accurate, it tells us where knowledge ends. That boundary gives us an honest place from which to begin.

A person who knows what they do not know can investigate, ask for help, find data, learn a skill, bring in expertise, or decide that they know enough to act. A person who does not know and cannot recognize that condition presents a much harder problem. So does a person who does not know but feels obligated to provide an answer anyway.

The problem is not ignorance. We are all ignorant of far more than we know. The problem is failing to recognize where the boundary lies. There is a meaningful difference between knowing something, believing something, assuming something, and having no idea. There is also a difference between not knowing the answer and not knowing how to find it.

Sometimes “I don’t know” exposes a knowledge gap. Sometimes it exposes a capability gap. Sometimes the missing piece is training, access, data, authority, time, or some other resource. Sometimes the person knows more than they think they do. And sometimes the answer simply cannot be known with enough confidence to justify pretending otherwise.

That is why I do not think “I don’t know” should either be punished or celebrated. If a manager tells me, “I don’t know why we missed production yesterday,” I can work with that answer, but I need to know what it means. Have they looked at downtime, staffing, material availability, and output? Have they narrowed the problem but not found the cause? Do they know the cause but not the solution? Or do they not know where to begin?

Those are very different conditions.

If the person never received the training required to solve the problem, that matters. If the necessary information does not exist, that matters. If another reasonably capable person with the same tools and opportunity would probably have solved it, that matters too. At some point, after we have considered tools, training, information, environment, and reasonable opportunity, repeated inability to solve problems expected of the role becomes a capability question.

Honesty does not erase capability requirements. A person can be completely truthful and still be unable to carry a particular responsibility. In that case, “I don’t know” has still been useful because it has made the real problem visible.

“I don’t know” also has a sibling: “I can’t.” The first exposes a boundary of knowledge; the second exposes a boundary of execution. “I can’t” may mean I do not know how, lack authority or resources, have too much competing work, or simply do not have the capability the responsibility requires. The phrase does not tell us why the boundary exists. It merely makes the boundary visible.

Organizations become less intelligent when people learn to hide those limits. Instead of saying, “I don’t know,” they offer a plausible explanation. Instead of saying, “I cannot get all three of these things done,” they promise all three and quietly allow one to fail. Instead of saying, “I don’t know how to do this,” they attempt it badly and hope nobody notices.

The organization may appear more confident, but it has not become more capable. An exposed unknown invites investigation. A disguised unknown can stop investigation before it begins.

That puts an obligation on leaders. If every question from the boss carries an expectation that an answer must immediately follow, people will learn to provide answers whether or not they actually possess them. At the same time, “I don’t know” cannot become an escape from responsibility. It is a legitimate starting point, but usually not a legitimate stopping point. Once the gap becomes visible, something should happen.

Years ago, I had an employee responsible for important parts of our IT environment. Eventually he left the company. Later, we had a server problem I could not solve. I worked the problem until I reached the end of what I knew how to do, and eventually I called the former employee and paid him to help us.

The obvious lesson would have been that I now knew who to call the next time the server failed. That would have solved the technical problem, but not the organizational one. The better question was not simply, “How do I fix this server?” It was, “Why did critical knowledge leave the company with one person?”

The server failure exposed a dependency we had not adequately understood, so we changed the system. We created outside IT support so the company would no longer depend on one person in quite the same way.

My “I don’t know” had exposed more than my own technical limitation. It exposed something the organization did not know about itself.

Organizations contain enormous amounts of knowledge that never appears on an organizational chart, job description, or procedure. Sometimes we discover it only when someone is absent, promoted, transferred, terminated, or retires. Everything works until the person carrying an invisible piece of the system is no longer there. Then the organization suddenly discovers what it did not know.

But ignorance does not always hide behind failure. Sometimes competence hides it.

I once had a manager responsible for a paint system that periodically went down. He was good at getting it running again. When the system failed, he could work through the immediate problem, spend a few hours repairing it, and restore production. That was genuine capability.

One day I told him I wanted him to spend as much time asking why the failure kept happening as he expected to spend fixing it. He objected, reasonably, that we might lose an entire day of production instead of half a day.

I told him I would own that consequence.

The extra investigation exposed a deeper issue. We had been repeatedly treating a symptom. We knew how to recover from the failure, but we did not understand why we kept having to recover. Because the manager was good at getting us running again, the unresolved question had become easier to tolerate.

A reliable workaround can conceal an important unknown.

That is why patterns matter. One failure may be noise. Repeated failures are different. Good data can tell us whether the pattern we think we are seeing is actually there. Pareto analysis, statistical process control, trend data, and reporting can help separate recurring problems from isolated ones.

But data does not explain itself. Knowing that one category causes most of our downtime is not the same as knowing why that category is failing. A control chart may tell us that a process has changed without telling us what changed it.

There is real progress in being able to say, “We know there is a pattern, but we do not yet know why.”

Sometimes the problem is that the data does not exist. In some positions I had enough access to systems that I could build reports and write SQL queries to find patterns myself. In other environments, I have not had that luxury.

There is a meaningful difference between “I don’t know because nobody has looked” and “I don’t know because the organization has not given us a practical way to know.” If leadership expects someone to answer a question, leadership has some obligation to provide reasonable resources with which to answer it. That may mean training, data, time, access, authority, equipment, people, or outside expertise.

It does not mean every unknown deserves unlimited resources. Knowledge has a price, and sometimes the value of knowing does not justify the cost of finding out.

Even when the organization is willing to pay that cost, some uncertainty remains.

I learned that while trying to forecast at Powder River. Ownership understandably wanted to know what the following year would look like. Those conversations often happened around October, when I barely felt comfortable predicting where the current year would finish.

I did not think “nobody can predict the future” was a useful answer, so I tried to make the uncertainty smaller. I built a forecast, looked for external market indicators that appeared to move with our business, and found one future that historically had roughly a 70 percent correlation with our results. I showed ownership the assumptions, the indicator, and the spreadsheet behind the forecast.

What I was really saying was that this was my best estimate, this was why I believed it had value, and this was why it might still be wrong.

Then COVID happened, and the relationship stopped working. Stimulus money changed discretionary purchasing behavior in ways the previous relationship with beef prices did not capture. The model that had once given us useful information no longer gave me enough reason to trust its output.

At that point, continuing to produce the same forecast would not have demonstrated confidence. It would have demonstrated false precision.

I told ownership that I could no longer provide what I considered a reliable prediction from that model. We could still build a budget, make decisions, and decide what risks we were willing to take, but we needed to understand that we were now operating with much less predictive confidence.

Ownership responded by putting a farm-economics expert on retainer. At first we consulted with him monthly and later quarterly. That did not make the future knowable. It gave us better resources with which to think about it.

Leadership owes people reasonable resources to answer the questions it expects them to answer. It does not owe them certainty, and reality does not owe leadership an answer simply because leadership wants one.

A forecast is not a plan. A forecast is an estimate of what we think will happen. A plan is a decision about what we intend to do. When confidence in the forecast deteriorates, the obligation to decide does not disappear.

A leader may need to say, “I do not know this with the confidence I would like. Here are the assumptions I am using. Here is what I believe. Here is what could make that belief wrong. And this is what we are going to do.”

There is nothing indecisive about that.

The goal is not certainty. The goal is enough justified knowledge to carry the responsibility of the decision.

That standard works in the other direction too. Sometimes people say “I don’t know” when they actually know enough. A manager may tell me they do not know what to do, but when I begin asking how they are thinking about the problem, I may discover that they understand the facts, have identified the likely cause, know the available choices, understand the risks, and already have a reasonable recommendation.

What they lack is not knowledge. They lack confidence in their own judgment.

If I solve the problem for them anyway, I teach them that when uncertainty becomes uncomfortable, responsibility moves upward. Sometimes the right response to “I don’t know” is to teach. Sometimes it is to work through the problem together. Sometimes it is to provide another resource or insist on deeper investigation. And sometimes the correct answer is simply, “You know enough. Decide.”

The leader's job is not merely to make people comfortable exposing their limits. It is to help them discover where those limits actually are. All of us have blind spots. We sometimes think we understand things we do not. But the reverse is also true. People can believe they are incapable of something they are already capable of doing.

Development requires better calibration in both directions. I need to discover where I know less than I think I know, and I need to discover where I know enough to act.

That becomes more important as authority increases. The more freedom someone has to act without prior approval, the more important it becomes that they recognize when they have reached the edge of their knowledge. High capability does not make “I don’t know” unnecessary. It raises the cost of getting it wrong.

None of this means we should investigate forever. Investigation can become avoidance just as easily as certainty can become arrogance. There comes a point where additional information is unlikely to change the decision. At that point, continuing to study the problem may simply postpone responsibility.

Somebody still has to decide.

The purpose of “I don’t know” is not to delay that moment. It is to make sure the decision begins from reality.

That is why learning starts with “I don’t know.” Not because ignorance deserves praise, and not because leaders need to prove they are humble. It starts there because an accurate “I don’t know” tells us where we actually are. Only then can we determine whether we need knowledge, training, data, resources, another person’s expertise, a better question, or simply the courage to act on what we already know.

The dangerous organization is not the one where people occasionally say, “I don’t know.” It is the one where nobody needs to.

In that organization, the unknowns have not disappeared. They have simply learned how to sound like answers.