The platform team spends a quarter building in isolation, careful, thorough, aligned to every framework. Then they demo it to the organisation, onboard the first real workload, and everything falls apart.
- The app’s latency requirement cannot be met through the hub firewall.
- The dev team’s GitHub Actions pipeline conflicts with the identity model.
- The workload needs a certificate rotation pattern that the policy set forbids.
- The “golden path” assumes things about the workload that no real workload satisfies.
Every one of these was knowable in week two. None of them were, because nobody asked.
Why This Fails Harder in NZ
Scarcity compounds isolation. NZ organisations typically field smaller platform teams, often two to four people, sometimes one. A small team working in isolation does not just miss requirements; it misses whole categories of requirements, because there is no redundancy in perspective. The single network engineer on the team is making decisions no workload owner ever validates.
The rework is unaffordable. In larger markets, a failed platform iteration gets absorbed. In NZ, that same iteration might consume half your annual platform engineering capacity.
The reputation blast radius is small. 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 your next three hiring rounds.
The Fix: A Pilot Partnership Model
1. Recruit one pilot workload team before design starts
Not after. Before. Choose deliberately:
- Representative, their requirements should resemble the next five teams’ (an internal web app is usually a better pilot than a one off IoT platform)
- Willing, not captive, a team assigned to the pilot will resent you; a team who volunteered will tell you the truth
- Shipping, pick a team with a real deadline; urgency surfaces design flaws kindness will not
2. Co design, do not consult
Practical mechanics that work well in small NZ organisations:
- Weekly working sessions with the pilot team during the build, not quarterly steering updates
- Pair on the first deployment, the pilot team’s engineers literally work alongside the platform team on their first landing
- Design reviews where the pilot team can say “that is wrong”, and it is treated as a gift, not insubordination
3. Define the “first workload” acceptance test early
Write down, before the platform exists, what onboarding must look like:
- Request to deployed environment: target days, not weeks
- Workload team needs zero manual platform team steps for routine deployments
- Compliance controls (logging, policies, tagging) satisfied automatically as a side effect of the golden path
If the platform cannot pass this test with a friendly pilot team, it will never pass with a hostile one.
4. Write the onboarding runbook from the pilot’s experience
Do not write docs describing what should happen. Write docs describing what actually happened, including the parts where the pilot team got stuck. Those stuck points are your roadmap for the next three sprints.
5. Grow the second wave from the first
In NZ’s tight market, your pilot team becomes your best recruiting asset. Teams that had a good landing zone experience will evangelise internally, and in an organisation of 200 to 2,000 people, internal evangelism outperforms any comms plan you will write.
An Honest Note on Scope
A pilot partnership means accepting the platform will not be complete at “launch.” Resist the temptation to onboard the pilot onto a “temporary” platform you will replace later. NZ organisations that do this end up running two landing zones for years, because nobody has capacity for the migration.
Build the real thing, small, with a partner. Then grow it one workload team at a time.
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?
One Block · build from here