Many organisations have invested in cloud landing zones — standardised account structures, networking patterns and security baselines. Far fewer have landing zones that teams actually adopt voluntarily. The gap between a technically sound reference architecture and a platform that teams choose to use comes down to three things: sensible defaults, escape hatches, and onboarding speed.
The reference architecture trap
The most common landing zone failure isn't technical — it's experiential. The platform team builds a complete, well-architected foundation, but teams find it slow to onboard, rigid in its constraints, and disconnected from their actual delivery workflow. The result is predictable: teams go around the platform, and the platform team responds by adding more controls, which drives more avoidance.
Defaults, not mandates
The most successful landing zones work like good frameworks — they provide strong defaults that cover 80% of use cases, with clear, documented paths for the other 20%. A team that needs a standard web application should be able to provision a complete environment in minutes, not days. A team with unusual requirements should know exactly what process to follow, not hit a wall.
Guardrails should be invisible when teams are doing the right thing. Tagging policies, network segmentation, encryption defaults and logging configuration should all be baked into the platform modules. Teams shouldn't need to think about these things — they should just work.
Speed as a feature
The single most important metric for platform adoption is time-to-first-deployment. If a team can go from "nothing" to "running code in a production-like environment" in under an hour, adoption follows naturally. If it takes days or weeks, teams will find shortcuts. Invest heavily in the onboarding experience — self-service provisioning, clear documentation, working examples, and responsive support for the first deployment.