Find the workaround

You have watched Marta do the Thursday update, so you know about the spreadsheet. You probably dismissed it in the same second you saw it, the way everyone does: she’s using a spreadsheet because the tool is bad, and once we fix the tool the spreadsheet goes away.

Open it anyway. That file is the most carefully specified document anyone at your company has produced about this problem, and nobody wrote it on purpose.

A workaround is a specification that has already shipped

Think about what it took to exist. Somebody hit a problem, invented a process, ran it, found it broken, and fixed it. Then they ran it again the next week, and the week after that, for two years. Every column in that file survived contact with a real Thursday.

That is not a wish list. It is a requirements document that has been through more iterations of real-world testing than anything your team will ship this quarter, and it contains the two things you never get from a meeting: the exceptions, and the order of operations.

Nobody volunteers exceptions in a meeting. Ask Marta what she does when someone is on parental leave mid-transfer and she will say oh, that hardly ever happens, because it hardly ever happens. It happened six times last year, and there is a column in the spreadsheet that handles it.

The move

Before you design anything, open the file they built by hand and read every column as a requirement somebody already paid for.

How to read one

Columns are fields you are missing. Each one exists because the information was needed and your product did not supply it in a usable place.

Colour is state. Yellow means changed, red means check this, grey means done. Somebody built a status model in cell formatting because the real system has no way to express it.

The notes column is the exception log. This is the richest part of the file and the part most likely to be dismissed as mess. It is not mess. It is every case your data model cannot represent.

The duplicated tab is an audit requirement. If there is a sheet called DO NOT DELETE or old_Q3, somebody once had to prove what a value used to be. Nothing in your system let them.

Thursday.xlsx                        WHAT IT SPECIFIES

A  employee_id                        the join key, and not email,
                                        because contractors have none

B  name                               she does not trust the id alone
                                        and wants to eyeball it

C  cost_centre_old   ] yellow         before and after, visible at once.
D  cost_centre_new   ]   when they      our screen shows only current
                        differ

E  effective_date                     changes can be backdated. our
                                        model has no concept of this

F  checked?  y/n                      it is a two-pass process: she does
                                        a pass, then verifies it

G  notes  "ignore, on leave           the exception log. about six a week,
          until 4 Nov"                  every one of them different

  rows 2 to 40 are this week.
  the tab named DO NOT DELETE is last quarter, kept because
  payroll asked her to re-run one in March.

Column E is the interesting one. Nobody has ever filed a ticket asking for backdated cost-centre changes. It is not in the request, it is not in the roadmap, and if you ship the bulk-edit feature as specified, Marta keeps the spreadsheet forever, because the spreadsheet is the only thing that can express a change that starts next month.

The tell

If you only have time for one question, ask this: which part of this do you redo by hand every single week?

Not the annoying part. The repeated part. Annoyance points at friction, which is worth fixing. Repetition points at something the system cannot do at all, which is worth building.

What it costs

A workaround encodes the constraints of the person who built it, and some of them have expired. Marta may be pasting into a third sheet because of a permissions problem that was fixed eighteen months ago. If you treat the file as sacred you will faithfully rebuild an obstacle course.

So read it as evidence of what she needed, never as a design. The column that says she needed to see before and after together is durable. The three-sheet copy-paste dance that got her there is not.

It also flatters the loudest workaround. The person who built a spreadsheet is, by definition, the person with enough time and skill to build a spreadsheet. Somebody else with the same problem may have simply given up, and given-up is invisible. Ask who else does this job, and whether they do it the same way.

And people are embarrassed by them. Expect oh, this is a mess, ignore it. It is not a mess, it is the spec, and saying so out loud is usually the moment the conversation gets good.

Try this week

Find the file. There is always a file.

Ask for it directly, and lower the stakes when you do:

Could you send me the spreadsheet you use for this? Not to judge it, honestly the opposite. It tells me what the system should have been doing and I’d rather copy it than guess.

Then open it and write one list: every column, and what each one means the product currently cannot do. That list is longer than the ticket, better sourced than the roadmap, and it took you twenty minutes.

Bring it to whoever wrote the ticket. You are no longer arguing about a feature, you are showing them a document their own colleague maintains, which is a much shorter conversation.