The Tools You Shouldn't Change

December 29, 2025 · 592 words · 3 min read

The gap between personal tooling freedom and team responsibility is wide.

In the past year I have changed a lot of things about my setup, from my editor, to my terminal emulator, my container runtime, my AI coding stack, and my entire site framework. I've written about most of these with enthusiasm. At home, I optimize for exploration, and the switching cost is one evening and the upside is mine alone.

At work you need a different mindset.

Earlier this year I found something better than a platform my team uses daily for tracking and coordinating work. Meaningfully better, where ten minutes of use makes the gap impossible to unsee, I ran it side by side for a couple of weeks and pretty much every session confirmed what I saw day one.

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

But when a team switches a coordination platform, the cost is never limited to the migration, you look at weeks of people rebuilding small intuitions they don't even know they have. Where to look for the thing they need. Which view gives them the answer without three clicks. How to structure a morning check-in so it takes two minutes instead of ten. That knowledge lives in muscle memory, not in any documentation, so when you rip it out you're asking everyone to be slightly worse at their job for a month while new habits form.

I am planning to write a separate post about the productivity industry and their tendency to sell the idea that the right system fixes everything. Tooling churn at the org level is the same trap! Just in engineering clothes. You end up trading known frustrations for unknown ones, and for a few weeks your team navigates with the lights dimmed while you, the one who pushed for the change, already have the map. And people will slightly resent you for it, rightfully so, even if the change is objectively good.

I also have to be honest about my motivation, because some of it was good intention. But some of it was restlessness, 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 and mentioned the alternative in a conversation, said what I liked, then let it go. Nobody asked me to and I didn't push, I just ran the math on disruption versus improvement and disruption won, because the improvement was mine and the disruption would be everyone's.

The thing is, this didn't feel like wisdom, it just felt like leaving something on the table, something valuable. I still open the alternative on my own machine sometimes. Every time, same twinge. The discipline isn't in not seeing the better option, everyone can do that and call themselves wise. Seeing it clearly and choosing not to act because the context demands something other than optimization. I've long felt that preserving difficulty is sometimes the point, how friction keeps you connected to the work. This is similar but the stakes are different.

Some future version of this story ends with the switch actually happening, when the timing makes sense and the improvement outweighs the disruption by enough margin. That version might arrive in six months or not at all. Either way, the restraint is just a bet I keep placing that stability is worth more than I want it to be.