Review all case details

Same verification standard. Redesign mobile capture, add save and resume, and make reason codes mandatory on every review decision.

Protects: The verification standard and an explainable review trail.

Costs: Several weeks of lower conversion while fixes ship.

Conditions: When drop-off is mainly friction rather than applicants who cannot pass.

Earlier choices: Any earlier path
Mobile completion recovers to 53% within three weeks. Every review decision now carries a reason a reviewer or auditor can read.

Lower-risk segments get a document set that still meets policy minimums; higher risk keeps the full step. Compliance signs off the tiers.

Protects: Conversion where extra friction adds little risk insight.

Costs: A tiering model that needs a named owner, documentation and periodic review.

Conditions: When compliance confirms every tier meets the policy minimum and the tiering logic can be explained to a reviewer.

Earlier choices: Any earlier path
Compliance approves two tiers. Completion reaches 57%, and the tiering rules now need an owner and quarterly review.

Risk flags: model-owner

Let merchants start accepting cards immediately and complete verification afterwards.

This bypasses KYC. It is shown because it is commonly proposed, not because it is a valid option.

Protects: Short-term activation numbers.

Costs: Merchants process payments before verification is complete, which the acquirer's policy does not allow.

Conditions: Not defensible here. Policy requires verification before activation. Faster review is the legitimate lever.

Earlier choices: Any earlier path
Compliance stops the change before release. Two weeks are lost and the review backlog is still four days.

Risk flags: kyc-bypass

Build a single verified merchant record. Launch POS first, then gateway and online on the same record.

Protects: Consistent verification and one source of truth across channels.

Costs: Online and gateway merchants wait for wave two.

Conditions: When most of the segment's value is in-store, or when online fraud controls are not yet proven.

Earlier choices: Any earlier path
POS launches on the shared record. Gateway and online follow six weeks later with no duplicate verification.

Launch POS, gateway and online at once on a shared record, with a larger integration team.

Protects: The omnichannel proposition the segment asked for.

Costs: Three integration risks land in the same week, with shared people on support.

Conditions: When the gateway security review is complete and support can absorb three channels at once.

Earlier choices: Any earlier path
Launch date holds, but the direct API security review becomes the critical path.

Risk flags: parallel-risk

Keep three onboarding systems. Each channel team launches when ready.

Protects: Channel team independence and speed for the first channel.

Costs: Three verification records that can drift apart, and merchants asked for the same documents three times.

Conditions: Only as a short bridge when a shared record is more than a quarter away, with reconciliation between records.

Earlier choices: Any earlier path
POS launches quickly. Within a month, 40 merchants have mismatched details between channels.

Risk flags: record-drift

Launch to 50 merchants with written exit criteria: activation time, first-transaction success and review backlog.

Protects: Real evidence before scale, with a defined point to expand.

Costs: The commercial headline is smaller at launch.

Conditions: When the launch includes anything not yet run in production, such as a new channel or record.

Earlier choices: Any earlier path
The pilot meets two of three criteria. Review backlog is the one to fix before scaling.

Launch to the whole segment on the date. Known gaps are written down and accepted by a named executive.

Protects: The commercial date and clear ownership of the remaining risk.

Costs: Open gaps become live risks for every merchant in the segment.

Conditions: When the open gaps are operational rather than verification or security gaps, and the person accepting has the authority to do so.

Earlier choices: AA, AC, BA, BC, CA, CC
The segment launches on the date. Two operational gaps are tracked to closure by their owner.

Earlier choices: AB, BB, CB
The open API findings are a security gap, so risk acceptance is challenged. Launch proceeds for POS and hosted page only.

Risk flags: security-acceptance

Move the date until all channels meet every gate.

Protects: A clean launch with nothing outstanding.

Costs: Lost commercial window and pressure on the next date.

Conditions: When a gate failure would affect verification, funds or card data, not just convenience.

Earlier choices: Any earlier path
Launch moves six weeks. The segment's largest prospect signs with a competitor for its online channel.

Leave business declines alone. Move a bounded share of the affected issuers to the alternate link and watch its error rate.

Protects: Service for most affected traffic without overloading the alternate link.

Costs: About 40% of the affected traffic still times out until the primary link recovers.

Conditions: When you can see response codes by issuer and link, and the alternate route has headroom you have measured.

Earlier choices: Any earlier path
Success recovers to 94.8% in eight minutes. The alternate link holds at 85% of its capacity.

Turn on automatic resend for all failed authorisations to recover volume quickly.

Blanket retry is unsafe on a payment path. It risks double charging and makes the outage larger.

Protects: Nothing reliable. Retries do not fix a failing link and resend business declines.

Costs: Duplicate approvals for requests that already succeeded at the issuer, extra load on a failing link, and resent declines.

Conditions: Not defensible as a blanket action. Retries are only safe for specific failure codes with an idempotency key the issuer honours.

Earlier choices: Any earlier path
Load on the failing link rises 70%. Success dips to 86.0% and the number of requests with an unknown outcome more than doubles.

Risk flags: blanket-retry, duplicate-risk

Approve low-value transactions on behalf of the two issuers within their written stand-in limits. The third issuer stays on its normal route.

Protects: Cardholder and merchant experience for low-value payments.

Costs: Credit exposure within the limits, and stand-in advices that must be sent and reconciled later.

Conditions: When stand-in limits exist in writing for each issuer and advice processing is tested.

Earlier choices: Any earlier path
Low-value approvals recover for two issuers. The third issuer's timeouts continue.

Risk flags: stand-in-exposure

Wait for issuer and scheme records, match each unknown request by key, then reverse only confirmed duplicates.

Protects: Financial correctness: only real duplicates are reversed.

Costs: Two hours of uncertainty for merchants and cardholders.

Conditions: When keys are present and issuer records will arrive before settlement cut-off.

Earlier choices: A, C
Matching confirms 180 duplicates from manual re-presentment. Each is reversed with a reference.

Earlier choices: B
Matching confirms 610 duplicate approvals created by the blanket retry. Each is reversed with a reference.

Send reversals for all requests with an unknown outcome so no cardholder stays charged.

Blanket reversal swaps one integrity problem for another.

Protects: Speed for cardholders who were charged twice.

Costs: Valid approvals are also reversed, so merchants may ship goods they are not paid for.

Conditions: Only for a narrow set where evidence shows no approval can have reached the issuer.

Earlier choices: Any earlier path
Duplicates are cleared, but around 1,000 valid payments are reversed and must be re-collected.

Risk flags: blanket-reversal

Take no action now. The normal reconciliation will surface any duplicates.

Protects: Team focus on recovery.

Costs: Cardholders stay double charged for a day or more, and duplicates may enter settlement.

Conditions: When the volume is very small and the next reconciliation runs before settlement.

Earlier choices: Any earlier path
Reconciliation flags duplicates after the settlement file is built. Corrections must go through adjustments.

Risk flags: late-detection

Settle verified items on time. Hold suspects and release them through adjustments prepared and approved by different people.

Protects: On-time funding for most merchants and correct books.

Costs: Some merchants receive part of their funds a day late.

Conditions: When you can isolate suspect items and have independent approval for adjustments.

Earlier choices: AA, AB, BA, BB, CA, CB
The clean batch settles on time. Suspect items clear over two days with a full adjustment trail.

Earlier choices: AC, BC, CC
Isolation takes until cut-off. The batch settles 40 minutes late but correct.

Hold the entire file until every item is verified.

Protects: Absolute certainty in the file.

Costs: Every merchant is funded late, including those unaffected.

Conditions: When suspect items cannot be isolated and errors would be large or hard to recover.

Earlier choices: Any earlier path
All merchants are funded a day late. The support desk takes 900 calls.

Send the full file on time and fix errors with chargebacks and adjustments afterwards.

Knowingly settling unverified duplicates puts financial integrity behind the deadline.

Protects: The funding date.

Costs: Known errors are paid out, and recovering funds is slower and less certain than holding them.

Conditions: Only when suspect value is trivial and recovery from merchants is reliable.

Earlier choices: Any earlier path
Funds move on time, including duplicates. Recovery takes weeks and some is written off.

Risk flags: integrity-deferred

One L1 seat and one L2 seat, 24/7.

Protects: Immediate L2 diagnosis at any hour.

Costs: Uses all twelve people with no spare for handover overlap, training or absence above the assumption.

Conditions: When overnight incidents needing L2 are frequent enough to justify the cost and you can add headcount soon.

Earlier choices: Any earlier path
Coverage works on paper. The first month with two people on leave forces overtime on four shifts.

Risk flags: no-slack

L1 24/7. L2 staffed 07:00 to 23:00 with a paid on-call rota overnight, and two people spare for overlap and absence.

Protects: Sustainable shifts with a 30-minute handover overlap.

Costs: Overnight L2 response depends on on-call wake-up time.

Conditions: When most overnight incidents can be contained by runbooks until L2 joins within an agreed time.

Earlier choices: Any earlier path
Shifts get a 30-minute handover overlap. Overnight L2 joins within 20 minutes on average.

Double-staff L1 and L2 around the clock for resilience.

This coverage is impossible with the available people. A rota that relies on unsustainable hours is a risk, not a control.

Protects: The appearance of resilience.

Costs: Needs twice the available headcount. It only works on paper with 70-hour weeks.

Conditions: Only with roughly double the headcount. With twelve people it is not achievable.

Earlier choices: Any earlier path
The rota cannot be filled. Gaps appear in week one and overtime becomes the plan.

Risk flags: impossible-coverage

Named, time-bound elevation for L2 with logging. High-risk changes approved by someone other than the executor, often L3. Validation by a third person or an automated check.

Protects: Every privileged action is attributable, and nobody approves or checks their own work.

Costs: Slower emergency changes and an approver rota at night.

Conditions: For any change or access that could affect funds, card data or many merchants.

Earlier choices: A, B
Elevation is logged per person. Emergency change approval moves to L3 on-call, with validation by an automated check.

Earlier choices: C
The controls are sound, but nobody is free to approve at night. Approvals fall back to L3 on-call.

Make L1 and L2 different teams with different managers. Keep the shared account and executor approval.

Separate teams are not separation of duties if one person can still approve and execute their own high-risk change.

Protects: A clear org chart.

Costs: No real control: the same person still holds access, approves and validates.

Conditions: Splitting teams helps capability and ownership. It is not a control on its own.

Earlier choices: Any earlier path
The structure looks tidy. The next audit finds self-approved emergency changes unchanged.

Risk flags: split-not-control, self-approval

L2 diagnoses only. Every recovery action is done by engineering on-call.

Protects: Privileged access held by fewer people.

Costs: Slower recovery and engineers paged for routine runbook actions.

Conditions: When recovery actions are rare and mostly need code changes rather than runbooks.

Earlier choices: Any earlier path
Overnight recovery time rises from 25 to 55 minutes. Engineers report on-call fatigue within a month.

Risk flags: l3-fatigue

Triggers are met, so page L2 and an incident commander. L3 owner for the gateway joins. Handover notes are written as the incident runs.

Protects: One person directing, with the right owner on the problem.

Costs: Two or three people woken for an incident that may turn out small.

Conditions: When the escalation triggers have been agreed in advance and are met.

Earlier choices: Any earlier path
The L3 owner finds a certificate issue within 20 minutes. The fix is approved independently and validated against live approvals.

To save time, the L2 engineer approves and executes a configuration change on the gateway alone.

Self-approval of a high-risk change is exactly what separation of duties exists to prevent.

Protects: Speed at 3 a.m.

Costs: No independent check on a high-risk change made by a tired person.

Conditions: Not defensible for a high-risk change. Use pre-approved standard changes if speed matters.

Earlier choices: Any earlier path
The change restores approvals but disables a fraud rule as a side effect. It is found at 09:00.

Risk flags: self-approval

Wake L2, L3, vendor support and management at once.

Protects: Nobody can say they were not told.

Costs: Several people talking at once and no clear commander. Fatigue for the next day.

Conditions: When impact is severe and broad, and an incident commander is named in the first minutes.

Earlier choices: Any earlier path
Twelve people join the bridge. Diagnosis takes 45 minutes because nobody is directing.

Risk flags: no-commander

Check which transactions are actually affected, order the signals in time and test whether the database is cause or symptom.

Protects: Acting on the cause, not the loudest symptom.

Costs: A few minutes of continued impact while you look.

Conditions: When impact is contained and the recommended action is disruptive.

Earlier choices: Any earlier path
The timeline shows database pressure following token retries. The database looks like a symptom.

92% is high. Let the tool fail over the database.

Confidence alone does not authorise automation, especially for actions outside an approved runbook scope.

Protects: Speed, if the tool is right.

Costs: A disruptive action on stale telemetry and a noisy alert. Failover drops in-flight transactions.

Conditions: Not defensible here. Failover is outside the tool's approved action scope, and the evidence is stale.

Earlier choices: Any earlier path
Failover takes four minutes and drops in-flight requests. Approvals do not recover because the cause is elsewhere.

Risk flags: confidence-not-authority, symptom-chased

Mute the grouped alerts for 15 minutes and wait for a clearer signal.

Do not mute unresolved customer impact. Suppress only confirmed noise, with critical signals retained, a named owner and an expiry.

Protects: Responders from alert fatigue.

Costs: Real impact continues unobserved and the signal you need may be muted.

Conditions: When alerts are confirmed false and no customer impact is visible.

Earlier choices: Any earlier path
Card-not-present approvals keep falling. A merchant reports it before the team sees it.

Risk flags: muted-impact

Check the token service's dependencies, refresh the stale exporter and test one hypothesis at a time.

Protects: A diagnosis you can explain and validate.

Costs: Takes a specialist and some minutes.

Conditions: When the dependency map is current and the earliest signal is clear.

Earlier choices: Any earlier path
The certificate store shows one node serving an old certificate chain after a rotation at 02:00.

Allow the pre-approved runbook action: restart stateless pods, one at a time, with automatic stop on error.

Protects: Fast, bounded action inside an approved scope.

Costs: May mask the cause if it is not in the pods.

Conditions: When the action is inside an approved, reversible runbook scope and you keep investigating in parallel.

Earlier choices: A, C
Restarts briefly clear errors on two pods, then errors return. That points away from the pods.

Earlier choices: B
Restarting payment API pods has no effect. The cause is still unknown.

Open a priority case with the certificate and HSM vendor and wait for their analysis.

Protects: Specialist knowledge of the vendor's components.

Costs: Vendor response time while impact continues.

Conditions: When the evidence points into a vendor-owned component you cannot inspect.

Earlier choices: Any earlier path
The vendor responds in 40 minutes and asks for logs your team could have checked.

Remove the node from rotation with on-call approval. Confirm recovery by approval rate and token success, not by alerts going quiet.

Protects: A measured recovery with a named decision.

Costs: Minutes for approval at night.

Conditions: When the action is reversible and its effect can be measured within minutes.

Earlier choices: AA, BA, CA
Approvals return to baseline within six minutes, confirmed against transaction data.

Earlier choices: AB, AC, BB, BC, CB, CC
The node is removed on suspicion. Approvals recover, but the team confirms the cause only next morning.

Let the tool act on its own whenever confidence passes 90% in future.

A confidence threshold is not an action scope. Tonight's high-confidence call was a symptom.

Protects: Faster responses for repeat issues.

Costs: Tonight's 92% recommendation was wrong. This would have made it automatic.

Conditions: Not defensible. Expand action scopes per runbook, with limits and rollback, not by a confidence threshold.

Earlier choices: Any earlier path
The policy is drafted, then withdrawn after review finds it would have failed over the database tonight.

Risk flags: confidence-not-authority

Fix by hand tonight. Afterwards, retire the noisy pool alert, add exporter staleness alerts and add certificate rotation to the dependency map.

Protects: Better signals for the next incident.

Costs: Tonight's fix depends on the engineer on call.

Conditions: When tonight's action is simple and the bigger gain is telemetry quality.

Earlier choices: Any earlier path
Recovery takes 20 minutes. The follow-up removes 40% of noisy alerts the next month.

Charter the centre for two bounded services with agreed outcomes, a fully loaded cost case and a go or no-go review at month 9.

Protects: Learning before commitment. A business case tested against real delivery, quality and retention.

Costs: Slower to show scale. The vendor contract may need a short extension.

Conditions: When the organisation has not run its own engineering centre before, or the talent market is unproven.

Earlier choices: Any earlier path
The board approves a 12 role pilot with outcome measures. Finance accepts the fully loaded cost case after the salary-only view is withdrawn.

Give the centre end-to-end ownership of one product domain, with 30 roles, a named product partner at headquarters and explicit scope boundaries.

Protects: Real ownership from the start, which attracts stronger talent than a support role.

Costs: More hiring and transition risk at once. Headquarters must give up part of a roadmap.

Conditions: When a sponsor can enforce the scope boundary and the domain has few dependencies on other teams.

Earlier choices: Any earlier path
The centre owns the merchant reporting domain. Two headquarters product heads accept the boundary; one escalates and the sponsor holds the line.

Approve 60 roles and move every service from the vendor within the year to capture the salary saving quickly.

Overbroad immediate transfer on a salary-only business case. Headcount is not capability, and continuity depends on the incumbent you are exiting.

Protects: The headline saving and a simple story for the board.

Costs: Overbroad scope, a salary-only business case and a hiring plan the market cannot fill in time.

Conditions: Rarely defensible. Only if the vendor is exiting anyway and a large experienced team can be acquired intact.

Earlier choices: Any earlier path
The plan is approved on the salary comparison. Transition, overlap and management costs are not in the budget.

Risk flags: salary-only-case, overbroad-transfer

Hire the centre lead, architects and engineering managers first, then about 3 starts a month. Shadow, then reverse-shadow the vendor, with written exit criteria per service.

Protects: Continuity and real knowledge transfer. Clear readiness evidence before the vendor steps back.

Costs: Slower ramp and a longer, more expensive overlap with the vendor.

Conditions: When live services are critical and knowledge sits with a few vendor people.

Earlier choices: A, B
Services move one at a time after reverse-shadowing. Exit criteria are met for the first service at month 8.

Earlier choices: C
The spine is hired, but at this pace the 60 role plan cannot be met in year one. The board is told the scope must shrink or the vendor stays longer.

Hire leaders and teams together at about 5 starts a month. Services transfer only after a readiness review: runbooks, on-call, access, test coverage and one incident handled.

Protects: A faster ramp with a readiness gate that stops premature handover.

Costs: Managers onboard while hiring. Early teams carry more risk of inconsistent practice.

Conditions: When some experienced leaders are already available and the gate is enforced by someone independent of the centre.

Earlier choices: A, B
Two services pass the readiness gate by month 9. One fails on runbook gaps and stays with the vendor another quarter.

Earlier choices: C
Hiring moves, but readiness reviews keep failing on access and knowledge gaps. Transfers slip and the vendor is extended.

Open all roles through agencies at about 10 starts a month and end the vendor contract on the original date regardless of readiness.

Ending the incumbent before exit criteria are met puts live service at risk. Headcount is not readiness.

Protects: The original date and the headline headcount.

Costs: Headcount arrives without context or mentors. Live services lose the people who know them.

Conditions: Not defensible for live payment services. A hard date is not a readiness criterion.

Earlier choices: Any earlier path
Headcount targets are reported as met. A settlement report fails in the first month after exit and nobody in the new centre has run it before.

Risk flags: exit-before-ready

Scale by one domain at a time, each with written decision rights, funding and intake, service acceptance, risk tiers for change, security and quality guardrails, succession plans and an independent challenge role retained at headquarters.

Protects: Growth tied to evidence, with clear ownership and an independent check.

Costs: Governance effort and slower growth than headquarters wants.

Conditions: When delivery, quality and retention evidence is positive and a next domain is ready to accept.

Earlier choices: AA, AB, BA, BB
A second domain is chartered with acceptance criteria. Headquarters keeps strategy and architecture challenge.

Earlier choices: AC, BC, CA, CB, CC
The charter is sound, but the evidence does not support scaling yet. Service acceptance blocks the next domain until quality recovers.

Keep scope as is for two quarters, fix the weakest service, close remaining vendor dependencies and build succession for key roles.

Protects: Stability and quality before more growth.

Costs: Lost momentum. Strong engineers may leave if the centre looks stalled.

Conditions: When quality or retention evidence is mixed, or a key dependency on the vendor remains.

Earlier choices: Any earlier path
Defects fall and the last vendor dependency closes. The scale decision returns in two quarters with better evidence.

Approve doubling headcount on the strength of the year one story, without service acceptance or new decision rights.

Equating the label with maturity. Scaling without acceptance criteria or decision rights multiplies the existing weaknesses.

Protects: Momentum and a visible commitment.

Costs: Scales whatever is weak today, and leaves ownership unclear between headquarters and the centre.

Conditions: Rarely. Only if every outcome measure is strong and governance is already in place.

Earlier choices: Any earlier path
Headcount doubles. Two product heads and the centre lead both claim the same roadmap and nobody resolves it.

Risk flags: label-not-maturity

Compliance and legal confirm what applies. Each requirement gets an owner, the evidence needed and its dependency on others.

Protects: Engaging each body on what it actually decides.

Costs: A week of mapping before visible progress.

Conditions: When a launch changes outsourcing, data flows or acceptance methods.

Earlier choices: Any earlier path
The map shows regulator notification, two scheme certifications and committee approval, with the assessor report as an input to two of them.

The previous launch went well. Use its approvals list.

Protects: Speed and familiarity.

Costs: The last launch had no outsourcing change, so a notification and an approval may be missed.

Conditions: When the new launch has no material differences from the previous one.

Earlier choices: Any earlier path
The checklist omits outsourcing. Nobody owns the regulator notification.

Risk flags: missed-requirement

Ask the Authority to review the whole launch, including scheme and internal matters.

Protects: A feeling of maximum caution.

Costs: Asks the regulator about matters it does not decide, and delays the ones it does.

Conditions: When genuine uncertainty about applicability cannot be resolved by compliance and legal.

Earlier choices: Any earlier path
The Authority replies that scheme certification and internal approvals are not its matters. Two weeks pass.

Risk flags: authority-confused

Fix the edge case and book a re-test. Send a complete written response on outsourcing. Keep a conditions register.

Protects: Every required approval on paper.

Costs: The date may slip if the re-test slot is late.

Conditions: When fixes are known and re-test slots are available within the window.

Earlier choices: Any earlier path
Re-test is booked for week -2. The written response is filed with the assessor's report attached.

A contact at the Authority sounded comfortable on a call. Treat that as clearance and launch on the date.

Informal agreement never replaces a required written approval.

Protects: The announced date.

Costs: No written outcome. The scheme failure is still open.

Conditions: Not defensible. An informal conversation does not replace a required written response or certification.

Earlier choices: Any earlier path
Legal blocks the plan. The written response is drafted in a hurry a week later.

Risk flags: informal-approval

Launch without the edge-case flow, after Scheme A confirms in writing that the reduced scope is certified. Respond to the Authority in writing.

Protects: The date for most of the product.

Costs: A smaller launch and a second release later.

Conditions: When the descoped flow is not essential and the scheme confirms the reduced scope in writing.

Earlier choices: Any earlier path
Scheme A confirms the reduced scope in writing. The edge-case flow moves to a later release.

Launch when every required written approval is in place. Conditions and assessor findings are owned and reported to the risk committee.

Protects: A launch with clear evidence and owned conditions.

Costs: Ongoing reporting overhead.

Conditions: When every required approval is in writing and remaining items are conditions, not missing approvals.

Earlier choices: AA, AC, BA, BC, CA, CC
Launch proceeds. Conditions are reviewed monthly until closed.

Earlier choices: AB, BB, CB
Scheme A is not certified, so the register shows a missing approval. Launch waits.

Move the launch by four weeks to close every finding first.

Protects: A launch with nothing outstanding.

Costs: Commercial credibility after the public announcement.

Conditions: When a required approval is missing or a finding affects card data or funds.

Earlier choices: Any earlier path
Launch moves to week +4. Sales manages the change with key merchants.

Process live payments for a few friendly merchants while approvals are pending.

A small live launch is still a live launch. It needs the same required approvals.

Protects: Early operating experience.

Costs: Live transactions without the required approvals, however few.

Conditions: Only when no approval is required for the pilot scope, confirmed in writing.

Earlier choices: AA, AC, BA, BC, CA, CC
Compliance confirms the pilot scope needs the same approvals. It starts after they land.

Earlier choices: AB, BB, CB
Compliance stops the pilot before it starts.

Risk flags: pilot-without-approval

Measure lead and cycle time, time waiting and blocked, WIP, rework, escaped defects, predictability and a short team experience survey, using existing tool data at team level.

Protects: An honest picture of where time goes, including stakeholder decision latency.

Costs: Four weeks before visible action. Some headquarters stakeholders will see their own delays measured.

Conditions: Almost always the right start, unless an outage needs immediate action first.

Earlier choices: Any earlier path
The baseline shows a typical change spends 12 of 34 days waiting for stakeholder decisions and only 6 days in active work.

Rank squads by utilisation, story points delivered and commits, and review the lowest performers.

Utilisation, story points, commits and lines of code do not measure delivery or outcomes, and they push blame onto engineers.

Protects: A quick, familiar report.

Costs: Story points are not comparable across teams. Utilisation hides queues. Teams learn to game the numbers.

Conditions: Not a sound diagnosis. Activity counts can be context, never the measure of effectiveness.

Earlier choices: Any earlier path
The two lowest-ranked squads are put on improvement plans. Both are the squads with the most headquarters dependencies.

Risk flags: vanity-metrics

Use existing evidence to select one suspected delay, run a bounded reversible experiment, and measure flow while it runs.

Protects: Early progress and a limited commitment that can be reversed.

Costs: The suspected delay may not be the largest. Without a baseline, improvement cannot be attributed confidently to the change.

Conditions: When the suspected cause is already well evidenced, the sponsor needs early results and the change is easy to reverse.

Earlier choices: Any earlier path
A reversible experiment starts on the suspected handoff delay. Flow measurement begins alongside it, so the team cannot establish a credible before-and-after improvement.

Risk flags: experiment-without-baseline

Name a single product owner per domain, publish capacity allocation across headquarters and regions, set decision and escalation SLAs, a clear RACI, and thin risk-tiered approval with independent assurance for high-risk change.

Protects: Fast decisions with a named owner, and independent assurance where risk warrants.

Costs: Product heads give up direct access to squads. Conflicts must be resolved openly by the sponsor.

Conditions: When a sponsor is willing to arbitrate conflicting priorities and product owners have real authority.

Earlier choices: A
The squad 3 conflict is escalated and resolved by the sponsor in two days. Decision wait drops from 12 to about 5 days.

Earlier choices: B, C
The model is sound, but without a baseline nobody can show it worked. Headquarters remains sceptical.

Create a weekly cross-location committee that approves every piece of work and every change.

A gate for every task slows all work without improving control where risk is real.

Protects: Everyone feels consulted.

Costs: Adds a queue to every item, low-risk changes wait as long as high-risk ones, and accountability is diluted across the committee.

Conditions: Not defensible as the standard path. A committee is only appropriate for a small number of high-risk decisions.

Earlier choices: Any earlier path
Approval queue rises from 5 to 9 days. Low-risk fixes wait behind major changes.

Risk flags: gate-everything

Each region names a product owner and receives a fixed capacity share. The CIO arbitrates only conflicts that cross regions.

Protects: Fast local decisions and clear regional ownership.

Costs: Shared domains split across regions, dependencies multiply and spare regional capacity cannot automatically serve another region's priority.

Conditions: When regions map to separate business units with few shared systems and cross-region conflicts are rare.

Earlier choices: A
Regional decisions are faster: illustrative decision wait falls from 12 to 6 days, but cross-region dependency waits rise from 7 to 10 days. Fixed shares leave some capacity unused while another region queues work.

Earlier choices: B, C
Local decisions appear faster, but shared work waits across regional boundaries. The model assumes 6 days of decision wait and 10 days blocked on dependencies; without a baseline these are illustrations, not measured improvement.

Risk flags: regional-fragmentation

Pilot two squads with members across locations: onboarding and buddies, domain exposure visits, a planned overlap window with late slots rotated fairly, async decision records and runbooks, paired delivery, a shared definition of done, access parity and on-call with clear handovers.

Protects: Ownership and context at the centre, sustainable hours and measured results.

Costs: Travel and onboarding effort, and some headquarters engineers must change how they work.

Conditions: When work is product-shaped and leaders accept a phased pilot with before and after measures.

Earlier choices: AA
The pilot squads reduce blocked time and rework. Illustrative lead time is 20.5 days against a 34 day baseline. The before and after comparison is credible because the baseline exists. No productivity figure is promised for the rest.

Earlier choices: AB
The pilot squads reduce blocked time and rework. Illustrative lead time is 31.5 days against a 34 day baseline. The before and after comparison is credible because the baseline exists. No productivity figure is promised for the rest.

Earlier choices: AC
The pilot squads reduce blocked time and rework. Illustrative lead time is 26.5 days against a 34 day baseline. The before and after comparison is credible because the baseline exists. No productivity figure is promised for the rest.

Earlier choices: BA, CA
The pilot squads reduce blocked time and rework. Illustrative lead time is 20.5 days. No baseline was taken, so there is nothing credible to compare it with. No productivity figure is promised for the rest.

Earlier choices: BB, CB
The pilot squads reduce blocked time and rework. Illustrative lead time is 31.5 days. No baseline was taken, so there is nothing credible to compare it with. No productivity figure is promised for the rest.

Earlier choices: BC, CC
The pilot squads reduce blocked time and rework. Illustrative lead time is 26.5 days. No baseline was taken, so there is nothing credible to compare it with. No productivity figure is promised for the rest.

Headquarters writes more detailed tickets; the centre implements them and hands back for review.

Protects: A familiar model and clear task boundaries.

Costs: More handoffs, less context, more rework and little ownership at the centre.

Conditions: For short, well-defined work with little domain knowledge needed.

Earlier choices: AA, BA, CA
Rework rises and blocked time grows. Illustrative lead time is 27 days. Retention at the centre falls.

Earlier choices: AB, BB, CB
Rework rises and blocked time grows. Illustrative lead time is 38 days. Retention at the centre falls.

Earlier choices: AC, BC, CC
Rework rises and blocked time grows. Illustrative lead time is 33 days. Retention at the centre falls.

Risk flags: ticket-factory

Ask all centre engineers to stay reachable across all three time zones so nobody waits.

Time zone coverage should come from rotas and handovers, not from every engineer being available 24/7.

Protects: Short waits for answers in the short term.

Costs: Burnout, attrition and errors. It is not real coverage.

Conditions: Not defensible. Use a planned on-call rota with handovers for real out-of-hours needs.

Earlier choices: Any earlier path
Response times improve for a month, then three engineers leave and on-call incidents rise.

Risk flags: always-on