The tool is not the bottleneck. The channel is.

Halfway through a rollout, an advisory firm I work with ran an honest self-assessment: effectiveness 7 out of 10, efficiency 4 out of 10. The instinct in that gap is to buy something, or to train harder. Both would have been wrong.

The number nobody wants to write down

Two ratings came out of that review. Doing the right things: 7 out of 10. Doing them efficiently: 4 out of 10. Then the more uncomfortable one — the principal rated their own proficiency with the firm's tools at the bottom of the scale, unprompted.

That is not a knowledge gap you close with a webinar. The team is excellent at its actual craft. Everything outside that craft simply costs them far more time than the plan assumed, and the plan had quietly priced that at zero.

What we stopped doing

The first decision was subtraction. Every new initiative on the roadmap got paused until the people using the current setup signalled they were ready for more. The hours freed up went back into the tools already in place — not into rollout number four.

This is the part that is hard to sell, including to yourself. Pausing looks like standing still, and an automation budget is easier to defend with new capability than with adoption of old capability. But shipping a fifth system into a team that has not absorbed the second one does not add capacity. It adds surface area.

Channel fit beats training

The pattern underneath the efficiency score turned out to be about delivery, not ability. Written summaries were not being read — stated plainly: no time to read. What got agreed in a working session with one person did not reach the other. The information existed; it just never landed.

So the experiment became per-person rather than per-tool. One channel per stakeholder, tested rather than assumed: a two-minute screen recording instead of a written update, a spoken walkthrough, a single number in the one report someone actually opens. The content stayed the same. Only the container changed, and the container was the variable that mattered.

The same logic produced the least sophisticated artefact of the whole project: a one-page visual map showing the old folder structure colour-matched to the new one. It lives inside the shared drive itself, not in a wiki, not in a whiteboard tool. Anything that requires opening a fourth application to answer "where did my file go" will not be opened.

Move the data, not the person

A related case: a stakeholder outside the organisation would not enter participant data into the prepared structure. Instead they emailed a spreadsheet in their own format, with columns missing.

The reflex is to insist on the process. The cheaper move was to accept the spreadsheet and use an LLM to reshape it into the target structure — add the missing columns, split it across the intended tabs, then have a human verify the result. Ten minutes, no negotiation, no training session about a system this person will touch twice a year.

Choose deliberately which participants have to change behaviour. For anyone at the edge of the process, meet them where they already are and absorb the mismatch on your side.

Route people like tickets

The last change was governance, and it was the cheapest one of all: when the principal raises a technical issue, it gets forwarded to whoever owns that area, instead of being solved by whoever happens to be in the conversation.

Handling it yourself feels responsive and quietly makes you a single point of failure. It also duplicates work that the owner will do again later, properly. Roles were already defined on paper — the fix was not a new document, it was actually using the routing that existed.