Count the systems before calling the team slow

The task took ten minutes. Recording that it was done took fifteen: mark it in the project tool, move the CRM stage, tick the row in the tracking spreadsheet, post in the team channel, email the client. Five places to say one thing, and by Thursday two of them disagreed. From your chair that looks like a slow team. From theirs it is a week spent telling systems what the other systems already know.

Every boundary between tools is a handoff

A person crossing from one system to another does five small jobs nobody wrote down. Find the right record. Translate what the last tool meant into what this one expects. Re-key or copy the fields. Check that the target accepted them. Remember where the next step lives. None of those jobs shows up on a timesheet, and none of them is client work.

Multiply that by the tool count. Intuit's 2026 survey of 725 accounting and bookkeeping professionals, three quarters of them at firms under a hundred people, found the average firm runs ten applications, fewer than half of them fully integrated, and loses about five hours per person each week moving, re-entering, and reconciling information between them (Intuit QuickBooks, 2026). That is a United States sample of accountants, but a Canadian brokerage or advisory practice with a CRM, a back office, a compliance portal, an e-signature tool, and a shared drive runs the same arithmetic. Five hours a person across a team of twenty is a hundred hours a week spent as the wiring between systems that were supposed to talk to each other.

The eighth system rarely retires the seventh

Nobody plans to run ten tools. Each one arrived to solve one problem on the day it was the loudest problem: the CRM for the sales side, the project tool for the delivery side, the spreadsheet when the project tool could not produce the one report a partner wanted. Each purchase was reasonable. The retirement that should have followed never happened, because retiring a tool is a project and buying one is a purchase order.

The most expensive version is the consolidation that did not consolidate. A firm buys the eighth system to replace the other seven. Eighteen months later it runs eight. Migration stalled at the hard part, two teams kept their old tool for the one thing the new one could not do, and now every record lives in two places with a person keeping them in sync by hand. The project that was meant to remove a boundary added one.

Adding a tool and removing a boundary are different jobs

The instinct when the team looks slow is to buy something faster. It usually fails, because speed inside a tool was never the problem. The time goes at the edges, in the crossings between tools, and a new tool adds edges.

Removing a boundary means one of three things. Retire a system and move its one irreplaceable report into something the firm already runs. Name one system as the operating record, so that when two disagree nobody has to call a meeting to decide which is true. Or automate the crossing, so that when a stage changes in the CRM, the project tool, the spreadsheet, and the client email update themselves and the person does none of it. Each of these takes the tool count down or takes a human out of the middle. Neither happens by adding a licence.

A firm of ten to fifty people runs a small enough set of tools that the boundaries can be listed one by one. This is not the enterprise problem of hundreds of applications. It is a finite map, and the expensive people acting as middleware between specific systems can be named.

Start by counting where done gets recorded

Pick one task the team finished this week. Ask the person who did it how many places they had to record it before it counted as done, and have them include the chat post and the client email. That number is the boundary count for one workflow.

Then take each place on the list and ask who reads it and what they would do differently if it went blank. A place nobody reads is a boundary to remove. Two places that hold the same fact are a disagreement waiting for Thursday. Do this for one workflow, not all of them. The count will tell you more about why the team looks slow than any performance review, and it costs one conversation.