Three signs your team is working around your software

If your team has stopped trusting the system of record, you're not having a tooling problem. You're having a "the work has moved past the software" problem. Three patterns give it away every time: the shadow spreadsheet, the handoff that needs a Slack message to make sense, and the new joiner who gets a hidden curriculum on top of the official training.

Software is meant to make work faster. Sometimes it does the opposite. The thing the company runs on stops fitting the way the company actually works, and the team starts quietly routing around it. You don't see this on a dashboard. You see it in the small, daily, slightly embarrassing places people use to keep the wheels turning.

Here's how to spot it before it gets worse.

1. The spreadsheet that nobody talks about

Every business of a certain size has a master spreadsheet. Pricing, commissions, segmentation, inventory, account ownership, something. The official tool has the data. The spreadsheet has the truth. Senior people quote the spreadsheet in meetings, not the system.

That's the first signal. It's also the most obvious one in retrospect and the easiest one to ignore in the moment, because the spreadsheet works. The person who owns it knows every nested formula and every colour-coded tab. When that person is in the office, things move. When they're on leave, things stop.

The spreadsheet is doing real work. It is also a single point of failure dressed as a productivity tool. We've never walked into a 100-plus person business that didn't have at least one of these. Some have ten.

2. The handoff that needs an explanation

Watch what happens when two teams who share data have to coordinate. Sales updates a deal. Finance needs to bill against it. Operations needs to provision against it. If that handoff requires a Slack message that says "hey, just so you know, the value in field X actually means Y for this record," the system isn't doing its job. The team is.

You can usually find this pattern by reading the #ops or #handoff Slack channel for ten minutes. If most messages start with "FYI" or "quick note on record 4521," the team is paying a tax every day to make the system behave.

The tax is invisible because it's distributed. Two minutes here, five there, an email thread to confirm a number that should have been in the report. None of those are crisis-level. Together they're a full-time job that doesn't appear on any org chart.

3. The new joiner who gets a hidden curriculum

The third signal is the most uncomfortable, because it's the most expensive and the most predictable. New hires get onboarded with the official training: here's the CRM, here's the ticketing system, here's how to log time. Then someone takes them aside and says, "OK, so what the system says is X, but what we actually do is Y."

That hidden curriculum is the gap between the software and the work, made visible. If new joiners need it to be productive, your team has built a parallel operating system on top of the official one. It works as long as the people who know the workarounds are still around to teach them. It collapses the moment they leave.

The hidden curriculum also slows everyone down. New people stay junior longer because they're learning two systems: the real one and the documented one. That's a cost most companies don't notice until they try to scale a team quickly and realise they can't.

Why this isn't a tooling problem

The reflex when you see these signals is to assume the software is bad and should be replaced. Sometimes that's right. More often it isn't.

The work has evolved. New products got added. A new region opened. Sales started using a different qualification model. Pricing got more complex. The team adapted in real time, the way teams do. The system didn't, because nobody was given the time, the brief, or the mandate to update it. So the team built workarounds, and the workarounds became the actual process.

Replacing the system at that point usually fails. The new system inherits the workarounds because the team treats them as requirements. You end up with a more expensive version of the same problem.

The thing to fix first is the gap between what people are doing and what the system thinks they're doing. Sometimes that's a config change. Sometimes it's automation that bridges two tools so the team doesn't have to. Sometimes it's a small, focused build that takes over one specific job the spreadsheet was doing. Replacement is the last option, not the first.

What to actually do when you see the signals

Start by mapping the work. Not what the org chart or the SOP says people do, but what they actually do, on a Tuesday, when nothing is on fire. Sit with three or four people across different teams. Watch them work for an hour each. Note every tool switch, every copy-paste, every Slack message that exists to compensate for a missing piece.

You'll see patterns. The same workaround will show up in different places. The same column will get copied between two tools five times a week. Those are your candidates for fixing first.

The fix is usually smaller than the size of the original system would suggest. The CRM doesn't need to be replaced. It needs a daily job that pushes three fields to the billing system and writes a status back. The spreadsheet doesn't need a new platform. It needs an audit trail, an access model, and one specific operation extracted into a tool that can scale beyond one person's head.

Most of our engagements start here. Not "your software is broken." Closer to "your software is fine, but it's no longer in sync with how the work actually happens, and that gap is costing you more than you think."

A note on AI in this picture

AI doesn't change the diagnosis. It does change what the fix looks like.

The spreadsheet that one person maintains? Sometimes the right move is a small AI-assisted layer that reads the spreadsheet, validates the inputs, and pushes the result to the system of record automatically. The handoff Slack message that explains record 4521? Sometimes a small agent that watches the data, flags the ambiguity, and asks the owner to clarify in-line. The hidden curriculum? Sometimes a model that reads how senior people actually use the system and surfaces those patterns to new joiners during onboarding.

None of these are dramatic. They're not "the AI transformation of your business." They're small, specific bits of plumbing that make the system fit the work again. Done right, they don't replace what the team is doing. They remove the part the team was doing because the system couldn't.

If you recognise yourself in any of the three signs, the work has already told you something. The first step isn't a tool choice. It's admitting the workaround exists.