8. Project: get 5 squads to adopt a standard

Overview

This is your graduation from the module. Over seven lessons you learned why the architect leads with borrowed authority and not from the org chart, why influencing beats commanding, how trust is an account earned and spent, how to give guardrails instead of being a gate, how to disagree without blocking, where the conversations that hold up the architecture happen, and how to build consensus instead of winning debates. You saw all that applied in pieces. Now it's your turn, from beginning to end, over a concrete situation: get Mercado's five squads to adopt a common standard without being able to order them to. The reason for doing it yourself, complete, is the usual one and it's tough: if I let you repeat the lessons' examples, I wouldn't know whether you learned the craft or memorized the answers. With a real rollout you plan from scratch, the only way to solve it is to apply the method —and that is, exactly, the proof that the module worked—.

Your deliverable is three artifacts: (1) the trust and disposition map of each squad —who's an early adopter, who's a skeptic, what your balance is with each—; (2) the adoption plan that combines the module's tools —where you sow, what guardrail you build, what load-bearing conversations you have, how you handle the squad that disagrees—; and (3) the executed measurement, in Python, of the leadership reflex (commanding) against your plan (influence + guardrail), over two numbers that sum up the module: the genuine adoption and the architect's load. No part requires building the standard: it's pure leadership work —map, plan, measure—, which is exactly what separates an architect who designs from one who gets it adopted. Build it yourself first; reading the reference solution without having attempted it is like reading the score of a game you didn't play.

Connection with the module: this project closes the arc. Lessons 2 and 3 gave you the why and the currency (influence, trust); lessons 4 to 7 gave you the practices (guardrails, disagree-and-commit, load-bearing conversations, consensus). Here you use them all at once over a real rollout. And with this lesson the module closes: at the end is the summary of the eight lessons and the bridge to module 5, where you'll learn to translate business goals into quality attributes —the architect talking with the stakeholder, after learning to talk with the teams—.

The project case: the observability standard

The situation —yours to solve— is this:

The VP of engineering wants that, by the end of the quarter (twelve weeks), Mercado's five squads —catalog, orders, payments, shipping, platform— adopt a common observability standard: structured logs in JSON, a trace-id that travels across the services, and a unified error contract. The business reason is real: today, when something fails in production, tracing the problem across the five services takes hours because each squad emits logs its own way. Leadership, in a hurry, proposes the obvious way: send a memo that the standard is mandatory and put it into every squad's sprint. You, as architect, aren't the boss of any squad (your formal authority is 0%), and your job is to achieve real adoption —not the nominal "done"— with the module's method.

Each squad's context (given to you by your knowledge of the ground, so you don't have to invent it):

• platform — Suffers the problem more than anyone: they're the ones who get the tickets when something fails and can't be traced. Your trust balance with them is high (you helped them in several incidents). Natural candidate for early adopter.
• catalog — Pragmatic team, open to improvements if you lower the cost for them. Neutral-positive balance. Would adopt if it sees evidence.
• orders — Busy, with a tight backlog; not against it, but "no time". Neutral balance. Moves if the cost of adopting is low.
• shipping — Skeptical from experience: in the past a standard was imposed on them that turned out to be a pain. Low balance. Will resist anything that smells like imposition.
• payments — Has a legitimate technical concern: their current log format is tied to an audit requirement (PCI), and they fear the standard breaks that compliance. Neutral balance, but with a real objection to resolve.

Notice the mix: a clear early adopter (platform), two pragmatic ones (catalog, orders), one skeptical from experience (shipping), and one with a legitimate technical objection (payments). The module's method should have something different to say about each one. Don't re-teach how structured logging or tracing works —that's for another guide—; your job is to lead the adoption.

What you have to deliver

Follow the steps in order; each one leans on the previous.

Part 1 — The trust and disposition map

For each of the five squads, write: your approximate trust balance (high/neutral/low), its disposition (early adopter / pragmatic / skeptical / with an objection), and what module lever you'd use with it. Identify by eye where you'd start and which will be the hardest —before planning the rollout—.

Part 2 — The adoption plan

Design the twelve-week rollout combining the module's tools: where you sow (early adopter, lesson 2), what guardrail you build so adopting is cheap and you don't have to approve every PR (lesson 4), what load-bearing conversations you have and with whom (lesson 6), how you handle payments's legitimate objection (disagree-and-commit / escalate, lesson 5), and how you reach a consensus the five make their own (lesson 7). Not "convince them": a concrete plan, week by week or by phases.

Part 3 — The executed measurement

Write and run the Python that compares two scenarios over the twelve weeks: the mandate (the leadership reflex) against your influence + guardrail plan, measuring two things: the genuine adoption (out of the 5 squads) and the architect's load (how many migration PRs they have to review). Deliver the real numbers, run, not cited from memory. Reuse the engines from lessons 2 and 4.

The rubric

Here's how the project is evaluated. It's not by length or elegance: it's by whether the leadership is well thought out and well defended with evidence.

Criterion	Doesn't meet	Meets	Excels
Trust and disposition map	Treats the 5 squads the same	Distinguishes disposition and balance per squad	Also names the module lever for each one
Adoption plan	"I send an email" or "I convince them"	Rollout that uses early adopter + guardrail + conversations	Also handles payments' objection well (escalate vs. commit) and seeks consensus
Executed measurement	Numbers cited from memory or invented	Adoption and load run in Python	Also interprets the two numbers and states assumptions
Judgment	Commands because it's faster	Justifies the influence with the measured adoption	Also says when the mandate would be acceptable

The criterion that weighs the most, and the one that separates a technical leader from someone who only sends memos, is the combination of the plan with the executed measurement: if you deliver a pretty plan but the numbers came out of your head and not from running the code, you didn't measure —you asserted with invented figures, which is worse, because it fakes rigor—.

The reference solution

Attempt the whole project before continuing. What follows is one correct solution, not the only one.

Part 1 — The trust and disposition map

Squad	Balance	Disposition	Module lever
platform	High	Early adopter	Sow here (lesson 2): they have the pain the standard cures and they trust me. First yes, and source of evidence.
catalog	Neutral-positive	Pragmatic	Lower the cost of adopting (guardrail, lesson 4): adopts if I give it library + platform's evidence.
orders	Neutral	Pragmatic, no time	Guardrail + paved road (lesson 4): only moves if adopting costs almost nothing; make the easy thing the right thing.
shipping	Low	Skeptical from experience	Trust + load-bearing conversation (lessons 3, 6): 1:1 to listen to their bad prior experience; impose nothing, or they resist on reflex.
payments	Neutral, with an objection	Legitimate technical objection (PCI)	Disagree-and-commit / integrate the objection (lessons 5, 7): resolve their audit concern before asking for adoption.

What I see by eye, before planning: I start with platform (early adopter with high balance) because it's the cheapest yes and the best source of evidence. The hardest isn't the skeptic (shipping) but payments: their objection is technical and legitimate (the standard could break their PCI compliance), so it's not resolved with influence or evidence —it's resolved by really resolving the objection, or the standard itself is wrong for them—. If I ignore that objection and push, I either break their compliance (a disaster) or lose them. shipping is hard but manageable: their resistance is to the imposition, not the standard, so the key is not to impose.

Part 2 — The adoption plan

Weeks 1-3 — Sow in the early adopter and build the guardrail.

• Work with platform (early adopter): help them migrate one service to the standard. Since they already suffer the problem and trust me, the yes is cheap. Goal: for the value moment to happen —the first incident they trace in minutes instead of hours—.
• In parallel, build the guardrail that will make adoption cheap for the others: a shared observability library (that emits logs in JSON with trace-id automatically, with the right shape by default) and a CI check (fitness function) that verifies the format without me reviewing every PR. This is the paved road: make the easy thing the right thing (lesson 4). That way I don't become the gate that approves every migration.

Weeks 2-4 — The load-bearing conversation with payments (the legitimate objection).

• A 1:1 with the payments lead before asking them anything: "what would stop you from adopting this?". Listen to the PCI concern thoroughly (lesson 6). It's a real objection, not resistance.
• Resolve it in the design: ensure the shared library preserves (or even improves) the fields PCI compliance demands, and that it doesn't expose sensitive data in the logs. If the standard can't accommodate PCI, change the standard —that's really listening—. Here it's disagree-and-commit done well: their objection improves the decision (lesson 5). And if payments had wanted, for example, to store data unencrypted "to simplify", there I would escalate (grave risk); but their objection is the opposite —protecting compliance—, so I integrate it.

Weeks 3-6 — Spread with evidence to the pragmatic ones.

• With platform's evidence (the incident traced in minutes, told by them), approach catalog and orders. For them the argument isn't my authority (I have none) but: "it worked for platform, here's the ready library, migrating costs you 20 minutes". The guardrail (library + paved road) makes the yes cheap for the pragmatic ones with no time.

Weeks 4-8 — The conversation with shipping (the skeptic).

• 1:1 with shipping to listen to their bad prior experience (the standard that was imposed on them and hurt). Acknowledge that experience (a trust deposit, lesson 3), and be explicit that this isn't an imposition: there's no order, there's a library that saves them work and evidence that it served other squads. Let them decide. With the skeptic, the key is that the adoption feels theirs, not imposed —or they resist on reflex—.

Weeks 8-11 — Build the consensus and the ratification meeting.

• By the time I gather the meeting with the five squads, I already have each one's yes (or path to yes) in private: platform already uses it, payments has its objection resolved, catalog and orders saw the evidence and the cheap path, shipping decided without pressure. The meeting ratifies an already-built consensus (lesson 6), it doesn't decide cold. Consensus isn't that everyone loves the standard; it's that everyone can say "I understand it, my concerns were heard, I commit" (lesson 7).

Week 12 — Close.

• Genuine adoption of the five squads, held up by the library (guardrail) that maintains the standard without me reviewing every PR. I led the standard without ordering it or becoming the bottleneck.

Part 3 — The executed measurement

# Project: get the 5 squads to adopt ONE observability standard
# (structured logging + trace-id + common error contract) in 12 weeks,
# WITHOUT authority to order it. We compare the leadership reflex (MANDATE)
# against the architect's plan (INFLUENCE + GUARDRAIL), measuring two things:
# GENUINE adoption and the architect's review load.

SQUADS = 5
WEEKS = 12

# --- Genuine adoption (lesson 2 engine) ---
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.75)
adopt_mandate = mandate(g0=2.0, backslide=0.12)

# --- Architect's load (lesson 4 engine) ---
# Migrating to the standard, each squad opens PRs. With MANDATE the architect
# reviews every PR (gate). With GUARDRAIL a shared library + a CI check
# (fitness function) approve the routine; the architect only reviews the
# real exceptions.
PRS_PER_SQUAD = 8
total_prs = SQUADS * PRS_PER_SQUAD
EXCEPTIONS = 5                       # PRs that really need architect judgment
gate_reviews = total_prs             # reviews everything
guardrail_reviews = EXCEPTIONS       # reviews only what matters

print("GENUINE ADOPTION of the standard (out of 5 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}/5   influence = {adopt_influence[-1]:.1f}/5")
print()
print("ARCHITECT'S LOAD during the migration:")
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 (5/5 nominal) but {adopt_mandate[-1]:.1f}/5 real, and puts")
print(f"the architect reviewing {gate_reviews} PRs: bottleneck.")
print(f"Influence with guardrails reaches {adopt_influence[-1]:.1f}/5 genuine and leaves the")
print(f"architect reviewing only {guardrail_reviews}: I led the standard without ordering it or being the gate.")

What to expect. Running it:

GENUINE ADOPTION of the standard (out of 5 squads):
week       mandate  influence+guardrail
0             2.00                 1.00
4             1.20                 4.18
8             0.72                 4.99
12            0.43                 5.00

Week 12: mandate = 0.4/5   influence = 5.0/5

ARCHITECT'S LOAD during the migration:
design        total_prs  arch_reviews
GATE                 40            40
GUARDRAIL            40             5

The mandate gets paperwork (5/5 nominal) but 0.4/5 real, and puts
the architect reviewing 40 PRs: bottleneck.
Influence with guardrails reaches 5.0/5 genuine and leaves the
architect reviewing only 5: I led the standard without ordering it or being the gate.

Read the two blocks together, because they show the two faces of the module in the same case.

The first block is the genuine adoption (lesson 2 engine). The mandate starts high —2.0 on day zero, and 5/5 if we count the nominal "done" the squads report under pressure— but erodes to 0.4 of 5 real by week 12: the imposed standard is met half-heartedly (JSON logs but empty, trace-id that doesn't propagate) and abandoned. Influence + guardrail starts at 1.0 (only platform), spreads with the evidence and the paved road, and reaches 5.0 of 5 genuine, where it stays —the five squads really use it because they adopted it by conviction and the library keeps it easy—.

The second block is the architect's load (lesson 4 engine). Under the mandate, since there's no guardrail, the architect ends up reviewing every migration PR to verify the standard was applied —40 PRs, the bottleneck—. With the guardrail (library that makes the right thing easy + CI check that verifies the format), the automation approves the routine and the architect reviews only the 5 real exceptions (the rare cases, like payments' PCI integration). Eight times less load, and the load that remains is exactly the one that needs their judgment.

The point of the project is that these two numbers are connected, and that connection is the module's thesis. The mandate fails on both sides at once: it gets hollow adoption (0.4) and it turns the architect into the gate (40 reviews). It's not a coincidence: commanding without building the road forces you to police compliance one by one, and policing compliance doesn't produce conviction. Influence with guardrails wins on both sides at once: genuine adoption (5.0) because it was built with evidence and consensus, and low load (5) because the guardrail holds up the standard without the architect. Leading without authority isn't choosing between adoption and not-being-the-bottleneck; it's getting both with the same method —or losing both with the mandate—.

The assumptions I state: the diffusion parameters (seed 1.0, contagion 0.75) and 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 40 PRs with 5 exceptions assumes most of the migration is routine (the library covers it) and only a few cases touch real judgment —which is true because I built the library; without it, many more PRs would need review—. The model captures the structure of the problem, not an exact prediction of weeks.

Exercises

These exercises transfer the method to other Mercado leadership situations, so you confirm you learned to lead and not to repeat a rollout.

Exercise 1 — The squad that reports "done" in week 2. Under your influence plan, in week 2 the orders squad tells you "we already adopted the standard, it's done". It sounds good, but you remember lesson 2. What signal would make you suspect it's nominal compliance and not genuine adoption, and how would you verify it without offending the squad?

See solution

The suspicious signal: orders was the "pragmatic but no time" squad, with a neutral balance, that in your map would only move if the cost of adopting was almost zero —and you're barely in week 2, when the guardrail (the library) maybe wasn't even ready for them and platform's evidence was just starting—. A "done" so fast from a squad that had neither time nor a strong reason to prioritize it is suspicious: they probably ticked the checkbox (imported the library, or worse, copied a format) without really adopting it. The speed and the lack of questions are the flag (lesson 2): real adoption generates doubts, friction, requests for help; a smooth and fast "done" is usually nominal.

How to verify it without offending: don't accuse ("did you really do it?"), but verify by using the standard, with genuine curiosity and offering value. For example: "great! Hey, let's take advantage —let's do a test trace of an error across orders together, so you see the trace-id in action and tell me if anything's missing". If the standard is really adopted, the trace works and everyone wins. If it's nominal, the trace fails (empty logs, trace-id that doesn't propagate) and they themselves discover it in the attempt, without you accusing them —and there you offer to help them close it well, turning the verification into a trust deposit instead of an audit—. The key: verify by real use, not by the report, and do it in a way that helps instead of polices.

Exercise 2 — The VP pushes for the mandate. Halfway through the quarter, the VP gets impatient: "this is going slow, better I send a memo that it's mandatory and we put it into every sprint". With the project's numbers, argue why the mandate would achieve less than your plan, and acknowledge where the VP would be right (when the mandate does help).

See solution

Why the mandate would achieve less: with the project's numbers, the mandate takes the genuine adoption to 0.4 of 5 by week 12 (nominal compliance that erodes), while the influence plan reaches 5.0 of 5 real. And along the way, the mandate puts the architect (or someone) reviewing the 40 migration PRs to verify compliance —the bottleneck— against the guardrail's 5. The VP's memo would get exactly what the architect wants to avoid: a board that says "5/5 adopted" (the paperwork) over a system where, when it fails in production, the logs will still be no use for tracing —because they were filled with garbage to meet the checkbox—. The mandate's haste buys a headline and loses the result.

Where the VP would be right (when the mandate does help): the VP is right about the urgency —twelve weeks is a real deadline and "this is 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 the influence plan has built the genuine adoption (the squads already use it because they wanted to), a VP memo declaring the standard "official" helps —it gives institutional backing to something that already has conviction, closes the last laggards, and prevents a new squad from ignoring it—. The order matters: mandate after consensus amplifies; mandate instead of consensus erodes. The mandate also works for the truly non-negotiable (security, legal compliance), where there's no room to spread by conviction. The answer to the VP isn't "the mandate never"; it's "first let's build the real adoption —which is already on its way, here's platform's evidence— and then, if you want, your memo seals it; the other way around, we get paperwork that falls apart".

Exercise 3 — The legitimate objection vs. the capricious resistance. In your plan, you treat payments's objection (PCI) very differently from shipping's resistance (bad prior experience): one you integrate, the other you work with trust. Explain why the same attitude ("listen and adapt") is applied differently to each one, and what you'd do if a squad instead resisted for no real reason —just "I don't want to".

See solution

Why the same attitude is applied differently:

• payments (legitimate technical objection): their concern —that the standard breaks PCI compliance— is a technical fact that, if true, means the standard is wrong for them. Listening here isn't just building trust; it's collecting information that improves the decision (disagree-and-commit, lesson 5: their objection makes the standard better). The adaptation is technical: change the library or the standard to accommodate PCI. If I ignore this, I don't lose adoption —I break their legal compliance, a disaster—.

• shipping (resistance from experience): their reluctance isn't a technical objection to the standard; it's a trust wound from a bad precedent (something was imposed on them that hurt). Listening here is above all about repairing the relationship (lesson 3): acknowledge their bad experience, and show with actions —not imposing, letting them decide, giving them the library that saves them work— that this time is different. The adaptation is relational and process, not technical: the standard may be perfect; what has to change is how I present it to them (as an offer, not as an order).

The same attitude (listen and adapt) with two contents: for payments I adapt the standard (technical information); for shipping I adapt the approach (trust and process). Confusing them would be the error: if I treat payments' PCI objection as "resistance to overcome with trust", I break their compliance; if I treat shipping's reluctance as "a technical objection to resolve", I don't understand that their problem is that they don't trust, not that the standard is wrong.

If a squad resists for no real reason ("I don't want to"): first, suspect that there is a reason they're not saying —the flat "I don't want to" usually hides a fear (of it costing them time, of being evaluated badly, of a past pain) that a private load-bearing conversation (lesson 6) can bring to light: "what would really stop you?". Most "capricious resistances" are unsaid objections. If after really listening it turns out there's no reason —just inertia—, then the lever is diffusion and social proof (lesson 2): don't fight with that squad, but let the other four adopt and have the evidence and peer pressure do the work ("the others already use it and it serves them"). The laggard with no real reason gives in to the accumulated evidence, not to my insistence —and if in the end a single squad doesn't adopt something that serves the other four, that's information for the VP (institutional backing), not a battle I should win spending all my trust—.

Module summary and where you go next

With this project you close module 4, the leadership module. You started with the thesis —being right isn't having power: the architect leads with borrowed authority, not from the org chart— and the orchestra conductor who gets forty musicians to sound together without playing any instrument, measuring that their formal authority over the five squads is 0% (lesson 1). You turned that thesis into the measured why: influencing beats commanding, because the order gets nominal compliance that erodes (0.4/5) while influence spreads genuine adoption that stays (5.0/5) (lesson 2). You met the currency: the trust account that's deposited (being right, helping, admitting mistakes, giving credit) and withdrawn (imposing, failing after insisting, stealing credit), and for which the same correct proposal is followed (+10) or ignored (−10) (lesson 3). You learned to influence at scale without drowning: guardrails instead of gates —merge 50 of 50 instead of 15, touch only the 6 that touch boundaries— and to scale as a multiplier who decides and mentors (lesson 4). You learned to disagree without blocking: disagree and commit —the middle point (9 weeks) between the blocker who slows everything (15) and the one who caves and lets the flaw through (lesson 5). You discovered where leadership really happens: the load-bearing conversations —the decision deferred in the cold meeting (5/10) and decided in the prior 1:1s (10/10)— (lesson 6). And you learned to make decisions stay: build consensus —the good decision everyone makes their own (8 × 0.95 = 7.6) beats the perfect one no one executes (10 × 0.40 = 4.0)— (lesson 7). Here, in the project, you did it all yourself: you mapped the trust and disposition of five squads, planned a rollout that combines the six tools, and measured that influence with guardrails wins on both sides —genuine adoption and low load— where the mandate loses on both.

The capability you take away: facing any architecture change that depends on teams that don't report to you, you can lead its adoption without authority —spreading instead of ordering, funding with trust, giving lanes instead of gates, disagreeing without blocking, holding the load-bearing conversations, and building the consensus that makes the decision execute itself—. You stopped waiting for being right to impose itself and started leading the adoption, which is the architect's real work: not designing the system, but getting the organization to build it.

Where you go next, within this guide:

• Module 5 — Stakeholders and quality attributes. You now know how to lead the teams; module 5 teaches you to talk with the other side —the business—: translate goals like "we want to grow 10x" or "we can't go down on Black Friday" into quality attributes (scalability, availability), handle the non-technical stakeholder, explain the trade-off in their language ("more availability = more money"), and know how to say no. If this module was about influencing down and sideways (the teams), the next is about translating upward (the VP) —the other half of the architect who moves between the code and the business—.

And toward the rest of the ecosystem: every time this module talked about "standard", "guardrail", "contract", or "ADR" without re-teaching them, it leaned on the guides that do teach them —architecture-decisions-and-tradeoffs, api-design-and-integration, architectural-styles-and-boundaries—. Now you have what none of them covers: technical leadership without authority, the social skill that decides whether those technical decisions get adopted or stay in a document. The module's lesson, in one phrase: architecture isn't built by whoever is right; it's built by whoever gets a group of people who don't report to them to make a decision their own —and that's the biggest and hardest lever of the craft—.

Resources

• Will Larson — Staff Engineer — the module's natural close: the manual of the high-level engineer who leads without being a manager, with real stories of standard rollouts and technical decisions achieved by influence. Exactly what you did in this project.
• Gregor Hohpe — The Software Architect Elevator — the architect as the person who connects the business and the teams by moving between levels, leading without authority; the framework that holds up the whole module and anticipates the next (talking with the stakeholder).
• L. David Marquet — Turn the Ship Around! — the leader who multiplies by giving intent instead of orders; the extreme example that leading is enabling, not commanding, which sums up the attitude of the whole module.
• Jeff Bezos — Amazon Shareholder Letter 2016 ("disagree and commit") — the tool that appears in two lessons of the module (disagree and consensus); the executive example of how fast decisions are made without sacrificing honest disagreement.