How to Tell If Your Team Is Working Around Software Instead of With It

There’s a quiet diagnostic that tells you whether your software is working. It’s not in the analytics. It’s in how your team behaves around the software. Specifically: are they working with it or around it?

Five signs your team is routing around the system

• They export data to spreadsheets to do real work
• They send information by email that “should” be in the system
• They keep separate Slack channels or docs that mirror what the system holds
• They build personal shortcuts (saved searches, bookmarks, copy-paste templates) to avoid the system’s defaults
• New hires get an oral history that contradicts the official documentation

One or two of these is normal. Four or more means the system isn’t doing its job. Your team has decided, collectively but silently, that working around the tool is faster than working through it.

Why this matters more than analytics suggest

The analytics inside the software will show “high usage” — because the team is logging in. They’re just not doing the real work there. The real work is happening in the shadows.

This is dangerous because leadership thinks the software is working. The team knows it isn’t. The gap between perception and reality compounds.

The data integrity cost

When work happens outside the system, the data inside the system becomes unreliable. Reports look right but reflect partial reality. Forecasts get built on incomplete inputs. Decisions follow.

One commercial mover I worked with had a CRM with 100% utilization (every rep logged in daily) and a sales process running mostly in a shared Google Sheet. The CRM analytics looked great. The forecast was off by 20%. Leadership couldn’t figure out why until they watched what the reps actually did.

Why workarounds happen

Three common reasons:

The system is too slow. Filling out the official process takes 10 minutes. A workaround takes 2. The team picks 2.

The system asks for data the user doesn’t have. Required fields the rep can’t answer at the time. So they fudge or skip.

The system’s output isn’t useful. The reports it generates don’t help the team make decisions. So the team builds their own reports somewhere else.

None of these are user problems. They’re design problems. The fix isn’t more training or stricter policies. It’s making the system worth using. (See How to Build Software Around People, Not Just Processes.)

What to do

The size of the gap tells you how broken the software fit is. If the gap is small, your software is working. If it’s large, you have a real problem the analytics aren’t showing you. The fix is making the software fit how the team actually works.