DIAGNOSIS
I have recently come across a discussion where someone asked for advice on building an application. They had never built one before and were looking for guidance on where to start.
The responses arrived immediately.
“Use this platform.”
“Launch fast.”
“Focus on beta.”
“Talk to customers early.”
“Don’t spend a year building the perfect product.”
None of these suggestions were inherently wrong. In fact, most of them were perfectly reasonable in isolation.
What was missing was something else entirely.
Nobody asked questions first.
No one asked:
- what kind of application it was
- who the users were
- what market it targeted
- what platform it needed to operate on
- what problem it was solving
- whether there were technical, financial, legal, or operational constraints
The discussion moved directly to solutions before understanding the problem itself.
This pattern appears increasingly often, not only online, but inside organisations as well.
Diagnosis is slowly being replaced by participation.
The objective is no longer necessarily to understand a situation thoroughly before responding. Instead, the system rewards immediacy. Fast reactions. Fast opinions. Fast visibility.
The result is an environment filled with detached fragments of advice, often valid on their own, but disconnected from context.
“Launch fast” can be excellent guidance. Or catastrophic.
It depends entirely on what is being built, for whom, under which constraints, and at what cost of failure. Without context, advice becomes generic heuristics masquerading as expertise.
This shift is subtle because the individual pieces often sound intelligent. The issue is not that the recommendations are always wrong. The issue is that they are delivered before sufficient understanding exists.
Professional thinking traditionally followed a different sequence:
- observe
- question
- diagnose
- constrain
- decide
- act
Increasingly, digital environments reward the reverse:
- react
- contribute
- optimise visibility
- refine later
These are fundamentally different operational models.
One prioritises clarity and responsibility. The other prioritises speed and participation.
This would not matter much if the consequences remained confined to online discussions. But the same behaviour increasingly appears inside real systems.
Organisations rush into transformation before understanding internal constraints. Teams adopt tools before defining workflows. Processes are automated before ownership is clarified. Decisions are made from dashboards before signals are verified.
The surface moves quickly. The underlying structure remains poorly understood.
In many cases, the pressure to appear responsive becomes stronger than the need to be accurate.
Questions slow momentum. Uncertainty reduces confidence. Careful diagnosis delays visible action. In environments optimised for engagement and speed, this feels inefficient.
Yet in most operational environments, the opposite is true.
In medicine, engineering, aviation, logistics, restructuring, or systems design, premature action without sufficient diagnosis usually increases complexity rather than reducing it. The cost of moving quickly in the wrong direction is often far greater than the cost of pausing to understand the system properly.
This is not an argument against iteration, experimentation, or adaptability. Those remain essential. But iteration without diagnosis eventually becomes drift.
A system that no longer asks questions first gradually loses the ability to distinguish signal from noise. And once that happens, activity begins replacing understanding.
More on diagnosis:
Where to Start When Something Feels Wrong in an Organisation