Stabilise, diagnose, redesign:
does the order matter?

The purpose of this piece is to examine the order in which an organisation under strain should stabilise, diagnose and redesign, which is a question executives and advisers often answer by instinct, and to propose a way of thinking about sequence that holds up better when the answer is not obvious. I use stabilisation to mean arresting deterioration and restoring basic control, diagnosis to mean establishing what is actually true about the organisation's condition, and redesign to mean changing the operating system so that the condition does not recur.

Two positions are common, and both are reasonable. The first holds that when an organisation is losing cash, trust or control, the priority is to stop the loss, and that a careful diagnosis while the organisation deteriorates is a luxury it cannot afford. The second holds that acting before the cause is understood risks treating a symptom, and that an intervention built on the wrong picture can make the position worse. I think each is right in part, and this piece does not contend that either is mistaken.

Why the order is contested

The argument persists, as far as I can tell, because the two positions describe different situations. Where the failure is acute and visible, such as a cash shortfall, a loss of control over a critical commitment or a collapse in decision-making, speed matters and a short delay can close options permanently. Where the cause is unclear, acting on assumption is expensive, because the first intervention often shapes what the organisation can do next. Most real situations contain both, which is why a rule that says always stabilise first, or always diagnose first, is likely to be wrong for part of the problem.

A sequence that tolerates uncertainty

The sequence I would suggest overlaps its stages and does not treat them as strictly linear.

In terms of the FREEDOM Framework™, the first two stages are Frame the System and Rigorous Analysis, with Frame the System being a deliberately fast pass over the domains and Rigorous Analysis the slower work that follows it. The Enterprise System Health Check is the quickest way I know of to do the first of these, and the Enterprise System Diagnostic is the instrument for the second.

What is low regret in the first weeks

The useful test of whether a move belongs to stabilisation is regret: if the later diagnosis shows the move to have been unnecessary, how costly is it, and can it be undone? The table applies that test to some common moves.

Move	Stabilise now?	Reasoning
Restore a clear decision cadence: who decides what, and how often	Yes	Low regret and easily reversed, and organisations in difficulty have very often lost it
Protect cash and critical commitments	Yes	Preserves options that a later redesign will need
Establish one trusted view of the position	Yes	Every later decision depends on it, and several competing versions of the numbers are common in a crisis
Pause initiatives that contradict one another	Yes, with care	Reversible if recorded, although dependencies should be confirmed first
Restructure	Not yet	Hard to reverse, and the right design depends on a diagnosis that has not yet been done
Replace a major system	Not yet	Commits capital to a design made for the crisis state
Change senior leadership	Case by case	Sometimes leadership is the constraint, and sometimes it is where a structural problem has surfaced

The point of the table is to illustrate a way of reasoning and not to prescribe a list, since the answer for a particular organisation will turn on what is actually failing and how quickly.

The risk of redesigning too early

It is tempting, once the immediate loss has been stopped, to treat the emergency measures as the new design, partly because they work and partly because everyone is relieved. The difficulty is that controls tuned for an emergency are usually heavier than the organisation needs in normal conditions, and a structure built around the people who happen to be present in a crisis tends to be difficult to change once they leave. I would concede that some emergency measures do prove worth keeping, and the practical suggestion is to record, at the time, which measures are temporary and which are candidates to become permanent, so that the decision is made deliberately and not by default.

Where leadership alongside the CEO fits

In an organisation under strain, the CEO's attention is the scarcest resource and it is usually consumed in full by the situation. One role a leader working alongside a CEO can play is to hold the decision cadence and lead the executive team through the sequence above, so that stabilising, framing and diagnosing proceed together while the CEO keeps attention on the decisions only they can make. I would add that I regard it as part of the job to build capability as the work proceeds, so that the organisation is not left dependent on an outside adviser once it has stabilised.

If the first interventions in a stabilisation tend to determine what the organisation is able to do next, and the diagnosis that would show whether they were the right ones comes later, would it not be reasonable to choose the early moves for how easily they can be reversed, and to treat the question of order as a matter of regret and not of principle?