Expertise Is Overrated. Problem Solving Is Not.

A Simple Wire, A Familiar Lesson

The other day, I had to extend an electrical wire at home. I am not an electrician, but I am an engineer. So, I did what we do best: watched a few videos, selected the right materials, and planned the operation. In the end, it worked. Better, in fact, than the sloppy wiring job done by the former owner, a professional in construction, mind you.

This did not make me an expert. I had no illusions about that. I did not need to learn how to build a complete circuit board or plan grounding for the entire house. I identified the problem, reached out for information, and matched a short, focused period of self-training to a specific need. Outcome: problem solved, a few new things learned, and more autonomy gained. A quantum of growth.

The Illusion of Expertise in Tech

And this got me thinking…

Becoming an expert in a specific skill or framework that becomes outdated within five years is, in truth, not the wisest investment. The tech industry is littered with graveyards of yesterday’s silver bullets. Today it is Kubernetes, tomorrow it is something else. Instead, what endures is the ability to recognise patterns of challenges, categorise them at a conceptual level, and understand the paradigms most appropriate to solve them.

That kind of thinking is timeless. It transcends tools, frameworks, and hype cycles. It also brings far more value to an organisation, because it builds resilience, adaptability, and sound judgement.

In IT, we have built a culture where expertise has become a prison. Everyone is a “Senior Scala Developer,” a “React Expert,” a “Java Craftsman,” a “Python Engineer.” Titles and tools have become identities. And with them, come rigidity.

Each hire locks us into a stack, a framework, a set of assumptions, often at the cost of adaptability.

We have lost sight of the core mission: solving problems.

Real Engineering: Diagnosis First

It is sometimes better not to know about the box. It makes it easier to think outside of it. Today, many engineers unconsciously restrict their creativity by clinging to the comfort zones defined by their expert skills. They become prisoners of the very golden towers they have mastered: the frameworks, languages, and paradigms that once enabled them now quietly limit them.

True engineering begins where certainty ends. Not with the tool you know best, but with the problem you do not yet understand.

As Alan Kay once said, "A change in perspective is worth 80 IQ points.". A timely reminder that the best solutions rarely come from the same place the problem was created.

Solving Problems, Not Just Writing Code

Solving problems means more than writing code. It requires the ability to:

• Identify the surface of the problem (what is visible, what is symptomatic, what is merely noise);
• Formulate what success looks like: how do we know the problem is solved?
• Define measurable criteria for progress: what are the signs we are moving in the right direction?
• Understand constraints of time, risk, environment, and people.

When I wired that cable, I did not simply copy a video. I paid attention to the tools available, safety aspects, margin for error, and the design of the existing circuit. I approached the work like an engineer: not by becoming an expert, but by understanding the shape of the problem and acting deliberately within its constraints.

Certification Does Not Equal Capability

Contrast this with what we see every day in tech: a flurry of certifications, LinkedIn badges, and courses completed in three weeks that magically produce “experts.” Three weeks of Python and a Coursera badge? Welcome to senior backend engineering. One bootcamp later and you are leading a refactor.

It is not that learning is bad. Quite the opposite. But learning should sharpen your ability to reason, not inflate your title. It should help you see problems more clearly, not trap you into defending one solution space.

Let me offer a fact that often gets overlooked: most software problems are not technical. They are mismatches. Between what the user needs and what the system does. Between what is promised and what is delivered. Between the surface of the problem and the shape of the solution.

I once worked with a team that brought in a React specialist to improve performance. He certainly knew React. But the root issue was not in the front end . It was the data model and the latency of upstream APIs. The expert optimised the wrong thing, beautifully. Because nobody had taken time to explore the problem properly. The mismatch persisted.

Tool Worship Is Not a Strategy

Let us stop pretending that hiring a “Kubernetes ninja” or “AWS magician” will fix anything. The only magic that matters is disciplined problem solving. The rest is theatre.

You do not need to be an electrician to fix a wire, just as you do not need to be a certified X engineer to write good software. What matters is curiosity, discipline, and the willingness to learn what the problem demands.

Let us stop hiring for tools. Let us start building teams who know how to diagnose, reason, and adapt.

That is real engineering.

Less Noise, More Clarity

Let us be honest. In the real world, experts do not brag. They solve. Quietly. Effectively. And when they do not know, they ask smart questions. That is what we should aim for. Less noise. More clarity.

Because in the end, the goal is not to be an expert. The goal is to be useful. And useful people do not hide behind frameworks. They face problems and make them go away.

Hire minds, not toolkits. Value learners, not label holders.