How do you cut the modules of an automation suite two teams change independently — one shared action library, or per-team modules over a common adapter layer?
answer
- Coupling against duplication, decided on evidence
- Do both teams mean the same thing?
- Share the layer with fewest opinions
- Shared code needs a named owner
- Promote into shared only after two repeats
basics
~20 sIt is a coupling-versus-duplication call. Share business actions only when both teams mean the same thing by a flow and need changes to land together. Otherwise give each team its own actions over a shared adapter layer.
solid answer
~50 sDecide it on conditions, not preference. **One shared action library** wins when both teams mean the same thing by a flow, when a product change must reach both in the same release, and when the library has a named owner and a review path — its cost is a shared cadence and a blast radius that reddens both teams' runs. **Per-team modules over a shared adapter layer** win when the teams' definitions differ, when their cadences differ, or when the shared library has become a negotiation bottleneck — its cost is duplication that drifts. The layer worth sharing regardless is the adapter layer: it encodes how the product is reached, which is a fact rather than a judgement, so teams rarely disagree about it. My default is per-team actions over shared adapters, with an action promoted into shared code only after both teams have written the same shape twice.
code
pseudocode · 14 linescut A - one shared action library
team_a_cases -> shared_actions -> adapters
team_b_cases -> shared_actions -> adapters
cut B - per-team actions over a shared adapter layer
team_a_cases -> team_a_actions -> adapters
team_b_cases -> team_b_actions -> adapters
promotion rule used with cut B:
move an action into shared_actions when
both teams have written the same shape twice
and a named owner accepts it
move it back out when
it needs a per-team flag to satisfy both callersgo deeper
Recall that shared code reduces duplication but couples the people who share it, and that two teams changing one module at once can break each other's runs.
Explain the mechanics of each cut: what one shared action library makes cheap, what per-team modules over shared adapters make cheap, and why the adapter layer is the least contested thing to share.
Show the operational evidence you would gather — cross-team edits to the same flow, runs reddened by another team's change, product fixes applied twice — and how a promotion rule keeps shared code deliberate rather than accidental.
Own the decision and its reversibility: splitting a shared library later is mechanical, merging two diverged ones is a design argument. Commit to a default, name the condition that would change it, and say who owns the shared code.
## The two cuts on the table Two teams share one product area and one automation suite. Both write cases, both need flows like sign-in, order placement and cancellation, and both change the suite in the same week. There are two defensible module cuts. **Cut A — one shared business-action library.** Both teams' cases import a single action library, which sits over a shared adapter layer. One definition of "place an order" exists. **Cut B — per-team action modules over a shared adapter layer.** Each team owns its own actions; the only shared code is the adapter layer that speaks the transports. | | Cut A: shared actions | Cut B: per-team actions | | --- | --- | --- | | Cost of a product flow change | One edit, both teams get it | Two edits, or one team lags | | Cost of a disagreement about meaning | A negotiation before either team moves | Each team decides locally | | Blast radius of a mistake | Both teams' runs go red | Contained to one team | | Release coupling | The library's cadence is shared | Independent | | Duplication | Low | Real, and it drifts | | What newcomers read | One vocabulary | Two, and they diverge | Notice what does **not** appear in the table: which one is better. That is the point of the question. ## The conditions that pick between them The decision is a coupling-versus-duplication call, and five conditions carry it. 1. **Do the two teams mean the same thing?** If "an order" carries the same fields, the same lifecycle and the same success criteria for both, a shared action is one concept with two users. If one team means a subscription renewal and the other a physical shipment, a shared action is two concepts wearing one name, and every future change is a negotiation about which meaning wins. This condition dominates the rest: shared code across a genuine meaning boundary never settles. 2. **Must a flow change land for both at once?** Where a change to the product's sign-in must be reflected in both teams' cases in the same release, one library is the mechanism that makes that automatic. Where the teams follow the product on their own schedules, one library forces a coordination they do not otherwise need. 3. **Is there an owner and a review path?** A shared library with no named owner degrades into a magnet: everyone adds, nobody removes, and it accumulates parameters for each caller's special case. If nobody will own it, Cut A is being chosen in name only. 4. **What is the observed pain today?** Count it rather than argue it. Cross-team edits to the same action per month, and runs broken for team B by a change from team A, point at Cut B. Duplicated maintenance — the same product change fixed twice, and one copy forgotten — points at Cut A. 5. **How reversible is each choice?** Splitting a shared library later is mechanical and dull. Merging two libraries that have diverged in meaning is a design argument no one wants. Where the evidence is thin, the cut that is cheaper to undo is the better bet. ## The shape most teams land on The common resolution is neither pure cut: **share the layer with the fewest opinions.** Adapters encode how the product is reached, which is a fact about the product rather than a judgement about what a flow means, so two teams rarely disagree about them and a change there is usually a fix both want. Actions encode meaning, and meaning is exactly where teams differ. That yields per-team action modules over shared adapters, plus a **promotion rule** for the actions that are genuinely common: - An action moves into a shared library only after both teams have independently written the same shape at least twice. - Promotion comes with a named owner and a stated compatibility promise, or it does not happen. - Anything promoted that later needs a per-team flag comes back out: the flag is evidence the two meanings were not the same after all. This is a deliberately slow path into shared code, and slowness is the feature. Premature sharing is the expensive mistake in this design because it is the one that is hard to reverse. ## How to argue it in the room State that the answer depends, then say on what, in the order above, and put a number on it: how often the two teams edit the same flow, and how often one team's change reddens the other's runs. Then commit to a default — shared adapters, per-team actions, promotion on the second repeat — and name the condition that would change your mind, which is the two teams demonstrably meaning the same thing and needing changes to land together. A candidate who declares one cut universally correct has missed the question; a candidate who only lists tradeoffs and never decides has missed it too.
- What would you measure over a quarter to decide, rather than argue it?Two counts. How often both teams edit the same flow in the same month, which argues for sharing, and how often one team's change to a shared step reddens the other team's runs, which argues against it. Add the number of product changes fixed twice because a copy was forgotten. Three numbers usually end the debate faster than any principle.
- Why is the adapter layer the safer thing to share than the action layer?Adapters encode how the product is reached, which is a fact about the product rather than a judgement about what a flow means, so two teams rarely disagree and a fix there is usually one both want. Actions encode meaning, and meaning is exactly where two teams differ — which is why shared actions turn into negotiations.
- A shared action has grown a flag so each team gets its behaviour. What does that tell you?That the two teams never meant the same thing, and the shared module is now carrying two concepts under one name. Take it back out into per-team actions rather than adding a second flag. Flags on shared steps are the earliest measurable sign that a promotion was premature.
saying these in an interview costs you the question
- Declares one cut universally correct without naming conditions
- Shares code across two teams that mean different things by a flow
- Creates a shared library with no named owner
- Lists tradeoffs endlessly and never commits to a default
- Ignores that merging diverged libraries is far harder than splitting one