A change programme has a geometry, and most programmes get it wrong. They treat every department as if it stands at the same distance from the change, then call it resistance when distant departments move slowly.
The right model is orbital. Each department traces its own path around the change at its own radius. Inner orbits are tight, fast, and the center is always visible. Outer orbits are wide and slow - same gravitational pull, but the same arc takes far longer to complete. Calibrating support to that distance is most of the work of change management.
Distance is a measurement, not a verdict
When we say a department is far from the change, we are not saying they are less capable, less committed, or less valuable. We are saying something specific: the gap between their current movement patterns and what the change requires is large.
A finance team in a cloud migration is not slow. Their existing expertise - budgeting cycles, cost centres, variance analysis, audit trails - is real and hard-won. But none of it maps directly to consumption-based billing, reserved instance economics, or cloud cost allocation tags. They are not starting from zero knowledge. They are starting from a large distance. The gap is not about them. It is about the specific change and where it sits relative to their world.
The neuroscience of skill acquisition supports treating distance as a real, physical quantity. Scholz et al. (2009) showed that learning to juggle produced measurable changes in white matter tracts underlying the intraparietal sulcus - the structural pathways that carry the new skill. White matter changes take longer to form than grey matter changes. Building new technique from scratch is not slow because of attitude. It is slow because the substrate has to change.
Distance is a property of the relationship between a department and a particular change. It is not a property of the department.
What near distance looks like
A department in the inner orbit does not experience the change as foreign.
They may not welcome every aspect of it. They may have strong opinions about the implementation. But the fundamental vocabulary of the change is already part of how they work. When the change talks about containers, latency, deployment pipelines, infrastructure as code - they have mental models for these already. The change is reconfiguring familiar terrain, not asking them to learn to walk on a new planet.
The inner orbit benefits from this. Their re-learning time is short. They can demonstrate the new pattern to others before others have even understood what the pattern is. They are the most useful early resource in any change programme - not because they are more motivated, but because they can translate between the change language and the organisation’s existing language.
What middle distance looks like
A department in the middle orbit carries relevant experience, but the change asks for it in a different shape.
This is the club-throwing problem. A club must be thrown with a specific spin, caught at a precise point in the rotation. The throwing motion is similar to a ball throw - but “similar” is exactly what makes it tricky. The club thrower who relies entirely on ball-throwing muscle memory will drop the club consistently, because the critical difference - the spin, the grip, the catch point - is exactly where the technique diverges.
Security teams in a cloud migration hold this position. They understand threat modeling, access control, incident response, and compliance. All of it transfers in concept. None of it transfers in practice without rebuilding technique for cloud-native tooling, shared responsibility models, and the new attack surfaces that virtualised infrastructure creates. Their knowledge is a foundation. It is not a shortcut.
The middle orbit does not need more enthusiasm. It needs practice time in the new technique. The existing knowledge is not the problem - it is valuable. The problem is treating that knowledge as a substitute for the new body language rather than a foundation for it.
What far distance looks like
A department in the outer orbit arrives at the change with essentially no directly transferable technique.
This is not unusual. In a cloud migration, the finance team is in the outer orbit. In a psychological safety culture programme, senior leadership is in the outer orbit. In a digital transformation, the operations team is in the outer orbit. The pattern shifts with every change - but every change has an outer orbit.
Departments here face a specific challenge that is not about capability: they have to build an entirely new motion pattern from near-zero, while continuing to run all of their existing work. The inner orbit can practice the new throw in their spare time. The outer orbit is still fully occupied with the old pattern when the change asks them to start learning the new one.
The departments beyond the outer orbit
There is a fourth category: departments that are not yet in orbit at all.
Every change programme has a leading edge and a trailing edge. The tech team is in the inner orbit on day one of a cloud migration. The manufacturing team, the customer service team, the regional offices in markets where the migration hasn’t started - they are not yet part of the orbit.
This is not a problem. It becomes one when the change programme assumes they will arrive at the same pace and with the same preparation as departments that have been in orbit longer.
The distance from the change is not fixed from the moment the programme launches. Departments enter the orbital pattern at different times, and when they do, their starting distance still reflects the gap between their existing movements and what the change asks for.
| Juggling | Distance from the change |
|---|---|
| Inner orbit - familiar motion, short re-learning arc | Fast-track paths, demonstrate the change to others, early ownership of new tools and methods |
| Middle orbit - relevant knowledge, new technique needed | Technique-specific retraining, enough practice time to rebuild methods in new context, explicit recognition of what transfers and what does not |
| Outer orbit - near-zero direct technique transfer | Longer timeline, different learning approach, clear answer to 'why does this matter for what we do', protected time to build from scratch |
| Beyond visibility - not yet in scope | Prepare the entry point before they arrive - know their starting distance and have the support structure ready when they join the programme |
Building bridges, not shortcuts
The work of change management at each orbital distance is different because the distances require different interventions.
Inner orbit departments need acceleration and responsibility. The change should lean on them early and use their experience to build the programme’s credibility with departments further out.
Middle orbit departments need the right kind of practice. Not just information about the change - structured practice time in the new technique, with enough tolerance for the early drop rate that club-learning always produces. Reducing the practice time to speed up the programme is how technique fails to form.
Outer orbit departments need something the change programme rarely builds correctly: a bridge from their existing world to the change’s requirements. Not “here is what the change is” but “here is why the change matters for the specific work you do, and here is the specific new motion you need to build.”
The distance changes
This is worth repeating from Which Prop Are You Holding?: the orbital assignment is not permanent.
A finance team that is in the outer orbit of a cloud migration is in the inner orbit of a financial planning platform migration. The same tech team that holds the inner orbit in a cloud migration may find themselves in the outer orbit of a customer-centricity programme. Distance is a relationship between the department and the specific change, not a fixed property of the department.
The change manager who assumes that inner-orbit departments will always be the fast movers has made a category error. They are fast movers in this change. The next change may put them exactly where the finance team is now.
The cascade is the same. The props change. The distances shift. The programme has to be rebuilt for each change rather than copied from the last one.
Read next: The Change Is Always Juggling - why every major organisational change follows the same underlying cascade.