The pattern behind the annoying step
This is normal, and it's fixable once you can see why it's there — no org chart or consultant needed. 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 have probably already named yours.
That step is rarely random. It almost always sits exactly where two teams — or two tools, each owned by a different team — stop talking to each other. The spreadsheet is not just tracking the work. It is quietly showing you where your organisation's communication breaks.
Conway's law, briefly
In 1968 Melvin Conway argued that any organisation that designs 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 are 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, and found the loosely coupled teams' products were reliably more modular — split along the same lines as the teams that built them (MacCormack, Rusnak and Baldwin, Research Policy, 2012). That is measured evidence, but it is 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 organisational boundary without asking anyone, just by reading the file:
- Who can change which tab. A tab that only one person edits, while everyone else only reads it, marks an ownership line.
- Whose export lands in it. A block of pasted values with a different date format or column order than the rest of the sheet 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 — another sign of a one-person handover.
- Where the formula style changes. A shift in naming, structure or formula style partway down a sheet usually 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 — and if the two teams either side of that boundary still don't talk to each other directly, the workaround grows back. The organisation hasn't changed how it communicates, so it needs somewhere to put that gap again. Give it a year and there is 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 are 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 to do it.
- 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 of the boundary is patching the symptom.
What done looks like
Done is measurable: either the hand-off no longer exists, or it has one named person or system responsible for it — not "the team," not "whoever notices." If you can't point to that, the fix isn't finished yet, however tidy the spreadsheet looks.