Intent over mandates - leading the move from legacy to modern tooling

Every legacy-to-modern program I have seen fail, failed the same way. A central group decided the new architecture, wrote a migration plan, and handed it down as a mandate. Six months later the old system is still running, the migration tickets are stale, and the people who understood the real risk have quietly gone back to firefighting.

Mandates lose because the person signing off on the plan is never the person who knows why the legacy system is dangerous at 2am. That knowledge lives with the engineers. So should the decisions.

Give intent, not orders

The shift that works is the one L. David Marquet calls intent-based leadership: you stop giving orders and start giving intent, and you push the authority to decide down to where the information already is.

In practice that means a team stops saying "what do you want us to do about the legacy billing service?" and starts saying "we intend to move billing behind the new gateway this quarter, here is why, here is how we will know it worked." Your job as the leader is no longer to approve the step. It is to make sure the intent is sound and the team has the competence and context to back it.

Two things have to be true for that to work, and both are on you:

• Clarity. Everyone can state the destination and why it matters. Not the steps, the why. "Off the legacy runtime by Q3 because it blocks our security posture and nobody left can patch it."
• Competence. Teams can actually make the call. That is training, pairing, and removing the gatekeepers who used to be the only ones allowed to say yes.

Tooling is where you prove it

Don't start the cultural change with the scariest migration. Start with the toolchain, because it is the smallest piece of "modern" that compounds and it is measurable from day one.

CI gets the attention, but CI is only one tile. The thing you are actually building is a paved road: the scaffolding generator that stands up a new service the right way, the shared libraries that solve the boring problems once, the formatter and linter that end the style arguments, the local dev environment that comes up with a single command, the pipeline that tests and ships, and the observability that tells you what happened after it shipped. Each piece on its own is a convenience. Together they are the difference between a team that can decide and a team that has to ask.

A team that owns that toolchain gets a tight feedback loop: change, test, ship, see the result. That loop is exactly the competence-and-clarity engine intent-based leadership runs on. Every green build, every generated service, every boring deploy is the team being proven right without asking permission. Get the tooling in place first and the bigger migrations stop feeling like leaps, because the team now has a net.

legacy:   commit -> wait -> manual test -> hope -> deploy on a Friday
modern:   commit -> generate -> CI -> green -> deploy, any day, boring

The second line is not just faster. It is a team that trusts its own decisions, on a toolchain that makes the modern path the path of least resistance.

Measure value, not activity

Here is the trap: "we rolled out the new tooling" is an activity, not a result. You can adopt every tool on the list and still ship slower. So measure the outcome, and measure it the same way everywhere - with DORA.

The four signals tell you whether the toolchain actually moved delivery:

• Deployment frequency - how often you ship. Rising means the paved road is being driven on, not just installed.
• Lead time for changes - commit to production. This is the metric that exposes legacy drag the loudest.
• Change failure rate - how often a deploy breaks something. Good tooling pushes this down; it should not trade stability for speed.
• Time to restore - how fast you recover when something does break.

Take a baseline per team before you change anything, then watch the numbers move. If deployment frequency climbs while change failure rate holds or drops, the tooling is shipping value. If you adopted everything and the numbers are flat, the road exists but nobody is driving on it - and that is a leadership problem, not a tooling one.

What changes in practice

• You measure outcomes, not compliance. DORA trending the right way beats "how many teams followed the migration template."
• You make the modern path the lazy path - a generator, shared CI, libraries that solve the boring problems - so choosing it requires no permission.
• You let teams opt out with a reason, and you treat repeated opt-outs as a backlog, not a violation.
• You say "I intend to" yourself, out loud, so the language becomes normal.

Leadership in a migration is not picking the architecture. It is making the destination obvious, making the authority real, and then getting out of the way.