Module 4: Technical Leadership Without Authority
2. Influence instead of mandate
Overview
By the end of this lesson you'll understand, with a measured curve and not with an intuition, why the order is a bad lever for the architect —even worse when they have no authority to enforce it— and why influence, which seems slower and weaker, is the only one that really moves five squads. The idea to internalize is that mandate and influence aren't two speeds of the same road; they're two different mechanisms that produce different results. The mandate seeks compliance by obligation: "do it because I say so". Influence seeks adoption by conviction: "do it because it's good for you and here's why". The first, where there's authority, gets fast but shallow obedience —people meet the letter and resist the spirit—; where there's no authority, as in the architect's case, it doesn't even get that. The second starts slower —you have to convince someone, and that someone convinces another— but produces a genuine adoption that spreads and stays. This lesson models the two dynamics over Mercado's five squads across twelve weeks, so you see with your own eyes how the imposed standard erodes while the influenced standard spreads.
This matters because it's the quantitative why of the whole module. Lesson 1 established that the architect's formal authority is 0% —they can't order—. This lesson answers the natural objection: "well, but if they could order, wouldn't it be more efficient?". The answer, measured, is no —and that "no" is liberating, because it means the lack of authority isn't just a limitation to work around, but the alternative lever (influence) is in fact better for the result that matters: real adoption—. A standard the squads adopt because you convinced them is used well, is maintained, and survives you no longer looking; a standard they "adopted" because you ordered it (if you could order it) is met half-heartedly and abandoned as soon as no one is watching. Influence isn't the consolation prize of the one who has no power; it's the right technique, and this lesson proves it with numbers.
Connection with the module: this lesson is the why; the four practices that follow are the how. Lesson 1 measured the problem (0% authority); this one measures why influence is the solution and not a patch. Everything that comes leans on this: the trust account (lesson 3) exists because influence is paid for with trust; the guardrails (lesson 4) are influence at scale —you influence many decisions without touching them one by one—; disagree-and-commit (lesson 5) is how you keep the influence when you disagree; the load-bearing conversations (lesson 6) are the channel through which influence travels; and consensus (lesson 7) is influence consolidated into a decision that stays. If lesson 1 said "you can't command", this one says "and good thing, because influencing works better —here's the curve—".
The song that catches on and the corporate phrase no one uses
Think about it with something you see all the time. A song becomes a hit. No one ordered it to become popular —there's no authority that can decree "this song will be liked"—. What happened was diffusion: a few people heard it and loved it (the early adopters), showed it to their friends, those friends to others, and in a few weeks half the world sings it. The adoption was genuine —people sing it because they like it— and that's why it holds: it keeps playing months later, because everyone who adopted it did so by conviction, not by obligation. Influence spread from person to person, and reached far precisely because no one imposed it.
Now the contrast. A company decides, from the top, that all employees use a new phrase in their emails —say, "thank you for your proactive collaboration"—. A memo goes out: "from today, it's mandatory". What happens? On day one, nominal compliance is one hundred percent —everyone, obedient, puts in the phrase, because they were ordered to and there's a boss watching—. But no one made it their own: the phrase sounds forced, ridiculous, no one believes in it. So as soon as the surveillance loosens, people stop using it —they go back to plain "thanks"—, and three months later the mandatory phrase has disappeared, while the song no one ordered keeps playing. The memo got immediate and hollow obedience; the diffusion got slow and real adoption. One evaporated; the other stayed.
That's exactly the difference between mandating and influencing a technical standard. When the architect orders "everyone use the new log format" (and even if they could enforce it, which they can't), they get the corporate phrase: nominal compliance on day one, resistance underneath, and erosion as soon as they stop looking —the squads put the format in half-heartedly, fill it with empty fields, and abandon it in the first tight sprint—. When the architect influences —convinces one squad, that squad sees the benefit and tells others, another follows— they get the song: it starts slow (a single squad at first), but it spreads from squad to squad by conviction and social proof, reaches all five, and stays because each one adopted it because it wanted to. This lesson measures the two curves.
Worked example: the standard that spreads vs. the one that's imposed
We model the adoption of the standard by the five squads across twelve weeks, counting genuine adoption —squads that really use the standard—, not the nominal compliance for show. Influence is modeled as diffusion: it starts with a convinced early adopter, and each week the already-convinced infect a fraction of those remaining (social proof, word of mouth), with an adoption that stays. Mandate is modeled as an order in week zero: nominally all five comply, but the genuine adoption starts low —only the ones that already agreed— and doesn't grow (no one is convinced by an order), and besides there's backsliding: without conviction, part of what's adopted reverts in silence.
# Adoption of a standard by 5 squads across 12 weeks.
# The architect CANNOT order. We compare two mechanisms and count
# SQUADS with GENUINE adoption (really use the standard), not the nominal
# compliance for show.
SQUADS = 5
WEEKS = 12
# INFLUENCE: diffusion. Starts with 1 convinced early adopter. Each week the
# already-convinced infect a fraction of those remaining (social proof, word of
# mouth). The adoption is genuine and stays.
def influence(seed=1.0, contagion=0.75):
adopted = seed
hist = [adopted]
for _ in range(WEEKS):
remaining = SQUADS - adopted
new = contagion * adopted * (remaining / SQUADS)
adopted = min(SQUADS, adopted + new)
hist.append(adopted)
return hist
# MANDATE: the architect orders in week 0. Nominally all 5 comply.
# But GENUINE adoption starts low (only the ones that already agreed) and
# does NOT grow: no one is convinced by an order. Besides there's backsliding:
# without conviction, part of what's adopted reverts in silence.
def mandate(genuine0=2.0, backslide=0.12):
genuine = genuine0
hist = [genuine]
for _ in range(WEEKS):
genuine = max(0.0, genuine - backslide * genuine)
hist.append(genuine)
return hist
inf = influence()
man = mandate()
print("GENUINE adoption of the standard (out of 5 squads), week by week:")
print(f"{'week':<8}{'influence':>11}{'mandate':>10}")
for w in range(0, WEEKS + 1, 2):
print(f"{w:<8}{inf[w]:>11.2f}{man[w]:>10.2f}")
print()
print(f"Week {WEEKS}: influence = {inf[-1]:.1f}/5 squads mandate = {man[-1]:.1f}/5 squads")
print(f"The mandate achieved 5/5 NOMINAL compliance on day 0, but only {man[-1]:.1f}/5 real.")
print("Influence started slower and reached all 5 squads -- and stays.")
What to expect. Running it:
GENUINE adoption of the standard (out of 5 squads), week by week:
week influence mandate
0 1.00 2.00
2 2.42 1.55
4 4.18 1.20
6 4.91 0.93
8 4.99 0.72
10 5.00 0.56
12 5.00 0.43
Week 12: influence = 5.0/5 squads mandate = 0.4/5 squads
The mandate achieved 5/5 NOMINAL compliance on day 0, but only 0.4/5 real.
Influence started slower and reached all 5 squads -- and stays.
Read the two columns top to bottom, because the crossover between them is the whole argument.
Notice week 0. The mandate starts above influence: 2.0 squads against 1.0. It makes sense —the day you issue the order, the squads that already agreed comply immediately (that's why the mandate starts at 2), while influence still only has one early adopter (that's why it starts at 1)—. If you measured only day zero, you'd conclude the mandate wins: it gets double the starting adoption. This is the trap that makes so many people choose to command: in the short term, it seems to work better. And if you could also enforce the order, the nominal compliance would be 5/5 that same day —five squads that "already adopted it" on paper—. An impatient architect sees that nominal 5/5 and declares victory.
Now follow the columns down. Influence grows —2.42, 4.18, 4.91— because each convinced squad infects those remaining: the diffusion accelerates in the middle (when there are already several convinced ones pushing) and reaches all five around week 8, where it stays pinned at 5.00. The mandate does the opposite: 1.55, 1.20, 0.93 —it erodes—, because the genuine adoption it had (the 2 squads that agreed) doesn't grow (no one else is convinced by an order) and in fact crumbles (the backsliding: without conviction, even the ones that complied revert in silence). By week 4 the curves already crossed —influence (4.18) passed the mandate (1.20)— and from there the distance only widens. In week 12, the outcome is brutal: influence has 5.0 of 5 squads with genuine adoption; the mandate has 0.4 —less than the 2 it started with—.
Here's the lesson made into a number, and it must be engraved: the mandate buys a headline on day one and pays for it with ruin in month three. Its nominal 5/5 was smoke —compliance for show that evaporates as soon as no one is watching—; its real adoption never passed 2 and ended at 0.4. Influence did the opposite: it gave up the day-one headline (it started at 1, not 5) in exchange for an adoption that spreads and stays. And notice the asymmetry of the architect without authority: they don't even have the false headline available —they can't force the nominal 5/5, because their authority is 0%—, so if they try to command, they get the worst of the mandate column (the erosion) without even the momentary consolation of compliance. For them, influence isn't the best option; it's the only one that produces something other than zero.
An honest nuance, because the model simplifies. The exact numbers —1.0 seed, 0.75 contagion, 0.12 backsliding— are illustrative, not measured from Mercado; change the parameters and the curves move. But the shape is robust and it's what matters: any process where adoption spreads by conviction (influence) beats in the medium and long term any process where adoption is forced without converting (mandate), because the first grows and the second erodes. The model doesn't say "it'll be exactly 5.0 against 0.4"; it says "the order without conviction crumbles and influence with conviction spreads", and that crossover happens for a wide range of parameters. The only way the mandate would win in the long term would be if it produced conviction —but then it wouldn't be a mandate anymore, it'd be influence under another name—.
Deep dive: why the order produces resistance, and what "influencing" really is
If the mandate is so bad, why is it so many people's reflex? And if influence is so good, what exactly does it consist of? It's worth taking apart both questions.
Why the order produces resistance. When someone is ordered to adopt something they don't understand or share, three things happen, and all three work against adoption. First, reactance: people (and teams) value their autonomy, and an order that feels like an imposition on how they do their work triggers resistance —not against the content of the order, but against the fact of being commanded—. An engineer may agree with the standard in the abstract and still resist if it's imposed, because what they defend is their right to decide how they work. Second, malicious compliance: without being able to openly disobey, the team obeys the letter and betrays the spirit —adopts the log format but fills it with empty fields or useless data, "complying" in a way that makes the standard useless—. Third, absence of ownership: no one feels responsible for the standard working, because no one chose it; it's someone else's order, so when something breaks, the team shrugs —"I just did what I was told"—. The three combine into the erosion you measured: imposed adoption has no one to hold it up.
What influencing really is. Influencing isn't manipulating or "selling" with tricks; it's a concrete process with three moves. First, start with the convincible: you don't try to move the five squads at once, you look for the early adopter —the squad (or the person) that has the problem your standard solves and is willing to try it—. With platform, for example, which suffers when it can't trace an error across services: for them the log standard isn't an imposition, it's a relief. Second, produce evidence: you let that early adopter use it and show results —"since we migrated, finding the cause of an incident went from hours to minutes"—. That evidence, said by a peer and not by the architect, is what convinces the next squad: not your authority (which you don't have), but the social proof that it worked for a team like them. Third, lower the cost of adopting: you make saying yes cheap —a ready library, a migration guide, your help on the first PR— so the convinced squad doesn't have to fight with the implementation. That's the mechanism of the diffusion you measured: it's not magic or charisma, it's sowing in the right place, letting the evidence talk, and removing the friction so the yes spreads.
The diffusion of innovations, in one phrase. What you modeled has a name and a theory: it's Everett Rogers's diffusion of innovations —how a new idea or technology spreads through a population via innovators, early adopters, early majority, late majority, and laggards—. The S-shape of the influence curve (slow, then fast, then it saturates) is exactly that dynamic: the start costs because you have to convince the first without social proof, the middle accelerates because there's already evidence and peer pressure, and the end flattens because only the laggards are left. The architect who understands this doesn't despair at the slow start —they know the first squad is the most expensive to convince— nor is surprised that the last one costs —the laggards always cost—; they work the curve, they don't fight it. And they know the central moral: their job isn't to convince the five squads; it's to convince the first so well that it convinces the rest.
Common mistakes
Choosing to command because it seems faster (of short-term myopia). What happens: the architect sees that the mandate starts high (the nominal 5/5 of day one) and concludes it's more efficient, so they order instead of influencing —and three months later they have 0.4 instead of 5—. Why it happens: the mandate does win in the short term, and if you only measure day one, you make the wrong decision; the erosion comes later, when no one attributes it to having commanded. How to spot it: if your success metric is "how many said yes this week" instead of "how many use it well in three months", you're optimizing the false headline. How to fix it: measure the genuine and sustained adoption, not the immediate nominal compliance; accept the slow start of influence in exchange for the high finish, which is the one that counts.
Trying to command without having authority (of simulating power). What happens: the architect, frustrated, issues the order anyway —"it's mandatory"— without being able to enforce it; they get the mandate's erosion without even the momentary compliance, and burn trust along the way. Why it happens: commanding feels decisive and fast, and under pressure it's tempting; they forget that without authority the order has nothing to hold it up. How to spot it: if you issue "must" and "mandatory" over teams that don't report to you, you're simulating a power that doesn't exist. How to fix it: swap the "must" for the "here's why it's good for you, and here's the first squad it already worked for"; influence is the lever you do have.
Trying to convince the five squads at once (of ignoring the diffusion). What happens: the architect launches the standard to the five squads simultaneously with a big announcement, expecting even adoption, and gets frustrated when none starts —because no one wants to be first without evidence—. Why it happens: communicating (to everyone at once, which was M3) is confused with influencing (which spreads from one to another); the early-adopter step is skipped. How to spot it: if your adoption plan is "announce it to everyone and wait", you're not using the diffusion. How to fix it: sow in the right early adopter —the one with the pain the standard cures—, produce evidence with them, and let that evidence move the next squad; you convince the first so it convinces the rest, not the five at once.
Exercises
Exercise 1 — Read the crossover of the curves. Without running the code, use the output table. (a) In what week does influence overtake the mandate? (b) Why does the mandate start above influence if it's supposedly the worse mechanism? (c) If an architect could only measure adoption in week 1, which mechanism would they choose, and why would it be a mistake?
See solution
-
(a) The crossover. Influence overtakes the mandate between week 2 and 4: in week 2 influence is at 2.42 against 1.55 for the mandate (already passed it), and in week 0 it was below (1.00 against 2.00). The crossover happens in the first weeks and from there the gap only grows.
-
(b) Why the mandate starts above. Because the day the order is issued, the squads that already agreed comply immediately —the model starts the mandate at 2.0 for that reason—, while influence still only has its single early adopter (1.0). The mandate "harvests" at the start those who didn't need to be convinced; influence literally starts with one. The mandate has the first-day advantage.
-
(c) Measuring only week 1 would be a mistake. They'd choose the mandate, because in week 1 it's higher (and its nominal compliance would be 5/5). It would be a mistake because that advantage is transient and misleading: the mandate is about to erode (it doesn't grow and it backslides) and influence is about to accelerate. Measuring in week 1 captures exactly the one moment when the worse mechanism looks like the best. Adoption is a phenomenon of months, not days; measuring it on day one rewards the false headline and punishes real diffusion. The right metric is the sustained adoption at the end of the horizon (week 12: 5.0 against 0.4), not the starting one.
Exercise 2 — The imposed standard "everyone adopted". An architect with a bit of borrowed authority gets the five squads to adopt their log standard by pressure: they send a firm email, get the managers to put it into the sprints, and in two weeks the five squads report "done". They declare victory. Three months later, when an incident occurs, they discover they can't trace the error across the services. What happened, and what signal should have alerted them that the "done" was false?
See solution
What happened is the mandate column made real: they got nominal compliance (all five reported "done") without genuine adoption. The squads, pressured and without conviction, adopted the standard in the worst way possible —malicious compliance—: they put in the log format but filled it with empty fields, default values, or data that's no use for tracing anything; they "complied" in a way that satisfies the checkbox and betrays the purpose. That's why, when the incident arrives and they really need to follow the thread of an error across the services, the logs are no use: they're in the right format but empty of useful content. The standard exists in the letter and not in the spirit.
The signal that should have alerted them: the speed and uniformity of the "done" were too good. Five squads genuinely adopting a new standard in two weeks is suspiciously fast —real adoption takes time, has friction, generates questions and doubts—. A unanimous and fast "yes" under pressure is almost always nominal compliance, not adoption. The other signal: no one asked hard questions or asked for help with the migration —which indicates no one took it seriously enough to run into the real problems of implementing it—. They should have measured adoption by using the logs in a real case (can I trace a test incident?), not by counting checkboxes. The lesson: the "done" reported under mandate measures obedience, not adoption; only real use measures it.
Exercise 3 — Design the diffusion. The architect wants Mercado's five squads to adopt a feature flags pattern (being able to turn functionality on and off without deploying). They have no authority. Apply this lesson's influence mechanism: where would you start, how would you produce evidence, and how would you lower the cost of adopting so the diffusion starts? Give a concrete plan, not "convince them".
See solution
The plan follows the three moves of influence:
1. Start with the right early adopter —the squad with the pain the pattern cures. Don't launch it to the five. Look for the squad that suffers most from not having feature flags: probably catalog or orders, which deploy often and have had scares releasing a half-baked feature. For them, being able to turn off a feature without deploying isn't an imposition, it's a relief to a pain they already feel. Starting there makes the first yes cheap —you solve a problem they already have—.
2. Produce evidence with that early adopter. Help them set up feature flags in one real feature and wait for the value moment to occur: the day they use a flag to turn off something that went wrong without having to do an emergency deploy at midnight. That case —told by them, not by you— is the evidence. "Last week we turned off the new checkout in thirty seconds when it caused problems, no rollback or deploy" convinces the next squad far more than any document of yours, because it comes from a peer who lived the benefit.
3. Lower the cost of adopting so the diffusion starts. Turn what you learned with the early adopter into something ready to use: a feature-flags library or wrapper already integrated with Mercado's stack, a short guide of "how to add your first flag in 20 minutes", and your offer to sit with the next squad on their first PR. That way, when orders sees catalog's evidence and wants to adopt it, saying yes doesn't cost them fighting with the implementation from scratch —the road is already paved—.
What you would NOT do: send an email to the five squads saying "adopt feature flags, it's the new standard practice". That's the mandate (without authority, besides), which produces the zero start and the resistance. The diffusion plan convinces one squad so well that its evidence and the paved road move the rest —you convince the first so it convinces the rest—.
Summary and next step
In this lesson you measured the module's why: influencing beats commanding where there's no authority —and in fact also where there is—. With the song that catches on and the corporate phrase no one uses you saw the two dynamics: the diffusion that starts slow and stays against the order that gets hollow obedience and evaporates. And you measured it by executing: over the five squads across twelve weeks, the mandate starts high (2.0 against 1.0 on day one, 5/5 nominal) but erodes to 0.4 real, while influence starts at 1.0, crosses the mandate around week 2-4, and reaches all five squads where it stays. You understood why the order produces resistance —reactance, malicious compliance, absence of ownership— and what influencing really consists of —start with the convincible, produce peer evidence, lower the cost of adopting—, which is Rogers's diffusion of innovations applied to a technical standard.
Before moving on you should be able to: explain why the mandate wins day one and loses month three; distinguish nominal compliance from genuine adoption; describe the three moves of influence (early adopter, evidence, lower the cost); and argue why you convince the first squad so it convinces the rest, instead of the five at once.
What follows is the currency with which influence is paid. In lesson 3 you'll see that influencing isn't free: each attempt to move a squad is paid from a trust account that's deposited (with correct calls, help, admitting mistakes) and withdrawn (imposing, being wrong after insisting, stealing credit). You'll see, executed, how two architects with the same correct technical proposal get opposite results —one is followed, the other ignored— for the single difference of their trust balance. It's the step from "I know influence works" to "I know what influence is bought with, and how not to run out of funds".
Resources
- Everett Rogers — Diffusion of Innovations — the theory that shapes this lesson's curve: how an innovation spreads through innovators, early adopters, and majorities. The foundation of why you convince the first squad so it convinces the rest.
- Jeff Bezos — Amazon Shareholder Letter 2016 ("disagree and commit") — the same letter we'll see in lesson 5 contains the idea that high-velocity decisions are made by convincing, not imposing; an executive counterpoint to this lesson.
- Gregor Hohpe — The Software Architect Elevator — on how the architect "sells" technical decisions to the business and the teams without authority; influence as a central skill of the role, not as plan B.
- Martin Fowler — Software Architecture Guide — Fowler's hub on why effective architecture is built with teams that make it their own, not with mandates from a tower; a good conceptual counterpoint on real vs. imposed adoption.