Article three covered the architecture: the hub, the edge servers, the GitOps pipeline, the signed OS images. Building that and getting people to use it are two different jobs.
This builds on what a fleet platform costs and the reference architecture. Read those first if you haven’t.
Nothing changes on its own once the platform is live. Engineers keep SSHing into a site and pulling code by hand, even after you tell them the old way is over, because that’s the workflow they know and trust. Getting them onto the new one takes a transition period, documentation, more than one training session, and one-on-one conversations to answer questions. Only after all that does SSH access get turned off.
People resist change
It’s Virginia Satir’s change model, which DeMarco and Lister cite in Peopleware: performance always dips before it improves, and announcing that ahead of time makes it easier for the team to handle.
My rabbi puts it more simply: you only get the juice out of a fruit by pressing it.
Training and tools come first
DeMarco and Lister point to three things that get a team working the same way: training, tools, and peer review. People use the methods they already know, so training everyone on the same methods moves the whole team toward using them. A few good tools do more for consistency than any rule can. And where people already review each other’s work, they tend to converge on the same practices without being told to.
Applying training, tools, and peer review gets you there faster than a policy that forces the outcome.
Document everything
Write down what changed and why: a short note per decision, a runbook for the common tasks, an FAQ for the questions that keep coming up. The two pilot users can answer questions today. Six months from now, when one of them has moved to something else, the doc is what’s left.
Make the easy way the fast way
The old way to ship an app change: SSH into the edge server, git pull, restart the service, watch the robot move for a minute. The new way needs to be at least as fast, or people won’t switch. One command does the whole deploy: same five minutes as SSH, but it runs through the platform, so the fleet’s Git history actually shows what’s running.
The same goes for routine questions like “which build is on this site” or “did the last rollout to ring one finish.” Nobody should have to ask the platform team, or wait for someone back from leave, to get that answer. One command should give it, as fast as the deploy itself. If it doesn’t, engineers keep their own spreadsheet on the side, the same way they kept SSHing in.
Ginger Bill’s line on tools holds here too: a good one is invisible, and the clearest sign it’s working is that people stop noticing it’s there (Ginger Bill, 2026).
I like telling myself, when joining a project and setting their new flow, that it’s ready when I’m not needed, when developers don’t know what I’m doing anymore. Sad but true
Two users migrate first
Pick two engineers who already ship deploys regularly, not the platform’s most senior engineer and not someone who just joined the team. Move their whole workflow onto the platform before anyone else touches it.
Don’t just hand them a document and hope it works out. Walk each one through the deploy flow yourself: slow, focused, and don’t leave until their questions are answered.
Two people are enough to catch problems that only show up when someone other than the platform’s own builder is driving, and few enough that fixing what breaks stays a short list. They’ll find the missing CLI flag, the alert nobody tuned, the doc page that assumes access most engineers don’t have. Each of those gets fixed once, for two people, long before a company-wide rollout would hit every team with the same problem in the same week.
Once those two use the platform every day, they can answer “does this actually work.” Other engineers ask them directly and copy their setup. Nobody waits for a rollout schedule to reach their own team.
DORA’s research on platform engineering found that internal platforms can hurt throughput and change stability when the rollout isn’t managed well (DORA, Platform engineering). Two pilot users give you that real-world check before the whole fleet depends on the platform working.
Train people more than once
The pilot users end up as evangelists too: they explain the new way to whoever asks, not just use it themselves.
New developers will pair with someone who’s already run a deploy, watch it happen on a real site, then run the next one themselves while that person watches and answers questions. After that, offer a weekly hour where anyone with a broken deploy can show up. It drops to monthly once things settle down.
The decision
Mandating the platform on a fixed date means every team hits its first real problem in the same week. None of them has done this before. The platform team spends that week firefighting one-off requests and fixes nothing upstream. It looks decisive in the announcement and falls apart right away. Microsoft’s own platform-engineering docs list “Mandated” as an early, immature stage of adoption, and say plainly what happens there: teams either fail to use the mandated standard or use it without being satisfied with the result (Microsoft, Platform engineering adoption).
Leaving adoption to chance doesn’t work either. Nothing forces anyone to compare the old workflow with the new one, so only the teams who were going to switch anyway do. A year later, the fleet still runs two systems side by side, permanently, because nothing ever made switching urgent.
Putting one person in charge of every repository creates a worse problem than the one it solves. Every fix and every question waits on them, and if they’re sick, on leave, or just busy, everything stops. Training two pilot users to answer those questions themselves is what gets you out of that trap: they become the people others ask, not just you.
Two pilot users give the rollout a real, working example before anyone else needs one. Self-serve tooling gives everyone after them a path that’s actually faster than the shortcut. Training that repeats keeps that path current as the platform changes. Skip any of the three, and the other two stop working as well.
I’m David Bensoussan. I build deployment and update infrastructure for hardware and robot fleets. If you’re working out how to ship software to machines you can’t reach, book 30 minutes and we can work out your fleet’s update path.