# Adoption is a design decision.

The org chart will tell you who owns the change. It will not tell you who makes it work.

Source: https://kimberlytegroup.com/perspectives/adoption-is-a-design-decision/

A KimberLyte perspective.

## Read the room before the roadmap.

A new system changes more than a workflow. It can change whose judgment is visible, who gets asked for help, and who feels exposed when a number is challenged.

Treat those concerns as design inputs. Ask what people are protecting. Listen for workload, credibility, control, and the fear of being left behind. A useful objection is information.

## Build with the people carrying the work.

The people closest to the work know where the official process ends and the workaround begins. Involve them early enough to change the design.

Make the first useful change tangible. Test it in a real workflow, with real constraints. Give people a way to raise a problem without being cast as resistant.

## Plan for the day after launch.

Who answers the first difficult question? Who has the authority to resolve conflicting guidance? What happens when a key person is away?

Training is part of adoption. So are ownership, incentives, support, and the time to learn. We treat those as part of delivery, because a launch only starts the work.

## Take it into the room

Does the work have an owner—or does it have a person everyone knows to call?

Prepare a concise working note for an internal discussion. Use only information I am authorized to provide in this tool. Do not ask for confidential records or production access. If I have not provided enough context, ask for a sanitized description of the decision and pause; do not invent an organization, facts, results, or owners.

THE QUESTION
Does the work have an owner—or does it have a person everyone knows to call?

CONTEXT TO ADD
[A sanitized description of our decision, current process, and known constraints.]

AUDIENCE
Write for the accountable sponsor. Lead with the decision to make, the consequence of waiting, and the evidence needed. Keep technical detail only where it changes that decision.

EXAMINE
1. Which exception makes the team call a particular person, and what judgment does that person supply?
2. Who can act in their absence, and where is that authority actually documented?
3. What work pauses, and what workaround becomes attractive when the official route is slow?
4. What workload, credibility, or control concern might the workaround be protecting? Treat these as hypotheses, not motives you know.
5. What safe rehearsal would show whether the backup has the authority, context, and capacity to act?

RETURN
An absence rehearsal: representative exception; decision required; primary and backup roles; authority boundary; capacity needed; escalation route; what to test with the people doing the work.
Use a compact table. Label each material statement as supplied fact, inference, or unknown. Link facts to the context or evidence I supplied; do not invent citations. For each unresolved item, name the role that should answer it and the smallest evidence request that could resolve it. Finish with one decision for the next meeting and what would change the recommendation. This is a working hypothesis for human review, not a finding about our organization.

Prompt adapted from KimberLyte Working tools: https://kimberlytegroup.com/working-tools/
The website's scenarios are fictional illustrations, not evidence about our organization.