You do not need to stop shipping. You need to start with one service.
Every CTO who hears the pitch for identity engineering has the same reaction: "This sounds right, but I cannot freeze my roadmap to do it." Fair. You should not freeze your roadmap. The teams that try to adopt a platform capability all at once, across every service, in one coordinated push, end up in the same place every time: stalled at proof-of-concept with a frustrated organization behind them.
There is a better pattern. It has been proven in infrastructure migration, database cutover, and monolith decomposition. It works for identity adoption too.
The Backstage 10% problem
Spotify built Backstage to solve exactly the kind of problem identity engineering addresses: giving every service a clear declaration of what it is, who owns it, and how it connects to everything else. The results were real. Onboarding time dropped from 60 days to 20 days. Backstage users were 2.3x more active on GitHub, deployed 2x as often, and had 17% faster lead time.
Then other companies tried to adopt it. Average adoption across organizations settled at roughly 10%, often stalling after the initial proof-of-concept. Teams reported 70+ setup steps to get a single service registered. The tool worked. The adoption strategy did not.
This is not a Backstage problem. It is a pattern that repeats across every platform initiative that launches with a big-bang rollout. The pattern holds across engineering tooling adoption broadly: phased rollouts consistently outperform company-wide mandates because each phase produces real data that justifies the next expansion.
The problem is never "the thing does not work." The problem is "we asked everyone to change at once, nobody had time, and the initiative died."
The strangler fig for identity
In 2004, Martin Fowler coined the strangler fig pattern after observing strangler figs in a rainforest. The trees grow around their hosts, gradually replacing them while the host continues to function. Applied to software, the pattern means: stay in production the entire time, migrate piece by piece, and never require a cutover day where everything changes at once. The Microsoft Azure Architecture Center documents this as a standard migration strategy.
The same pattern works for identity engineering. You do not need to declare the identity of every service before any of it becomes useful. You need to declare the identity of one service, the one that breaks most, and let both humans and agents work against that declaration for long enough to measure the difference.
Here is the concrete sequence.
Phase 1: One service, one quarter
Pick the service with the most pain. Not the most important one. Not the one the VP of Engineering cares about. The one that generates the most incidents, the most confused onboarding questions, the most "wait, what does this service actually do?" conversations in Slack.
Write its identity declaration. This is not a rewrite. It is a document that lives alongside the existing code. It states what the service is, what it is not, what it guarantees, what it depends on, and where its boundaries are. If you have read The Bug Nobody Wrote, you know the five questions to run against it: completeness, consistency, real boundaries, spoofability, and currency.
Then let the team work against it. Point your agents at the declaration. Reference it in code reviews. Use it when onboarding a new engineer to the service. Use it when debugging the next incident. Do not mandate it. Just make it available and see who reaches for it.
What to measure over the quarter:
| Metric | Before | Watch for |
|---|---|---|
| Onboarding time to first meaningful PR | Baseline it in week 1 | Target a measurable reduction by week 12 |
| Incidents traced to spec ambiguity | Count the ones where "nobody specified that" is the root cause | These should decrease as the declaration fills gaps |
| Agent output accepted without rework | Track the acceptance rate for AI-generated code on this service | Higher acceptance means the declaration is giving agents real context |
| Time to resolve boundary disputes | How long does it take when two teams disagree on who owns a behavior? | A clear declaration shortens these conversations |
You do not need to wait a year to know whether this is working. By the end of one quarter, you will have data.
Toyota provides a reference point for what that data can look like. They built "Chofer" on top of Backstage and reported over $10M in cost reduction, with individual teams saving six weeks of development time per project. That was a full platform play. You are starting with one service, but the measurement approach is the same: pick concrete metrics, baseline them before you start, and read the delta at the end of the quarter.
Phase 2: Adjacent services
If Phase 1 works, and it will produce data either way, you expand along dependency chains. Not across the whole organization. Along the services that talk to the one you already declared.
This is the strangler fig growing. The first service has a declaration. The services that depend on it start bumping into questions the declaration raises. "Your identity says you guarantee P99 under 200ms, but we are calling you synchronously and our P99 is 400ms. Something does not add up." These conversations happen naturally once one service has a clear identity and its neighbors do not.
Declare the next two or three services. The ones directly upstream or downstream. Now you have a small cluster of services with declared identities, and agents working across that cluster have real context about what each service is, what it promises, and where the boundaries sit.
Capital One's experience with phased infrastructure adoption is instructive here. They reported an 80% reduction in infrastructure deployment time migrating to Terraform, but they did it service by service, not all at once. The phased approach let them learn from each migration and apply those lessons to the next one.
At this point, you are not running a special initiative. You are just writing declarations for services as they come up for work. A service that is getting refactored gets a declaration as part of the refactoring. A service that had an incident gets a declaration as part of the postmortem. The identity layer grows as the team touches services, not as a separate project that competes with the roadmap.
Phase 3: The platform emerges
Gartner projects that 80% of large software engineering organizations will have platform engineering teams by 2026, up from 45% in 2022. Most of those teams will face the same adoption challenge: building something that works technically but fails organizationally because nobody has time to adopt it.
The strangler fig pattern sidesteps this. By the time you have declared identity for 15-20 services, you are not asking anyone to adopt a platform. You have a platform. It grew service by service, each declaration informed by real pain and measured by real metrics. The coverage expanded along dependency chains, so the services that talk to each other have compatible declarations. And the team has been using it for months, so there is no adoption gap to bridge.
This is the difference between building a platform and mandating a platform. Building one service at a time means each declaration solves a real problem for the team writing it. Mandating adoption across the organization means each team has to find time for something that does not yet solve their specific problem.
The full ROI of a platform investment takes months to materialize. That timeline is fine when the platform is growing organically alongside feature work. It is fatal when the platform requires a freeze on feature work and has to justify itself before it has produced any data.
Monday morning
Here is how to pick your first service.
Open your incident tracker. Sort by frequency over the last 90 days. Look at the top five. At least one of them will have a pattern where the root cause is not a code bug but a spec gap: "we did not account for this scenario," "the service was not supposed to handle that," "the boundary between these two services was not clear."
That is your first service.
Do not announce an initiative. Do not create a project plan. Do not ask for a dedicated sprint. Just write the declaration. Put it next to the code. Point one agent at it. Run the five questions against it. Baseline your metrics.
In twelve weeks, you will have data. The data will tell you whether to expand or adjust. Either way, you did not stop shipping. You did not freeze the roadmap. You started with the service that hurt most, wrote down what it is supposed to be, and measured what happened when everyone, humans and agents, could finally read it.
The roadmap kept moving. One service got clearer. That is all it takes to start.
Identity declarations should grow alongside your services, not ahead of them. We are building tooling that makes this incremental adoption path concrete.