The shadow spreadsheet: how a backup copy becomes the real system

A month after launch, someone on the team is still maintaining their old spreadsheet. They don't mention it in the check-in call, and when asked they say they keep it just in case.

That spreadsheet isn't a discipline problem. It's a twelve week route that already started, and it almost always ends the same way.

How does a copy turn into the real system?

In six steps, and none of them looks serious on its own.

Week 1. Someone exports the data to keep a copy, just in case. The data lives in the system. The spreadsheet is a copy and nothing else.

Week 3. On a busy day, one case gets written only in the spreadsheet and nobody moves it into the system. The data starts living in both places, and they no longer say exactly the same thing.

Week 5. The team starts checking the spreadsheet, because it's more up to date. For day to day questions, the spreadsheet is already the source.

Week 8. The weekly report is built from the spreadsheet, because the one from the system doesn't add up. The information behind decisions comes from there.

Week 12. New cases go into the spreadsheet first. The system gets filled in later, when somebody has time.

Month 6. The system is an interface sitting on top of a spreadsheet, and the team is right not to trust it, because it genuinely is incomplete.

Nobody ever decided to create a parallel system. Every step was reasonable on the day it happened.

Illustrative route

Twelve weeks of a backup spreadsheet

In which week does somebody look?

Week 2Week 6Week 12Nobody looks

Week 1

Someone exports the data to keep a copy, just in case.

The data lives in the system. The spreadsheet is a copy and nothing else.

Week 3

On a busy day, one case gets written only in the spreadsheet and nobody moves it into the system.

The data starts living in both places, and they no longer say exactly the same thing.

Week 5

The team starts checking the spreadsheet, because it is more up to date than the system.

For day to day questions, the spreadsheet is already the source.

Week 8

The weekly report is built from the spreadsheet, because the one from the system does not add up.

The information behind decisions comes from the spreadsheet.

Week 12

New cases go into the spreadsheet first. The system gets filled in later, when somebody has time.

The system fell behind and gets filled out of obligation, not out of use.

Month 6

The system is an interface sitting on top of a spreadsheet, and the team is right not to trust it.

The project keeps getting paid for and the spreadsheet is the real operation.

There is no fix, there is a restart

By this point you do not correct a drift, you implement again. And the second time is harder than the first, because the team already has the experience that the previous system did not work, even if what did not work was the support around it.

The cost by the week somebody looks

• Week 2: A ten minute conversation. The spreadsheet is still a copy: it holds no data the system does not have. It takes understanding why it exists, solving the case that person cannot solve in the system, and agreeing on a date to shut it down. There is nothing to recover.
• Week 6: The conversation, plus a stretch of manual work. Some cases live only in the spreadsheet, so on top of talking they have to be moved into the system and the field the system did not cover has to be sorted. It is still days of work, and the team has not stopped using the system.
• Week 12: You have to reconstruct before you can fix. You have to reconstruct the real state of the open cases, decide which of the two sources wins, and retrain the team. The expensive part is not the work: it is that the system lost credibility, and that does not come back by migrating data.
• Nobody looks: There is no fix, there is a restart. By this point you do not correct a drift, you implement again. And the second time is harder than the first, because the team already has the experience that the previous system did not work, even if what did not work was the support around it.

The route is illustrative and describes the pattern that repeats, not the measurement of a customer. The exact weeks vary with each team, the order of the steps almost never does.

Why does the week somebody looks decide the cost?

Because what changes isn't the route, which is always the same, but the point where it gets cut.

In week 2 the spreadsheet is still a copy: it holds no data the system doesn't have. It takes understanding why it exists, solving the case that person can't solve in the system, and agreeing on a date to shut it down. Ten minutes of conversation, and nothing to recover.

In week 6 some cases live only there. On top of the conversation, those cases have to be moved into the system and the missing field has to be covered. It's days of work, and the team hasn't stopped using the system yet.

In week 12 you have to reconstruct the real state of open cases, decide which of the two sources wins, and retrain the team. The expensive part isn't that work: it's that the system lost credibility, and that doesn't come back by migrating data.

If nobody ever looks, there's no correction, there's a restart. And the second implementation is harder than the first, because the team already has the experience that the previous one didn't work, even if what didn't work was the support around it.

Why does the backup appear?

Because it's an insurance policy, and nobody trusts a new system by decree. The person who built that file three years ago knows exactly what happens when something gets lost inside it, and doesn't yet know what happens when something gets lost in the new system.

Keeping it costs little in the first weeks. Two minutes per case, and it buys peace of mind. Nobody decides to create a parallel system: they decide not to let go of the one that worked for them.

What does it look like before anyone says it?

Four things happen before the topic reaches a meeting.

Someone asks for a full export to keep a copy. There are fields nobody fills in, and they're exactly the ones being written down somewhere else. Team questions get answered without anyone opening the system, because one person has the answer at hand. And a shared file appears with the process name and a date in the title.

None of the four is a complaint. That's why they never reach the check-in call, where everyone says things are going well.

What shouldn't you do when it appears?

Ban it. That's the most common reflex and the worst one, because it removes the signal from view without addressing the reason, and the next version of the backup will live in a personal file where nobody can see it.

A shadow spreadsheet says one of two things, and both are useful: either that person wasn't trained on their specific case, or the system doesn't cover their specific case. The first takes an hour to fix. The second is a free product request, and it's usually real: somebody found the edge of the design before we did.

The script for the conversation when the spreadsheet appears

Five questions, in order, with what to listen for in each answer.

1. What information goes into the spreadsheet and not into the system? If the answer is "the same things", it's still a copy. If a field of their own shows up, that's the gap in the system.
2. Was there ever a time the system didn't have the answer? Look for the specific episode, not the general opinion. The backup almost always starts with one case that went wrong.
3. If the spreadsheet couldn't be opened tomorrow, what would be lost? The answer tells you whether data already lives only there, which is what separates a ten-minute conversation from a project.
4. Who else looks at it? If someone else on the team checks it, it stopped being a personal backup and is already the group's source.
5. What would have to happen to stop maintaining it? It's the only question that produces a shutdown date, and with no date both paths coexist forever.

What do you look at instead of satisfaction?

What share of the process's cases went through the system. Not how many cases there were, and not whether people say they like it, which is a question that almost always gets a yes.

Someone can think the system is excellent and not use it, and those two things coexist without contradiction for months if nobody looks at the number.

What do you do in week one so it never appears?

Three things, all of them management rather than product.

Train by role instead of by tool, so nobody sits through two hours of features they'll never touch. State who fixes what and how fast, because the backup is born from the fear of having no way out. And set a shutdown date for the old path, communicated before launch. With no shutdown date, both paths coexist forever, and the new one loses badly because the old one already knows how to work.

We stay watching usage through the entire first month instead of disappearing the day after training. That isn't generosity: the difference between week 2 and week 12 is the difference between a conversation and a reimplementation.

How many of the spreadsheets currently coexisting with a system started out as a temporary backup? The answer is usually all of them.