Your organisation releases every two weeks on a train. Teams complain about lead time. Is the train the problem?

What the interviewer is testing

Whether you can distinguish a symptom from its cause, and whether you know that release trains are usually a coupling artefact rather than a process choice.

The arithmetic first

With a fixed two-week cadence, a change finishing an hour after departure waits fourteen days. So the p90 of lead time is roughly the cadence, regardless of how fast the teams are. Removing the train would improve lead time enormously — if the train is removable.

Batching also degrades diagnosis: when a release of forty changes causes a regression, there are forty suspects, and change failure rate is attributed to a batch rather than a change.

The question that matters

Why is there a train? There are two very different answers.

Legitimate: the release genuinely must be synchronised. Packaged software shipped to customers, mobile app store submissions, embedded firmware, or a system whose components share a contract that changes in lockstep. Here the train is the right tool, and the improvement available is a shorter cadence, not its removal.

Symptomatic: teams are on a train because their services cannot deploy independently — shared database schema, synchronous version-coupled APIs, a shared library that must be upgraded everywhere at once, or an integration test suite that only runs against a complete set. Here the train is treating the pain rather than the cause, and removing it without fixing the coupling would break production.

The approach

Determine which it is by asking a concrete question: what would break if one team deployed on Tuesday alone? The answer names the coupling precisely.

Then the work is in the contracts, not the calendar: backward-compatible schema changes, versioned APIs with a tolerant-reader discipline, consumer-driven contracts replacing the shared integration environment, and independent deployability as an explicit architectural requirement with a fitness function behind it.

Meanwhile, shorten the cadence. Weekly then daily is achievable in stages and delivers real improvement while the decoupling work proceeds.

What a strong answer adds

Warning against removing the train first and fixing coupling later. Teams that do this get a period of production incidents that discredits the whole direction. Decouple, prove independence for one service in a pilot, then let teams leave the train as they qualify.

Common weak answers

"Trains are waterfall, remove it" without diagnosing the coupling. Accepting the train as fixed and optimising within it.