The pattern behind the annoying step
Every workbook has one step nobody likes.
Someone exports a report from one system and pastes it into another. Someone rebuilds the same tab every Friday by hand. Someone emails a file to someone else, who copies numbers out of it.
You've probably already named yours.
That step is rarely random. It almost always sits exactly where two teams stop talking to each other, or where two tools owned by different teams do. The spreadsheet isn't only tracking the work. It's quietly showing you where the organisation's communication breaks.
This is normal, and it's fixable once you can see why the step is there. No org chart, no consultant.
Conway's law, briefly
In 1968 Melvin Conway argued that an organisation designing a system ends up with a system that copies the organisation's own communication structure (Conway, 1968).
Teams that talk daily end up with tightly linked parts. Teams that barely talk end up with a handover between them. A file, an export, an email, standing in for the conversation they're not having.
Later research tested this directly in software. MacCormack, Rusnak and Baldwin compared products built by tightly coupled teams against similar products built by loosely coupled ones. They found the loosely coupled teams' products were reliably more modular. Those products were split along the same lines as the teams that built them (Research Policy, 2012).
That's measured evidence, and it's about software architecture, not spreadsheets. Reading your workbook the same way is a reasonable inference, not a proven finding. Say that plainly to yourself before you act on it.
Finding the seam in your own workbook
You can usually find the boundary without asking anyone, just by reading the file.
- Who can change which tab. A tab one person edits while everyone else only reads marks an ownership line.
- Whose export lands in it. A block of pasted values with a different date format or column order came from someone else's system.
- Who emails whom. If a number only updates after an email arrives, the email is doing the work the spreadsheet should be doing.
- The cells nobody dares touch. Cells everyone avoids are usually the ones only one absent person understands.
- Where the formula style changes. A shift in naming or structure partway down a sheet marks where one person's section ends and another's begins.
Why a fix that ignores this comes back
You can clean the data, tidy the formulas, even automate the export.
If the two teams either side of that boundary still don't talk to each other, the workaround grows back. The organisation hasn't changed how it communicates, so it needs somewhere to put the gap again.
Give it a year. There's a new manual step standing in the same place, doing the same job.
Reading keep / clean / connect / convert against the boundary
- Keep respects the boundary when the handover is small, rare, and both sides already know who owns it. Leave it alone.
- Clean respects it when the data is fine but arrives in the wrong shape. You're tidying the file, not the relationship.
- Connect respects it when it puts a direct link between the two systems, so the handover stops depending on a person remembering.
- Convert only respects it if the new build gives the handover a single named owner. A convert that automates the mess without naming who owns each side just moves the seam somewhere less visible.
Any fix that skips naming who owns each side is patching the symptom.
What done looks like
Done is measurable. Either the hand-off no longer exists, or one named person or system is responsible for it. Not "the team." Not "whoever notices."
If you can't point at that, the fix isn't finished, however tidy the spreadsheet looks.
The step everyone hates was never really about the spreadsheet. It was two people who needed to talk, and a file standing in for the conversation.