Fresh eyes without old mistakes

The first post in this series argued that a new manager's biggest advantage is that nothing looks normal yet. You notice the odd manual step, the strange rule, the service nobody wants to touch.

But fresh eyes have a blind spot. They see what's strange today without seeing what happened before. Some of the odd things you notice are mistakes nobody got round to fixing. Others are the scar tissue from a bad week two years ago, and they're doing their job. From the outside, the two look exactly the same.

A newcomer who fixes everything they find will fix some real problems, and also bring back a few the team had already solved.

Find out why the fence is there

There's an old idea, usually credited to G. K. Chesterton: if you find a fence across a road and can't see what it's for, don't take it down until you've found out. Once you know why it's there, you can decide whether it still needs to be.

In a team, the fences are things like:

• A manual approval step before a certain kind of release.
• A check that runs twice, or a report that's generated a day later than seems necessary.

Each of these might be waste. Each might also be the reason something hasn't gone wrong in a long time. The way to tell is to ask, and to ask in a way that makes it easy to answer honestly: "What does this protect us from?" works better than "Why do we still do this?"

Read the history first

Before proposing a change, find out whether the team has been here before. Most teams keep more history than they realise:

• In retrospective notes, the same complaints tend to come back. If something was raised five times and never changed, find out what got in the way before you try again.
• Postmortems tell you which fences were built after which fires.
• If the team wrote down why it chose one approach over another, those decision records are the fastest way to understand a design that looks odd. With the Reportal & CUED team, we moved ours out of Confluence and into a repository of their own.
• Search old tickets for the thing you want to change. Often there's one from two years ago with a long discussion and a good reason it was closed.

And ask people directly: "Have we tried this before?"

With the DSP teams, our release runbook says to post in the team channel before every production deploy, listing the changes since the last release and checking that everyone is fine with it. I told the team I thought it was absurd: the list could be generated from the commits. Then I read the reason written next to the step, which was to make sure no large processing is running. That reason is mostly out of date. Running jobs keep the image they started with and only new jobs pick up the new one, so a deploy doesn't interrupt them. But it isn't completely gone. If a release ever includes a breaking change to the database model, old jobs that are still running could hit a schema they don't expect. That hasn't happened yet, but I can see it happening.

It's fine to complain, but come with a solution. So the change I'm proposing keeps the check where it still matters: generate the change list automatically, and only ask for the check on releases that change the data.

Write the proposal down

When you do want to change something, write it down before you change it. A short decision record is enough: the context, the options, what each one costs, and what you recommend.

Always include "leave it as it is" as one of the options. It forces you to say what the current way gets right, and it shows the team you've understood why things are the way they are.

Writing it down also slows you down in a useful way. A proposal that seemed obvious in your head often has a gap once it's on the page, and the team can point out what you missed before it costs anything.

Let the team choose

A change the team picked is much more likely to last than one handed to them, because they know the code and its history better than you do.

In February 2023, when we set time aside for tech debt across the TV & AV repositories, I didn't pick the topics myself. I listed ten candidates and asked everyone to score each one on urgency and importance. Continuous deployment for every repository and consistent linting and test coverage came out on top, followed by a common branching flow. Those became the plan, and we tracked progress repository by repository.

Remove old things by asking, not guessing

Fresh eyes are especially tempted by things that look unused: a database nobody mentions, a service with no recent commits, a storage bucket with an old name. Deleting them feels like progress. It's also how teams find out, too late, that something still depended on them.

In January 2023 I started an inventory of our department's cloud resources: 107 Kubernetes namespaces, 97 MongoDB databases, 41 S3 buckets and around 50 Lambda functions. Instead of guessing what was safe to remove, we gave every item an owner and asked each owner to decide whether it was still needed. Unused resources could then be removed with confidence, instead of lingering because nobody was sure.

Leave the reasons for the next person

The DSP teams keep their decision records in a repository too, and the release check belongs there: why it was added, why most of that reason no longer holds, and when it still matters. The next person who joins shouldn't have to dig through a runbook to find out why a fence is there.