Hey!

Welcome back to another week of musings.

Spring is in full motion now. I've been enjoying going to the ballpark (sadly, the Giants are on a losing streak).

I hope you had a great weekend and managed to rest.

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• I'm a mechanical keyboard user, and recently WorkLouder opened a pre-order for a desk mat that also serves as a cutting mat. A very niche product, but cool for me.
• We had the Claude leak in the last few days. It was interesting to see it unfold live, but also inventive people copying and trying to fork in ways to not get DMCA'd.

Lately, I've been dealing not only with the usual bureaucracy of other teams' backlogs and priorities, but also with top-down orders that force migrations.

Migrations are the sole scalable fix to tech debt. If you're not migrating, you're dying. A company wants fewer vendors, fewer platforms, lower costs, more consistency, and better reporting.

The problem is that the teams driving these migrations often have to provide a broad solution that works company-wide. By definition, that means the solution is optimized for scale of adoption, not necessarily for the teams that already have a mature process and solid automation in place.

That is where the friction starts.

Broad solutions create local pain

When your team already has a robust process, being told to move to a newer but less mature platform can feel like a step backward.

And if the migration team is showing progress daily through adoption, they're building trust and wins. But for the teams doing the work every day, the story can look different. Maybe your existing tooling is faster. Maybe your automation is more reliable. Your process may already handle edge cases that the new platform has not yet considered.

And that gap matters a lot (for us)!

Adoption is not the same as improvement

One of the harder parts of these conversations is that some teams are primarily measured on how quickly they roll out the new thing.

If their goal is "100% adoption," then every exception looks like resistance. Every request for a better migration path looks like a delay. Every concern about productivity can be treated as secondary as long as the adoption metric keeps rising.

That is how you end up in a bunch of meetings and endless email threads whose cost starts to exceed the benefit of "just adopt it".

At that point, the real discussion is no longer about tooling. It is about whether the organization values standardization more than it values the productivity of the teams expected to take on the change.

Fight for the adaptation path

In my experience, the best outcome is usually neither total refusal nor blind adoption.

The better path is to retain the parts of your process that are already mature and adapt them to the new platform where possible.

Sometimes that means convincing the migration team to allow your existing tooling to remain in place. Other times, it means getting enough support from them so your team can bridge the gap without losing too much functionality.

And in the best cases, it means pushing your requirements into the new platform itself. If the platform team is willing to listen, they can add the missing functionality. If they are open to it, maybe your team can even inner-source those improvements and help make the platform better for everyone else.

That is a much better outcome than pretending the gaps do not exist.

Escalation is part of the job

One uncomfortable truth of working at companies is that the answer from one team is not always the final answer. Sometimes the team says no. Sometimes they refuse exceptions.

In those situations, handling escalation well can matter more than winning the original argument. If you can find the right approval path at a level higher than the team, you can still "win".

That sounds sad, but it is also just part of organizational life. Sometimes you have to find the bigger bear. Influence, alignment, and escalation are all part of how technical decisions get made in practice.

Pick your battles, but do not give up too early

Not every tool is worth defending. Not every migration is worth resisting. Sometimes the standard solution is good enough, and the right move is to move on.

But if your team has a mature process that genuinely works, you owe it to the team to at least try.

Try to preserve the parts that are already delivering value. Try to get help adapting your workflow. Try to push your requirements into the platform roadmap. Try to make the new standard better instead of simply absorbing its current limitations.

You do have to pick your battles. But if you never advocate for your team's reality, nobody else will.

Your turn!

Have you had to deal with a forced migration to a platform less mature than what your team already had? Were you able to get exceptions, adapt your process, or influence the new platform itself? Let me know your thoughts by replying to this email!

Happy coding!