Chapter 34: Coordinate Multiple Teams and Dependencies

Green everywhere, and the journey stalled

It is the third Thursday of August at KijaniPay, and every team in the room has a green number, which is precisely why the meeting is going badly.

The mobile team’s lead goes first. The onboarding flow shipped on schedule, the flow is green, and the app store rating has moved. Kwame Mensah reports for risk: the volume automation that the June rewrite ordered second is running, the fraud-loss rate holds at 0.31 percent against the 0.4 percent early-warning threshold, and the rule refinements that waited all spring for the automation are deployed. The banking team’s integration lead reads from the seam: the Savanna Settlement Bank sandbox milestone is met, the settlement window integration is on track, and Nadia, who was the settlement engineer’s understudy when the spring leave exposed the single point of failure, now runs the bank’s change window herself. The data team shows the dashboards, live on the wall, and notes that the credit-model refinements still wait on September’s cohort data, which is a fact, not a complaint. The support lead closes the reports: invoicing calls are down from eleven to five a week, and the cash-flow-visibility score that moved from 3.2 to 3.9 in the summer has held.

Then the wall, because the wall carries the journey. Amara Osei asks the question the green numbers are hiding: “What does the merchant see?” Zanele Dlamini puts the journey on the screen, the sentence from chapter 2, a merchant who can see her settlement and borrow against it, drawn as a path with six steps: signup, KYC decision, onboarding, first transaction, settlement visible, application. Under the path is one number. Median time from merchant signup to first settled transaction: 24 days. Target: 14. June reading: 14.

The room is silent for the reason rooms go silent: each team’s number is true, and the sum of true numbers is a failure. The mobile team ships the signup in minutes. The risk team’s rules engine decides in minutes. And between the minutes sits a queue: the KYC decision, for the 40 percent of applications the engine routes to manual review, takes a median of 11 days, because the manual review queue is fed by every team and pulled by no one. Kwame says it himself, because the chapter is about to be about exactly this: “The rules engine decides in minutes. The queue in front of the rules engine decides in days.”

That is the subject of this chapter. Chapter 30 built the execution rhythm and the flow inside one team, and the KijaniPay delivery system responded: nine completions a week, cycle time under five days, the WIP limit holding. Chapter 32 gave the product goal and the outcome-based backlog, and the June rewrite stopped the team from ordering requests by the loudest ask. Chapter 33 taught the seams of a hybrid: the unit named, the seam owned, the interface calendar written, the coordination moved from one head into the architecture. This chapter scales the same discipline to the place where it is hardest and most consequential: the multi-team system, where the work is delivered by several teams and the risk has moved from the work inside the teams to the interfaces between them. The thesis, in one sentence: when more than a handful of people deliver one product, mastery is scaling coordination without centralizing every decision, which means naming the dependencies, owning every interface, writing the handoffs down, integrating on a schedule rather than by accident, planning and risking across the seams, running the system as one flow, reducing the dependencies worth reducing, and restructuring the work when the coordination tax exceeds the value of the boundary.

The decision this chapter improves is the one the wall is forcing: not whether the teams are competent, but whether the coordination between them is designed or improvised. The teams are not the problem. The seams are the problem. And the seams are the only part of the system that no single team owns.

The system has no plan of its own

Every team’s plan is local, and every local plan is true. The mobile plan is true: the signup flow shipped, the flow is green. The risk plan is true: the automation runs, the fraud loss holds. The banking plan is true: the sandbox milestone is met. The data plan is true: the dashboards are live, the model waits on evidence that does not exist yet. The support plan is true: the calls are down. The system’s plan is nothing but the sum of the seams between the true plans, and the seams have no owner in any single team’s plan, which is why the journey takes 24 days while every step takes minutes.

Call the pattern the local optimum, because that is what it is: each team has optimized its own piece of the system to look excellent, and the system as a whole is worse than any of its pieces. The local optimum is not a failure of competence. It is a structural fact of divided work. The moment two teams divide a journey between them, there are three things to manage: the work in team one, the work in team two, and the handoff between them. The handoff is the part nobody plans first. With five teams and six steps, the merchant’s journey is one product delivered by five organizations-within-an-organization, and the journey itself, the only non-local fact in the building, is the one thing no team owns.

The arithmetic of divided work is worth stating plainly, because it explains the shape of every scaling failure. With two teams there is one seam. With three teams there are three seams. With five teams there are ten pairs of teams, and while not every pair hands work to every other, the coordination the project must design grows with the seams, not with the people. The temptation is to answer the growth with a committee: the coordinating body that meets weekly, collects each team’s status, and redistributes the work by consensus. That is chapter 8’s mistake at team scale, the governance that has meetings but no decisions, applied to the delivery system: it centralizes the decisions the teams should own, slows the cadence to the committee’s calendar, and leaves the seams as unowned as before, because a committee owns nothing. The alternative is not less coordination. It is better-placed coordination: the seams owned by named people, the handoffs written down, the integration scheduled, the flow managed at the system level, so that the teams stay autonomous and the system still holds together. Ownership of the seam is the opposite of centralization. It is the thing that makes autonomy safe.

The rest of the chapter is that discipline in order. The dependency board names what crosses between teams. The interface agreement writes down how it crosses. The integration event proves it crossed. The cross-team plan and risk review look forward at what will cross. The system flow shows what the crossing costs. The reduction moves remove crossings that should not exist. And the restructure decision asks the question underneath all of it: whether the team boundaries themselves are the right design, or merely the inherited one.

Six kinds of dependency

The dependency board starts with a classification, because the type of a dependency selects its fix. Six kinds cover the practical universe of what crosses between teams, and each has a signature symptom that tells you which one you are looking at.

The technical dependency is the one where the systems must connect: the mobile app calls the platform’s settlement API, and the API’s schema version decides whether the call works. Its symptom is the integration error, the build that fails at the seam, the contract mismatch found in the shared environment instead of in the plan. The fix is the interface agreement and the version discipline, both of which this chapter builds.

The resource dependency is the one where people or things must be shared: the two QA specialists that chapter 30 priced as shared between the platform team and the fraud automation, the risk analyst whose window the credit-model work needs, the staging environment that only one team can use at a time. Its symptom is the calendar, the meeting that cannot be scheduled, the specialist who appears in four plans at once. The fix is the capacity discipline of chapter 19: explicit allocation, an owner who decides the conflict, and a stated consequence when the sharing breaks.

The sequence dependency is the one where work must happen in order: the rule refinements must deploy before the automated checks can absorb new applications, the friction-fix experiment must run before the September cohort, the settlement setup must complete before the first transaction. Its symptom is the queue, the waiting work whose owner says it will move when someone else’s work moves. The fix is the sequence discipline of chapter 17: the dependency logic stated, the critical path named, the resequencing decided when the evidence changes.

The decision dependency is the one where a choice must be made before the work can continue: the credit committee’s review dates, which chapter 30 scheduled into the look-ahead so the pilot’s files did not wait for the committee’s calendar, the regulator’s license review that raised the data-residency question, the council’s threshold decisions. Its symptom is the wait, the item that is done except for the signature. The fix is the decision-rights discipline of chapter 8: the authority named, the evidence prepared, the date committed, and the escalation path for the decision that will not come.

The data dependency is the one where shared information must be consistent: the merchant record schema that mobile, risk, data, and banking all read and write, the reconciliation data that chapter 21’s settlement failure exposed, the cohort definitions that support and data must agree on. Its symptom is the mismatch, the two teams whose numbers for the same merchant disagree, the report that cannot be reconciled. The fix is the schema ownership: one owner for the shared data, one source of truth, and a change path that reaches every consumer before the change ships.

The external dependency is the one that lives outside the project’s authority: Savanna Settlement Bank’s settlement window and change calendar, the regulator’s reporting requirement for the lending pilot, the sandbox that the bank grants and can withdraw. Its symptom is the window, the date the project does not control, the calendar that moves without the project’s permission. The fix is the contract and the trigger discipline of chapters 20 and 23: the external owner named, the evidence defined, the buffer sized, the alternative prepared, and the escalation clause written before the window slips.

The classification earns its place because misclassifying a dependency misselects the fix. A technical dependency fixed by a meeting is a meeting that merely meets: the schema mismatch is not resolved by consensus, it is resolved by the interface agreement and the version. A decision dependency fixed by a schedule is a promise that cannot be kept: the credit committee’s date is a governance problem, and the fix is the decision right, not the calendar. A data dependency fixed by blame is the chapter 28 conflict waiting to happen: the two teams whose numbers disagree both believe they are right, and the fix is the owner of the truth, not the louder voice. A real multi-team system does not have one kind of seam; it has all of them, and the board that records dependencies without classifying them is the register that records and does not coordinate.

Discover the dependencies you actually have

The dependency board is the minimum viable tool of multi-team coordination, and the discipline of building it is the discipline of this chapter’s first act: the discovery. Dependencies hide. They hide in the handoffs that work by habit, in the queues that no one owns, in the schema that two teams both believe they control, in the external window that the calendar happens to respect and the risk register does not record. The discovery discipline is the set of practices that finds the seams before the journey does, and each practice is cheap, which is exactly why it is skipped.

The journey walkthrough is the first and best discovery instrument, because it finds the dependencies in the only place they actually live: the flow of the work. Walk one real merchant record end to end, signup to first settled transaction, with the teams in the room, and watch where the record waits. The walkthrough at KijaniPay in August takes 40 minutes and finds the whole chapter: the record enters the mobile team’s queue instantly, reaches the risk engine, is routed to manual review for the 40 percent, and then the record waits, because the manual review queue is pulled by the risk team’s capacity, and the risk team’s capacity is committed to the rule refinements and the credit-model work, and the credit-model work waits on September’s data, and September’s data waits on the September cohort, and the September cohort waits on the onboarding flow, and the onboarding flow waits on the friction-fix experiment, which is the queue in its full circular form. Nobody pushed the record into that queue on purpose. The queue is the shape the handoffs make when nobody owns them.

The standup question is the second instrument, and it is one sentence: what are you waiting for? Chapter 30 put the dependency on the board as a row with an owner and a date rather than a wall in the risk register, and the multi-team version of the rule is the same question asked at every team’s cadence, with the answers collected into the dependency board. The question works because waiting is the universal signal: the team that is waiting knows the dependency exists, knows who it waits on, and usually knows what it needs, and has not been asked. The look-ahead planning of chapter 30 scales the same way: the next two weeks’ handoffs named with owners and dates, at the cross-team level, so that the settlement window, the credit committee’s review, and the risk team’s manual-review capacity appear in the plan before the work arrives at them.

The data-flow map is the third instrument, for the dependencies that neither the walkthrough nor the standup will surface because they are silent until they break. Draw the data as it moves between the systems: the merchant record from signup to KYC to settlement to the credit model, the reconciliation from the settlement provider to the ledger, the cohort definitions from growth to data to support. Every crossing is a dependency, and the crossings that have no owner are the data dependencies that will surface as mismatches: the two teams whose numbers for the same merchant disagree, the reconciliation that chapter 21 showed can drift for seven days before the functional suite notices. The data-flow map is the walkthrough applied to information instead of work, and it is the instrument that finds the schema and the source-of-truth questions before the mismatch does.

The board itself is the collected result, and its minimum viable form is deliberately small: a row per dependency, with the name, the type, the direction, the owner, the evidence, and the cadence. Direction matters because it assigns the ownership rule: the dependent team names the dependency, because the dependent team feels it first, and the provider team confirms the interface and the evidence, because the provider team knows what it can actually commit. The owner is a person from the governance map, not a committee and not a team: the seam owner of chapter 33, at the scale of teams, with the decision right to integrate the impact and the duty to escalate when the seam cannot be resolved. At KijaniPay the board that comes out of the August walkthrough has fifteen rows: the KYC package from mobile to risk, the decision and its evidence from risk back to mobile, the settlement setup from risk to banking, the settlement window from Savanna to banking, the merchant record schema shared by four teams, the credit-model inputs from data to risk, the cohort definitions between growth, data, and support, the staging environment shared by five teams, the two QA specialists shared with the fraud automation, the credit committee’s review dates, the regulator’s reporting requirement, the September cohort’s data promise, the friction-fix experiment’s measurement plan, the support call transcripts flowing to discovery, and the reconciliation feed between the settlement provider and the ledger.

The failure pattern is the register that records without coordinating: the board that every team updates and no one owns, the rows with types but no owners, the dependency logged and never resolved, the meeting where the board is reviewed as a report rather than worked as a queue. The field signal is the row with the stale date and the unchanged owner, the dependency that has been true for months and is discovered again at every standup, and the cost is the confidence the board was meant to provide: the team that believes the seam is managed because the seam is listed. The board is a working instrument, not an archive. A dependency row is not done when it is written. It is done when the interface is agreed, the evidence is defined, and the crossing happens on its cadence, and until then the row is work, with an owner and a date, exactly like the work it describes.

The interface contract

The dependency board names what crosses. The interface agreement writes down how. It is the handoff reduced to one page: what crosses between the two teams, in what form, with what evidence, at what cadence, and how the crossing changes when the world changes. The minimum viable form is deliberately sparse, because the interface agreement earns its place by being read at the seam, not by being comprehensive. Five fields carry it: the interface, the provider’s commitment, the receiver’s acceptance evidence, the change path, and the owner. Everything else is decoration, and decoration on an interface agreement is how agreements die.

The KYC handoff at KijaniPay is the worked example, and it is the one that matters because it is the bottleneck. The interface: the merchant application package, the identity documents and business details in the defined schema, crosses from the mobile team to the risk team. The provider’s commitment: the rules engine returns a decision within the SLA, and the 40 percent routed to manual review receive a decision with the evidence recorded, on a queue that is capped and pulled, not fed and abandoned. The receiver’s acceptance evidence: the mobile team accepts the decision only when it carries the reason and the reviewer, so that the merchant can be told the truth and the support team can answer the call. The change path: the schema, the SLA, and the queue policy change only through the owner, Kwame, with the support lead’s sign-off for the merchant experience, and the change record carries the version and the date. The owner: Kwame, on the record, not on the rotation.

Why write it down? Because the handoff that lives in the heads of the two people who happen to do the work dies when they are not in the room, and because the agreement turns the seam from a relationship into a commitment with evidence. The interface agreement is the chapter 33 seam discipline given a written form: at Meridian the seam lived in the interface calendar; at KijaniPay it lives in the contract page. The contract does not remove the human relationship at the seam. It makes the human relationship unnecessary for the crossing to be correct, which is the entire point: the crossing should not depend on the analyst who happens to know the schema.

The interface contract has two failure shapes, and both are walked by competent people. The first is the contract as bureaucracy: the agreement that is signed, filed, and never consulted, with the fields that outlive the interface, the SLA that no one measures, the owner who has changed three times and the page that still carries the first name. The field signal is the page that nobody can update without a meeting, the contract that has become an artifact of the seam instead of an instrument of it. The repair is the contract’s retirement criteria, the same discipline the book applies to every artifact: the interface is re-reviewed when its evidence goes stale, the page is re-signed when the interface changes, and the page is deleted when the interface is deleted, because the contract that constrains the interface that no longer exists is the standardization that outlived its purpose. The second failure is the heroics handoff, the contract that exists on paper and the crossing that actually depends on the person: the analyst who quietly fixes the schema mismatch every Friday, the banking lead who calls Savanna’s change window and smooths the delay. The field signal is the question only one person can answer, the seam that is green because of the person, not because of the agreement. The heroics handoff is the chapter 25 pattern at the seam, and the repair is the same: move the coordination from the head into the contract, the version, the evidence, the escalation, so that the seam survives the person.

The delivery-style contrast belongs here, because the interface agreement takes a different frame on each clock. In the predictive register, BlueLine’s interface register from chapter 31 carries the same instrument with a heavier frame: the interfaces between the contract packages are identified and changed only through the formal change path, because an uncontrolled interface in physical work is expensive to reverse. In the adaptive register, the frame is lighter: the contract lives on the dependency row, the version lives in the schema, and the change path is the seam owner plus the release. In the hybrid register, Meridian’s interface calendar carries the row and the gate, and the agreement is what the row means. The frame differs; the content does not: the interface, the commitment, the evidence, the change path, the owner. The contract that fits the clock is the contract that gets maintained, and the contract that gets maintained is the contract that is actually true.

Integrate on a schedule, not by accident

The agreements describe the seams. The integration event proves them. The discipline of the multi-team system is that integration is a cadence, not a phase: the project integrates on a schedule, early and often, so that the seams are exercised while the failure is cheap, instead of being discovered in the integration week at the end, when the failure is a crisis.

The integration week is the classic failure: the plan that schedules the teams’ work in parallel and reserves the last weeks for putting it together, the seams that have existed on paper for months and have never met in reality, the first end-to-end run that happens when the calendar says integration starts. The integration week fails for the same reason every end-phase discovery fails: the seams have been owned in the plan and unowned in the work, and the first time the real systems meet is the first time anyone sees the real mismatch. The schema that two teams each believed they controlled, the settlement window that the plan respected and the environment did not, the manual review that nobody had pulled into the look-ahead, all of them surface in the same two weeks, and the teams spend the integration week not integrating but discovering. The field signal is the calendar with the integration phase circled at the end, the milestone that exists on paper, and the first joint test that has no prior joint tests behind it.

The repair is the integration event on a cadence, and the form it takes at KijaniPay is the journey Friday: every second Friday, the product council and the five teams walk one real merchant journey end to end on the shared staging environment, watching the record move through every handoff, and the walkthrough ends with the only question that matters: where did the merchant wait? The journey Friday is the system demo done properly, which means it demos the journey, not the components: the mobile team does not show its board, the risk team does not show its engine, the data team does not show its dashboards. The room watches one record, and the record is the system. The journey Friday is the walking skeleton of chapter 14 at multi-team scale: the thinnest end-to-end thread that exercises every seam, run on a schedule, with the evidence of each handoff visible in the environment, not in the slides.

The integration plan is the calendar of these events, and it is one of the chapter’s field outputs: the shared environments with their data sets, the journey walkthroughs on their fortnightly cadence, the end-to-end tests that the teams run against the journey thread, the reconciliation runs that prove the data crosses cleanly, the owners and the dates for each. The plan is small, because its whole purpose is to make the seams a habit: at KijaniPay, the journey Friday on the second Friday of each fortnight, the reconciliation check on the day after, the staging environment standing with the real schema and the seeded merchant records, and the September cohort run scheduled against the walkthrough so that the friction-fix experiment’s measurement plan is itself walked end to end before the cohort sees it. The integration plan answers the question the integration week was avoiding: not when will we put it together, but when will we prove it together, and the answer is every fortnight, on the environment, with the record, in front of the owners.

The rule underneath the cadence is the one chapter 21 proved with the settlement failure: the test that runs inside a team cannot see the failure at the interface, because the failure at the interface lives between the teams. The functional suite was green while the reconciliation drifted, because the suite never interrupted the batch window. The journey Friday exists because the journey is the only test that crosses every seam, and the journey is the only thing the merchant actually experiences. The teams’ tests prove the teams. The journey test proves the system, and the system is the product.

Plan and risk across the seams

The dependency board shows today’s seams, and the interface contracts define them, and the journey Friday proves them. The forward discipline is the cross-team plan and the seam risk: the work that will cross in the coming weeks, and the risk that lives at the seams, in no single team’s register.

Cross-team planning is the look-ahead of chapter 30 scaled to the system: the quarterly planning event where the teams bring their dependency needs to one table, the next two weeks’ handoffs named with owners and dates, the capacity of the shared resources checked against the demand. The quarterly event at KijaniPay has a fixed agenda that is not a status round: each team names the dependencies it will need, the seams that will be exercised, the evidence it must receive and the evidence it must provide, and the conflicts are decided in the room, on the record, with the owners, because the alternative is the conflict decided in the corridor, off the record, without the owners. The cross-team plan is the integrated roadmap of chapter 16 at team scale: the same discipline of assumptions, decision dates, and integration points, applied to the seams instead of to the work packages.

The seam risk is the risk that no team owns, and it is the blind spot the cross-team risk review exists to close. The chapter 22 register works well at the team level and fails at the seam level, because the risk that lives between two teams is logged by neither: the settlement window that slips against the release date, the regulator’s reporting calendar against the lending pilot’s cohort, the credit committee’s review dates against the onboarding throughput, the shared QA capacity against the fraud automation’s regression needs. Each of these risks has two teams that can see it and no team that owns it, and the risk that no one owns is the risk that arrives as an issue. The cross-team risk review is the seam owners’ review: each dependency row on the board examined for what happens when it fails, the consequence priced, the response chosen, the trigger named, and the row promoted into the teams’ registers with the owner attached, so that the seam risk is owned by the person who can act on it.

The escalation discipline completes the forward view, and it is the chapter 39 material in its seam form: the dependency that cannot be resolved at the seam escalates with the evidence, not with the panic. The interface contract carries the escalation path in its change field, and the escalation is a decision request, not an appeal: the seam owner brings the context, the options, the evidence, and the recommendation, and the governance layer decides with the record. The failure is the escalation that arrives as an emergency, the dependency that waited until the window closed and then escalated the disaster instead of the decision. The field signal is the escalation that names the date after the fact, and the repair is the seam risk review that named the date before it: the cross-team plan exists to make the escalation boring, and the boring escalation is the one that gets decided.

One system, one flow

The boards, the contracts, and the events coordinate the work. The flow discipline runs the work, and at the system level the flow is the only non-local truth, which is why the wall at KijaniPay carries the journey and not the teams. The map the wall implies is the chapter’s primary picture, the team interaction map with its owned interfaces and its one integration point:

Figure 34.1: The team interaction map at KijaniPay, August. Each
box is a team; each arrow is an owned interface with its evidence;
the integration point is where the system is inspected as one
journey rather than five components.

   signup --> +------------+   KYC package    +------------+
   merchant   |  mobile    | --------------->|  risk      |
              |  team      | <---------------|  team      |
              +------------+  decision and   +------------+
                   |            SLA evidence      ^
                   |                              | credit
                   v                              | model
              +------------+                  +------------+
              |  banking   |<-----------------|  data      |
              |  team:     |  settlement and   |  team:     |
              |  Savanna   |  reporting        |  schema,   |
              |  seam      |                   |  model     |
              +------------+                  +------------+
                   |
                   v  settlement visible, first transaction
              +------------+
              |  support   |<-- merchant calls, the discovery
              |  team      |    channel feeding the backlog
              +------------+

   Integration point: journey Friday, fortnightly. One real
   merchant record is walked end to end through every handoff
   on the shared staging environment. The journey WIP limit and
   the end-to-end cycle time are the system's only non-local
   numbers, and the walkthrough ends with one question: where
   did the merchant wait?

The map is read two ways. Along the arrows it is the dependency board drawn as a picture, the interfaces with their owners and their evidence. At the integration point it is the answer to the local optimum: the journey Friday is where the system is inspected as a system, because no team can see the merchant from inside its own box, and the merchant is the only view that is not local. The teams are the boxes, the interfaces are the arrows, and the integration point is where the arrows are proven, on the environment, in front of the owners, on a schedule. When a map has boxes and arrows but no integration point, it is an org chart. When it has an integration point but no owned arrows, it is a demo. The map with both is the coordination this chapter is about.

The arithmetic is the chapter’s Numbers That Matter, and it is Little’s Law worked at the journey level, the law chapter 17 introduced with its careful assumptions, applied to the merchant journey as one system. The journey has 17 merchants in flight at the August reading, in the signup screen, the KYC queue, the settlement setup, the verification and the activation steps, and the system completes about 5 journeys per week, five merchants reaching their first settled transaction each week. Little’s Law states that the average time in the system equals the average number in the system divided by the average completion rate, and the arithmetic holds: 17 journeys divided by 5 completions per week gives 3.4 weeks, about 24 days, which is the number on the wall. The June reading was 14 days, 2 weeks, which means the system held about 10 journeys in flight at the June rate, and the journey WIP has grown by 7 since, because the ready column that chapter 32 watched grow from 18 to 47 items now feeds the journey with more starts than the journey can finish. The 24 days are not a mystery. The 24 days are 17 divided by 5, with the assumptions spoken: the merchants are homogeneous enough for the average to mean something, the completion rate is stable across the weeks, and the in-flight count is measured at a moment in a system that is not in a death spiral. The chapter is about to act precisely because the assumptions are still true enough to act on.

The insight the arithmetic gives is the one the wall was hiding: the queue is not the risk team’s failure, it is the system’s shape. The risk team’s manual review is the bottleneck of the journey, the step where the waiting concentrates, and the system flow is governed by the bottleneck, exactly as chapter 30 taught inside the team. The teams have optimized their own flow and the system has one flow, and the system’s flow is the journey. The field signal of the multi-team flow failure is the team that reports high utilization while the system stalls: the risk team is busy, the rules engine is fast, the manual reviewers are fully loaded, and the merchant still waits 11 days, because the queue is fed by every team and pulled by no one, and the queue is the system’s buffer, growing in the place where the handoff is unowned.

The system-level discipline is the journey WIP limit, the chapter 30 policy applied to the system instead of the team: the journey column capped at 11 merchants in flight, so that the system stops starting work it cannot finish, and the teams pull journeys from the ready column when the journey column has room, instead of pushing them in when the signup happens. The WIP limit converts the journey from an uncontrolled queue into a controlled system, and it has the same consequence chapter 30 documented inside the team: the starts slow down, the completions rise, and the cycle time falls, because the work that is in the system is the work the system can actually carry. The target arithmetic is the chapter’s promise: at the journey WIP of 11 and the completion rate that the cleared queue and the pulled manual review bring to 5.5 per week, the cycle time is 11 divided by 5.5, exactly 2 weeks, the 14-day target on the wall. The numbers reconcile, which is the discipline’s test: the target is not a hope, it is the arithmetic of the flow, and the flow is the system’s truth.

The flow is also where the multi-team system gets its ethics, because the journey WIP limit is the visible version of the rule chapter 30 named for the team: starting one merchant is the visible decision to delay another. The signup that the mobile team ships is a journey that will wait at the queue, and the team that starts it without checking the journey column has made the waiting merchant’s decision for them, off the record. The journey WIP limit makes the decision visible and owned, and the governance layer, the product council, owns the priority, exactly as chapter 8 taught: the decision to start belongs to the governance layer, not to the team with the loudest signup volume.

Reduce the dependencies worth reducing

The dependency board names the seams, and the discipline of mastery is not only to manage them but to ask which of them should exist at all. Every seam is a cost: an owner, an agreement, an integration event, a risk review, a moment where the work can wait and the wait can hide. The cheapest dependency is the one that has been eliminated, and the second cheapest is the one that has been decoupled, and the third is the one that has been standardized so that many seams share one mechanism. The three moves are the reduction discipline, and they are applied in that order, because each removes a different kind of cost.

Eliminate: delete the handoff by making the crossing unnecessary. The manual review at the risk team is the chapter’s example in its purest form: the rule refinements that waited all spring for the volume automation are now deployed, and the automation absorbs a larger share of the KYC decisions, so the seam between the engine and the human reviewer moves, the 40 percent manual share falls, and the queue that fed it shrinks at its source. Elimination is not always automation. It can be the decision to stop asking: the approval that chapter 26 removed from the executive floor, the step in the journey that no merchant step actually needs, the report that nobody reads. The elimination move asks the question the teams are too polite to ask: what would break if this seam did not exist, and the honest answer, nothing, is the seam’s deletion notice.

Decouple: make the crossing asynchronous so that neither side waits on the other. The settlement setup at KijaniPay is the example: the merchant’s onboarding does not need to wait for the settlement window to prove itself, because the window is a standing capability, not a per-merchant step. The onboarding completes against the standard service, the first transaction settles in the window, and the merchant’s journey does not hold its breath for Savanna’s change calendar. Decoupling is the chapter 17 sequencing discipline applied at the seam: the dependency logic examined for what truly must wait and what only believes it must wait, the handoff redesigned so that the fast step does not queue behind the slow one, the buffer placed where the flow needs it and not where the habit put it.

Standardize: make many seams share one mechanism. The merchant record schema at KijaniPay is the example: instead of four teams each defining the merchant in their own system and reconciling the differences forever, one owner, the data team, holds the schema, and the other teams consume it as the standard. The staging environment is the same move: one shared environment with the real schema and seeded records, instead of five environments that each prove a different truth. Standardization converts the data dependencies from a permanent reconciliation cost into a one-time agreement cost, and it is the move that the platform team exists to embody.

The platform and enabling teams are the organizational forms of standardization, and they deserve their names because they earn them with the flow of others, not their own. The platform team owns the shared capability, the settlement API, the merchant record service, the staging environment, so that the five teams do not each build a private integration with Savanna and a private schema and a private truth. The platform team is measured by the journeys the product teams complete, not by its own backlog, and the platform team whose utilization report is its proudest artifact has become the queue it was built to remove. The enabling team is the more specific form: it exists to raise another team’s capability, the fraud automation that raised the risk team’s capacity, the specialists who coach the mobile team through the new testing practice, and it is measured by the other team’s flow, with a sunset date, because the enabling team that becomes permanent is the dependency it was created to remove. The failure pattern is the platform that becomes a queue of its own: the shared capability so heavily loaded that every team waits on it, the platform team reporting 95 percent utilization and every product team reporting the platform as their top dependency, the standardization that centralized the bottleneck instead of removing it. The field signal is the platform team’s WIP limit, the queue at the shared service, the phrase we are waiting on the platform in every team’s standup, and the repair is the same discipline applied to the platform: the platform’s own flow managed, its own seams owned, its own reduction moves applied, because the platform is a team like any other, with dependencies and a bottleneck, and the organization that forgets it has simply moved the queue.

The warning underneath the reduction discipline is Conway’s, and it deserves the name because it is the most useful fact in the multi-team book: the systems an organization builds tend to mirror the communication structure of the organization that builds them, because the people who must talk to each other to design the interfaces will design the interfaces to look like the conversations they have. The merchant journey at KijaniPay is stalled end to end because it is split across five teams, and the product is the organizational chart drawn as software: the signup step, the KYC step, the settlement step, the data step, the support step, each owned by a team, each optimized by a team, and the journey, the thing the merchant experiences, owned by no team. Conway’s warning is the chapter’s deepest argument for the restructure that follows: if the journey is the product, the organization that cannot see the journey in its own structure will keep building the seams it keeps managing. The reduction moves reduce the seams that should not exist. The restructure moves the seams that should exist to where the value is.

Restructure the work, not just the coordination

The dependency board, the interface agreements, the journey Friday, the cross-team plan, the seam risk review, and the journey WIP limit are the coordination discipline, and they are enough when the boundaries are right. The restructure decision is for when the boundaries are wrong, and the discipline is knowing the difference, because restructuring to avoid coordination is the most expensive form of theater: the new org chart that redraws the seams, the re-org that moves the boxes and leaves the handoffs exactly where they were, the coordinator role that centralizes the decisions and removes the autonomy the boundaries were meant to protect.

The decision test is the coordination tax, and it is measurable before the decision and reviewable after. Measure the cost of the seams: how many people does the smallest change touch, how many meetings does one experiment cost, how much of the teams’ capacity goes to coordination rather than construction, how often does the journey wait at a handoff. At KijaniPay the measurement is stark, and it is the evidence the August council actually uses. The friction-fix experiment, the smallest piece of work the product owns, touches four teams: the mobile team for the signup screen, the risk team for the KYC question, the data team for the measurement plan, and the support team for the merchant communications, and the coordination cost of the experiment is a quarter of a day per team, five meetings, and the journeys it is meant to fix wait at the queue the meetings do not touch. The rule of thumb is not arithmetic, it is the question: does the work flow through the teams, or does the work flow through the coordination about the teams? When every change touches every team, the boundary is not serving the work; the work is serving the boundary.

The restructure moves are three, and the choice among them is a design decision with a record, the chapter 33 re-tailoring discipline applied to the team structure. Re-slice by journey: form the stream-aligned team that owns a full slice of the journey end to end, the onboarding journey team at KijaniPay taking signup, KYC, activation, and the support that carries them, one team with one outcome and one flow, so that the seams move to the boundaries where the work genuinely changes nature, the merchant acquisition to the lending decision, the lending to the settlement, the settlement to the collections. Merge: the boundary between two teams that coordinate constantly is evidence that the boundary is wrong, and the merge is the honest version of the coordination the two teams were doing in meetings. Split: the team that has grown too large to hold one outcome, the journey team that has absorbed so much that its own internal coordination becomes the problem, splits along the journey’s natural fault lines. The discipline under the moves is the same as under every design decision in this book: the restructure is chosen for the value it enables, not for the chart it draws, and it is reviewed on evidence, with the floors held.

The floors are the point of the restructure, because the restructure must never move the obligations that chapter 24 made nonnegotiable. The audit trail that protects the merchant and the regulator, the data-residency discipline that the license review raised, the fraud-loss guardrail, the reconciliation that proves the money, the accessibility and the fair-lending rules: these are not re-sliced by the journey team’s convenience. The journey team owns the work, and the control rows stay owned by the accountable people, the audit and the compliance and the risk floors, with the interface agreements carrying the evidence exactly as they did between the old teams. The restructure moves the seams, and the floors do not move, and the organization that remembers the difference has restructured the work, while the organization that forgets it has restructured the risk.

The restructure also has its failure pattern, and it is the re-org as avoidance: the organization that redraws the boxes because coordinating is hard, the new chart that promises fewer meetings and delivers the same meetings with new names, the team that is re-formed and immediately reconstituted because the underlying dependency was never the problem, the people were in the wrong boxes for the right reasons. The field signal is the restructure without a measurement: the decision made on the belief that the new chart will be better, with no coordination-tax baseline, no review date, no evidence to confirm the seams moved to where the value is. The repair is the chapter’s whole discipline: measure before, decide with the record, review after, and treat the restructure as a hypothesis about the boundaries, tested by the flow, exactly like every other decision in this book.

The August rebuild

The worked application is the two weeks after the third Thursday, and it is worth following in sequence, because the sequence is the chapter. The product council does not declare a restructure in the first hour. It does the coordination discipline first, with the numbers on the wall, and it lets the evidence decide whether the boundaries are wrong.

The first act is the dependency board, and it comes out of the journey walkthrough the council runs the same afternoon. The room walks one real merchant record, and the record’s wait is the agenda: 40 percent of applications route to manual review, the manual review queue holds the median at 11 days, and the queue is fed by every team and pulled by no one. The board that follows has fifteen rows across the six types, and the ownership rule is applied as the chapter teaches: the dependent team names the row, the provider team confirms the evidence, and each row gets one owner from the governance map, not a committee and not a team. Kwame owns the KYC handoff, the banking lead owns the settlement window row, the data lead owns the schema, Ifeoma owns the shared QA capacity, and Zanele owns the journey itself, the one row that has no team, the row the wall was carrying.

The second act is the interface agreement for the KYC handoff, the bottleneck’s contract, written in the session on the chapter’s one-page form, with Kwame as the owner on the record and the support lead’s sign-off on the change path. Two more agreements follow the same shape: the settlement contract between the banking team and the platform, carrying Savanna’s window as the external row with its trigger and its prepared alternative, and the model-input contract between data and risk, carrying the schema, the cadence, and the September data promise, so that the credit model’s wait is a dated dependency with an owner instead of a hope.

The third act is the integration event, the journey Friday, scheduled on the wall: every second Friday, one real merchant record walked end to end on the shared staging environment, the September cohort’s first friction-fix variant walked before the cohort sees it, the reconciliation check on the day after, and the integration plan written as the chapter’s field output, the environments, the data sets, the walkthroughs, the owners, the dates. The rule is spoken aloud, because the room needs to hear it: the teams’ tests prove the teams, and the journey test proves the system, and the system is the product.

The fourth act is the flow, and it is the arithmetic the chapter has been building to. The journey WIP is capped at 11, the queue’s policy written as the chapter 30 explicit policy: the manual review pulled, not fed, the 40 percent falling as the deployed rule refinements let the automation absorb more decisions, the starts slowed at the signup to the rate the journey can carry. The council recomputes the forecast on the wall: 11 journeys in flight at 5.5 completions per week gives 2 weeks, the 14-day target, the September cohort scheduled against the new cycle time, the board’s date question answered with a forecast instead of a hope. The numbers reconcile, and the reconciliation is the discipline: the queue was the system’s shape, the WIP limit is the system’s control, and the 14 days are arithmetic, not aspiration.

The fifth act is the restructure decision, and it is the evidence, not the frustration, that decides it. The council measures the coordination tax of the friction-fix experiment, five meetings and a quarter of a day per team for the smallest piece of work in the product, and the measurement is the trigger the chapter named: when every change touches every team, the boundary is serving the work poorly. The council forms the onboarding journey team, re-slicing the merchant journey’s first three steps, signup, KYC, and activation, out of the mobile, risk, and support teams into one stream-aligned team with one outcome, merchant activation, and one flow, while the banking team stays the external seam to Savanna, the platform team stays the owner of the settlement API and the merchant record service, and the data team stays the owner of the schema and the model. The floors are named on the record before the team is formed: the audit trail, the data residency, the fraud-loss guardrail, the reconciliation, the fair-lending rules, none of them moving, each carried by the accountable person with the interface agreement as the evidence. The restructure is scheduled for review at the month-nine reading with the coordination-tax baseline recorded and the journey WIP and the cycle time as the confirmation, and the record carries the whole decision: the context, the options considered, the evidence, the choice, the floors preserved, the review date, the chapter 33 re-tailoring form applied to the team structure.

The machine’s boundary is drawn in the same sessions, because the multi-team system is a place where automation earns a bounded role. The machine can draft the dependency board from the teams’ boards, the repositories, and the standup notes, the candidate rows the room corrects; cluster the what are you waiting for answers into dependency candidates, the draft signal the seam owners verify; flag the interface evidence gaps, the handoff with no SLA, the contract with no owner, the dependency row with a stale date; and compute the flow arithmetic, the journey WIP, the completion rate, the cycle time, the forecast, the numbers the room still interprets. The human check is the chapter’s content: the ownership assignments, the interface agreements, the change paths, the integration events, the WIP policy, the restructure, and the data boundary, the book’s standing rule in its strongest form, because the multi-team system multiplies the systems the data might flow into: the merchant records, the KYC documents, the settlement data, the credit data, the compliance-sensitive rows never enter an unapproved system, and the machine’s drafts carry only the aggregate signals, never the protected records, and every draft is verified against the board and the records before it informs a decision.

The discipline that carried the two weeks is the chapter’s whole argument, and it is worth stating once plainly. The teams were never the problem, and the seams were never going to manage themselves. The dependency board named what crosses, the interface agreements wrote down how, the journey Friday proved it crossed, the cross-team plan and the seam risk review looked forward, the WIP limit ran the crossing at the system’s rate, and the arithmetic turned the queue into a forecast. The reduction moves removed the seams worth removing, and the restructure moved the seams worth moving, and the floors held throughout, because the coordination of multiple teams is not the enemy of autonomy, it is the condition of it: the team that knows its seam is owned is the team that can move fast without breaking the system, and the system that knows its journey is owned is the system that can deliver the merchant’s experience end to end, which is the product, which is the point.

The most common next failure is the one the September cohort will face in the month after this chapter ends: the journey team forms, the WIP limit holds, the cycle time falls to the target, and the organization, pleased with the improvement, lets the discipline drift — the dependency board’s rows aging with owners who changed roles, the interface contracts unread, the journey Friday rescheduled around the launch, the seam risk review skipped because the seams are quiet, the quiet the signal that the seams are unowned again, because the coordination of multiple teams is not a project with an end, it is an operating condition with a cadence, and the cadence decays exactly as fast as the team stops maintaining it. The next chapter turns to the seams that the dependency board and the interface agreements cannot reach by themselves: the teams that are distributed, cross-cultural, and partnered, where the distance is temporal and organizational as much as geographic, where the handoff crosses languages and employers and time zones, and where the coordination discipline of this chapter must be carried by documentation, asynchronous discipline, and trust built across boundaries, which is the subject of the next chapter.

Practice

One. A quick check: classify the dependency. For each scene, name the dependency type, technical, resource, sequence, decision, data, or external, and the one seam the scene most risks leaving unowned. (a) The mobile team ships the signup screen while the settlement API’s schema version in the shared environment is a release behind, and the journey Friday finds the mismatch. (b) The two QA specialists appear in the fraud automation’s plan and the platform team’s plan with no owner deciding the conflict. (c) The credit-model refinements wait on September’s cohort data, and September’s cohort waits on the onboarding flow. (d) The credit committee’s review calendar is full, and the pilot’s files sit approved-but-unreviewed. (e) The merchant record schema is edited by the data team and read by four others, and the reconciliation keeps finding gaps. (f) Savanna Settlement Bank moves its change window, and the settlement release date does not move with it.

(a) is a technical dependency, the schema version at the API seam, and the unowned seam is the version discipline, the contract that should have carried it, which the journey Friday then discovers. (b) is a resource dependency, and the unowned seam is the allocation decision, the person with the authority to choose, the shared QA specialists that chapter 19 priced and chapter 30 named: without the owner, both plans assume the specialists, and the calendar conflict becomes a delivery conflict. (c) is a sequence dependency, the circular queue that chapter 32 built and the walkthrough exposed, and the unowned seam is the ordering, the dependency logic between the cohort and the model that nobody has drawn as a sequence, which is why the queue feeds itself. (d) is a decision dependency, and the unowned seam is the decision right, the authority and the evidence and the committed date, because the files are done except for the signature, which is the signature of the governance gap, not the calendar. (e) is a data dependency, and the unowned seam is the schema ownership, the single source of truth with one owner and one change path, and the reconciliation gaps are the mismatch’s evidence, the chapter 21 lesson in data form. (f) is an external dependency, and the unowned seam is the trigger and the alternative, the contract with Savanna’s window and the buffer and the prepared response, because the window the project does not control is the dependency that must be owned the most. The common error is classifying by the symptom instead of the fix: the schema mismatch is not a technical problem to schedule, it is a data problem to own, and the misclassification is how the dependency hides.

Two. A field drill: build the dependency board. Take the project you lead or the one you work on, the one delivered by more than one team. Walk one real piece of work end to end, one merchant journey, one patient, one order, one release, and watch where it waits. Then write the dependency board: each row with the name, the type, the direction, the owner, the evidence, and the cadence. Apply the ownership rule strictly: the dependent team names the row, the provider team confirms the evidence, and each row has one owner from the governance map, a person, not a committee. Then answer: which row has no owner, which type has the most rows, and what does that say about the system?

The drill passes when the board is small, ten to twenty rows, and the walkthrough produced it in an afternoon. The most common failure is the board built from the org chart instead of the journey: the rows between the departments the chart already names, with the real crossings, the schema, the window, the queue, hidden inside the departments; the repair is the walkthrough, the real record, the real waits. The second failure is the owner who is a team or a committee or the project manager, every row, which is the coordinating committee in table form; the repair is the person from the governance map with the decision right, because the row whose owner is a committee is the row that waits for a meeting. The third failure is the row with no evidence field, the dependency named and never confirmed, which is the register that records without coordinating; the repair is the evidence the provider commits and the receiver accepts, because the dependency without evidence is a hope with a date.

Three. A field drill: write the interface agreement. Choose the one seam on your board that is the bottleneck, the handoff where the work waits. Write the one-page agreement: the interface, what crosses and in what form; the provider’s commitment, with the service level and the evidence; the receiver’s acceptance, the evidence it will not accept without; the change path, who can change the agreement and how; and the owner, the person, on the record. Then name the heroics the agreement replaces: the question that currently only one person can answer, the fix that happens quietly every week, the seam that is green because of the person.

The drill passes when the agreement fits on one page and the receiver’s acceptance is written in the receiver’s language, the evidence the receiving team actually needs, not the evidence the provider finds convenient, which is the chapter 33 lesson at the team scale. The most common failure is the agreement written by the provider for the provider: the SLA in the provider’s units, the acceptance in the provider’s demo, with the receiving team’s question, what does the merchant experience, absent; the repair is the receiving team writing the acceptance row. The second failure is the change path with no owner, the agreement that everyone signed and no one can amend, which becomes the contract that outlives its interface; the repair is the named owner and the version, the date, the record. The third failure is the heroics the agreement leaves in place: the analyst who still fixes the mismatch every Friday, the agreement on paper and the crossing in the head; the repair is the test, the journey Friday, the crossing proven on the environment, because the agreement is true only when the evidence proves it.

Four. A decision room: move the bottleneck. It is the third Thursday of August at KijaniPay, and the wall reads: journey cycle time 24 days against the 14-day target, 17 journeys in flight, 5 completions a week, the KYC manual review at a median of 11 days for the 40 percent of applications routed to manual review, the rule refinements deployed, the September cohort the last lever before the month-nine benefit reading, the application flow at 43 per month against the 65 the benefit clock needs. The options: (a) cap the journey WIP at 11, pull the manual review queue on the risk team’s cadence, and let the deployed automation absorb more decisions, accepting that the signup rate will slow for a few weeks; (b) borrow the risk analyst from the credit-model work to clear the queue in two weeks, protecting the signup rate and the September cohort’s size; (c) open a parallel manual review channel staffed by support team members trained on the KYC evidence, keeping the queue shallow and the signups flowing; (d) hold the current system and tell the board the journey will reach 14 days after the September cohort, once the model and the automation mature. Decide the move and say what the record must carry.

The defensible answer is (a), and the reasoning is the chapter’s flow discipline in one decision. The queue is the system’s shape, and the system’s control is the WIP limit: 11 journeys in flight at 5.5 completions a week gives the 14-day target by arithmetic, and the pulled manual review and the deployed refinements are what bring the completion rate from 5 to 5.5, the starts slowing for a few weeks being the visible decision to finish the journeys already started, the chapter 30 ethics at the system scale. (b) is defensible in intent and risky in execution: the credit-model work is itself the September dependency — the refinements wait on September data and the model waits on the refinements — and the analyst borrowed from the model is the circular queue re-borrowed from itself, defensible only if the credit model’s window is verified before the commitment. (c) is the chapter 21 and 24 mistake wearing new clothes: the manual review is the risk control with the evidence and the reviewer recorded, and the support team trained on the KYC evidence is the control diluted by convenience; the fraud-loss guardrail and the audit trail do not move for the queue’s comfort, the floors that chapter 24 made nonnegotiable. (d) is the hope the chapter exists to refuse: the 24 days are not going to fall by maturity, they are going to fall by the flow being controlled, and the board’s date question deserves a forecast, not a promise. The record must carry the WIP policy and its owner, the queue rule, the interface agreement’s change, the forecast arithmetic, the review date, and the September cohort’s rescheduling decision, because the bottleneck move is only as credible as the record that carries it.

Five. A decision room: coordinate or restructure. The August council has the evidence on the wall: the dependency board with its fifteen rows, the friction-fix experiment touching four teams at five meetings, the coordination tax measured at a quarter of a day per team, the journey WIP at 11 with the cycle-time forecast at 14 days, the September cohort scheduled, and the floors named, the audit trail, the data residency, the fraud guardrail, the reconciliation, the fair-lending rules. The options: (a) coordinate with the current five-team structure, the board, the contracts, the journey Friday, the WIP limit, and review the boundaries at the month-nine reading; (b) re-slice the onboarding journey now, forming the journey team from mobile, risk, and support with the banking seam and the platform seam held and the floors preserved; (c) keep the five teams and add a coordinator role, one person who owns the journey and resolves the seams, reporting to the council; (d) merge mobile and risk into one team and keep the rest as they are, because the KYC handoff is the bottleneck. Decide the move and say what the record must carry.

The defensible answer is (a) as the immediate decision with (b) as the reviewable hypothesis, and the reasoning is the chapter’s discipline: the coordination move comes first, because the coordination tax is measured before the restructure, and the boundaries are re-decided on the evidence the coordination produces, the chapter 33 re-tailoring rule applied to the team structure. (b) alone, without the coordination discipline first, is the re-org as avoidance: the journey team formed without the dependency board, the interface agreements, and the flow arithmetic that would tell it which seams to own, the new chart that redraws the seams and inherits the old ones. (c) is the coordinating committee in person form, the heroics coordinator of chapter 33 made a role: the one person who owns the journey becomes the journey’s bottleneck, and the autonomy the boundaries were meant to protect is removed by the person meant to protect it. (d) gets the symptom half right and the system wrong: the KYC handoff is the bottleneck, but the merge moves the seam instead of owning it, and the merged team inherits the risk floors and the compliance evidence with no interface agreement to carry them, the chapter 24 mistake in organizational form. The record must carry the coordination baseline, the dependency rows and their owners, the contracts, the integration plan, the WIP policy, the coordination-tax measurement, the restructure hypothesis with its review date and its floors, and the evidence that will confirm or refute it, the journey cycle time, the application flow, the September cohort’s outcome, because the decision is a hypothesis about the boundaries, and the record is how the hypothesis is tested.

Six. The mastery drill: coordinate, eliminate, decouple, or escalate. Here is a dependency list from a regional payments platform, one row per line. For each, decide the move, coordinate by owning it on the board with an interface agreement, eliminate by removing the seam, decouple by making it asynchronous, or escalate by taking it to the governance layer with the evidence, and name the field signal that would reveal a wrong move. The list: (a) the KYC package from the mobile team to the risk team, 40 percent manual review, median 11 days; (b) the settlement window from the banking partner, a change calendar the project does not control, with a release date scheduled inside the window; (c) the merchant record schema, edited by the data team, read by four teams, reconciled weekly; (d) the approval from the executive floor for the settlement exception, two signatures, one of which is the compliance head’s; (e) the staging environment, shared by five teams, with a booking calendar that keeps colliding with the release runs; (f) the cohort definitions between growth, data, and support, three versions of the phrase eligible merchant, none of them the same; (g) the credit committee’s review dates, with the pilot’s files approved but unreviewed; (h) the manual review of the KYC decision for the 40 percent, once the rule refinements are deployed.

The mastery is not the single right answer, it is the reading of the dependency and the move that fits its type, and the field signals that would reveal the wrong move. (a) is a sequence and technical dependency to coordinate: the interface agreement with the SLA and the capped, pulled queue, and the wrong move is escalation, because the seam is owned by Kwame and the queue is a flow problem, not a governance problem, the field signal being the queue that keeps growing while the escalation keeps being made. (b) is an external dependency to escalate with the evidence: the window is the project’s constraint and the alternative is the prepared response, and the wrong move is coordination, because no interface agreement with the banking partner moves the window, the field signal being the release date announced before the window was confirmed, the announcement that outran the evidence. (c) is a data dependency to coordinate by ownership, one owner, one source of truth, one change path, and the elimination move, the weekly reconciliation, is the wrong move, because the reconciliation is the evidence the schema needs, not the seam to remove, the field signal being the reconciliation gaps that keep appearing, the data dependency that has no owner, not the reconciliation that is too slow. (d) is a decision dependency to eliminate: the two signatures are the approval queue that chapter 26 removed at KijaniPay, and the wrong move is coordination, because the agreement that carries the approval to the seam still leaves the wait at the signature, the field signal being the approved item that sits for days, the decision right that was never delegated. (e) is a resource dependency to coordinate by allocation and to decouple where possible: the environment’s owner decides the calendar, and the teams move the work that does not need the real environment to the local environments, the field signal being the booking collision, the calendar conflict that is actually a capacity conflict with no owner. (f) is a data dependency to standardize, the three versions of eligible merchant consolidated into one definition owned by the data team with the cohort promise in the interface agreement, the field signal being the report whose cohort counts disagree with the report beside it, the mismatch that is a definition, not a number. (g) is a decision dependency to escalate with the evidence: the credit committee’s calendar is the governance layer’s, and the files approved-but-unreviewed are the decision wait, the escalation carrying the consequence of the wait and the decision request, the field signal being the files that keep being re-approved, the review that is a formality, not a decision. (h) is a sequence dependency to eliminate where the evidence allows: the manual review for the 40 percent is the control the deployed refinements can shrink, and the wrong move is coordinating the queue forever, the field signal being the manual review share that stays at 40 percent after the automation absorbed the share it could, the seam kept alive by habit, not by risk, the chapter 24 discipline applied, the control reduced only on the evidence that the automated check holds the floor.

Seven. The transfer question. On the project you lead, or the one you work on, where is the local optimum? Which team reports green while the system’s end-to-end number is red, and what is the end-to-end number, the journey, the handoff, the waiting line, that no single team owns, and when did you last walk one real piece of work end to end and watch where it waited? Can you draw the dependency board of your own work: the six types, the rows, the direction, the owner, the evidence, the cadence, and which row has no owner, and what is the question that only the person who currently carries the seam can answer, and what happens when that person is not in the room? Which of your handoffs live in heads instead of contracts, and what is the interface agreement you could write this week, the interface, the commitment, the evidence, the change path, the owner, and whose acceptance is missing from it? When do you integrate, on a schedule with the shared environment and the journey walkthrough, or in the integration week at the end, and what did the last integration week find, and when was it first discoverable? Which of your risks live at the seams, the window, the calendar, the shared specialist, the schema, and which team’s register carries them, and who owns the risk that no team owns? What is your system’s one flow, the end-to-end cycle time and the journey WIP, and which team’s utilization is hiding the system’s stall? Which of your dependencies should be eliminated, decoupled, or standardized, and what is the platform or the enabling team that became a queue, and who measures it by the flow of others rather than its own? And the question underneath all of them: is your coordination the ownership of seams, or the centralization of decisions, and is the boundary serving the work, or is the work serving the boundary, and if every change touches every team, what is the journey team you would form, and which floors would you refuse to move? The durable principle: when more than a handful of people deliver one product, mastery is scaling coordination without centralizing every decision, the dependency named, the interface owned, the handoff written, the integration scheduled, the risk carried across the seam, the system run as one flow, the seams worth reducing reduced, and the boundaries worth moving moved, with the floors held, because the seam that is owned is the condition of the team that is fast, and the journey that is owned is the condition of the product that works. The most common next failure is the drift: the rows age, the contracts go unread, the journey Friday reschedules, and the quiet seams become the unowned seams again, because the coordination of multiple teams is an operating condition with a cadence, not a project with an end. And the next chapter carries this coordination to the teams the dependency board cannot reach by itself: distributed, cross-cultural, and partnered, where the distance is temporal and organizational as much as geographic, and the handoff crosses languages, employers, and time zones.*

Notes

• The composite cases remain author-created illustrative material. The KijaniPay August product council review, the journey wall with its 24-day reading, the fifteen-row dependency board, the three interface agreements, the journey Friday integration event, the journey WIP cap, the coordination-tax measurement, the onboarding journey team, and all named characters and roles are teaching constructions consistent with the facts established in earlier chapters: the product goal, a merchant who can see her settlement and borrow against it, with the settlement promise, the fraud-loss guardrail, and the benefit clock from chapter 2; the merchant discovery that settlement visibility and cash-flow confidence drive the borrow decision, and the evidence ladder, from chapter 6; the staged launch with the Lagos cohort and the per-market readiness evidence from chapter 12; the adaptive life cycle and the product-and-project perspectives from chapter 13; the walking skeleton and the decomposition discipline from chapter 14; the Savanna Settlement Bank dependency row, contract negotiation, and sandbox access from chapter 16; Little’s Law and its assumptions from chapter 17; the cost and capacity discipline from chapters 18 and 19, including the two QA specialists shared with the fraud automation; the settlement reconciliation failure, the green suite and the drifting ledger, the batch window, and Ifeoma’s role from chapter 21; the risk register, the fraud-loss threshold, the credit committee, and the guardrail discipline from chapter 22; the contingency and trigger discipline from chapter 23; the audit trail, the data-residency question, the compliance floors, and the fair-lending and accessibility obligations from chapter 24; the heroics pattern from chapter 25; the delegation board and the removed approval queue from chapter 26; the flow board, the WIP limit of six, the explicit policies, the aging report, the ready column growing from eighteen to forty-seven items, the Friday review, the look-ahead, the settlement engineer’s spring leave and Nadia as understudy, the credit committee’s review dates scheduled into the look-ahead, and the December heroics from chapter 30; the interface register and the formal change path of the predictive control cycle from chapter 31; the June rewrite, the forty-seven items grouped into the five outcome streams, the volume automation ordered second, the fraud team’s queue of rule refinements waiting for the automation, the outcome-based backlog, the September cohort friction-fix experiment, the credit-model refinements waiting on September data, the support calls falling from eleven to five a week, the cash-flow-visibility score moving from 3.2 to 3.9, the board’s date question, the one hundred fifty-five applications against the two hundred thirty-three linear path, the forty-three applications a month against the sixty-five needed, the eligible cohort of about fourteen hundred with the three hundred fifty target, and the empirical loop from chapter 32; and the seam discipline, the interface calendar, the seam owner, and the re-tailoring record from chapter 33. The teaching numbers introduced here are fully reproducible from the text: the journey at 17 merchants in flight and 5 completions per week, 17 divided by 5 giving 3.4 weeks, about 24 days; the June reading of 14 days implying about 10 in flight at the then rate, the journey WIP growing by 7 as the ready column fed more starts than the journey could finish; the 40 percent of KYC applications routed to manual review with the median decision at 11 days; the target at 11 journeys in flight and 5.5 completions per week giving exactly 2 weeks, the 14 days on the wall; all stated with their assumptions, the average meaning what it means when the merchants are sufficiently homogeneous, the completion rate stable, and the system not in a death spiral, as teaching judgments rather than measurements. The standards and sources are described in the book’s own words: Little’s Law, the relation between average time in system, average number in system, and average completion rate, originates with John D. C. Little, A Proof for the Queuing Formula: L = lambda W, Operations Research, 1961, and is described here as in chapter 17, with its assumptions stated rather than as a universal law; Conway’s observation that systems tend to mirror the communication structures of the organizations that build them originates with Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968, and is described here in the author’s own words as a warning, not a law; the stream-aligned team, the platform team, the enabling team, and the complicated-subsystem team are concepts from Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution Press, 2019, described here in the author’s own words and adapted to the book’s method-neutral register; the empirical loop and the review discipline follow the current official Scrum Guide, November 2020 edition, by Ken Schwaber and Jeff Sutherland, as cited in chapter 32, described here in the book’s own words; the general project-management guidance of ISO 21502:2020, Project, programme and portfolio management: Guidance on project management, which treats the coordination of people and the monitoring and control of work across a project as part of ongoing practice, is described in the book’s own words as the general frame for the dependency and interface discipline; and the PMBOK Guide, Eighth Edition, Project Management Institute, November 2025, per the book’s reference baseline of 1 August 2026, treats the tailoring of approaches and the management of interfaces inside its performance domains, described here in the book’s own words. This book remains independent of PMI, ISO, and all standards and framework bodies, and no proprietary certification manual, commercial text, or framework guide is reproduced or paraphrased here.