Why Smart People Get Stuck

Everyone is training people on tools. Nobody is training them to think when tools break

Somewhere in your organisation right now, someone is staring at a report that worked perfectly yesterday and shows nothing today. They have refreshed. They have closed and reopened. They have tried the thing they tried last time, whatever that was. They are about to raise an IT ticket, or call a colleague, or quietly work around it and say nothing.

They are not incompetent.

They are undertrained. And the training they are missing has nothing to do with the tool.

The conversation most organisations are having

There is absolutely nothing wrong with investing in tool training.

Every organisation that runs on data and digital tools needs people who can use those tools well — Excel, Power BI, Tableau, Teams, SharePoint. The investment makes sense. The returns are real.

The problem is not that organisations train people on tools. The problem is that tool training tends to dominate so completely that a different question rarely gets asked.

Not how to use the tool.

What to do when the tool fails.

Every additional tool an organisation deploys is another potential point of failure. Every workflow that depends on a connection between systems is another place where something can go quietly wrong. As organisations add capability, they multiply complexity. And the people expected to work inside that complexity are, in most cases, equipped only for the smooth version of it.

That is where the invisible cost lives. Not in the failures that get escalated.

In the hours that disappear before the escalation.

In the IT tickets raised for problems that were never IT problems.

In the decisions delayed because a dashboard stopped working and nobody could explain why.

In the meetings called to discuss a data discrepancy that turned out to be a filter left on by one person on one machine.

Multiply those moments across a team over the course of a year, and the number becomes significant. The cost just never appears on a single line in a budget, so nobody adds it up.

And underneath all of it, quieter and harder to measure, is the confidence that erodes every time someone cannot figure out what went wrong. People who are genuinely good at their jobs begin to feel uncertain around technology. They become dependent on the one person in the team who seems to know how to fix things. That dependency, once established, is surprisingly hard to reverse.

The question is not whether this cost is real. Most leaders who pause to think about it know that it is. The question is why so little has been done about it.

We already know this problem. We solve it with people every day.

The irony is that organisations already understand how to close this kind of gap — because we solve a version of it every day with people.

Imagine onboarding a new employee tomorrow. A capable person, well-qualified and motivated. No reasonable organisation would hand them unrestricted access to every system and say: figure it out.

Instead, we give them context. We show them not just what the tools do, but how to think when the tools behave unexpectedly. We build judgment alongside knowledge, because we understand intuitively that knowing a tool is not the same as being able to work with that tool under pressure.

Yet when it comes to formal training programmes, we almost always stop at the tool. We teach people what buttons to press. We build courses around features and functions. And then we send people back to their desks, equipped to use the tool the way the training demonstrated — and largely unprepared for the moment it behaves differently.

That gap between what training covers and what work actually requires is rarely named.

It is just quietly absorbed, one frustrating afternoon at a time.

Two kinds of people

You have almost certainly seen the contrast, even if you have never named it.

Two people encounter the same broken tool on the same afternoon. One spirals — clicking, googling, escalating, waiting, trying the same thing again and hoping the result changes. The other pauses, does something deliberate, reads what the result tells them, and either resolves it or knows precisely what to try next.

The difference is rarely experience with that specific tool. It is rarely seniority. Some of the most technically certified people in an organisation are among the worst troubleshooters, because certification teaches you how the tool works when it works — not how to think when it does not.

The spiral is worth understanding, because most people live in it without realising. It usually begins with confusion, followed almost immediately by action — because doing something feels better than sitting with uncertainty.

The first attempt fails. The second is a variation of the first. The third is the first attempt again, tried with slightly more hope. At some point the person either stumbles onto the answer by accident, escalates to someone else, or gives up.

What almost never happens is a pause.

The people who consistently fix things quickly are almost always doing something different at that first moment of confusion. They slow down. They ask what they actually know versus what they are assuming. They think before they touch anything. That habit — so simple to describe, so rarely practised — is the difference between minutes and hours.

It is almost always something developed through years of working with complex systems, through trial and error, through having someone show them early in their career how to reason rather than react.

Most people were never shown that. Not because they were not capable of learning it.

Simply because nobody thought to teach it.

That gap compounds. Every tool added to the stack makes it wider. Every new system, every new integration, every new workflow creates more surface area for things to go wrong — and more moments where the absence of that thinking habit becomes costly.

A small test can save hours. A clear mind can save careers.

One story. One test. Thirty seconds.

A colleague once sent a message asking whether the server was down. He had not received an expected email, and the server, in his mind, was the obvious explanation. It was a reasonable assumption — but it was still an assumption.

The fastest test was not to check logs or raise a ticket.

It was to send him a test email.

He received it on his phone. Not on his laptop. That single result — before any settings were changed, before any ticket was raised, before any time was spent investigating the wrong thing — eliminated an entire category of causes. The server. The sender. The network. The account. All ruled out in thirty seconds, before touching a single setting.

The same principle applies everywhere.

A Power BI report returning wrong totals for one team but not another.

An Excel formula that works on every row except the ones imported from an external system.

Different tools, different symptoms, identical thinking.

Define what you actually know.

Separate it from what you are assuming.

Run the test that eliminates the most possibilities with the least effort.

What remains is always smaller than what you started with.

That is not a technical skill. It is a thinking habit — and it transfers across every tool, every system, and every failure mode an organisation is likely to encounter.

What that way of thinking actually involves

It starts with a question that sounds almost too simple.

What do I actually know right now? And what am I just assuming?

In the email story, the assumption was that the server was the problem. The knowledge was only that an email had not arrived. Those are not the same thing — and the moment you separate them, the path forward becomes considerably clearer.

From there, the thinking follows a structure. Not a complicated one. Built around identifying all the possible causes before settling on the most likely one.

Around choosing the test that rules out the most at once, rather than the test that feels most obvious.

Around knowing what a result actually proves, rather than what it merely suggests.

That last point matters more than most people realise. A test result is information.

Used carelessly, it confirms a bias.

Used correctly, it eliminates a category.

The difference between those two outcomes is not technical knowledge. It is the discipline to ask: what does this result actually tell me — and what does it not?

That structure transfers across any tool, any organisation, any level of technical complexity. It works on a broken Excel formula and a failed Power BI refresh and a SharePoint permission error and a Teams notification that never arrived. Because it is not about the tool.

It is about how you think when the tool stops cooperating.

And once that habit is built, it does not expire when the software updates.

Perhaps the question is not which tools to train next

Organisations will continue investing in tool training, and they should. New tools will emerge, existing tools will evolve, and the people using them will need to keep pace. That investment is not going away, nor should it.

But perhaps alongside it, there is a different question worth asking — one that most training strategies have not yet found room for.

Not what tool to train people on next. Whether the people being trained have the thinking underneath the tools to work effectively when those tools behave unexpectedly. Whether the capability being built is genuinely resilient — or fragile in exactly the way that becomes visible on a Tuesday afternoon when the deadline is two hours away and the numbers are wrong.

Because tools will always, eventually, behave unexpectedly. And when they do, no amount of product training will matter as much as the ability to slow down, separate what you know from what you are assuming, and find the fastest path to an answer.

The tools will keep changing. New platforms will replace old ones. Systems will be integrated in ways nobody has imagined yet.

The thinking habit, once built, does not expire.

That is what makes it worth teaching.

And what makes it remarkable that almost nobody does.

FYT Consulting builds practical data and AI capability in organisations. If this article has surfaced a question about how your team handles the moments when tools fail — you already know what to do next.