The internal tool nobody used
Six months of engineering. Three demos to leadership. Logged into twice in production. The tool was a project nobody had asked for.
An engineering team I worked with had spent six months building an internal observability dashboard. The dashboard was technically impressive — real-time, multi-source, with custom alerting. The team had given three demos to leadership. Each demo had gone well. The dashboard had been launched in production with a celebratory Slack post.
Three months later, the dashboard had been logged into twice. Both times by the engineer who had built it. The alerts had fired and been ignored. The dashboard had drifted out of date with the underlying systems. The engineer had moved on to a new project. The dashboard quietly rotted.
The pattern is more common than engineering leadership wants to admit. Internal tools are built from a position of engineering empathy — this would be useful for the team — without a named user who has committed to use them. The engineer's belief in the tool's utility is sufficient justification for the build. The actual operational need is not validated. The tool gets shipped. The use never materializes.
The reason this happens is structural. Internal tools are not subject to the same diligence as customer-facing features. There is no PM writing a spec. There is no design review checking the user flow. There is no sales conversation that has to close. The engineer who proposed the tool is also its only stakeholder, and the only feedback loop is whether other engineers compliment the demo. Compliments are cheap. Daily use is expensive.
The cost is rarely framed as cost. Engineering capacity is the most fungible budget in any company — six months of one engineer's time is, in dollar terms, somewhere between $150K and $250K. The dashboard that nobody uses cost the company at least that, plus the opportunity cost of the revenue features that did not ship. Most engineering organizations do not run this accounting because nobody is incentivized to.
The discipline that prevents this is small and almost always skipped. Before any internal tool is built, a named user must agree, in writing, to use it daily for at least three months after launch. The named user is not the engineer who proposed it. The named user is the person whose work the tool is supposed to make easier. If no such person exists or will commit, the tool is not built. The discipline kills somewhere between half and three-quarters of proposed internal tools, which is approximately the rate at which they would have rotted anyway.
The corollary is maintenance. Every internal tool that survives the launch needs a quarterly maintenance owner who is graded on the tool's continued utility. Without the owner, the tool drifts. The dashboard that worked in January is wrong by June and gone by December.
The internal tool nobody used is not an engineering failure. It is a discipline failure that happened to be expressed in code. Fix the discipline. The tools that survive will be the ones the team actually needed.