What Changed Around the Person?

The plan assumes it began with him

Imagine a senior engineer whose code reviews have slowed from one day to two or three. His manager has a development plan half drafted, with "responsiveness" as the first goal.

The slowdown is real. The plan assumes it began with him.

Before the plan goes further, look at the months before the slowdown. This article shows how.

The short version: Behaviour changes at a point in time, and so does the situation around it. Build a timeline that starts well before the change, fill it from records, and ask the person to correct it. Then ask whether you're looking at a moment or a pattern before you choose a plan.

Start before the change

Most of us look at the change itself. If a change in the situation affected the behaviour, it came first. So the useful part of the record is the stretch before. The timeline will also show if the situation shifted in response to the behaviour.

Our guide to Behaviour Intelligence asks whether a change is new or has been building, and what else changed when it started. A timeline answers both.

Start earlier than feels necessary. Go back at least one full cycle of the person's work, such as a quarter, a release cycle or a planning round, plus a margin. Then ordinary swings show up as ordinary.

Build it from records, not memory

Memory blurs dates. "It's been like this for ages" and "it was fine until last month" can both feel true and both be wrong at the edges.

Use dated facts: calendars, announcements, project plans, targets, rotas, handover notes. Mark the behaviour on the same line, described as observations, not explanations. Performance Is a Signal. Not a Diagnosis. covers that step. Use windows, not exact dates, because behaviour drifts. "Between early July and mid-August, reviews took two to three days" is honest. "On 3 July he changed" isn't.

Then add what happened around the person. Six questions cover most of it:

• Role. What does this person own now that they didn't before, or no longer own?
• Team. Who joined, left or changed manager?
• Workload. How much arrives, and how does it arrive?
• Priorities. Which goals, targets or deadlines moved?
• Relationships. Which key working relationship changed?
• Wider change. Which tool, restructure, policy, client or season changed?

Skip the ones that don't apply. Add anything else that's dated. This list is for building a dated record. What If the Behaviour Isn't the Problem? is for choosing a response once you know where the cause sits.

What a timeline can look like

Illustrative scenario. The engineer's timeline.

• March. The team's other senior engineer leaves. Reviews that were shared now land on him.
• April. The roadmap changes. A payments feature is added, and no other work is removed.
• May. A new tech lead arrives, with stricter review standards.
• June. The team moves to new repositories and build tooling.
• Early July to mid-August. Reviews take two to three days.

Four things changed in the four months before the slowdown. The timeline doesn't tell you which one mattered, or whether any did. It tells you what to ask him, and it stops the plan from starting with "responsiveness".

Read it with care

A timeline is easy to over-read. Three habits help.

Coincidence isn't cause. In most organisations, several things change at once. The timeline shows what coincided with the behaviour. It doesn't show what produced it. Use it to generate questions, not to name a culprit.

Allow for lag. A change in March may not show in behaviour until June. Look for effects some weeks after an event as well as straight after it.

Record what didn't change. If the role, the manager and the workload stayed the same, that's useful too. It narrows where you look next.

Keep the timeline to work. If life outside work comes up, it's theirs to raise, and yours to make room for.

Let the person correct it

Build the timeline openly. Tell the person you're looking at what changed around their work, and why. Keep it to work records. It's a tool for understanding, never evidence against them.

Show it to them. They'll know which dates matter and which don't, and they'll add what the records miss, such as an arrangement nobody wrote down.

Treat their corrections as evidence, not objections. Their timeline and yours will differ in places. Each difference is worth understanding. The conversation itself is covered in Performance Is a Signal.

A moment or a pattern?

A single late week is a moment. A pattern lasts. These are our rules of thumb, not tests with cut-offs.

Duration. Has it outlasted one full cycle of the work? A month-end crunch looks like a problem if you look only at month-end.

Recurrence. Has it happened before, at the same point in the calendar? If so, the calendar may be part of the explanation.

Spread. Does it show up everywhere, or in one team, one client or one kind of task?

Direction. Is it a step, a drift, a spike or a recovery? With a step, look for the dated event it lines up with. With a drift, ask what has been building up.

After the dust settles. Once the changed conditions have bedded in, such as the new tool learned or the new owner in place, has the behaviour returned? If it has, it was a moment. If it hasn't, you're closer to a pattern.

The last check tells you most. Behaviour that outlasts the change is the behaviour worth planning around.

What the timeline means for the plan

A development plan needs a target. The timeline helps you choose it.

If the change landed alongside a new demand, aim the plan at that demand. For the engineer, that might mean a protected review slot and a second reviewer. If the behaviour has outlasted the changes, a plan built around skills or habits now has something to stand on. If the picture is still unclear, keep recording, and set a date to look again.

Put that date in the plan. A plan is a hypothesis about what will help, as we say in What If the Behaviour Isn't the Problem? The timeline is how you read the result.

Opptimise helps people leaders see the situation around a person over time before they decide what a change means.

A timeline shows what moved, and when. Better understanding comes before better action.

Sources

• Opptimise, Behaviour Intelligence: Understanding Behaviour Before Deciding What to Do.
• Opptimise, Performance Is a Signal. Not a Diagnosis.
• Opptimise, What If the Behaviour Isn't the Problem?

Drafted and illustrated with AI assistance and reviewed by the Opptimise team.