In Part 1 the first workload met a landing zone that had never met a workload. In Part 2 deny first policies made the compliant path the slow path. This field note is about the quieter failure underneath both: nobody co-designed the platform with the people who would live on it.
SELL! is a fictional company. Any resemblance to a real platform team’s war story is the point.
Setting the Scene
Week fourteen at SELL!. The lending app is limping along. Governance is being rewound toward audit mode. Then Sales wants a second product line in Azure: a payments rewrite with a hard partner deadline.
Tui flags it in the Monday standup. The partner will see every slip. The platform lead says the golden path is ready.
Announce the platform. Drop the second team onto the golden path.
- Demo the reference architecture to the payments team.
- Issue a subscription through the still-manual request form.
- Expect their pipeline to match the platform identity model.
- Treat exceptions as edge cases, not design feedback.
The Pilot: The Golden Path Works Perfectly
The platform team is ready. They have diagrams. They have a golden path. Hemi, who leads payments, sits through the demo and nods. The hub looks tidy. The identity model looks tidy. The subscription lands the same afternoon.
On paper, wave two is done. The partner kickoff is in ten days. Nobody has run a real deployment yet.
The payments team took the subscription. The golden path was not tested.
- The architecture walkthrough lands without argument.
- A subscription is issued the same day.
- Hemi's first pipeline run is scheduled for Thursday.
- The partner still thinks the date is holding.
The Team Nobody Recruited
Every mismatch that follows was knowable in week two of the original build. None of them were, because nobody asked a real workload team to help design the path.
Onboarding Day: First Contact With Payments
Thursday is first contact in the literal sense. Hemi’s team deploys for the first time into a landing zone that has never seen their app. The pipeline fails in the first hour. The partner programme manager is on the email thread by lunch.
This is no longer an internal delay. Wave two has an external blast radius: the partner sees the slip, and Sales will have to explain it.
| Symptom | What to do instead |
|---|---|
| The first real workload, or the second, lands and networking, identity, and CI/CD all conflict with what the platform team shipped in isolation. | Recruit one pilot workload team before design starts. Co-design weekly. Pair on the first
deployment. Treat "that is wrong" from the pilot as a gift. References: Why Landing Zones Fail · CAF: Application landing zones · WAF: Operational Excellence |
Post-Onboarding: The Cracks Widen
The second team is in the door. The first real deployment is what widens the cracks.
Pipeline Issues
The payments team’s Azure DevOps pipeline conflicts with the identity model. The workload needs a certificate rotation pattern the policy set forbids. The golden path assumed a shared Key Vault and a platform owned identity flow. Hemi’s team already had neither.
Latency Issues
The app’s latency requirement cannot be met through the hub firewall. The golden path assumes hub inspection of every east west flow. That was never tested against a payments hop that has to clear a partner SLA.
Reputation Issues
In larger markets, a failed platform iteration gets absorbed. At SELL!, that iteration consumes half the annual platform engineering capacity. Everyone knows everyone. If the platform’s first impression is “our app could not deploy for six weeks,” that story follows the team across their next three jobs, and across the next three hiring rounds. The partner will remember it too.
The Lessons We Can Learn
Recruit Before Design Starts
Choose deliberately:
- Representative: requirements should resemble the next five teams
- Willing, not captive: volunteers tell the truth; assignees resent you
- Shipping: a real deadline surfaces design flaws kindness will not
Co-design, Do Not Consult
Weekly working sessions during the build, not quarterly steering updates. Pair on the first deployment. Design reviews where the pilot can say the design is wrong.
A worked hour looks like this. Hemi brings the certificate rotation job. The shared Key Vault pattern cannot satisfy it. The session ends with a per-workload vault variant on the roadmap, and the shared pattern is no longer treated as gospel. That is co-design. A steering pack that notes “identity to be confirmed” is consulting.
Define the First Workload Acceptance Test Early
Write down, before the platform exists, what onboarding must look like:
- Request to deployed environment: days, not weeks. That is the metric from Part 2, agreed before build this time
- Zero manual platform steps for routine deployments
- Logging, policies, and tagging satisfied automatically as a side effect of the golden path
If the platform cannot pass this test with a friendly pilot, it will never pass with an unwilling one.
| Symptom | What to do instead |
|---|---|
| Onboarding docs describe what should happen. Pilots get stuck on steps nobody documented. The second team repeats the same stuck points. | Write the onboarding runbook from the pilot's actual experience, including where they got stuck.
Those stuck points are the next three sprints. References: CAF: Platform automation and DevOps · WAF: Operational Excellence checklist |
Operations: The Two Platform Trap
A pilot partnership means accepting the platform will not be complete at launch. That is uncomfortable when a partner deadline is already on the calendar. The tempting move is to stand up a “temporary” path for payments, promise a proper landing zone later, and keep wave two moving.
NZ organisations that take that deal do not get a short detour. They get two platforms. The temporary one is what payments actually run. The intended one stays a backlog item. Three people cannot operate both and also migrate the first. Capacity that was too scarce to recruit a pilot is far too scarce to unwind a split estate.
Build the real thing, small, with a partner. Then grow it one workload team at a time. At SELL!, Hemi should have been in the room when the hub and identity model were chosen, not fourteen weeks later with a partner watching the clock.
| What they did | Should have done |
|---|---|
| Built the landing zone for a quarter with no workload partner in the room. | Recruited a willing, shipping pilot team before the first design session. |
| Assumed the golden path matched every team's pipeline and identity model. | Paired on the first deployment and changed the path when reality disagreed. |
| Treated the second team's blockers as edge cases. | Treated every blocker as a product defect and updated the acceptance test. |
| Wrote docs for the platform they intended to build. | Wrote the runbook from where the pilot actually got stuck. |
The Moral
A landing zone built alone is a hypothesis. A pilot partnership is the experiment. SELL! shipped the hypothesis, then paid for the experiment in week fourteen with a partner deadline on the line.
The test: when the pilot team’s engineers describe your platform to another team, is their description accurate, and would that other team want in?
If you cannot spare a workload partner from the payroll, buy the partnership as an engagement. See Fractional Cloud Architecture and Advisory.
One Block · build from here