No Tool Is Set in Stone

Most teams know their tools aren't working. They stay anyway.

Not because the tool is good. Because switching feels expensive. Because nobody knows what the alternative would be. Because the last time someone suggested a change, it turned into a six-month project. Because everything has been built around the current setup and untangling it seems impossible. So the team adapts, works around the limitations, adds workarounds on top of workarounds, and the friction becomes invisible because it's always been there.

This is what happens when change management isn't a company principle. When the default assumption is that tools, processes, and structures are permanent unless there's a crisis. The cost of that assumption compounds quietly over time, and most teams never calculate it.

The alternative isn't chaos. It's building a company from day one where change is expected, planned for, and cheap.

Change management as a design principle

When you set up a team with the assumption that nothing is permanent, you build differently. You don't create deep dependencies on specific tools. You don't let documentation live only in one place. You don't wire your entire workflow to a single platform in a way that makes migration feel like surgery. You keep teams small and autonomous enough that a tooling decision in one team doesn't require a company-wide rollout to change.

The principle isn't "change often." It's "never let the cost of changing become a reason to stay somewhere that no longer fits." That's a subtle but important difference. Frequent switching for its own sake erodes trust and creates instability. But the fear of switching, the kind that keeps teams stuck in tools they've outgrown, is just as damaging and far more common.

In practice, this means communicating from day one that no tool is set in stone. Not as a warning, but as a design principle that shapes how people build and what they hold onto.

What a real migration looks like

We moved from Jira to GitHub Issues to what would have been Motion. Each switch had a reason. Jira had everything we needed but felt heavy, too much overhead for the pace we were moving at. GitHub Issues made sense on paper: already there, one less tool, fits the principle of doing less. In practice it was confusing and unfamiliar in ways that slowed the team down. We knew within days. We stayed a few weeks anyway, because switching immediately would have felt chaotic, and there's a difference between being willing to change and being impulsive about it.

The decision to move was mine. I gave the team one to two weeks to form an opinion, collected that input, and then decided. Not a committee, not a vote, not a month-long evaluation process. A clear owner, a reasonable window, a decision.

What made the whole thing cheap was twofold. First, the infrastructure we had already built. AI and MCP handled most of the migration. The actual switch took seconds to minutes. Getting everyone comfortable with the new tool took a few days, but only when the owner communicated the change clearly and early. Second, we didn't migrate everything. We left the ballast behind. Only what was actively needed came along. Anything that hadn't been touched in weeks got dropped. The tool switch became a natural filter. What survived was what actually mattered.

And there's a bonus most people overlook: every switch is also an opportunity to improve your automation. You're not just moving to a new tool, you're rebuilding the integration layer, and that's a chance to do it better than before. Teams that treat migrations as optimization cycles come out faster on the other side, not just different.

Why hoarding makes switching expensive

The less you accumulate, the cheaper every switch becomes. A migration is only painful when you've built up things you weren't willing to let go of. Thousands of tickets nobody looks at. Documentation that hasn't been opened in a year. Automations built around a specific tool's quirks rather than around a principle that could travel.

In the age of AI, hoarding operational content makes even less sense than it used to. AI generates meeting summaries, ticket drafts, status updates, and routine documentation. You don't need to preserve that. It can be regenerated. What you do need to preserve are the things that remain true over time: concepts, principles, validations, architectural reasoning, the decisions that are still guiding the product months later. These are the inputs from which AI and team members derive their current work. Everything else is transient.

When you build with that distinction in mind, switching tools stops being a documentation problem. The evergreen content travels. The operational layer regenerates. The migration cost drops to almost nothing.

How much of what's sitting in your backlog right now would you actually miss if it disappeared tomorrow?

One tool for the whole company is no longer a virtue

There used to be a strong argument for standardizing on a single toolset across an entire company. Less training, less integration complexity, easier IT management. That argument is weaker now than it's ever been.

MCP and AI are universal information interfaces. They don't care which project management tool a team uses. They can read from Jira or GitHub Issues or Motion or anything else. They can write to Confluence or Notion or a markdown file. The integration layer that used to require everyone to use the same tool now sits on top of whatever tools make sense for each team's actual work.

This means a product team using Linear, an engineering team using GitHub Issues, and an operations team using Motion can all share context through the same AI layer without any of them compromising on the tool that fits their workflow best. The cost of that heterogeneity has dropped dramatically. The benefit of giving each team the right tool for their context hasn't changed at all.

The deeper point

Every tool you use encodes assumptions about how work should flow. Those assumptions made sense when you chose the tool. They may not make sense anymore. The discipline of change management as a default value is the discipline of staying honest about that, consistently, before the friction becomes invisible.

Build small, autonomous teams. Keep documentation toolagnostic. Preserve what's timeless, let AI handle what's transient. Make the principle explicit from day one. And when a tool stops serving the work, treat the switch as an optimization opportunity, not a crisis.

The AI and automation layer that enables all of this is itself evolving faster than any of the tools that sit on top of it. What that layer looks like, and how to build on top of it without locking yourself in, is the topic of the next post.