Increment One: The First Six Weeks

Part 4 of “The Landing Zone That Survived” — a year in the life of a New Zealand platform team, told from fakey.xyz. Fictional organisation, aggressively fake people, realistic problems.

Recap. In Part 1, Fakey McFakerson got the mandate and a 1.6 FTE team. In Part 2, Discovery Week produced a requirement register, a control triage agreed with Serge Secure, and a finance mapping from Tessa Spreadsheet. In Part 3, the design decisions document settled the subscription strategy (product line primary, compliance-scoped exceptions), a hybrid network with a measured “low-latency corridor” for Netty Latency’s fraud stack, Terraform as the IaC choice, and — unexpectedly — MegaCorp Megalodon’s security questionnaire proved the documentation alone was worth revenue. Now: the team has to actually build something. They have six weeks, 1.6 FTE, and a pilot team who is already counting the days.

Increment One has a scope so small it fits on a sticky note, and that sticky note — which Fakey genuinely keeps above her desk, in handwriting so bad Robbie Deployment claims it’s a security control — reads:

By end of week 6: a workload team can be given a subscription, in the right place, with the right tags, with cost visible to finance, and everything in audit mode. Nothing is denied yet. Nothing needs to be.

That last sentence is the whole philosophy of the increment, and it took an argument with Serge to earn it.

Week 0: The Argument That Set the Tone

The increment planning session opened with a three-way disagreement that Fakey considers, in retrospect, the most valuable 45 minutes of the increment.

Serge Secure wanted increment one to include enforcement: “If we deploy logging and policies and nothing is enforced, the first workloads land on an unguarded platform and we’ll be retrofitting forever. Every workload onboarded before enforcement is future migration debt.”

Robbie Deployment wanted increment one to include everything in the design document: “The vending pipeline, the hub skeleton, the log analytics, the DNS — if we build them separately we’ll rebuild each three times.”

Fakey wanted the one thing both of them were treating as an afterthought: “Neither of you has mentioned the pilot team once. Increment one’s actual deliverable is a workload team that trusts us. The technology is the receipt.”

The resolution — and it’s worth stealing the shape of it, if not the specifics:

• From Serge’s concern: every policy deploys in audit mode from day one (Discovery Week’s triage made this survivable — 168 OBSERVE controls means the platform is watching everything even while enforcing nothing). Plus a written commitment, with a date: enforcement waves begin in increment four, and no workload lands in production before its applicable ENFORCE controls are active. Serge’s retrofit-debt fear is answered with sequencing, not refusal. He signs it. Reluctantly. In the meeting notes it says “agreed under protest”, and everyone treats that as a genuine signature.
• From Robbie’s concern: a hard scope cut, made by asking one question of every proposed component: “Does the pilot team need this to receive their environment in week 6?” If not, it moves to the backlog. The hub gets built (the pilot’s environment must connect to it). The full ALZ accelerator’s extra structure does not. Robbie, to his credit, did the cutting himself once the question was on the wall — engineers cut scope far more honestly when they wield the knife.
• From Fakey’s concern: a commitment that became the increment’s definition of done: “Netty Latency can deploy a test resource into a compliant environment via pipeline by Friday of week 6.” Not “the platform is complete.” Not “all controls active.” One team, one environment, one working path.

Weeks 1–2: The Boring Foundations, and the First Real Lesson

Weeks one and two were, by design, boring: EA billing setup and subscription creation, the management group hierarchy from Part 3 (Platform / Landing Zones with Prod, Non-Prod, Sandbox / Decommissioned), the central Log Analytics workspace, and the repo — Terraform, remote state in Azure Storage, deployment identity via workload identity federation, no human credentials anywhere in the pipeline.

And in week two, the team hit the lesson that every small platform team hits and no reference architecture warns you about:

The ALZ accelerator is built for organisations bigger than yours.

The reference implementation assumes a platform team with capacity to operate its full surface area: multiple custom roles, a broad policy assignment matrix, connectivity resources sized for scale. Fakey’s team is 1.6 FTE. Robbie’s now-famous assessment, delivered in stand-up with the enthusiasm of a man who has just talked himself out of a month of work:

“Every component we deploy is a component we promise to operate. The accelerator deploys about forty things we promise to operate. We currently have the operating capacity for about six. I’d like to propose we deploy six.”

The six, chosen ruthlessly against the week-6 definition of done:

1. Management group hierarchy
2. Central Log Analytics workspace + the audit-mode policy initiative that wires every subscription’s diagnostics to it
3. The hub vNet, firewall subnet skeleton, and VPN gateway to Petone
4. The tagging policy initiative (audit mode — counting violations, not blocking them)
5. The subscription vending pipeline — but version zero: a manual-triggered Terraform run with a request form that is, genuinely, a form
6. The budget and cost view for finance

Everything else in the accelerator — custom roles, sandbox automation beyond an expiry policy, DNS split-horizon refinements, the connectivity subscription’s full structure — was explicitly deferred with entries in the design document’s Deferred Decisions section. Each with a trigger: “when the second product line onboards”, “when the first PaaS workload needs private endpoints”, and so on.

Lesson 1 — Deploy what you can operate, not what the accelerator can deploy. The gap between those two numbers is where platform teams quietly drown. Write the gap down and manage it deliberately.

Weeks 3–4: The Pipeline, the Form, and Tessa’s Dashboard

Vending, version zero

The vending pipeline at end of week 4 is not impressive to look at, and the team is proud of it anyway. The flow:

1. A workload team fills in a request form (a Microsoft Form, to Tessa’s open delight and the engineers’ open disgust — it won on speed-to-build, which is the increment’s entire value system). The form asks, in plain language: product line, environment, data classification (with worked examples from Discovery Week — the passport example is now famous), whether personal information will be processed, expected monthly spend band, and the requesting team’s billing contact.
2. A human — Robbie, currently — reviews it against the subscription strategy from Part 3. This is the deliberate, documented manual step: the review takes minutes, and every decision it makes is one the automation will later encode. Robbie keeps a running log of every judgement call he makes, labelled “future pipeline logic”. By increment five, that log is the automation spec.
3. The pipeline runs the vending Terraform: creates the subscription via the EA, places it in the right management group, applies the tag policies and budget, wires diagnostics to the central workspace, and creates the workload team’s RBAC.
4. The requesting team gets an email with their subscription ID, their cost dashboard link, and a one-page “what you have and what it means” — written by Netty’s team during a pilot-team working session, which is why it’s actually readable.

Total elapsed time for the first real request: two days and four hours. Against a five-day target and a four-week historical reality. Tessa Spreadsheet’s reaction, in the team channel, was a single emoji and the sentence “I have never once received something from IT ahead of schedule. What is wrong with you people.” — which Fakey has since described as the best review the platform has ever received.

The cost view, or the week Tessa became a platform person

Week 4 contained the meeting Fakey now cites whenever anyone says FinOps is a phase you do later.

Tessa was given a walkthrough of Azure Cost Management pointed at the platform’s first subscriptions, with the tag-to-finance-code mapping live. Twenty minutes in, she stopped the demo and asked the question that changed the roadmap:

“Can I see the hub network’s cost separately? And can I see what each product line’s share of it is?”

The honest answer was “not yet, the allocation rule from Discovery Week isn’t implemented” — and in that moment the shared-cost allocation rule stopped being a policy footnote and became a named deliverable, owned by Tessa, scheduled for increment two. Penny Pockets’ office now had skin in the platform: the CFO’s office could see, for the first time in fakey.xyz’s history, infrastructure cost by product line, updating daily.

Tessa’s verdict at the end of the session: “Fix the tags by hand at month-end and I’ll tell everyone this failed. Do what you just showed me, monthly, automatically — and I will personally sell this platform in every meeting I’m in.”

That sentence is why increment one included a cost dashboard that nobody had prioritised, and why the platform’s most effective evangelist turned out to be in the finance department.

Meanwhile, in audit mode: the first honest number

By week 5, the audit-mode policies had been counting for two weeks, and produced the platform’s first piece of evidence — and its first uncomfortable truth.

The tag audit initiative found that 61% of existing resources (deployed during earlier experiments across the organisation) were missing the finance product code. The diagnostics audit found that 100% of pre-platform subscriptions were sending logs nowhere at all. Serge Secure received this report and — in what Locksley Keymaster described as “the closest Serge comes to joy” — filed it as the first entry in the CPS 234 evidence pack: baseline measured, gap documented, remediation tracked.

The uncomfortable truth was for Fakey: two of the untagged experiments belonged to people in her own engineering organisation, including one subscription belonging to a colleague who had been quietly running a staging environment on it for eleven months. This became increment one’s governance moment — handled not with a deny policy, but with a conversation and a migration plan, which is what audit mode is actually for: you learn who your real customers and offenders are before you have enforcement powers, and by the time you have them, nobody is surprised.

Weeks 5–6: The Pilot Team Gets Real

The final fortnight belonged to Netty Latency’s team — the pilot partnership from Part 1 paying its first dividend.

The pattern that made it work, and the one worth copying:

• Pairing, not handover. Netty’s two engineers worked with Robbie on their first environment request and first pipeline deployment — literally at the same desk (well, same Teams call; Netty’s team sits in the Wellington office two days a week, which is two more than anyone expected).
• Friction was captured as it happened. Every point of confusion got a ticket: the request form’s data classification question was reworded twice; the RBAC model was initially too narrow (the team couldn’t see their own resource group’s cost — a fifteen-minute fix that taught the platform team more about the workload experience than the whole previous month); the “what you have” one-pager was rewritten after Netty’s engineers read it and said “this says what it is, not what I do with it.”
• The pilot team wrote the docs. The golden-path quickstart that came out of week 6 was co-authored, and it shows — it’s the only platform document in fakey.xyz’s history that an engineer has described as “actually good”.

Friday of week 6, 4:47pm. Netty’s engineer deploys a test container app, via GitHub Actions, into the vending-produced environment, wired to the central workspace, tagged correctly, budget active. The pipeline goes green. Netty posts one message in the platform channel:

“Deployed. 8ms budget intact in test. One question: when can my other two engineers have environments? They’re watching me and getting jealous, which is a sentence I never thought I’d say about infrastructure.”

Fakey closed the increment with that screenshot pasted above the sticky note.

The metrics, honestly reported in the increment review to Barry Bigboss:

Barry’s only question: “When does the second team onboard?” — which, given where the series started, is the right question to end an increment on.

The Steal-This Increment Checklist

• A definition of done expressed as one team doing one real thing — not a component list
• Deploy only what you can operate — count the operational surface before you deploy it
• Audit mode everywhere, with a written enforcement date — the protest-signature goes in the notes
• A manual step in the vending process, logged as “future pipeline logic” — automate what you’ve learned, not what you assume
• Finance in the room in week 4, not month 12 — the shared-cost allocation rule is a deliverable, not a footnote
• Friction captured live from the pilot team — every confusion is a ticket, every ticket is roadmap
• Metrics honestly reported, including the overtime and the 0% legacy coverage
• The pilot team co-authors the documentation — and gets jealous teammates by week 6

Next in the Series

Part 5 — “Onboarding the Pilot Team for Real (It Does Not Go Smoothly).” Netty’s production migration begins, the low-latency corridor meets reality, a Friday-afternoon pipeline incident tests the “repo is the truth” rule, and the platform team learns the difference between a customer who is using your platform and one who is depending on it.

What did your first platform increment actually deliver — and what did it promise? Comments open at fakey.xyz.