The Tool Nobody Has Questioned

Something breaks. A contract comes up for renewal. A new hire asks why do we do it this way, and can't be given a good answer.

Those are the moments when most tool decisions actually get made, which means they get made under pressure. The result is choices driven by urgency rather than fit.

But the deeper problem sits a layer down, and it's the reason the pressure keeps arriving.

A tool that works and a tool nobody questioned look identical

From the inside, there is no visible difference. The subscription renews. The team keeps logging in. Nothing is on fire. "We haven't changed anything" describes both the system that is earning its place and the system nobody has looked at in three years.

The difference only surfaces when something forces it. A vendor raises prices. A key employee leaves and takes their knowledge of the workarounds with them. An integration won't connect because the tool's API hasn't been updated since it was adopted. By then the decision is already constrained: you're choosing under pressure, with incomplete information, and with a bias toward whatever resolves the immediate pain rather than what fits the business.

Evaluation is the only thing that separates the two states. Not because it produces change. Most of the time it doesn't, and shouldn't. Because it converts "nobody's looked" into "we looked, and it's fine," and those are different facts even when the tool is the same.

A rhythm, not a project

The word "evaluation" suggests something formal. Resist that. What keeps the two states distinguishable is a rhythm small enough to survive contact with a busy quarter.

Quarterly, a pulse check. Five minutes at the end of a meeting that already exists. Is this still working? Has new friction appeared? Are people using the tool as intended, or have workarounds developed? You're not deciding anything. You're noticing.

Annually, one focused hour on the systems that matter most. Does this still fit where the business is heading? Are we paying for things we don't use, or missing things we now need?

And on triggers, regardless of the calendar. A significant hire or departure, a new offering, a growth milestone that changes how work flows. These shift the context enough that what worked before may quietly no longer fit.

Three questions do most of the work

"Is this tool still good?" is too vague to produce an answer. These are sharper:

Does it reduce friction or create it? A tool adopted to make something easier can become the source of its own friction: extra steps, limitations the team routes around, slowness that eats into the day. If it creates more friction than it removes, that's worth seeing clearly.

Does the team use it, or work around it? Adoption is a signal. If people consistently reach for a spreadsheet, a messaging thread, or their own notes instead, that's information. It doesn't automatically condemn the tool, but if the workaround has persisted, something is being routed around for a reason.

Can your data get out? If your data is locked inside a tool in a proprietary format, you've created a dependency that constrains every future decision. Tools that export freely leave you options. Tools that don't have an exit cost you haven't priced in yet.

Is it the tool or the process?

One distinction saves a lot of wasted migrations. A capable tool can feel broken because the process around it is poorly designed, and swapping tools just transfers the dysfunction to a different interface. A sound process can equally be undermined by a tool that can't support it without constant workarounds. Asking "which one is the problem?" before acting prevents cycling through tools while the workflow stays broken. If you've read When to Stop Patching and Start Redesigning, this will be familiar: see the system clearly before deciding what to change.

"Keep going" is a finding

The most common outcome of a healthy rhythm is confirming that things are working well enough to continue. That's not a wasted exercise. It's the whole point.

Without it, "we haven't changed anything" stays ambiguous. After it, "we're keeping this" is a conscious decision, made against criteria, by people who looked. The team uses the tool with confidence instead of the low-grade unease of never having questioned it. And when change eventually is needed, the decision starts from a known baseline instead of from scratch.

The instinct to justify evaluation by the changes it produces is worth resisting. A review that concludes "keep going" has done its job exactly as well as one that leads to a migration.

Keep it too small to cancel

The biggest risk to an evaluation rhythm isn't that it produces bad decisions. It's that it gets abandoned. That happens the moment it becomes heavy: dedicated meetings, reports, multi-week assessments. People do that once, maybe twice, and then quietly let it lapse.

Five minutes every quarter, consistently, beats the exhaustive review that happens once and never again. The moment evaluation becomes a project in itself, people stop doing it. And then you're back to waiting for something to break before asking whether it still works, which is to say, back to not knowing which kind of tool you have.

If you know something in your stack needs looking at but it keeps sliding down the list, tell us what's on it and we'll help you make it a short conversation rather than a project.