Skip to content

SkilLab framework

SHIFT Lens: five lenses for reading any change initiative (Celemi Cayenne)

Stakeholders · Hypothesis · Initiative · Friction · Time

SHIFT Lens (Stakeholders · Hypothesis · Initiative · Friction · Time) is a SkilLab framework to structure an organizational-change initiative across five testable dimensions before roll-out. Each dimension demands an explicit sponsor answer, and each missing lens is a predictable failure source later.

Diagram of the SHIFT Lens: five lenses for reading any change initiative (Celemi Cayenne) framework

The five lenses

Stakeholders. Who wins, who loses, who decides. Explicit power-and-interest map. Without stakeholder mapping, change collides with invisible vetoes.

Hypothesis. Which hypothesis the change tests. “If we do X, we will observe Y”. Without an explicit hypothesis, change becomes political articulation without evaluation criteria.

Initiative. Which concrete initiative proves or refutes the hypothesis. Minimum viable pilot, not full roll-out. Without a pilot, expensive and unnecessary failure.

Friction. Where organizational inertia will appear. Predictable sticking points: politics, processes, systems, culture. Mapping in advance avoids field surprises.

Time. In which window the hypothesis is evaluated. 90 days, 6 months, 12 months. Without an explicit test horizon, the initiative enters an infinite loop.

How to apply

Apply SHIFT Lens as a one-page brief before approving any organizational-change initiative. The sponsor answers the five questions in writing. Sponsors who get stuck on Hypothesis or Time are usually the ones who complain most about “lack of execution” later.

Celemi Cayenne is the experiential complement. Teams run simulated change and use SHIFT Lens in the debrief to name what was missing.

When to use

  • Before approving roll-out of an organizational-transformation initiative.
  • To prepare a sponsor who must defend change internally.
  • In post-change retrospective to identify what was missing in the design.

When NOT to use

  • Minor operational changes where over-engineering costs more than the error.
  • Isolated technical initiatives without organizational implication.