Lesson 07 of 10 · Part 2 — Direction
Driving platform adoption
Get application teams to adopt a platform without forcing them: understand why they hesitate, start with a pilot team and their real problem, migrate together, publish the proof, build champions, make the platform path the easiest one, and use mandates only as a last, well-supported step.
Why teams hesitate
| Reason | What it sounds like | What helps |
|---|---|---|
| Migration effort | "We don't have time this quarter" | Do the first migration with them; tooling that does most of the work |
| Fear of losing control | "We won't be able to debug it" | Access, logs and runbooks; show what stays theirs |
| Missing features | "It can't do X" | Ask what X is; build it, or support an exception |
| Bad past experience | "The last platform was a mess" | Small, reliable steps; honest status |
| No visible benefit | "What's in it for us?" | Solve their top pain first |
You can't make a cat use a new bed by pushing it in. Put the bed somewhere warm, put its favourite blanket inside, and wait. Teams are the same: make the new place more comfortable than the old one, and they move by themselves.
A rollout that works
- Pick a pilot: a respected team with a real problem the platform solves, and the willingness to give feedback.
- Solve their problem, not the platform's: if their pain is slow deployments, start there, not with your favourite feature.
- Migrate together: pair with them on the first service; fix the rough edges you find; write the guide as you go.
- Publish the proof: deploy time before and after, incidents, cost, in their words. A short demo by the pilot team beats any slide deck.
- Grow champions: engineers in other teams who help their peers; give them early access and a voice in the roadmap.
- Make the platform path the easy path: templates, automation and support for the new way; old paths get slower and eventually deprecated.
- Mandate last: once the platform is proven, a deadline for remaining teams can be fair, if it comes with migration help and real exceptions.
Influence without authority
- Listen first: understand each team's constraints before proposing.
- Give before asking: help teams with problems unrelated to the platform; trust carries over.
- Be honest about what doesn't work yet, with dates for fixes.
- Share credit: the pilot team's success is their success.
Know when it's working
Track adoption per team (services on the platform), time to migrate a service, support tickets per migrated team, and satisfaction. Stalled adoption is feedback: ask the stuck teams what's missing.
Try it: an adoption plan
- List the teams that haven't adopted your platform (or a new standard) and the reason each would give.
- Pick a pilot team and their top pain the platform could solve.
- Plan a two-week pairing to migrate one of their services, with a before/after measurement.
- Draft the one-page story you'd share afterwards.
- Identify two potential champions in other teams and what you'd offer them.
Going deeper: deprecating the old way
Announce early with a date, publish a migration guide, offer help sessions, report progress publicly, give a short extension to teams that are genuinely blocked, and then switch off. Leaving old paths running forever doubles the platform team's work.
Recap
- Understand why teams hesitate: effort, control, features, history, benefit.
- Pilot with a real problem; migrate together; publish the proof.
- Grow champions; make the platform path the easiest; mandate last, with help.
- Influence comes from listening, giving, honesty and shared credit.
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.