Stop Building Internal Tools
When you run into friction or a manual process at work, what do you usually do?
For many engineers, the answer is to build a new tool.
You see something slow, repetitive, or error-prone. You understand the system well enough to automate it.
So naturally, you focus on solving the problem with code, especially when changing a process or behavior requires a bunch of coordination and follow-through.
And with AI tools accelerating development, it's easier than ever to turn an idea into something usable. What used to take days can now take hours.
The challenge is that speed removes a natural forcing function. The effort required to build something used to slow you down just enough to think through the implications. When that friction disappears, it becomes easier to ship tools without fully understanding what they will change, or whether they should exist at all.
Internal tools are rarely expensive to build. They can be expensive to live with.
Where Internal Tools Fall Short
Most internal tools don't fail because of poor implementation. They struggle because they don't actually improve the system they are inserted into.
A tool gets introduced, but the spreadsheet it was meant to replace sticks around "just in case."
People continue asking questions in Slack because it's still faster than opening another tab.
The old workflow never fully goes away, so the new one becomes optional.
Over time, this adds up. Each new tool introduces another place to look, another decision to make, another interruption in the flow of work. Nothing is broken, but everything feels heavier.
This is the same dynamic that shows up when work is constantly handed off without clear ownership. You may recognize this pattern if you've ever dealt with stories bouncing back from QA or product because "done" wasn't actually well defined. That loop is expensive, even when each step seems reasonable.
Research on developer experience consistently points to this system-level problem. Increased cognitive load makes it harder to focus on the work that actually matters, even when the individual pieces all seem helpful in isolation. Work published through ACM Queue highlights how friction accumulates across tools and processes rather than in any single decision.
Internal tools often contribute to this unintentionally because they are built as helpers rather than replacements. They make certain tasks easier, but they don't take ownership of them.
By the time this becomes visible, the tool is already "done," and unwinding it feels harder than living with it.
How to Think About Internal Tools
The shift that tends to change outcomes is moving from convenience-based thinking to system-level thinking.
Before you think about what to build, you need to be clear about how work is supposed to change.
A practical way to pressure-test this early is to ask:
Once this tool exists, what work should no longer happen?
This pushes you to identify a concrete behavior, artifact, or handoff that should disappear. If nothing is clearly being removed from the workflow, the tool is likely to sit alongside existing processes rather than simplifying them.
This way of thinking lines up closely with how effective teams approach prioritization more broadly. When work isn't clearly connected to removing friction or improving flow, it's easy to turn it into "busy work" that feels productive but doesn't move anything forward.
Guidance from DORA reinforces this framing. Internal platforms and tooling are most effective when they reduce cognitive load by taking responsibility for complexity that would otherwise be pushed onto individual developers.
This doesn't mean every tool needs to be large or centralized. It means that even small tools should be opinionated enough to define how a task is done to avoid complicating the process.
Tools that try to accommodate every possible workflow often reinforce the status quo. Tools that clearly replace a specific way of working are the ones that actually change behavior.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
How to Measure the Value of a Tool
One reason internal tools are hard to evaluate is that their value rarely lives inside the tool itself.
If a tool is doing its job, the evidence usually shows up elsewhere.
Instead of focusing on how often a tool is opened or which features are used, look for changes in the surrounding system:
- A manual report stops being generated.
- A recurring question no longer appears in Slack.
- A handoff no longer needs explanation.
- A meeting becomes shorter or unnecessary.
These signals are less convenient to track because they don't live in a dashboard. They require paying attention to how work flows across the team.
This mirrors a broader challenge with how teams talk about productivity. Measuring activity is easy. Measuring impact requires more judgment and context. Research on developer productivity consistently warns against relying on single metrics or surface-level signals when evaluating effectiveness.
If you had to explain why the tool was worth building without showing the interface, could you do it?
If the value only becomes clear during a demo, that's a sign the tool may be adding capability without removing work.
How to Get Everyone Bought-In
Getting buy-in for an internal tool is often framed as a persuasion problem. In practice, it's usually a clarity problem.
People resist tools that feel like additions. They are far more receptive when they understand what aspect of their workflow is being removed.
Instead of leading with features, lead with decisions:
- Which workflow is being replaced?
- Which document or process is being retired?
- Where will the new source of truth live?
This approach mirrors what works when advocating for less visible work, such as technical debt. Alignment comes from connecting changes to concrete outcomes rather than asking for trust in the abstract.
AI only complicates this conversation. When tools are cheap to build, it becomes tempting to bypass alignment and "just try something." But while AI reduces the cost of creation, it does nothing to reduce the cost of adoption, maintenance, and quality. If anything, it raises the risk of tool sprawl.
Internal tools can be a powerful way to improve how work gets done. They can also quietly increase friction when they're built without a clear understanding of what they are meant to change.
The difference is the ability to identify whether the tool was designed to replace work, reduce cognitive load, or simplify decisions for the people using it.
How do you approach developing internal tools?