Discovery Week: Five Days That Decide

Part 2 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 received the cloud mandate from CEO Barry Bigboss, established funding reality with CFO Penny Pockets, mapped the regulatory drivers with security lead Serge Secure, assembled a 1.6 FTE platform team, and presented a one-slide approach to the exec. Part 1 ended with the exec approving a pilot-partnership approach. This post rewinds slightly and zooms in on the part of the story Part 1 skimmed: Discovery Week — the five days of interviews and workshops between “the mandate” and “the approach.” Every question, every artefact, every mistake. Steal all of it.

Fakey has a rule about discovery, learned the hard way over fifteen years of watching projects die:

You cannot discover requirements from people you outrank. You can only collect their silence.

This is why Discovery Week at fakey.xyz is designed around a paradox: Fakey is leading the platform, but during discovery she deliberately talks less than anyone else in the room. Her job this week is not to present the cloud strategy. Her job is to be wrong in public as early and as cheaply as possible.

Here’s how the week actually ran — schedule, questions, transcripts, artefacts, and the three things it got wrong.

The Schedule (Published Five Days in Advance)

Fakey’s first act is to send the schedule to every participant with a one-line promise:

“Nothing decided this week is final, nothing you say this week becomes policy, and no question here is a performance review of how you work today.”

That last line matters more than it looks. The workload teams at fakey.xyz currently deploy through a process that takes a month and nobody can explain. If they think discovery is an audit of their workarounds, they’ll sanitise everything and Fakey will spend a year designing a platform for an organisation that doesn’t exist.

Two design decisions worth explaining:

One team per session, never a combined workshop. Combined discovery sessions produce groupthink. Netty Latency will not say “our fraud model needs sub-5ms to the payment service” in front of Vera Transaction, because in Netty’s experience, whoever states the hardest requirement gets assigned the hardest requirements. Separate sessions; separate honesty.

Friday is empty. The synthesis day is non-negotiable and it’s the one most organisations skip. Discovery without same-week synthesis produces a folder of notes that decay into folklore. By end of Friday, everything must be written down — including what went wrong in the interviews themselves.

The Workload Team Interviews: The Six Questions

Part 1 showed you five of the questions. Here’s the full set, in the order asked, with the actual fakey.xyz answers — because the answers are the instructive part.

Q1. “Walk me through the last environment you requested. What happened, step by step?”

Not “what’s painful about the process” — walk me through the last one. Specifics defeat generalities. What Fakey got, three times, from three teams, in nearly identical words:

“I email someone. I don’t fully know who. There’s a form somewhere but nobody can find the current version. Then there’s a meeting, and after the meeting someone says they’ll sort out the network bit, and then about four weeks later either it works or we get told to do it differently. Nobody ever tells us what stage it’s at.”

Note what’s actually being described: not a technical blocker — an opacity problem. The platform’s first success metric (request → compliant environment in under five working days) was chosen in Part 1’s exec slide, but this is where it came from: three teams independently described not knowing where their request was as worse than the wait itself.

Design implication captured: the vending process must have visible status. A pipeline with a dashboard beats a faster pipeline with no visibility. Write that down.

Q2. “What are you building in the next 18 months, and what will it need?”

This question produced the week’s most consequential single answer. Netty Latency, fraud platform lead, in full:

“The new fraud scoring engine is real-time. When a card transaction comes in, we have a budget of about 8 milliseconds total to score it and respond. The current scoring service talks to the transaction stream and to a feature store. If the new platform puts a firewall hop between those, or routes us anywhere weird, we’re dead — we’ll just fail the latency SLO and I’ll be standing in a meeting explaining it. So whatever you’re building, I need to know the hop count between my services before I commit to it.”

Robbie Deployment wrote one word in his notebook: “hubs.” The preliminary network design in everyone’s heads was a classic hub-spoke with centralised inspection. Netty’s requirement doesn’t kill that — but it means inspection placement between fraud services and the transaction stream is now a named design constraint with a named stakeholder, not a default.

This is the discovery week pattern to internalise: requirements arrive as war stories, not specifications. “We need sub-5ms” is a spec. “I’ll be standing in a meeting explaining it” is the reason the spec exists — and the reason it will be defended, negotiated, and eventually met.

Q3. “What data do you handle, and how would you classify it?”

Hugh Documents, customer onboarding lead, produced the second-consequential answer:

“Identity documents. Passports, driver licences, sometimes visa photos. We run verification against them and we’re required to keep evidence of the check. I honestly don’t know our classification scheme says about them because I’ve never seen the classification scheme.”

Two findings in one quote. First: fakey.xyz’s data classification policy exists on paper but has never reached the teams handling the most sensitive data in the company. Second: the onboarding team’s workload will need the strictest controls and almost certainly the strongest residency guarantees.

Serge Secure’s reaction on Wednesday, upon reading the transcript, was described by witnesses as “Serge discovering he has a bigger job than he thought.”

Design implication captured: the platform’s data classification controls must come with the training and defaults attached. A classification scheme that workload teams have never seen is not a control — it’s a document. The landing zone’s request form will embed the classification question (Post 4’s subscription strategy will lean on this), with plain-language examples, because the teams cannot be expected to know the taxonomy.

Q4. “How do you deploy today, and what would make that faster in Azure?”

The three teams deploy three different ways: one on GitHub Actions, one on Azure DevOps, one with a homegrown script someone maintains out of loyalty. None of them deploy to anything resembling production governance today — their workloads live in the Petone colo or on-prem VMs.

The honest summary of what they asked for, paraphrased across sessions: “Don’t make us learn a new deployment system. Give us ours, pointed at somewhere safe.”

Design implication captured: the platform supports both GitHub Actions and Azure DevOps from day one, and the golden-path documentation covers both. Standardising onto one is a Platform Team Priority; standardising onto one at onboarding is an Adoption Killer. Fakey writes in the synthesis doc: “We standardise later, by attraction, not by mandate.”

Q5. “If you had a compliant environment handed to you in a day, what would you do with it?”

This is the ambition question, and it exists to reveal scale. Answers ranged from Vera Transaction’s measured “migrate the payments API and prove the pattern” to Netty’s “run the fraud model training pipeline properly instead of on a workstation under someone’s desk” (there is, at fakey.xyz, a workstation under a desk running production-adjacent ML training; its location is a closely guarded secret and it will appear again later in this series).

Q6. “What should the platform NOT do?”

Asked last, and Fakey considers it the most valuable question of the week. Summary of answers:

• “Don’t take away our ability to see our own costs.” (All teams — nobody wants opaque chargeback.)
• “Don’t give us a process where we need a meeting to get a firewall rule.” (Netty.)
• “Don’t build it so we need the platform team to do anything routine.” (Vera. Verbatim, and repeated twice for emphasis.)

That last one is the platform’s operating philosophy, gifted by its first customers before a single resource existed: nothing routine requires a human intermediary.

Wednesday: Finance, or the Meeting That Pretends to Be About Money

The session with Tessa Spreadsheet and Penny Pockets’ office was scheduled for one hour. It ran 95 minutes, and by the end they had the closest thing the week produced to a technical specification.

Tessa walked Fakey through fakey.xyz’s actual finance hierarchy: cost centres map to product lines; the board report rolls up product lines to business units; and the annual plan is built in a spreadsheet Tessa is professionally, personally attached to.

The resulting requirements, in platform language:

1. Every resource must carry the finance product code. Not a generic tag standard — their code, at the granularity the board report uses.
2. Cost must be reportable by product line without manual mapping. If finance needs a lookup table to translate Azure tags into finance codes every month, the mapping will silently rot.
3. Shared platform costs need a stated allocation rule. Hub network, firewall, logging — who pays? Penny’s office proposed percentage-of-consumption; the details will take months, but the decision that a rule must exist was made in this meeting.

Tessa’s contribution to the synthesis — and she insisted it go in verbatim:

“If I have to fix cloud tags by hand every month-end, this platform has failed as far as I’m concerned. I will tell people it has failed. I know all of them.”

Policies enforcing mandatory tags go from “governance nice-to-have” to “Penny Pockets’ office is a platform stakeholder.” That single meeting converted FinOps from future backlog item into an increment-one requirement.

Wednesday & Thursday: Security, in Two Halves on Purpose

The security sessions were split deliberately. Part 1 (Wednesday) was requirements; Part 2 (Thursday, with the Privacy Officer joining) was constraints and evidence. Splitting them prevented the classic failure where one three-hour security session produces a wall of demands and no priorities.

The requirements half

Serge Secure arrived with a spreadsheet of 214 security controls and the intent to discuss all of them. Fakey’s counter-structure: every control got sorted into one of three buckets, in a full-day working session with Locksley Keymaster doing the actual sorting:

• ENFORCE — the platform makes this impossible to violate (policy, architecture)
• OBSERVE — the platform makes this visible (logging, detection, alerting)
• ENABLE — the platform gives teams the tooling to comply (templates, docs, golden paths)

This taxonomy did more for the Fakey–Serge relationship than any amount of diplomacy. Serge’s fear — the fear every security lead carries — is that a platform will be built and his controls will be “considered later.” The buckets gave him a place to put every control where it was visibly going somewhere, and gave the platform team a defensible reason for sequencing: you cannot enforce 214 controls on day one, but you can observe nearly all of them cheaply, and observation is the evidence trail CPS 234 actually needs.

By end of Wednesday: 31 controls marked ENFORCE (for eventual, staged rollout), 168 OBSERVE, 15 ENABLE, in a spreadsheet both parties had edited. Fakey described it later as “the most productive argument I’ve had in years.”

The constraints half

Thursday’s session with the Privacy Officer produced the residency decision-in-principle: payment and identity personal data stays in Azure NZ North; analytics and non-personal workloads may use Australia East; and — the nuance everyone was glad someone asked — which data flows to which support and telemetry endpoints became a question for the design phase rather than an assumption.

The session also produced the breach-detection requirement that Part 1 flagged: the Privacy Act’s notifiable-breach regime means the platform’s logging must be capable of supporting a timely detection-and-assessment, not an eventual one. Translated into platform terms: central log analytics, defined retention, and alerting that a human actually watches. (Who watches it — the operating model question — gets its own crisis in Part 8.)

Friday: Synthesis Day, and the Three Mistakes

Friday, no meetings. Fakey, Robbie, and Tessa in a room, producing the artefacts. By end of day:

1. The Driver-to-Control Map — every driver from Part 1 traced to observed/enforced/enabled controls (the Serge spreadsheet, refined)
2. The Draft Requirement Register — 23 requirements, each with a source (which session), a stakeholder (who said it), and a status (confirmed / needs design / conflicts)
3. The Assumptions List — everything they believe but haven’t verified, each with the name of who could falsify it
4. The One-Page “What Is This Platform For” — updated from Part 1 with everything discovery changed

And the honest section, which they titled “What We Got Wrong This Week”:

Mistake 1: They interviewed the teams they already knew. The three workload teams interviewed were the three with good relationships with engineering leadership. The fourth product team — the one with the historically frostiest relationship with central IT — wasn’t interviewed until the following week, and their discovery session surfaced a year of accumulated grievances and a genuinely different integration requirement. The lesson: discovery biased toward your friends is discovery biased toward your assumptions.

Mistake 2: The 90-minute sessions ran short. Two of three workload sessions ran out of clock with questions unasked. Fakey’s fix: 90 minutes was right for rapport but wrong for coverage — the follow-ups became a standing fortnightly coffee with each team lead, which turned out to be a better mechanism anyway.

Mistake 3: Nobody scheduled the exec readout as a decision meeting. The synthesis was presented to Barry Bigboss as an update, which he read politely, and the assumption-list items sat unconfirmed for three weeks because nobody had asked him to decide anything. The fix, applied going forward: every exec touchpoint ends with “here is the decision we need from you today.”

Writing down your discovery mistakes is not humility theatre — it’s the first evidence of the working culture the platform team will operate under. Teams that hide their discovery mistakes build platforms that hide their design mistakes.

The Steal-This Artefact Pack

Everything Discovery Week produced, as templates:

• The schedule + safety promise — sent to participants in advance, including “nothing becomes policy”
• The six questions — last one: “What should the platform NOT do?”
• One team per session — never combined discovery
• The control triage — ENFORCE / OBSERVE / ENABLE, sorted with security, not against them
• The finance session — one hour, mapped to their actual reporting codes, not a generic tag standard
• The requirement register — every requirement with a source and a named human
• The assumptions list — each with a named falsifier
• Synthesis day within the same week — or the notes become folklore
• “What we got wrong” section — written by the discovery team, kept in the repo

Next in the Series

Part 3 — “The Design Decisions Document, and the Arguments Behind It.” Subscription strategy, management groups, network shape — and the one condition Fakey attached to Robbie Deployment’s allocation. MegaCorp Megalodon’s security questionnaire arrives, and the team discovers their requirements document is worth real money before the platform even exists.

How does discovery run in your organisation — and what’s the best discovery question you’ve ever asked? Comments open at fakey.xyz.