Why week one is noisier than week four

Separate the noise from the actual failures

Three things reliably look like failure and are not. A high rejection rate, which should be high initially and falling. An exception backlog appearing suddenly, which is pre-existing data debt becoming visible rather than new debt being created. And uneven adoption, because people arrive at new tools at different speeds and the distribution is normal.

Three other things are real problems and are easy to miss because they are quieter. A rejection rate that stays flat means the feedback is not reaching whoever configures the agents, the loop is open. Rejections without reasons mean the same thing at source. And a team not working the queue at all is not slow adoption; it is a decision that has been made without being announced, and it needs addressing directly rather than waiting out.

• Flat rejection rate — the feedback is not reaching anyone who can act on it
• Rejections with no reasons — the loop is open at the source
• A team not engaging at all — a silent decision, not a slow start

Say it before it happens

The practical value of knowing this pattern is almost entirely in saying it in advance. Told in week zero that the first fortnight will be noisy, that rejections are wanted, and that you will judge the thing at week six, a team reads the early weeks as progress. Told the same thing in week three, after someone has already raised the noise as a concern, the identical explanation sounds like a defense.

It also protects the measurement. Set the review point before you start (six weeks is reasonable for most rollouts) and hold to it. The failure mode this prevents is real and common: a working implementation abandoned in week two because the noise it was always going to produce was read as a verdict.

A worked example: the fortnight that looked like failure

A rollout hits day nine. The rejection rate on prepared actions is running near a third, an exception backlog of several hundred records has appeared that nobody knew about, and two of five teams have barely opened the queue. A leader looking at that dashboard has every reason to intervene.

Take the three in turn. A third of items rejected means people are reading them and pushing back, which is the loop working; the number to watch is whether it is falling week on week, and at day nine there is not yet enough data to say. The exception backlog is not new debt; it is old debt becoming visible for the first time because something finally checked, and it would have been there whether or not you rolled anything out. Two teams lagging is a normal adoption distribution at day nine.

The intervention that feels natural here is to slow down: pause the rollout, reduce what the agents surface, give people a break from the noise. That is precisely the move that prevents week four from being quieter, because the rejections currently arriving are the only thing that will tune the system. The correct response at day nine is to do nothing except make sure the rejections carry reasons.

What you say in week zero

Since the entire value of knowing this pattern lies in saying it before it happens, have the sentences ready rather than improvising them.

Tell the team the first fortnight will be noisier than the settled state, and that this is the system calibrating rather than misbehaving. Tell them rejections are wanted, that a rejection with a stated reason is the single most useful thing they can produce in the first weeks, and that nobody will be judged on how many they send. Tell them an exception backlog will appear and that it is pre-existing debt made visible, not new problems created.

Then set the review point publicly and hold to it. Six weeks is reasonable for most rollouts. The specific date matters less than the fact that it was chosen in advance, because a review point set at the start is a commitment and a review point chosen later is whenever somebody lost patience.