The Tool Support Built in a Spreadsheet
Every company has a layer of software nobody decided to build. A spreadsheet that tracks which accounts need the manual fix. A saved query someone runs each Monday and pastes into a channel. A document listing the six steps to correct an order when the automated path fails. None of these exist in a repository, none have owners, and all of them are load-bearing — the business genuinely depends on them, and they were created because the real tooling didn’t cover a case that came up often enough to hurt.
What’s notable is how invisible that process is from the engineering side. The people doing the work don’t experience the gap as a missing feature; they experience it as their job, and they solve it the way anyone would — with whatever they can build themselves in an afternoon. No ticket gets filed because nothing is broken, exactly. The work is getting done. The cost shows up as time nobody measures, spread across people whose calendars aren’t in the planning discussion, and it compounds quietly as the workaround grows more elaborate.
Which makes those artifacts unusually good product signal, if anyone goes looking. A spreadsheet tracking exceptions is a specification for a feature, written by the person who understands the problem best, validated by the fact that they were willing to maintain it manually. A recurring query is a report someone needs. A document of manual steps is a workflow the product should support directly. Reading them tells you what to build with much more confidence than most requirements-gathering does, because the requirement already survived contact with reality.
They’re also a risk register. Manual steps get skipped under pressure, and a process that lives in one person’s head leaves with them. The spreadsheet has no access control, no audit trail, and often contains customer data that the rest of the system protects carefully — which means the same organization enforcing careful data handling in production is quietly duplicating that data into an unmanaged file because the alternative was not doing the work. That’s not a discipline failure; it’s a design failure upstream.
The habit worth forming is simply to go look. Ask what people do that the tools don’t support, and treat the answer as backlog rather than as evidence that support is resourceful. The gap between what a product does and what running the business requires is where this layer grows, and it grows whether or not anyone is watching — the only variable is whether it eventually gets designed, or just keeps accumulating in files that nobody owns.