The Two Weeks After You Change Something

You changed how something works. Everyone was told, everyone agreed, and it went well for about a week.

Three weeks later it is gone, and nobody decided to stop.

The shape of the fortnight

Predictable enough to plan around:

Days one to three. Everyone does it, because it is new and someone is watching.

Days four to seven. The first busy night. ⚠️ The change gets skipped once, nothing bad happens, and the skip becomes available as an option.

Week two. Split adoption — some people doing it, some not — which is worse than either extreme, because now there are two systems and nobody can rely on either.

Week three. Whichever way the split resolves becomes permanent, and it usually resolves toward the old way, because the old way requires no effort to remember.

Why the busy night kills it

Not resistance. The new thing has a cost in attention, and attention is what a busy night has least of.

⚠️ A change that costs even slightly more effort than the thing it replaced will be abandoned under pressure, regardless of how much better it is when there is time.

This is the design constraint, not a discipline problem. If the change is not cheaper in the moment, it needs to be so much better that people carry the cost deliberately — and that requires them knowing why.

What decides whether it survives

Whether the reason was given. ⚠️ "What it prevents", not "what to do." People carry a cost for a reason they understand and drop it for an instruction they do not.

Whether the first skip was noticed. Not punished — noticed, and mentioned. The unremarked skip is the moment the change starts dying.

Whether the old way was removed. If both are available, the old one wins. Removing the alternative is more effective than any amount of reminding.

Whether someone owns it. By role. A change belonging to everyone belongs to nobody by week two.

The check at day ten

One question, asked of two or three people:

"Are we still doing the thing we changed?"

⚠️ Ask it of people who do the work, not of the person who introduced it — the introducer will say yes, sincerely, because they are still doing it themselves.

Day ten, because week two is when the split appears and it is much cheaper to correct then than after it has resolved.

When the answer is no

Do not simply re-announce it. Ask why it was dropped, and take the answer seriously:

It cost more than it saved. ⚠️ Frequently true, and the honest response is to redesign or abandon it, not to insist.

It was unclear at the edges. It worked for the standard case and nobody knew what to do with the variations.

It conflicted with something else. Two rules, and the other one is older and better understood.

Only after ruling those out is it a discipline question — and it usually is not.

Changing fewer things

The most reliable improvement to adoption is doing less of it at once.

⚠️ Two changes in the same fortnight halve the attention available for each. Three means none of them survive, and the team learns that changes do not stick — which makes the next one harder still.

One change, given a fortnight, is faster in aggregate than three changes given none.

Three to hold

Changes introduced in the last quarter, and how many are still running. ⚠️ The number is usually sobering and it is never counted.

Days since the last change was introduced. If it is under fourteen, the previous one has not landed yet.

Whether the day-ten check happened. The single behaviour with the largest effect on whether any of this works.

Where the record has to sit

A change that lives in an announcement leaves no trace to check against. What changed, when, who owns it, and what it prevents — written down, or in two months nobody will be able to say whether it is still in force.

tasteck keeps recurring tasks and operational notes on the screens staff already use, so a new step appears in the work rather than in a message that scrolled away.

Nobody rejected your change. It was skipped once on a busy Friday, and nothing in the operation noticed.