IT Myths: Our Tooling Is Fine
The myth
“Our tooling is fine.” The monitoring works, the tickets get logged, the dashboards look busy. Nothing is obviously on fire, so the tools must be doing their job. And because they’ve been around for years, nobody really questions them.
The problem is that “fine” usually just means “familiar.” Teams learn to work around gaps, ignore noisy alerts and treat missing data as normal. Over time, that slow drip of friction becomes part of how the organisation operates.
The reality
Tooling shapes behaviour. Poor tooling shapes poor behaviour. If your monitoring is patchy, you get reactive teams. If your CMDB is unreliable, decisions depend on guesswork. If your service desk is clunky, people bypass it and support happens in chat threads and email instead.
None of that shows up as a single dramatic failure. It shows up as delays, confusion and “we’ll just fix it manually for now.” On paper, the tools exist. In practice, they’re holding the team back.
How “fine” tooling shows up in real life
- Monitoring nobody fully trusts: alerts are noisy, so teams quietly ignore half of them.
- Ticketing that’s there for the numbers: records written after the fact to keep reports tidy.
- Spreadsheets everywhere: people maintain shadow data because the “official” system is wrong.
- Dashboards that look good but say little: graphs for graphs’ sake, not decision support.
- Orphaned tools: platforms bought for a project years ago that nobody quite owns anymore.
The impact
When tooling doesn’t support the way you actually work, effort leaks out in a hundred tiny ways: duplicate data entry, manual reconciliations, chasing people for updates that should already be visible. Incidents take longer to diagnose because the data is incomplete or scattered.
For SMBs, there’s a financial cost too. Tool sprawl is common -- overlapping products, unused modules and legacy licences kept “just in case.” The spend is real, but the value isn’t. Money that could fund a smaller, better designed toolset ends up tied to platforms nobody wants to touch.
What good looks like
- Monitoring that highlights what matters, not everything that could possibly change.
- Service data that’s trusted enough to drive decisions without side conversations.
- Clear ownership for each tool, including who defines standards and keeps it tidy.
- Integrations that remove manual steps rather than creating new places for things to break.
- Regular reviews that ask, “Does this still earn its place?” instead of assuming it does.
The fix
- Get honest feedback. Ask the people who use the tools every day which ones slow them down.
- Map what each tool is really for. List the services it supports and where it feeds data.
- Spot overlap. Identify tools doing the same job badly in three different ways.
- Retire and simplify. Turn off unused features and plan to remove tools that don’t earn their keep.
- Design around services, not products. Choose tooling that supports how you want services to run.
First steps this week
- Pick one service and list every tool it relies on — monitoring, tickets, docs, reporting.
- Ask the team which of those tools they’d drop tomorrow if they were allowed to.
- Choose one small change -- reduce alert noise, remove a duplicate report or close a tool nobody owns.
Bottom line
“Our tooling is fine” is rarely true. It usually means “we’ve learned to live with the pain.” The aim isn’t to chase shiny new platforms. It’s to clear the clutter so your existing tools, people and processes can actually work together.
If you want to talk more, I can help. Let’s have a chat.