One step back and two forward: the J-curve

Whenever we make a change to how we work (or manage), there is the J-curve. Understanding it and managing it is a great aid to minimising risk and advancing well in a VUCA world.

Every change to a working system will have an initial negative impact on performance until we can identify issues, fix problems, learn new processes, and start to optimise performance of the new system. New teams need to form before they can perform. This is called the “J-curve”.

Every time we change anything about how we work, the performance of the work system goes backwards before it goes forwards.

This is a law of nature, for at least four reasons:

(1) People need to practice the new way, to get the hang of it. Our rule of thumb is: all new activities take at least three iterations before they start to work well.

(2) It’s a complex system. We don’t know what the effect of changes will be until we try them. Nobody knows. it’s all an experiment.

(3) We get it wrong.  We make mistakes.

(4) People may be actively resistant, disengaged, or at least holding back to see how it goes.

An observer can take a short-term view of a J-curve and say it was all bad. Or take a longer term view and look for the up-turn.

How do we manage through a J-curve?

Expect the downturn: allow for it and manage through it. Set expectations beforehand.  If management lose their nerve, we try to roll back and only make it worse.

We call this the “J chicken”


A very big downturn might be unrecoverable. For big changes, we need to consider scenarios and weigh up opportunity and risk. If the worst happens how much damage could there be? Can the system cope?


Make many small changes, not a few big ones. Reduce the impact and risk of each change. This is the reason for agile ways of working.

Don’t lurch, waltz.

This is one of the most compelling arguments for Agile with conservative, risk averse people. It is the safe way to advance in a VUCA world: iterate, increment (small Js), experiment, explore.


It’s all in our book: The agile Manager (small a)