Your Team Shouldn't Need Workarounds to Do Their Jobs

Walk through your operation and you will find systems your team built that nobody on the leadership side signed off on: a spreadsheet bridging two tools, a Slack channel running approvals, a standing meeting that exists only to reconcile what two systems say. 

Together, they are how the operation actually runs, and the official tools you bought have stopped reflecting what the team is doing.

The parallel version exists because the systems you bought did not fit the work the team had to do. 

The workarounds are how they kept doing their jobs anyway. By the time leadership sees them, the team has been carrying the operation on top of them for months.

‍

Every workaround your team built is data

The temptation, when leadership notices the workarounds, is to read them as a team problem. 

The people closest to the work built something off the official plan, and now leadership wants to know why. 

The question pushes the workarounds further into the dark instead of surfacing what they are saying.

A workaround is data. 

Each one points at a specific place where the systems you bought did not fit the work, and once you know what to look for, the most common pairings are easy to spot:

• A spreadsheet between two systems points at an integration dropping the data the team needs to act on
• A standing meeting to reconcile reports points at a reporting layer that has stopped agreeing with itself
• A Slack channel running approvals points at a workflow tool slower than the business can wait
• A senior person holding institutional knowledge points at a system that does not capture context the team needs
• A manual Friday status report points at an auto-generated one that has been wrong enough times to lose the team

The walkthrough that surfaces these takes an hour with each functional team, and it does not need a consultant or an audit tool. 

Ask the team to walk you through how a transaction actually moves through their part of the operation from start to finish. Every place they reach for something that is not the official system, write it down. 

Every time they say "we have to talk to [person] before we can do that," write it down. 

The most informative answer of all comes when they describe a workaround as "just how we do it now," because that phrase points at the workarounds that have become invisible even to the team running them.

Read the workarounds by elaborateness and you have a ranked map of where to invest next. 

Whichever one took the most ingenuity to build is the most expensive seam. That is the one to look at first.

‍

What carrying this costs

The cost of running on workarounds does not show up on any dashboard the leadership team looks at. 

Asana's Anatomy of Work research found that knowledge workers now spend about 60% of their time on what Asana calls "work about work": coordination, status chasing, tool switching, and the small reconciliations that keep workflows moving. 

The actual deliverables get the remaining 40%. Gloria Mark's long-running research at UC Irvine added the other half of the picture. 

After a single interruption, it takes the average person 23 minutes to get back to the level of focus that was lost.

The real cost lives in the hours your senior people spent reconciling, and in the ones who are looking at other jobs because the operation feels harder than it used to. 

None of that lands on a productivity dashboard, which is busy counting tickets closed and deliverables completed. 

The dashboard can stay flat or rise while the team running the operation grows more tired and more expensive.

‍

When the team stops trusting the software

The deeper cost takes longer to surface. When the systems do not agree with each other, people stop trusting any single one of them. 

Operations leaders double-check numbers before standups because being wrong in public has a cost, and finance ends up building parallel reports to explain discrepancies it did not create. At the executive level, decisions get delayed, less because anyone lacks conviction and more because the conviction is not matched by what the data is showing. 

What you have at that point is software the team has stopped trusting. The tools technically work, but the team has decided the actual source of truth lives somewhere else, in a Slack thread or a spreadsheet or in the senior person who has been with the company longest. 

The software is running but the business is being run on something underneath it.

The internal documentation suffers next. Shared docs, wikis, and onboarding materials drift from the actual process. 

New hires get trained on the official version and learn the real version from the senior person who has become the actual source of truth. The institutional knowledge moves further out of the system and deeper into the people, which is the version of the problem that is hardest to fix later. 

By then, the system documentation has become an artifact rather than a guide, and the operation runs on a version of itself nobody has written down.

We believe that business is built on transparency and trust, and that good software is built the same way. 

Software gets used the way it was designed when the team trusts it. The workarounds are how your team tells you that trust has been gone for a while.

‍

The fix has an order, and tools come last

The way to do this work is to start with the workarounds. The technology choice comes after. The integration spec comes after that.

We start every engagement now by asking the team to walk us through what they are doing by hand to make the systems work: the spreadsheets they maintain, the meetings that exist only to reconcile two tools, the one person they have to check with before they trust a number. 

The walkthrough shows the actual operation, not the documented one, and that is where the build has to start.

From there, the order is the same in every operation we have seen:

Name the workaround. Get a written list of every place the team is compensating by hand. The list will be longer than leadership expects. The work that maintains those workarounds has become invisible enough that nobody on the team would have flagged it without being asked directly.

Find the seam underneath it. The workaround is the symptom. The seam between two systems, or between a system and a process, or between a role and the information that role needs, is what the workaround was invented to bridge. The seam is where the next investment belongs.

Redesign the process so the context lives in the system. The team carries knowledge by hand because the system does not capture it. Designing for that capture is most of the actual work. It is also the step most projects skip, which is how new tooling ends up landing on top of the same broken process. A useful test: if the senior person carrying the most institutional knowledge left tomorrow, could the operation keep running? If the answer is no, the system is not holding what it needs to hold.

Then, and only then, decide whether new tooling helps. A new tool on a redesigned process changes the operation. A new tool on the old seams becomes part of the workaround layer the team ends up routing around. The tooling decision is the easier one once the first three are done correctly.

The order is not optional. 

The same step in the wrong place is the difference between a build that absorbs the workarounds and one that adds to them. 

We have run this order on engagements like the Quickrose operations platform we built for Witherspoon Rose Culture, where the institutional knowledge that used to live in three people's heads now lives in the system and the senior team stopped spending Tuesday reconciling.

‍

Where to start

You do not need a budget approval to find your worst workaround. You need an hour with your team and a willingness to take what they tell you seriously.

The walkthrough itself works like this. 

Pick a function in the operation that has the most workaround chatter: sales, support, finance, or operations, whichever the team complains about most. 

Sit with them for an hour. 

Ask three questions, and write down every answer:

• Walk me through how this work actually gets done from start to finish
• Where does the official process break down, and what is the workaround you have built around it
• If you could fix one thing about how the systems support this work, what would it be

The third question points at the most expensive workaround in that function. The team usually answers it in the first thirty seconds, because they have been thinking about the answer for months.

Take the answers from each function and rank the workarounds by elaborateness. Whichever one took the most ingenuity to build is the seam costing you the most. 

Trace that seam back to the system or process that should have held the work and could not, and you have your next investment, identified before anyone writes a tool selection memo.

The pressure to add AI is real and it is not going away. Boards keep asking. Competitors keep announcing. 

The path of least resistance is to point a model at the same seams the team is already working around. That stays productive right up until the model adds another layer of verification work on top of the senior people already doing more than they should be.

If your team has been telling you for months that the systems do not fit the work, they are telling you something true. 

The workarounds are how they are managing it without your help. They should not have to.

Name the workarounds in order of elaborateness. 

Trace each one to the seam underneath. 

Whether you take that work on inside the organization or bring it to a firm like Big Pixel, the order is the same. 

Start with the workarounds. 

The tool comes last.