Sanne keeps a laminated card taped to the edge of her monitor. It has nothing to do with Kubernetes or pipelines. It is a short checklist she wrote after the week her team almost shut down a fleet of servers that a payment partner still depended on. She calls it her outside-eyes checklist, and she runs through it before any infrastructure change that cannot be taken back. This post shares the story behind it along with the full list, lightly expanded for anyone who wants to adapt it for your own team. If you are about to make a one-way change and wondering whether an independent design review is worth the delay, start here.
How the card came to exist
Sanne’s team had spent a quarter moving an order-processing service from a group of long-lived virtual machines to a serverless design. The new version was faster to deploy, cheaper at quiet hours and far easier to scale during promotions. Testing had gone well. The final ticket read simply: terminate the old instances and delete their images.
The evening before, she mentioned the plan to Joris, an engineer on a completely different product who sat at the next desk. He asked an innocent question: “What else talks to those machines?” She started to answer and realised she did not actually know. Her team had mapped every caller they could see in their own code and dashboards. Nobody had looked at the firewall logs.
Joris spent an hour with her the next morning. They found an outbound file transfer, configured years earlier by a contractor, that a partner relied on for settlement reports. It ran from one of the old servers on a schedule and was not documented anywhere the team had looked. The termination was postponed, the transfer was rebuilt properly, and the card went up on the monitor that afternoon.
The outside-eyes checklist
Here is her checklist, grouped into four stages. Each item is phrased as a question you can answer yes or no.
Stage 1: Should this change get an independent review at all?
- Will this change delete data, infrastructure or a fallback that cannot be restored quickly?
- Would failure affect customers, partners, money or compliance?
- Has the plan been shaped mainly by people who want it to succeed?
- Is there a deadline, renewal or promise putting pressure on the team to finish?
If two or more answers are yes, the change goes through an outside review. If not, a normal peer review is enough. This filter matters, Sanne says, because asking for independent eyes on every small tweak would wear out goodwill and teach people to skim.
Stage 2: Have I picked the right reviewer?
- Is the reviewer outside my team and outside my reporting line?
- Do they have relevant technical depth in the area being changed?
- Do they gain or lose nothing whether the change goes ahead or not?
- Will they tell me something I would rather not hear?
The last one is the hardest to judge and the most important. A reviewer who is polite to a fault is no better than no reviewer.
Stage 3: Is my review pack honest and complete?
- Have I stated the decision in one sentence, including the point of no return?
- Have I shared the actual runbook, not a summary of it?
- Have I included raw evidence, such as network flow logs, access logs and dependency lists, rather than only my team’s interpretation?
- Have I written down the assumptions we have not been able to verify?
- Have I stated our recommendation openly so it can be challenged?
Sanne’s near-miss came from the third item. Her team’s inventory was correct as far as it went. The gap was in evidence they had never collected. Giving a reviewer raw logs lets them look somewhere new.
Stage 4: Am I ready to weigh a different view?
- Have I agreed in advance that the review is advisory and the decision owner is accountable?
- Do I know who decides if the reviewer and the team disagree on risk tolerance?
- Is there a cheaper, more reversible option I could fall back on if the review raises doubts?
- Will I record the reviewer’s notes and our response in the change record?
When an independent design review disagrees with you
A few months after the server incident, Sanne asked a reviewer from the platform team to look at another one-way step: retiring a self-hosted configuration management system in favour of a newer tool. The reviewer, Femke, felt the switch was premature, arguing that two critical services still used features the new tool handled poorly.
Sanne’s team disagreed. They had tested those features and were satisfied. So they used the approach that has served them since:
- Find what is actually in dispute. Both agreed the new tool was the right destination. The disagreement was about timing.
- Look for evidence that would settle it. Femke suggested a specific failure scenario. The team rehearsed it, and it exposed a real limitation in one service.
- Choose a less permanent route. They migrated everything except those two services, kept the old system running for them in a reduced footprint, and set a review date.
- Write it down. Both positions, the test result and the final call went into the change record.
For background on how experienced architects approach that kind of tooling decision, the piece on how a senior architect weighs configuration management options is a useful companion.
Why the idea travels well
Sanne’s grandmother, a retired nurse, laughed when she heard about the card. In her world, getting another specialist to examine the same findings before a big operation was simply normal. Some health websites now present the request as a regular service; MyMedicPlus, an international health-information and care-travel site, offers a way to send in a diagnosis for an expert to examine. This blog makes no judgement on any medical matter, which is entirely for qualified clinicians. The point is only that careful professions treat a fresh look before an irreversible step as ordinary good practice.
Adapting the checklist for your team
The card works because it is short and personal. A few suggestions for making your own version stick:
- Keep it to one page. If it grows longer, people stop reading it.
- Attach it to the change template so the stage-one filter is answered on every risky ticket.
- Rotate reviewers so no single person becomes a bottleneck or a rubber stamp.
- Time-box reviews to a few days; urgency is real, but so is the cost of an irreversible mistake.
- Celebrate catches publicly. When a review finds something, thank the reviewer in front of the team.
Teams designing larger cloud environments will find the checklist fits naturally alongside the patterns in our article on building fast, resilient DevOps environments on AWS. Architecture choices made early often determine which later changes become one-way doors.
The quiet value of asking
Sanne says the card has caught something genuine more than once since it went up. Just as often, the reviewer simply confirms the plan, and the team proceeds with more confidence. Either outcome is worth an hour of someone else’s time. The card stays on her monitor because the one time it mattered most, it was the difference between a quiet Friday and a partner phoning to ask where their reports had gone.