You own the baseline every new team account is issued with — how do you decide what it mandates and what teams choose?
answer
- each item is owned forever
- mandate what cannot be retro-fitted
- mandate what fails silently
- leave what varies with the workload
- vending must stay the easiest path
basics
~20 sMandate what cannot be retro-fitted, what fails silently, and what protects people outside the team; leave whatever varies with the workload. Every baseline item is owned forever, and a baseline heavy enough to be routed around stops being coverage at all.
solid answer
~50 sTwo costs pull in opposite directions. Everything in the baseline is something the platform team now owns for every account forever: it must apply, re-apply, evolve and be defended when it breaks somebody. Everything left out gets decided separately by every team, and the ones that matter get decided badly under deadline. So mandate on three tests — the item cannot be retro-fitted cheaply, its absence is invisible until an incident or an audit, or its beneficiary is somebody outside the team that would otherwise choose. Leave to teams whatever varies with the workload or is cheap to change later. Then watch the number that actually decides the outcome: the share of accounts that came through vending. A baseline heavy enough that teams get accounts another way has converted real coverage into a report that merely looks like coverage.
go deeper
Notice that the standards arriving with a new account are somebody's deliberate choice rather than a property of the platform, and that each one has an owner who maintains it.
Be able to sort concrete settings into what must be uniform and what varies by workload, and to justify the split by what each one would cost to change later.
Show that you would stage a tightening — report, then mandate for new accounts, then sweep existing ones in waves — rather than enforcing everything at once and causing the incident yourself.
The judgment being tested is that a baseline competes with the easiest path to an account: coverage teams route around is weaker than a smaller baseline everyone actually uses.
## Two costs pulling opposite ways A baseline is not free in either direction, and the judgment is entirely about which cost you would rather carry. **What you put in** becomes a permanent obligation. Someone must be able to apply it to a new account, re-apply it to an old one, change it without breaking the accounts that already have it, and answer for it at two in the morning when it turns out to be why a deployment failed. A baseline item with no owner is a liability with a governance label on it. **What you leave out** gets decided once per team, independently, by whoever is closest to a deadline. For most settings that is correct and healthy. For a few, it means the organisation has as many answers as it has teams, and discovers the fact during an incident. ## Three tests for mandating 1. **Can it be retro-fitted cheaply?** If not, it belongs in the baseline. An address range allocated from a central plan, the placement that decides which policy set applies, and the ownership record are all nearly free at issue and painful later — the first two because live traffic makes them a migration, the third because reconstructing intent is archaeology. 2. **Is its absence silent?** If a missing item produces no symptom until an incident review or an audit, nobody will ever add it voluntarily. Delivery of the audit trail and platform logs outward is the archetype: no team has ever missed it in the moment. 3. **Who benefits?** If the beneficiary is the team itself, the team can be trusted to decide. If the beneficiary is the organisation — the investigator six months later, the neighbouring account that needs to connect, whoever answers the auditor — the team has no incentive that matches the risk, and the decision belongs in the baseline. ## What to leave alone - Anything that varies with the workload: no central default is right for most of the teams receiving it. - Anything cheap to change later: mandate it and you have bought an obligation to avoid a cost the team could have paid itself. - Anything you cannot actually enforce. A rule teams route around is worse than no rule, because it appears as coverage in a report and is not. | Setting | Where it belongs | Why | |---|---|---| | Private address range | Baseline | Effectively irreversible once traffic flows; overlap blocks joining later | | Log and audit delivery outward | Baseline | Absent silently, and the beneficiary is not the team | | Owner, purpose, expiry | Baseline | A form field now, archaeology afterwards | | Placement in the hierarchy | Baseline | It decides which guardrails apply at all | | Machine sizes and scaling | Team | Varies with the workload and is cheap to change | | Storage tiers and lifecycle | Team | Depends on access patterns nobody central knows | | Alert thresholds | Team | A central value is wrong for most services that get it | | Tag vocabulary | Negotiated | Uniform keys centrally; the values belong to the team | ## The baseline is a versioned product Treat it as software with consumers, because that is what it is. - **Additive changes are cheap** for newly issued accounts and expensive for existing ones; separate the two decisions rather than bundling them. - **Tightenings need a rollout**, not an announcement: report the size of the gap first, mandate for new accounts second, sweep existing accounts in waves third. - **You must be able to state which accounts are on which version.** A baseline you cannot version is one you can never change safely. - **Every item needs a named owner** who will take the call when it is blamed. ## The number that tells you the answer The honest measure of a baseline is not how much it covers on paper. It is the share of accounts that came through vending at all, together with how long a request takes to become a usable account. Those two move in opposite directions: each item added to the baseline makes the process a little slower and a little more likely to be worked around, and every account created around it is an account about which the organisation can make no claim whatsoever. That is the trap worth naming explicitly. A mandated default that teams quietly defeat — a network restriction every team opens a path around, a required setting everyone disables on day two — looks identical in a report to one that works. The baseline competes with the path of least resistance, and a smaller baseline that is genuinely universal beats a larger one that is technically mandatory.
- How do you introduce a tightening to a baseline that many existing accounts will fail?Add it first as a reported finding with an owner attached, so the size of the gap is known before anything breaks. Then mandate it for newly issued accounts, which costs nobody anything. Then sweep existing accounts in waves, with owners warned. Tightening first and measuring afterwards is how a baseline earns the reputation that makes its next change harder.
- What tells you a baseline has grown too heavy?Two signals. Accounts start appearing that never went through the vending path, and the time from request to a usable account grows until teams plan around it. Both say the same thing: the baseline is no longer the easiest way to get an account, and every account created around it is one you can make no claim about.
saying these in an interview costs you the question
- Puts everything in the baseline, treating standardisation as free
- Says teams who dislike the baseline can simply be told to comply
- Freezes the baseline once written, so it never gains a control
- Counts a default teams have worked around as real coverage
- Treats accounts created outside vending as the teams' problem