How do you decide which journeys deserve end-to-end coverage, and keep that set from growing?

### Why this is a portfolio problem Every end-to-end journey is a standing liability: it consumes pipeline wall-clock, it needs an environment healthy enough to run, it breaks when the interface it drives is redesigned, and each ambiguous failure costs engineer hours to diagnose. It is also an asset: it is the only artefact that catches wiring, configuration and cross-component sequencing defects on a path real users walk. A portfolio holds assets under a constraint, and the constraint here is not moral - it is a budget nobody usually writes down. So write it down. Two numbers work: a **wall-clock ceiling** for the layer in the pipeline (what delay the team will tolerate before a release decision), and an **expected diagnosis load** (how many ambiguous failures per week the team can absorb). Both are choices, and different products choose differently - a payments platform and an internal reporting tool should not land on the same numbers. ### The two selection filters **Consequence.** Ask what is lost if this journey silently breaks for a day, and whether the loss is reversible. Money movement, safety, regulatory obligations, anything a user cannot undo, and anything that would be discovered by a customer rather than by the team all raise the score. For an airline seat-map service, *passenger reserves and confirms a seat on a paid booking* scores high: a silent failure is lost revenue plus a support queue. *Passenger changes the cabin-view colour theme* does not. **Uniqueness.** Ask which cheaper test could observe the same outcome. If a narrow test can, the journey adds cost without adding information. The journeys that survive this filter are the ones whose value lies in the crossing itself - several separately deployed components, real configuration, real serialization between them, real sequencing. A useful third input, where it is available, is **actual usage**: which journeys real traffic exercises most. It is evidence rather than opinion, and it usually reorders a team's intuitive list. ### Governance, because selection decays Selection is a one-off; the set grows continuously. Three mechanisms hold it: 1. **An admission rule.** Adding a journey requires stating in the change what it uniquely catches that no cheaper test can. Where the budget is already spent, adding one means retiring one. This converts a vague preference for fewer tests into a decision someone has to make explicitly. 2. **A push-down habit.** After every genuine end-to-end failure, ask which cheaper test would have caught the same defect, and write it. Do this consistently and the layer stops being the place defects are found and becomes the place they are prevented from escaping - and some journeys become retirable. 3. **A periodic review against evidence.** For each journey ask: has it caught a real defect in the last year, how many hours has it cost in diagnosis, and does the risk it covers still exist? A journey that has never failed for a real reason is not proof of a healthy system; it may simply be watching a path nothing changes any more. ### The escape-driven counterweight Governance that only ever removes is as wrong as growth that only ever adds. The counterweight is the **escaped-defect review**: when a defect reaches users, ask what would have caught it. Sometimes the honest answer is a journey that does not exist, and then the set should grow - deliberately, with the budget revisited rather than quietly exceeded. ### The organisational dimension The hardest part of this is rarely technical. Ownership decides everything: a suite owned by a separate group tends to grow, because the people adding journeys do not pay the diagnosis cost. Putting the journeys with the teams who own the components they cross aligns cost with benefit, and makes retirement conversations possible. Similarly, a shared suite that everyone depends on and nobody owns becomes the place where nobody may delete anything - which is how a thin layer stops being thin. Be honest, too, about what is contested. There is no evidence-backed universal number of journeys, no defensible ratio that applies across products, and the common claims about defect-cost multipliers by phase are widely repeated and weakly supported. What is defensible is the *shape of the reasoning*: risk times reversibility, uniqueness against cheaper levels, an explicit budget, and evidence-driven review. Assert the method, not a number. ### How to answer this in an interview Name the filters, name the budget in units you would actually publish, and give the two governance mechanisms that create the counter-pressure - the admission rule and the push-down habit. Then say what you would measure to know the portfolio is working: defects caught only here, escaped defects that a journey should have caught, and hours spent diagnosing. A candidate who answers with a number of tests has missed the question; a candidate who answers with a decision procedure and its feedback loop has owned it.