December 29, 2025/543 words/3 min read

The Tools You Shouldn't Change

Changing a team tool means making everyone relearn how to work.

In the past year I have changed a lot of things about my setup. I moved to an editor that handles AI better and a terminal emulator that does no AI at all. My container runtime got way better along the way, and I even moved this entire site to Next.js. I've written about most of these with enthusiasm. At home, I optimize for exploration. The switching cost is one evening, and the upside is mine alone.

Changing a tool at work makes everyone pay the switching cost.

Earlier this year I found a better alternative to a platform my team uses every day to keep track of work. It was meaningfully better. Ten minutes of use made the gap impossible to unsee, and a couple of weeks running both side by side confirmed what I saw on day one.

So I wanted to switch, and the pull was strong! It was the same pull that moves me from one tool to another at home, except there I just act on it. That muscle is well-trained by now.

When a team switches a coordination platform, people spend weeks rebuilding small intuitions they don't even know they have. Someone who has used it for months doesn't stop to wonder whether CMD+K will find what they need or which view has the answer without three clicks. Their morning check-in takes two minutes instead of ten because the structure is already familiar. That knowledge lives in muscle memory, not in documentation. When you rip it out, everyone gets slightly worse at their job for a month while new habits form.

I'm planning a separate post about the productivity industry's tendency to sell the idea that the right system fixes everything. Tooling churn at the org level is the same trap in engineering clothes. For a few weeks, everyone else is slower while you, the person who pushed for the change, already know where everything is. People will slightly resent you for it, rightfully so, even if the new tool really is better.

I meant well, but restlessness was part of my motivation too. It was the same itch I scratch when I change my terminal emulator or rethink my dotfiles. At home that itch is harmless, but at work everyone pays for it.

So I kept the existing tool. I brought up what I liked about the alternative in one conversation, but nobody asked me to switch, so I left it there instead of pushing. When I ran the math, the improvement wasn't enough to make everyone else absorb the disruption.

Keeping the tool felt like leaving something valuable on the table. I still open the alternative on my own machine sometimes. Every time, same twinge. What made it hard was seeing the better option clearly and deciding the context mattered more than optimization. I've long felt that preserving difficulty is sometimes the point because friction keeps you connected to the work. This felt similar, but here other people would have paid for my choice.

The switch might still happen in six months, when the timing is better and the improvement is large enough to justify making everyone relearn the system. It might not happen at all. For now, we keep the tool we already know.