The Trail That Goes Cold

Field Note #07: The Trail That Goes Cold

The hike you only do once a year

There was a project we ran every year. Same time, same general shape, same moving parts. It was big and it had dozens of steps, multiple teams, a tight deadline that was congressionally mandated. Everyone knew it was coming. And every single year, without fail, it felt like we were starting from scratch.

"Who handled that last year?", "What's the next step?", "Who handles the QA review?" They would spend the first three days just figuring out who did what twelve months ago.

That's the thing about a trail you only hike once a year. It goes cold. The path is still there, technically. But the markers fade. The brush grows back. And if you didn't write anything down the last time you walked it, you come back the following season and find yourself, what would feel like, blazing a new trail.

Why annual processes are uniquely fragile

I've written about undocumented processes before. About how they cause chaos in the day-to-day work, how tribal knowledge walks out the door when someone leaves. But there's a specific kind of damage that only happens with annual work that I want to write about. At least with everyday work, the knowledge gets refreshed constantly. Someone is always doing it, so someone always remembers how it goes.

Annual processes don't get that attention. Twelve months is a long time. People's memories of the details fade. The person who owned a task last time might have moved to a different role or left the company entirely. The spreadsheet that tracked everything is buried somewhere in a shared drive nobody maintains. The email thread with the key decisions is lost in someone's inbox under eleven months of newer email.

And when the calendar comes back around and the deadline appears on the horizon again, the team has no choice but to reconstruct everything from memory and fragments. Which means they're not actually running a process. They're reverse-engineering it. Every year.

What "who handled that last year" really means

That question: "who handled that last year?" sounds like a simple ask. But it's actually a signal that something fundamental is missing. It means the process has no memory of itself. It means the work that was done, the decisions that were made, the order things happened in, none of it was captured anywhere that survives from one year to the next.

It means the work lives in the people who did it. And people are unreliable archives. We forget details. We remember things wrong. We leave.

I was a small part of this project. I didn't have the full scope, but I had enough of watching this chaos unfold each year. I sat down with the project lead and we mapped it out. Identified the missing pieces and documented them. We modeled the process and built a system that captured the work in a structured, repeatable way.

The years that followed were much better. We stopped doing kick off meetings. Instead, we got a heads up that the project was about to kick off. The teams could review what they previously done last year, in what order, and what notes they'd left for themselves for the next year. They readied themselves with the knowledge of what had been done before.

The false comfort of "we've done this before"

There's a particular kind of overconfidence that grows around annual processes. Because the team has done it before, there's a feeling that they know how to do it. That it's familiar. That they'll figure it out when the time comes, just like they did last time.

But "we've done this before" is not the same as "we know how to do this." One is experience. The other is documented knowledge. Experience fades and transfers poorly. Documented knowledge doesn't fade, and it survives the departure of the person who originally held it.

Familiarity with a trail is not the same as having a map of it. One lives in your memory. The other survives the winter.

The teams I've seen handle annual processes well aren't the ones with the most experienced people. They're the ones who treated the process like something worth recording every time they ran it. Not just executing it, but capturing it and leaving breadcrumbs to follow for the next time. Building the map while they walked the trail, so that next year's team could start from the trailhead instead of from memory.

What an operational record actually gives you

When we finally started treating our annual project as a defined service that had structured steps, assigned ownership, and a ticket that traveled through the whole process -something changed. Not just in how we executed it, but in how the next year started.

Suddenly, it wasn't the Project Manager who owned the project, it was everyone. The ticket carried the ownership of each step, and the knowledge of how it was done. The trail was marked in real time.

The questions worth asking now

Most teams don't think about their annual processes until those processes are about to run. That's exactly when it's too late to fix the underlying problem.

If you have a process that runs once a year like an annual review, a compliance cycle, a big client event, a budget process, a product launch, etc. ask yourself a few things right now, before it's back on the calendar:

• If the person who ran it last year left tomorrow, could the team still execute it? Not fumble through it. Actually execute it, consistently, at the same level.
• Does anyone have a record of what was done, in what order, by whom? Not a memory. An actual record.
• When this process runs again, will the team spend the first week figuring out how it was done last time? Or will they be able to start executing from day one?

If the answers make you uncomfortable, the process is more fragile than it looks.

Mark the trail while you walk it

This is the wayfinder method I wrote about in Field Note #05. The fix isn't complicated. It's just discipline applied at the right moment: while the work is actually happening, not after. A defined service in Everstep turns every run of an annual process into a structured record. Steps are tracked. Ownership is logged. The ticket becomes the operational memory of how it was done, and that memory doesn't degrade when the calendar turns or when someone's last day comes.

The trail gets marked in real time. Not reconstructed from memory a year later. A simple 'Update Service Template' takes all those notes and decisions and makes them part of the process itself for next year.

Here's the thing I kept coming back to, the hard part of that annual project was never the work itself. The work was do-able. It was manageable. What made it hard was that we kept starting from the start -not from where we'd left off, but from scratch. From "who handled that last year?"