Change adoption is a design constraint.

Organizations often treat adoption as the final proof that a solution worked. That sequence is backwards. Adoption is one of the constraints that should shape the solution from the beginning: the roles, data, workflow, decision rights, measures, and support around the change.

Adoption is a condition, not a campaign

A campaign can create awareness. It cannot make a contradictory workflow coherent. Training can explain a process. It cannot give a team authority that the policy still withholds. A town hall can create energy. It cannot reduce the number of systems a person must reconcile before they can serve a customer.

The practical question is not “How do we get people to accept the change?” It is “What conditions would make the useful behavior reasonable, visible, and repeatable for the people who carry it?”

Map the changed decision

Change becomes easier to design when it is attached to a real decision. Start with one moment where the future state is supposed to improve the work:

• Which customer or business promise is this decision meant to protect?
• Who sees the trigger, who interprets the evidence, and who has authority to act?
• What changes in the role, workflow, data, policy, platform, or measure?
• What exception would make the preferred path unsafe or impractical?
• How will the team know that the behavior is holding without relying on sentiment alone?

Four tests for a workable future state

An illustrative pattern: the new exception queue

Illustrative pattern, not a client case: A service organization introduces a shared exception queue to replace local spreadsheets. The launch plan focuses on training and adoption reporting. In the first week, the queue grows because regional teams cannot see which exceptions they are allowed to resolve, the source data arrives late, and the escalation rule conflicts with an existing service-level measure.

A communications campaign might describe the queue more clearly. A better design would also clarify ownership, expose data freshness, align the measure, define the exception boundary, and give the team a short daily review in which the queue can teach the organization what to fix next.

The lesson is not that the tool failed. The lesson is that adoption evidence revealed a system boundary that the original design had left implicit.

Sequence the first 90 days around learning

1. Days 1–30: make the change legible. Name the changed decision, affected roles, current workarounds, stable promises, and the evidence that would show a harmful assumption.
2. Days 31–60: practice with a representative group. Observe real work, collect questions and exceptions, revise the workflow, and give leaders a visible way to remove blockers.
3. Days 61–90: reinforce the operating rhythm. Update standards, measures, role support, ownership, and review cadence. Decide what to scale, narrow, redesign, or stop.

What adoption measures should reveal

Adoption is not one percentage. Use a balanced set of signals:

• Whether the critical work completes through the intended path.
• Where exceptions, rework, and workarounds accumulate.
• Whether people can explain the decision boundary and act within it.
• How quickly the organization turns an observation into a safe experiment.
• Whether the intended customer, control, service, or financial promise is holding.

What would change this conclusion?

Some changes genuinely require a communications-led intervention, a compliance mandate, or a rapid response where the organization cannot run a long learning loop. Even then, the design question remains: what must be true for people to perform safely, and how will the organization discover when the condition changes?

Use this with your team: Choose one behavior your program expects to change. Write down the missing meaning, permission, practice, or recovery condition. Then ask which part belongs in the solution design rather than in the training plan.