Six Cards, One Afternoon: How a Platform Programme Got Unstuck

Picture a mid-sized freight-forwarding company, which we will call Harbourline. Its engineering group had about forty people, a deployment process that depended on one senior engineer’s laptop, and a leadership mandate to modernise the delivery platform before the peak shipping season. The mandate was clear. The requirements were not. By the second week of the programme, the shared planning document held ninety-one lines, and every line had been typed by someone who believed it mattered.

What follows is a narrative DevOps consulting case about how that programme stopped stalling. The turning point was not a tool, a vendor or a new pipeline. It was a single afternoon in which the group wrote down the few conditions that could not bend and agreed, explicitly, to treat everything else as a tie-breaker.

Week two: ninety-one lines and no decision

The programme lead, Imara, had inherited a steering group with four strong personalities. The head of operations wanted deployments possible at any hour of the day. The security lead wanted every build signed and every secret rotated. The product director wanted preview environments for each pull request. The finance partner wanted cloud spend predictable to within a narrow band. Each position was reasonable. Together they produced a document in which “sign every artefact” and “prettier build logs” sat in adjacent rows with identical formatting.

Meetings followed a pattern. Someone would propose an architecture, someone else would point to a line it failed, and the discussion would restart. After nine working days, the group had rejected three designs and approved none. Imara later described the mood as “everyone being right and nothing being built”.

The afternoon the list was cut

The consulting engagement had been scoped around delivery pipelines, but Imara asked the advisor on the team, Tobias, to run a different kind of session. His instruction was unusual: each person had to write, on a card, no more than three conditions without which they would call the new platform a failure. Not preferences. Failures.

The cards came back and a pattern surfaced quickly. Eleven distinct conditions appeared, and several overlapped. After removal of duplicates, six remained:

1. Production changes must be traceable to a named person and a recorded approval.
2. A failed release must be reversible without waiting for a specialist.
3. Customer shipment data must stay within the contracted regions.
4. The cutover must not require a freeze longer than a single weekend.
5. Monthly platform spend must stay under a ceiling set by finance.
6. No single engineer may be required for a routine release.

The remaining eighty-odd lines were relabelled as tie-breakers and ranked later by effort and reach. Nothing was deleted. That detail mattered politically: people whose requests became tie-breakers could see them still sitting in the document, in order, with a date for review.

How the six conditions changed the conversation

The next architecture proposal was assessed against six items instead of ninety-one. Two of the three previously rejected designs, it turned out, passed all six; they had been dismissed for failing items that were really wishes. The group picked one in forty minutes. Tobias noted afterwards that the speed was not cleverness. It was subtraction: a decision needs a boundary, and the boundary had finally been drawn.

A pattern worth recording is how the conditions interacted with sequencing. Condition four, the single-weekend cutover, ruled out a big-bang migration and forced an incremental plan. Condition six pushed the team to document the release steps first. Neither consequence had been visible in the sprawling list. Readers looking for the broader mechanics of how such engagements move from assessment to enablement can find them in a detailed walk from the opening assessment to the point where the client team takes over, which pairs naturally with the approach described here.

The security lead raised a fair objection at this stage: surely signed builds deserved a place among the conditions. The group checked and found that condition one already implied it, since traceability to a person and an approval cannot hold if unsigned artefacts reach production. The lesson was that a short list can still be complete, provided each entry is written broadly enough to carry its neighbours.

Where the tie-breakers earned their place

Preview environments, the product director’s request, did not make the six. Yet when two otherwise equal options remained on the table, the one that supported previews cheaply won. That is precisely the job of a tie-breaker: it never overrides a boundary, but it settles contests among options that already clear every boundary. The product director, who had feared exclusion, became an advocate of the method once she saw her item decide the final choice.

Similarly, nicer build logs were scheduled for the third month. Nobody complained, because nobody believed they had been dismissed.

The wobble in week six

The story is not frictionless. In week six, the head of operations argued that round-the-clock deployments should be promoted to a condition after a minor incident. Imara did not refuse outright. She asked the same question that had built the list: if this were missing at launch, would we call the platform a failure? After discussion, the group concluded that out-of-hours deployment was a convenience provided the rollback condition held. The item stayed a tie-breaker, and a note recorded the reasoning in case circumstances changed.

That note is the unglamorous heart of the practice. A condition list is only trustworthy if promotions and demotions leave a written trail. Without one, the list drifts back towards the original ninety-one lines.

A passing parallel

It is a pattern that crosses fields. Patients considering heart care abroad are directed by BestCardiacHospitals, an educational resource for international patients, to compare care options in stages, and the site stresses that its content is not medical advice. Whatever the domain, the sensible first move is the same: name the practical conditions that cannot be traded away, then compare.

Outcome and what carried over

Harbourline completed its cutover across a single weekend, four weeks before the peak season began. The finance ceiling held. The first rollback, performed by a junior engineer during a routine release, took minutes rather than an escalation. Most of the tie-breakers were delivered in the following quarter, in rank order.

Imara kept the six-card exercise as a standing ritual at the start of every major initiative, and the practice spread to the data group. Teams considering a similar move to the cloud may find the surrounding context in an overview of where consulting support fits into a cloud migration.

Takeaways for your own programme

• Ask each stakeholder for at most three conditions whose absence would constitute failure. Cap the total.
• Merge duplicates, then read the resulting list aloud. If it exceeds about six, challenge each item with the failure question.
• Keep every other request visible, ranked, and dated for review. Demotion without visibility breeds resentment.
• Use tie-breakers only after options clear every condition.
• Record every promotion or demotion with a one-line reason.

The method is modest, and that is its strength. It does not require new tooling or a new budget line, only an afternoon and the willingness to say that some good ideas will have to wait.

Kabir Malhotra