Skip to content
Beta

Change Acceleration: The 4-Level Model

Last updated on

The most common failure pattern: change management runs as a parallel workstream alongside the technical programme — it produces attractive communications, but no behaviour change. Real change only occurs when it is integrated into the programme, not running beside it.

Level 1: Leadership alignment (Months 1–2)

Section titled “Level 1: Leadership alignment (Months 1–2)”

If leaders are not visibly committed, no amount of energy from below will overcome organisational gravity.

Measures:

  • CEO or CIO sponsors the transformation publicly in an all-hands communication
  • Leadership team uses cloud metrics in business reviews
  • Cloud Strategy Board inaugural meeting is attended personally by all members
  • Leaders communicate what they themselves will do differently — not just IT

Signal of success: A business unit head spontaneously asks in a steering meeting: “What are our cloud costs this month — are they on plan?”

Middle management controls the daily priorities of teams.

Measures:

  • Department heads receive a cloud literacy briefing
  • Performance objectives for engineering managers include cloud adoption metrics
  • Managers receive an explicit mandate to protect time for cloud training

The critical failure pattern: Managers who receive no updated performance objectives naturally prioritise the work they are measured on. Engineering teams that must simultaneously maintain 100 % legacy availability and migrate to the cloud will always deprioritise migration.

Concrete measure: Update engineering manager objectives: 20 % of targets relate to cloud adoption progress (migration throughput, team training completion rate, cloud cost accountability).

Measures:

  • Training programme (Tracks A–F) deployed, all employees have access
  • Sandbox environments available from week 1 of training
  • Cloud Champions nominated and active in every team
  • Blameless postmortems established as the norm for cloud-related incidents
  • Lighthouse projects identified and celebrated as early proof of success

The lighthouse project pattern: Select 2–3 workloads for early migration where success is likely. Invest disproportionately in their success. Communicate the success loudly: “Team X migrated [Workload] in 6 weeks, 35 % cheaper, now deploying 3× per week instead of once per month.”

Change is only lasting when it is built into the organisation’s systems — no longer dependent on individuals maintaining it.

Systemic anchoring means:

  • Cloud engineering practices in hiring criteria and job descriptions
  • Cloud cost efficiency as a permanent metric in engineering team dashboards
  • Blameless postmortem process formalised (not Champion-dependent)
  • “Cloud by default” declared the architecture standard
  • New employees are onboarded into cloud practices as standard

The kick-off communication is remembered by perhaps 40 % of the intended audience. Core messages must be repeated:

Communicating once: A single kick-off communication is not enough.

Training without protected time: Instructing teams to complete training while maintaining 100 % workload is a false instruction — it reliably results in training not happening.

Change management as a parallel workstream: When change management runs alongside the technical programme but is never integrated, it produces attractive communications without behaviour change.

  1. Show leadership commitment publicly — all-hands communication by CIO
  2. Update engineering manager objectives — cloud adoption as a KPI
  3. Define first lighthouse projects and communicate them
  4. Build a communications calendar for 12 months