I have never found it useful to separate learning, work, and problem-solving into completely different parts of life.
We are usually encouraged to choose a field, learn its tools, become competent at using them, and then continue solving problems from inside that field. This makes sense when the problem stays neatly within those boundaries. The difficulty is that real businesses rarely behave that way.
A financial problem can begin in operations. An SEO problem can actually be an information problem. A reporting problem can originate in how data is collected. An automation problem may exist because nobody properly understood the process before trying to automate it.
The deeper I went into different kinds of work, the clearer this became.
My approach developed around a simple idea: understand the problem first, then allow the problem to determine what you need to learn, build, question, or change.
When people become good at using a particular tool, they naturally begin looking for places to use it.
Developers see opportunities to build software. SEO specialists look for search problems. Accountants look at financial records. Automation specialists see repetitive tasks. More recently, almost every kind of business problem seems capable of becoming an AI problem.
There is nothing inherently wrong with this. Expertise gives us useful ways of seeing the world. The contradiction begins when the tool starts deciding what the problem is.
A business may ask for automation because a task takes too long, when the real problem is that the task should not exist in its current form. A company may replace software because reporting is unreliable, even though unreliable information is entering the system long before the software receives it.
And what happens as more technology is added to a problem that was never properly understood? The organisation may move faster, but it also becomes harder to see why something is going wrong.
This is why I try to separate problem identification from solution selection.
“The formulation of a problem is often more essential than its solution.”
— Albert Einstein and Leopold Infeld
Before deciding what to build, automate, replace, or optimise, I want to understand what is actually happening, why it is happening, and whether the visible problem is really the problem at all.
My background in finance and auditing shaped much of this way of thinking.
Financial work is often treated as a collection of records, reports, reconciliations, and controls. But a financial number does not appear from nowhere. Something happened in the real business before that number reached a report.
A client placed an order. Someone approved an expense. Money moved. An employee entered information. A system transformed it. Another person classified it. Eventually, management saw a number and used it to make a decision.
If the final number is wrong, correcting the report may make the report look right again, but it does not necessarily correct the system that produced it.
The same problem exists outside finance.
A dashboard is only as reliable as the data behind it. An AI system is only as useful as the information and instructions it receives. An automated workflow can execute perfectly while repeatedly doing the wrong thing.
As organisations grow, these chains become longer. More people become involved. More software is added. More decisions depend on information that has passed through systems nobody fully understands.
That makes tracing the system increasingly important.
My first instinct is therefore not simply to repair the visible output. I try to understand how work, information, decisions, and responsibility move from one stage to another, because that is usually where the real problem becomes visible.
We are usually taught to think of knowledge in categories.
Finance belongs over here. Marketing belongs somewhere else. SEO, software development, data analysis, infrastructure, and AI each become separate professions with their own language, tools, and communities.
Specialisation is necessary. Nobody can understand everything deeply.
But there is another problem: the business itself does not care where one professional discipline ends and another begins.
If a search problem depends on how information is stored, then understanding SEO alone may not be enough. If financial reporting depends on information moving through several operational systems, accounting knowledge alone may not reveal where the failure began. If automation depends on a poorly defined business rule, better code will not make the rule better.
What should happen when understanding the problem requires crossing those boundaries?
In my case, I kept following them.
Finance pushed me toward data because I needed better ways to examine evidence. Repetitive work pushed me toward automation. Automation pushed me toward programming because I wanted to understand and control what the system was actually doing. Research and marketing led toward SEO and natural-language processing. Building applications eventually forced me to understand databases, deployment, servers, and infrastructure.
From the outside, this can look like moving between unrelated interests.
From my perspective, it has mostly been one continuous process of following problems far enough to understand what they connect to.
It is possible to spend a great deal of time learning something without discovering whether you actually understand it.
Books can explain concepts. Courses can show methods. Documentation can tell you how a tool is supposed to work. AI can now explain almost any technical subject within seconds.
This creates an unusual contradiction. Access to knowledge has become easier, while the difference between recognising an explanation and actually understanding the subject has become easier to overlook.
You usually discover that difference when you try to build something.
“What I cannot create, I do not understand.”
— Richard Feynman
A system that looks simple in theory begins exposing assumptions when it has to work with real data, real users, incomplete information, conflicting requirements, and unexpected failures.
That is why building has always been an important part of how I learn.
I usually begin with something practical: a spreadsheet system, a script, an automation, a reporting process, an application, an SEO system, or some piece of infrastructure. Building exposes what I do not understand, which gives me a much clearer idea of what I need to study next.
The objective is not to build everything unnecessarily. It is to make learning answerable to reality.
An idea becomes much more useful once it has survived the experience of actually being used.
Modern software makes it increasingly easy to operate powerful systems without understanding much about what happens underneath them.
For many situations, that is a good thing. People should not need to understand networking before sending an email or database internals before using business software.
The problem begins when operating a tool is mistaken for understanding the thing the tool is doing.
A tutorial tells us which button to press, so we press it. A framework provides an abstraction, so we depend on it. AI writes the code, generates the analysis, or recommends the action, and the result appears convincing enough to continue.
But what happens when the normal path stops working?
The software changes. The API behaves differently. The dataset contains something unexpected. The business grows beyond the assumptions used when the system was built.
At that point, knowledge of the interface is not enough.
I prefer learning the principles underneath the tool: how information moves, what assumptions are being made, where dependencies exist, how failure can occur, and how the result can be verified.
This is slower at the beginning, but it produces a different kind of flexibility later.
Once the underlying principle is understood, changing tools becomes much less threatening. The technology can change without taking the entire understanding with it.
Repetitive work naturally attracts automation.
If something requires ten manual steps, reducing those steps to one feels like obvious progress. With AI and modern automation platforms, businesses can now automate processes that previously required significant technical effort.
But speed and improvement are not the same thing.
If the underlying process is badly designed, automation does not repair it. It simply allows the same process to operate faster, more frequently, and often with less human attention.
A mistake that once happened ten times can now happen ten thousand times.
This is why I do not begin with the question, “Can this be automated?”
I first want to understand why the work exists. What enters the process? What decision is being made? Which exceptions occur? Who is responsible when something fails? Does every step still need to exist?
Sometimes automation is the right answer.
Sometimes the process needs to be simplified before it is automated. Sometimes the best improvement is removing the process altogether.
Useful automation should reduce unnecessary human effort without making the underlying work impossible to understand.
We increasingly work through systems that produce answers for us.
Accounting software produces reports. Analytics platforms produce charts. SEO platforms produce recommendations. AI produces explanations, analysis, strategies, code, and increasingly entire workflows.
The outputs can look precise enough that questioning them begins to feel unnecessary.
That is precisely where the danger begins.
“The first principle is that you must not fool yourself—and you are the easiest person to fool.”
— Richard Feynman
A system can process incorrect information perfectly. A dashboard can present misleading data beautifully. An AI model can produce a convincing explanation that does not survive examination.
The sophistication of the tool does not remove our responsibility for the conclusion.
And as more decisions become automated, that responsibility becomes more important rather than less. If nobody understands where an answer came from, how will anyone recognise when the assumptions underneath it stop being true?
This is why I place a high value on independent judgment.
Use the tool. Let it reduce work. Let it help organise information, find patterns, test possibilities, and expose things that would otherwise be difficult to see.
But keep the ability to examine the evidence, question the assumptions, and decide whether the answer actually makes sense.
Tools should extend judgment, not replace it.
Most systems are designed around the normal situation. The process works when the expected employee is present, the software behaves normally, the integration remains available, the data follows the expected format, and the business remains roughly the same size.
Under those conditions, almost any system can appear reliable. The real test begins when something changes.
What happens when the person who understands the process leaves? What happens when a vendor changes its software? What happens when volume becomes ten times larger? What happens when an assumption made two years ago is no longer true?
If the system works only while its original conditions remain intact, then the business has not removed the dependency. It has simply hidden it.
“A system is not resilient because it works when everything is normal. It is resilient because it remains understandable when something changes.”
— Muhammad Hassan Ali
This changes what I consider a successful system.
It should work, but it should also be understandable. Important decisions should be traceable. Processes should be visible. Failure should be observable. Knowledge should not exist only inside one person's head.
The objective is not to eliminate every possible failure. That would be unrealistic. The objective is to build systems that can change, recover, and continue being understood when reality moves away from the original plan; that is what I mean by resilience.
Long-term planning creates another contradiction.
Without a longer direction, businesses become reactive. They move from one immediate problem to another without knowing what those decisions are supposed to build toward. But the opposite approach can be equally misleading. A highly detailed plan for twenty years from now may look impressive while being based almost entirely on assumptions about a future nobody can predict.
“Plans are worthless, but planning is everything.”
— Dwight D. Eisenhower
I prefer treating vision as something that becomes more detailed as evidence becomes stronger. Start with the highest-level direction and fix the most important things first, then move into execution for the first quarter.
Execution produces information that planning cannot. Once that information exists, the next one to three years can be envisioned with greater clarity, followed again by execution. If the direction continues to prove itself, the horizon can gradually expand into a more detailed twenty-year vision.
This avoids treating vision as either meaningless inspiration or fixed prediction. Seeing the picture of the future that you want to see gives you direction for present decisions, while present execution continually improves our understanding of the future.
There is a temptation to treat every new business problem as a need for another tool.
I try to approach it differently.
First, understand what is actually happening. Trace the problem through the system rather than stopping where the symptom appears. Follow it across disciplines when necessary. Learn enough of the underlying principles to make an independent judgment. Build something practical. Test it against reality. Examine what breaks and what survives.
Then improve it.
If automation helps, automate it. If technology adds unnecessary complexity, do not add it. If the process depends too heavily on one person, make the knowledge visible. If the assumptions change, make sure the system can change with them.
This is the approach behind the work I do across finance, data, SEO, automation, AI, software, and infrastructure.
The individual technologies will continue to change.
That is inevitable.
What matters more is developing a way of thinking that remains useful when they do: understand the problem before choosing the solution, learn deeply enough to make your own judgment, build against reality rather than theory alone, and create systems capable of surviving the conditions that come next.
