Module 8: Capstone Project — Be Mercado's Architect Through a Change

6. Lead the rollout without authority

Next →

Overview

This is step 5 of the deliverable, and it's where the decision becomes —or doesn't— a real system. In the previous lessons you derived the attributes, designed the structure, and communicated it with the C4 and the ADR. But all of that is a decision on paper: the change's architecture only exists if the organization executes it. And executing it depends on five squads that don't report to the architect adopting the contracts of the change —the Seller API one, the platform-as-a-service ones— and on the seller_platform team forming and getting started. By the end of this lesson you'll have the deliverable's fifth artifact —the rollout plan with its measurement— and you'll have verified, executed, that influence with guardrails achieves genuine adoption where the mandate achieves only paperwork, and that the architect who orders becomes the bottleneck that step 1 swore to avoid.

This matters because it's the step where most architects fail without realizing, convinced that "a well-designed architecture implements itself". It doesn't implement itself. Module 4 dismantled that myth: being right isn't having power. The architect isn't the squads' boss; their formal authority over them is zero. If they deliver the C4 and the ADR and leave —confident that "it's well designed, they'll build it"—, each squad will keep to its priorities, the new team won't form, the contracts won't be adopted, and in a few months the real system won't look like the diagram —the ivory tower of module 1, now over the most important change of the year—. Step 5 is the recognition that the biggest and hardest lever of the craft isn't technical but social: what conversations the architect has, what guardrails they build, how they get a group of people who don't report to them to make a decision their own.

Connection with the module: this lesson does step 5 of the thread and contributes the M4 piece to the capstone. It receives its input from step 4 (the C4 and the ADR are the tools with which the architect influences —the evidence they show, the why they explain—) and from step 1 (the framed role: the gardener-architect who doesn't want to be the door is the one who here leads with guardrails). Its output —what was really adopted and who ended up owning what— feeds step 6: you can't plan the evolution or document something no one adopted. The frontier is respected: here the object is technical leadership without authority —influence, give guardrails, disagree-and-commit, consensus—; people management in depth (hiring, evaluations) stays out.

The orchestra conductor who plays no instrument

Think of an orchestra conductor. Before them, forty musicians, each an expert in their instrument —the violinist plays the violin better than the conductor, the trumpeter the trumpet better—. The conductor plays none. Their baton produces not a single note. And yet, it's they who get the forty to sound like a single music instead of forty simultaneous solos. How? Not by ordering each musician what note to play —it would be impossible and absurd—, but by giving a shared interpretation: the tempo, the dynamics, the entrance of each section, the sense of the work. The musicians, who play better than they do, play together because the conductor gave them a common frame they made their own. If the conductor tried to impose each note, the orchestra would stop; because they give a frame and trust each musician's craft within it, the music flows.

The architect who leads a change's rollout is that conductor. The five squads know how to implement their domain better than they do —catalog knows catalog, payments knows payments—. The architect isn't going to tell them how to write their code; it would be impossible and would be becoming the funnel of step 1. What they give is the shared frame: the contract of the change (how the services are exposed and consumed), the guardrail that makes it cheap to adopt (a contract-test in CI that verifies the format without the architect reviewing each PR), the evidence that it works (the early adopter that already uses it), and the consensus that makes the squads make it their own. Like the conductor, their power isn't in producing the notes, but in getting those who produce them to play together. This lesson measures the difference between conducting like that —influencing with a frame— and the reflex of one who doesn't know how to conduct: sending a memo that "it's mandatory" and hoping the music plays.

Worked example: adoption, measured

We're going to compare two ways of getting the six squads (the five existing ones plus seller_platform) to adopt the contract of the change, measuring two things at once: the genuine adoption (how many squads actually use it, not just on paper?) and the architect's load (how many migration PRs do they have to review?). The mandate scenario is the reflex of leadership in a hurry: a memo that it's mandatory. The influence + guardrail scenario is module 4's method: seed, give the lane, seek consensus. We reuse the two engines of module 4 —the diffusion of adoption and the review load—.

# Capstone step 5: lead the rollout WITHOUT authority. The change's architecture only
# exists if the organization executes it: the seller_platform team forms, and the squads
# that now expose services (catalog, payments, platform...) adopt the stable CONTRACT
# that makes it possible to consume them without co-changing. The architect doesn't order: they influence,
# give guardrails, and seek consensus. We measure two things: GENUINE adoption and their own load.

SQUADS = 6            # 5 existing + seller_platform
WEEKS = 12


# --- Genuine adoption of the contract (engine of lesson 2 of module 4) ---
def influence(seed, contagion):
    a, hist = seed, [seed]
    for _ in range(WEEKS):
        a = min(SQUADS, a + contagion * a * ((SQUADS - a) / SQUADS))
        hist.append(a)
    return hist


def mandate(g0, backslide):
    g, hist = g0, [g0]
    for _ in range(WEEKS):
        g = max(0.0, g - backslide * g)
        hist.append(g)
    return hist


adopt_influence = influence(seed=1.0, contagion=0.70)
adopt_mandate = mandate(g0=2.0, backslide=0.12)

# --- Architect's load (engine of lesson 4 of module 4) ---
# Migrating to stable contracts opens PRs. With MANDATE the architect reviews each PR to
# verify the contract is respected (gate). With GUARDRAIL a contract-test in CI
# (fitness function) approves the routine; the architect only looks at the real exceptions.
PRS_PER_SQUAD = 8
total_prs = SQUADS * PRS_PER_SQUAD
EXCEPTIONS = 6
gate_reviews = total_prs
guardrail_reviews = EXCEPTIONS

print("GENUINE ADOPTION of the change's contract (of 6 squads):")
print(f"{'week':<8}{'mandate':>10}{'influence+guardrail':>21}")
for w in (0, 4, 8, 12):
    print(f"{w:<8}{adopt_mandate[w]:>10.2f}{adopt_influence[w]:>21.2f}")
print()
print(f"Week 12: mandate = {adopt_mandate[-1]:.1f}/6   influence = {adopt_influence[-1]:.1f}/6")
print()
print("ARCHITECT'S LOAD during the rollout:")
print(f"{'design':<12}{'total_prs':>11}{'arch_reviews':>14}")
print(f"{'GATE':<12}{total_prs:>11}{gate_reviews:>14}")
print(f"{'GUARDRAIL':<12}{total_prs:>11}{guardrail_reviews:>14}")
print()
print(f"The mandate gets paperwork but {adopt_mandate[-1]:.1f}/6 real, and puts the architect to")
print(f"review {gate_reviews} PRs: the bottleneck that step 1 swore to avoid.")
print(f"Influence with guardrails reaches {adopt_influence[-1]:.1f}/6 genuine and leaves the")
print(f"architect reviewing only {guardrail_reviews}: leads the change without ordering it or being the door.")

What to expect. Running it:

GENUINE ADOPTION of the change's contract (of 6 squads):
week       mandate  influence+guardrail
0             2.00                 1.00
4             1.20                 4.44
8             0.72                 5.97
12            0.43                 6.00

Week 12: mandate = 0.4/6   influence = 6.0/6

ARCHITECT'S LOAD during the rollout:
design        total_prs  arch_reviews
GATE                 48            48
GUARDRAIL            48             6

The mandate gets paperwork but 0.4/6 real, and puts the architect to
review 48 PRs: the bottleneck that step 1 swore to avoid.
Influence with guardrails reaches 6.0/6 genuine and leaves the
architect reviewing only 6: leads the change without ordering it or being the door.

Read the two blocks together, because they show the two faces of leadership over this change.

The first block is the genuine adoption. The mandate starts high —2.0 on day zero, and if we counted the nominal "done" the squads report under pressure it would reach 6/6— but it erodes to 0.4 of 6 real by week 12: the imposed contract is met through gritted teeth (an API that says it follows the format but breaks in the edge cases, a service marked "migrated" that no one uses) and is abandoned as soon as the next priority arrives. Influence + guardrail starts at 1.0 (only the early adopter), spreads with the evidence and the cheap lane, and reaches 6.0 of 6 genuine, where it stays —the six squads really use it because they adopted it by conviction and the contract-test keeps it easy—. In a change like opening to external sellers, this difference is the difference between a surface that really works in production and one that "is migrated" on the board but falls over when a third party uses it differently than expected.

The second block is the architect's load, and here is where step 5 reconnects with step 1. Under the mandate, since there's no guardrail, the architect ends up reviewing each migration PR to verify the contract is respected —48 PRs, the bottleneck—. With the guardrail (a contract-test in CI that verifies the format automatically, plus the paved path of the well-documented contract), the automation approves the routine and the architect reviews only the 6 real exceptions —the rare cases that truly ask for their judgment, like how the payout ↔ payments seam handles a refund—. Eight times less load, and what's left is exactly what needs their cross-cutting view. Remember step 1: the architect framed their role to own 8 decisions and delegate 38; if in the rollout they became the door of 48 PRs, they'd reintroduce the funnel through the back door, precisely what they swore to avoid.

The point of the step is that these two numbers are connected, and that connection is module 4's thesis applied to the capstone. The mandate fails on both sides at once: it achieves hollow adoption (0.4) and turns the architect into the door (48 reviews). It's not a coincidence: ordering without building the lane forces policing compliance one by one, and policing compliance doesn't produce conviction. Influence with guardrails wins on both sides: genuine adoption (6.0) because it was built with evidence and consensus, and low load (6) because the guardrail holds up the contract without the architect. Leading without authority isn't choosing between adoption and not-being-a-bottleneck; it's achieving both with the same method —or losing both with the mandate—.

Deep dive: the rollout plan, squad by squad

The number shows influence wins, but not how it's executed. The rollout plan isn't "convince the squads"; it's a concrete plan that treats each squad according to its disposition, using module 4's tools. For this change, the map of the six squads and each one's lever:

  • seller_platform (the new team) — is the one that most wants the change, because it's its reason for existing. It's the natural early adopter: you seed here. That the sellers surface works in their team first is the source of evidence for the others. Lever: seed (diffusion, module 4).

  • platform — the change asks it to turn auth and notifications into stable services (contract) and set up the gateway. It has the pain (today everyone touches its auth) and gains with the contract. High trust balance. Lever: co-build the guardrail (the contract-test) with them, because they're the ones who'll operate it.

  • catalog — the change asks it to expose a listing ingestion contract (the import ↔ catalog seam). Pragmatic team: adopts if the cost is low. Lever: lower the cost with the guardrail and seller_platform's evidence.

  • payments — the change asks it to expose a payouts contract (the payout ↔ payments seam) that moves real money. Here there may be a legitimate objection: payouts to third parties touch compliance and auditing. Lever: the load-bearing conversation before asking for adoption —listen to the compliance concern and resolve it in the contract—; if the contract can't accommodate the auditing, the contract is changed (well-done disagree-and-commit, module 4).

  • orders — busy, no time, not against. Lever: the paved path —making adopting the checkout contract with the new flow cost almost nothing—.

  • shipping — the least touched by the change, adopts with the accumulated evidence of the others. Lever: social proof (the others already use it).

The rollout, in phases: seed in seller_platform and platform (weeks 1-3, and build the contract-test that makes adoption cheap); the load-bearing conversation with payments (weeks 2-4, resolve the compliance objection in the payouts contract before asking for anything); spread with evidence to the pragmatic ones catalog and orders (weeks 3-6, "it worked for seller_platform, here's the contract and the test, migrating costs little"); the conversation with shipping (weeks 5-8, the least touched, with all the evidence already accumulated); and the consensus meeting (weeks 8-11) that ratifies an agreement already built in private, not that decides cold. Consensus isn't that the six love the contract; it's that the six can say "I understand it, my concerns were heard, I commit".

Here's the capstone's integration lesson: the rollout uses the artifacts of the previous steps as tools of influence. The evidence that convinces the pragmatic ones is that seller_platform already uses the architecture of step 3. The argument that resolves payments' objection is the ADR of step 4, which already named the payout ↔ payments seam as a contract that preserves compliance. The justification for why it's worth adopting is the governing attribute of step 2 (scalability) translated into "this is what lets us grow 10x". The architect doesn't arrive at the rollout empty-handed: they arrive with the C4, the ADR, and the ranking, and those are their instruments of persuasion without authority. An architect who skipped steps 2-4 would arrive at the rollout with no evidence or why —only with their opinion—, and their only tool would be the mandate, which the number just showed loses.

An honest nuance about the model. The diffusion parameters (seed 1.0, contagion 0.70) and the erosion (0.12) are illustrative, chosen to show the robust shape —influence spreads and stays; the mandate erodes—, not measured from Mercado. The classification of 48 PRs with 6 exceptions assumes most of the migration is routine (covered by the contract-test) and only a few cases touch real judgment —which is true because the guardrail was built; without it, many more PRs would need review—. The model captures the structure of the problem, not an exact prediction of weeks.

Common mistakes

Delivering the design and expecting it to implement itself (of being-right-is-having-power). What happens: the architect finishes the C4 and the ADR, presents them, and assumes the squads "will build it because it's well designed". Months later, seller_platform didn't fully form, catalog didn't expose the ingestion contract, and the real system doesn't look like the diagram. Why it happens: it's the most comfortable myth of the craft —that the quality of the decision guarantees its execution—. How to spot it: if your change plan ends in "deliver the diagram", you skipped the hardest step. How to fix it: the decision is the easy half; making it happen is the other half, and it requires actively leading the adoption —seed, give the lane, converse, build consensus—; a diagram with no rollout is an ivory tower with a good drawing.

Mandating the contract as mandatory to go "faster" (of the mandate). What happens: the VP or the architect, in a hurry over the deadline, sends a memo that the change's contract is mandatory and puts it in every sprint. The board says 6/6 adopted; the reality is 0.4/6, with contracts full of junk to pass the checkbox and that fall over when a third party really uses them. Why it happens: the mandate buys an immediate headline and hides the outcome. How to spot it: if your adoption metric is "they reported it as done" and not "they're actually using it", you're measuring paperwork. How to fix it: measure adoption by real use (does a third party integrate without breaking?, does the payouts seam move money right?), not by the report; and use the mandate only after the consensus, as institutional backing that seals what already has conviction —never instead of the consensus—.

Becoming the door that reviews each migration PR (of the funnel, again). What happens: the architect, without building the guardrail, starts personally reviewing each of the 48 migration PRs "to make sure the contract is respected", and reintroduces the bottleneck that step 1 dismantled —over the biggest change of the year, precisely when they can least afford it—. Why it happens: reviewing feels like quality control; building a guardrail feels like "extra" work. How to spot it: if your review load during the rollout grows with the number of PRs, you're the door. How to fix it: build the guardrail (the contract-test in CI that verifies the format automatically) before the migration starts; the automation approves the 42 routine ones and leaves you the 6 that truly ask for judgment —you lead the standard without being the door—.

Exercises

Exercise 1 — Payments' legitimate objection. In your plan, payments may have a real objection to the payouts contract (it moves third-party money, touches compliance and auditing). Explain why that objection is treated differently from the mere reluctance of a squad "with no time", and what you'd do with it —drawing on the ADR of step 4—.

See solution

Payments' objection is treated differently because it's a technical fact, not a lack of will. A "no time" squad (like orders) resists over cost: it moves if adopting costs little, and the lever is the paved path. Payments' objection is of another nature: if the payouts contract really breaks the compliance or auditing of moving money to third parties, then the contract is wrong, not payments. Listening here isn't only building trust; it's gathering information that improves the decision —module 4's well-done disagree-and-commit: the objection, if valid, makes the contract better—.

What I'd do, drawing on the ADR. The ADR-021 already named the payout ↔ payments seam as "a genuine seam that requires a stable contract" —that is, the design already recognized that payments exposes a contract, not that seller_platform gets into its code—. With that in hand:

  1. The load-bearing conversation before asking for adoption: a 1:1 with the payments lead —"what would stop you from exposing this payouts contract?"— to listen to the compliance concern in depth. It's not resistance; it's a real objection.

  2. Resolve it in the contract: ensure the payouts contract preserves (or improves) the fields the auditing demands and doesn't expose sensitive data. If the contract can't accommodate compliance, the contract is changed —that's really listening—. The decision of how to structure that payouts contract with the compliance guarantees is, moreover, an api-design and architecture-decisions problem; the architect here detects and channels it, doesn't re-design it from scratch.

  3. And knowing when they would escalate: if payments wanted, for example, to skip the auditing "to simplify", that would be a serious risk and the architect would escalate. But their objection is the opposite —protecting compliance—, so it's integrated, not fought.

The lesson: distinguishing the legitimate objection (it's integrated, improves the contract) from the reluctance over cost (it's resolved with the cheap lane) is central to leading without authority. Confusing them is the mistake: treating payments' compliance objection as "resistance to overcome with evidence" would break compliance; treating orders' lack of time as a "technical objection" would fail to understand they only need it to be cheap.

Exercise 2 — The VP presses for the mandate. Midway through the rollout, the VP gets impatient: "this is going slow, better I send a memo that the contract is mandatory and we put it in every sprint". With the numbers of the step, argue why the mandate would achieve less, and acknowledge where the VP would be right.

See solution

Why the mandate achieves less. With the numbers of the step, the mandate takes the genuine adoption to 0.4 of 6 by week 12 (nominal compliance that erodes), while influence reaches 6.0 of 6 real. And along the way, the mandate puts the architect to review the 48 PRs of migration to verify compliance —the bottleneck— against the 6 of the guardrail. The VP's memo would achieve exactly what has to be avoided: a board that says "6/6 adopted" over a system where, when an external seller really integrates, the contracts will fall over —because they were filled with junk to meet the checkbox—. The mandate's haste buys a headline and loses the outcome, precisely in the change where the outcome (that third parties can really integrate) is everything.

Where the VP would be right. On the urgency —the deadline is real and "it's going slow" can be a valid concern—. And the mandate does have a legitimate place: as backing for the consensus, not as a substitute. Once influence built the genuine adoption (the squads already use the contract because they wanted to), a memo from the VP declaring it "official" helps —it gives institutional backing to something that already has conviction, closes the laggards, prevents a new squad from ignoring it—. The order matters: mandate after the consensus amplifies; mandate instead of consensus erodes. The answer to the VP: "first let's build the real adoption —which is already on its way, here's seller_platform's evidence— and then your memo seals it; the other way around, we get paperwork that falls over when the first third party tests it".

Exercise 3 — The rollout skipped the previous steps. An architect arrives straight to lead the change's rollout without having done steps 2-4: no ranking of attributes, no Conway maneuver, no C4 or ADR. They only have the sentence "open a Seller API and adopt a contract". Predict why their rollout is going to fail even if they use the right influence techniques.

See solution

It's going to fail because the influence techniques need raw material, and that raw material is the artifacts of the previous steps. Influencing without authority isn't charisma in a vacuum: it's persuading with evidence, with a why, and with a cheap lane. Without steps 2-4, the architect has none of the three:

  • Without the governing attribute (step 2), they can't answer "why must we adopt this?". Their only answer is "because I say so" —which is the mandate, the one that loses—. With step 2, the answer is "because this is what lets us grow 10x, the goal the business prioritized (scalability 38)", a why the squads can make their own.

  • Without the decided structure (step 3), there's no clear architecture to adopt; each squad will interpret "open a Seller API" its own way, and the surface will be born fragmented —the friction 21, not 7—. The rollout would be spreading the chaos, not a design.

  • Without the C4 and the ADR (step 4), they don't have the visual evidence or the documented why that convince the pragmatic ones and resolve payments' objection. They can't show catalog "here's how it looks, here's how you connect"; they can't resolve payments' compliance objection with an already-thought-out contract. Their load-bearing conversations would be improvised, unsupported.

The integration lesson: the rollout is step 5 for a reason —it depends on the four before it having given it its tools—. An architect with excellent influence techniques but without the ranking, the structure, and the communication artifacts is an orchestra conductor with no score: they know how to conduct, but they have nothing. The thread can't be started in the middle. The failure wouldn't be of their social skills; it would be of having tried to use them without what feeds them. That's why the capstone insists on the order: each step assembles the tools of the next.

Summary and next step

In this lesson you did step 5 of the deliverable: leading the rollout without authority. With the orchestra conductor who plays no instrument but gets forty musicians to sound together, you understood that the architect's power isn't in producing the notes but in giving the frame that those who produce them make their own. You measured it by executing: over the six squads, the mandate gets paperwork but only 0.4/6 of genuine adoption and puts the architect to review 48 PRs (the bottleneck), while influence with guardrails reaches 6.0/6 genuine and leaves the architect reviewing only 6 —it wins on both sides at once—. You saw the rollout plan squad by squad (seed in seller_platform, resolve payments' legitimate objection, spread with evidence, ratify the consensus) and, above all, that the rollout uses the artifacts of steps 2-4 as tools of influence: the governing attribute is the why, the C4 and the ADR are the evidence. An architect who skips those steps arrives at the rollout with no raw material to influence.

Before moving on you should be able to: plan a rollout that treats each squad according to its disposition and lever; measure the genuine adoption against the mandate and the architect's load; distinguish the legitimate objection (it's integrated) from the reluctance over cost (it's made cheaper); and explain why influence needs the artifacts of the previous steps to work.

What follows is step 6, the one that closes the craft. You already got the architecture adopted; lesson 7 teaches you to plan its evolution and document it so it survives. You're going to decide, executed, what to build now, what to put in a sacrificial version that will be replaced with real data, and what to defer leaving the seam —without over- or under-engineering—; and you're going to measure how the documentation that survives (docs-as-code: the README, the C4, and the ADR versioned) raises the bus factor of the new surface, so the change doesn't depend on a single head. It's the difference between launching a feature and closing the craft.

Resources

← Previous5. Produce the C4 and the ADRNext →7. Plan the evolution and the documentation