A surprising number of change efforts cannot name the behavior they are trying to change.

They can name the initiative: new CRM, new planning process, new operating model, new AI tooling, new enterprise motion, new customer segmentation, new performance system, new product development process. They can describe the rationale. They can list the benefits. They can identify stakeholders.

But when asked what a person should do differently at 10:15 on a Tuesday, the answer gets vague.

That vagueness is expensive. If the desired behavior is not specific, managers cannot reinforce it, teams cannot practice it, tooling cannot support it, metrics cannot measure it, and leaders cannot tell whether adoption is happening.

Change starts with a behavior-change spec.

The unit of change is substitution

The useful question is not, "What are we rolling out?" It is, "What old behavior is being replaced by what new behavior, in what moment?"

For example:

  • Old: reps update deal notes before forecast review. New: reps update next step, mutual action plan, risk, and close path within 24 hours of every customer interaction.
  • Old: product managers collect stakeholder requests and negotiate priority in meetings. New: product managers maintain a written investment thesis for each roadmap bet and reject work that does not match the current strategy.
  • Old: managers approve exceptions in Slack. New: exceptions go through a lightweight form with reason, customer impact, expiry date, and owner.
  • Old: teams ask finance for headcount after plans are already written. New: resource constraints are stated before planning begins.

The change lives in the substitution. Without it, people will interpret the change through the old system and call that adoption.

A weak spec says, "Use the CRM better." A strong spec says, "Within 24 hours of every customer interaction, the account owner updates next step, close risk, decision process, and mutual action plan; forecast review will use those fields, and deals without them will not be accepted into commit." The difference is not wording. It is operability.

Behavior has context

A behavior is not just an action. It has context: trigger, owner, tool, information, decision rights, timing, standard, consequence, and fallback.

If any of these are unclear, adoption will be uneven.

A team may agree to use the new process but not know when it begins. A manager may want to reinforce the new standard but lack authority to reject old work. A rep may understand the new CRM requirement but see no consequence when peers ignore it. A product team may accept the new prioritization framework but still get overridden by executive requests outside the framework.

The old behavior survives inside unclear context.

Write the behavior-change spec

Before you communicate the change broadly, write a simple spec:

1. Current behavior. What do people do today? Be honest. Include the unofficial version.

2. Desired behavior. What should they do instead? Make it observable.

3. Moment of substitution. Where does the new behavior replace the old one?

4. Affected roles. Who must behave differently: executives, managers, ICs, sales reps, PMs, CS leaders, finance partners, recruiters, support teams?

5. Required supports. What must change in tools, templates, metrics, incentives, approvals, meetings, documentation, and manager routines?

6. Reinforcement. Who will notice, correct, praise, or escalate behavior in the first 30, 60, and 90 days?

7. Failure modes. How will the old behavior try to come back?

8. Adoption evidence. What proof shows the behavior changed?

9. Retirement plan. What old artifact, channel, report, field, approval path, or informal habit will be removed or downgraded so the substitution is real?

This is not bureaucracy. It is clarity. If the leadership team cannot complete the spec, the organization will not magically infer it.

Beware concept changes

Many change programs stay at the concept level: be more customer-centric, move faster, operate with more ownership, become AI-native, improve accountability, increase collaboration, act like one company.

These may be valid aspirations, but they are not yet changes. They become changes only when translated into behavioral substitutions.

"More accountability" might mean commitments have named owners, dates, and review forums. "Move faster" might mean reversible decisions under a certain risk threshold no longer require executive approval. "Customer-centric" might mean roadmap reviews start with customer evidence and renewal risk, not stakeholder preference.

If you cannot translate the phrase, do not launch the phrase.

The operator's discipline

The best change leaders are almost annoyingly concrete. They keep asking: what behavior, by whom, where, instead of what, supported by what, measured how?

That is not small thinking. It is how big changes become operational.

The company does not adopt a concept. It adopts a new way of working.