1. Module introduction: leading without being able to command

Overview

By the end of this lesson you'll understand the truth that separates the architect who designs from the architect who gets it built, and it's an uncomfortable truth for every engineer who grew up believing that being right imposes itself on its own: being right isn't having power. You may have designed the best team restructuring, communicated it with the cleanest C4, and still watch nothing happen —because the people who would have to execute your design don't report to you, and you can't order them to do it—. The architect is almost never the boss of the teams they need to move. They don't sign their reviews, don't decide their priorities, can't fire anyone. Their authority, when they have it, doesn't come down from the org chart: it comes borrowed —from the credibility they earned and the trust they built—. This whole module is about learning to lead this way: influencing instead of commanding, moving five squads that don't report to you toward what the architecture needs, with the only lever you really have when you don't have formal authority.

This matters because it's the lever the three previous modules took for granted and none taught. Module 1 said the architect enables instead of dictating and doesn't become the bottleneck —but it didn't say how you enable a team you don't command—. Module 2 designed the org↔architecture restructuring —but really restructuring requires that five teams and their managers accept moving, and you can't decree it—. Module 3 taught you to communicate clearly —but communicating well is necessary and not sufficient: someone understanding your decision isn't the same as adopting it—. Between the perfect diagram and the built system there's an abyss, and the bridge over that abyss is technical leadership without authority. It's also the architect's greatest leverage: since they can't build the system with their own hands —it's five squads, forty engineers—, everything they achieve they achieve through others, and moving them without commanding them is literally the work.

Connection with the module: this lesson is the map, not the territory. Here you don't practice each technique yet; you understand why the six lessons that follow go in the order they go. First the why: lesson 2 shows, measured, why influencing beats commanding where there's no authority. Then the currency with which you influence: lesson 3 treats borrowed authority as a trust account that's deposited and spent. With that clear, the four practices: lesson 4 teaches influencing at scale without drowning —guardrails instead of gates, the architect as a multiplier and not as a single reviewer—; lesson 5, how to disagree without blocking —disagree and commit—; lesson 6, where influence really happens —the load-bearing conversations, the hallway and the 1:1 before the meeting—; and lesson 7, how to make a decision land and stay —building technical consensus, winning the team and not the argument—. Lesson 8, the project, puts you to leading with your own hands the adoption of a standard by Mercado's five squads.

The conductor plays no instrument

Think about it with an image you already know: an orchestra conductor. They stand in front of forty musicians —violins, cellos, trumpets, timpani— and get them to sound like one thing: they come in together, breathe together, speed up and stop together. They are, without argument, the most important person on stage. And now notice the odd part: the conductor plays no instrument. They produce not a single note. They're not the orchestra's best violinist —they probably couldn't play the first violin's passage anywhere near as well as the first violin—. Their value isn't in executing; it's in getting forty people who do execute to do it coordinated.

Now the question that matters: why do they listen to them? It's not because they can fire them —in most orchestras the conductor doesn't hire or fire the musicians, and even if they could, the power to fire doesn't make someone play well—. It's not because they shout louder. The musicians follow the conductor for one reason: they trust that their reading of the piece is the right one. They earned that trust —they know the score better than anyone, they've shown their ear, they've been right before—, and that trust is their authority. It's a borrowed authority: the musicians grant it because they believe it will lead them to sound better, and they'd take it away the moment it stopped being deserved. A conductor who abuses, who humiliates, who's wrong and doesn't admit it, loses the orchestra —they stay seated, but they no longer follow, they play defensively, each on their own, and the music falls apart—.

That conductor is the architect, and the orchestra is the five squads. The architect doesn't play the instruments —they don't write the bulk of catalog's, orders's, or payments's code—; their value is getting the five squads to sound coordinated: to adopt the same standard, respect the same boundaries, move in the same direction. And they can't order it: like the conductor, they're not the musicians' boss. Their authority is borrowed, made of trust, and it can be earned or burned. An architect who tries to conduct by shouting —imposing without having earned the trust— gets the same as a tyrannical conductor: the teams stay there, but they play defensively, they meet the letter and betray the spirit, and the system falls apart. This whole module is about learning to conduct the orchestra without being able to fire anyone —which turns out to be the only way the music really sounds—.

The case: Mercado, five squads and zero direct reports

Throughout the guide we accompany Mercado, the marketplace with its five squads —catalog, orders, payments, shipping, platform—. In this module the concrete situation is this: the architect wants the five squads to adopt a common technical standard —say, a unified way of emitting logs and handling errors, so that when something fails at three in the morning it can be traced across the five services—. It's a sensible, cross-cutting architecture decision, of the kind only the architect sees completely. And here's the module's problem in one sentence: the architect doesn't command any of the five squads. Each one reports to its own manager, has its own priorities, its own backlog someone else prioritizes. The architect can't put the standard into anyone's sprint. They can write the best document, give the best talk, and still, on Monday morning, each squad decides alone what it works on.

Before learning to move those five squads, it's worth measuring the exact size of the problem —how much formal authority the architect really has over the people they need to align—, because it's easy to underestimate. It feels like "the architect carries weight"; the number says otherwise.

Worked example: the gap between what they must move and what they command

The following code doesn't simulate anything complex: it just counts. It maps the five squads the architect must align, how many people are in each one, and who each one reports to —to compute what fraction of those people falls under the architect's formal authority—.

# Mercado's architect is responsible for the 5 squads adopting a common technical
# standard. But they're NOT the boss of any: each squad reports to its own
# manager. How much FORMAL authority does the architect have over the people they must move?

squads = {
    # squad     : (engineers, reports_to)
    "catalog":  (8,  "eng-manager-A"),
    "orders":   (9,  "eng-manager-A"),
    "payments": (7,  "eng-manager-B"),
    "shipping": (6,  "eng-manager-B"),
    "platform": (10, "eng-manager-C"),
}

architect_direct_reports = 0   # the architect has no direct reports in the squads

total_engineers = sum(n for n, _ in squads.values())
managers = {m for _, m in squads.values()}

print("The architect must align these 5 squads on a common standard:")
print(f"{'squad':<10}{'engineers':>10}{'reports_to':>16}")
print("-" * 36)
for name, (n, mgr) in squads.items():
    print(f"{name:<10}{n:>10}{mgr:>16}")
print("-" * 36)
print(f"{'TOTAL':<10}{total_engineers:>10}{len(managers):>11} mgrs")
print()

formal_authority = architect_direct_reports / total_engineers
print(f"Engineers the architect must move    : {total_engineers}")
print(f"Engineers they command (reports)     : {architect_direct_reports}")
print(f"Formal authority over people to align: {formal_authority:.0%}")
print()
print("Orders they can issue and that must be obeyed: 0.")
print("All their leverage has to come from INFLUENCE, not from the org chart.")

What to expect. Running it:

The architect must align these 5 squads on a common standard:
squad      engineers      reports_to
------------------------------------
catalog            8   eng-manager-A
orders             9   eng-manager-A
payments           7   eng-manager-B
shipping           6   eng-manager-B
platform          10   eng-manager-C
------------------------------------
TOTAL             40          3 mgrs

Engineers the architect must move    : 40
Engineers they command (reports)     : 0
Formal authority over people to align: 0%

Orders they can issue and that must be obeyed: 0.
All their leverage has to come from INFLUENCE, not from the org chart.

Stop at the number that shouts: 0%. The architect is responsible for forty engineers, spread across five squads and under three different managers, adopting a common standard —and their formal authority over those forty is zero—. They can't give a binding instruction to any of them. If tomorrow they write "everyone must migrate to the new log format by Friday", no one is obliged to obey: each squad will keep doing what its manager prioritized, and the architect's "everyone must" has no mechanism behind it to enforce it. This isn't a defect of Mercado or of this particular architect; it's the normal form of the role. The architect lives at the intersection of several teams precisely because their work is cross-cutting, and that cross-cutting position comes with a hard consequence: they influence far more people than they command —almost always, people they don't command at all—.

That 0% is the definition of the module's problem. If you had formal authority over the five squads, this module would be unnecessary: you'd say "do this" and it would be done (badly, as we'll see, but done). The module exists because the formal authority is zero. And the question it answers over six lessons is exactly this: if you can't command, how do you move forty people? The short answer —which the lessons develop— is that all your leverage has to come from influence, influence is paid for with trust, and trust is earned with a handful of concrete behaviors that can be learned. It's not charisma or magic; it's a craft with measurable techniques, and this module teaches them one by one.

It's worth anticipating the contrast lesson 2 will measure, because it's the most common trap. The architect without authority, frustrated by that 0%, sometimes tries to act as if they had authority: they command anyway —"this is mandatory, I decided it"—. And they get the worst of both worlds: since they have no real power behind the order, they can't enforce it; and since they commanded without having earned the right, they burn the trust that was their only lever. They end up with less influence than before they opened their mouth. Lesson 2 puts a number on that failure; for now it's enough to engrave the asymmetry: they must move 40, command 0, and the only way out is to influence.

The map of the six lessons

The six lessons that follow go in this order for a reason: first the why, then the currency, then the four practices that spend that currency to move people.

Lesson	What it gives you	Why it goes here
2	Why influencing beats commanding	It's the measured thesis: without authority, the order produces resistance; influence, adoption that spreads
3	The trust account	It's the currency of influence: with no balance, even the right proposal is ignored
4	Guardrails instead of gates	It's how you influence at scale without becoming the bottleneck —the multiplier—
5	Disagree and commit	It's how you disagree without blocking or caving —influence that doesn't become a brake—
6	The load-bearing conversations	It's where influence happens: the hallway and the 1:1 before the meeting
7	Building technical consensus	It's how the decision lands and stays: you win the team, not the argument

The arc is: first you understand why influence is the only real lever when authority is 0% (2); then you meet the currency with which that influence is bought, trust (3). With the currency in hand, you learn the four ways to spend it well: give lanes instead of approving everything (4), disagree without blocking (5), have the conversations that sustain the architecture (6), and build the consensus that makes a decision get executed (7). Lesson 8 —the project— puts it all together by having you get the five squads to adopt a standard, without authority, with the six tools.

What this module does NOT touch

It's worth marking the frontier from now, because there are neighboring topics that seem to belong here and belong elsewhere.

The bottleneck was raised in module 1. There we measured, with a queuing simulation, how an architect through whom every decision passes forms a queue that grows without end —the 46 weekly decisions against a capacity of 20, the backlog that reaches 260—. That module installed and measured the problem. This module teaches the leadership technique that avoids it: the guardrails of lesson 4 are the "how" of the "don't be the gate" that module 1 left pending. When in lesson 4 we talk about the bottleneck again, we don't re-measure the queue; we teach how to design the lanes that make most decisions never reach it.

Communicating with C4 was module 3. There you learned to choose the right diagram for the audience —the Context for the VP, the Container for the dev— and to use the ADR as the why that travels through time. This module takes for granted that you know how to communicate and concentrates on the next step: that the communicated decision gets adopted. Communicating is that they understand; leading is that they do. When here we say "the architect presents the standard", we take for granted that they communicate it well (that was M3) and focus on how they get the five squads to make it their own.

People management is out of scope. The performance 1:1s, the reviews, the hiring, deciding promotions, building the org chart —all that is the craft of management, and it's real and important, but it's not this module—. Here, when we talk about "1:1", we mean the technical 1:1 —the conversation about a design, an architecture question, a trade-off—, not the performance meeting. The distinction is the line that separates technical leadership from people management. The architect influences technically over people someone else manages. Confusing the two —believing that to influence technically you need a manager's authority— is precisely the mistake this module dismantles: you can lead the technical work without managing the person, and in fact it's the normal thing.

Common mistakes

Believing that being right is enough for them to follow you (of faith in being right). What happens: the architect arrives with the best technical argument, lays it out rigorously, and takes for granted the teams will adopt it because it's correct —and they don't adopt it—. Why it happens: the engineer was trained so that in the world of machines the right answer wins; they forget that in the world of people, adoption depends on trust, timing, and feeling ownership of the decision, not just on correctness. How to spot it: if it surprises and frustrates you that "being right" people don't follow you, you're operating under this belief. How to fix it: it's the whole module —accepting that being right is necessary but not sufficient, and that moving people requires influence, trust, and consensus besides being correct—.

Acting as if you had authority you don't (of commanding without power). What happens: the architect, frustrated by the 0%, starts giving orders —"this is mandatory, I decided it"— as if they commanded. They get the worst: they can't enforce the order (they have no real power) and they burn the trust that was their only lever. Why it happens: it's tempting to simulate the authority you don't have, especially under time pressure. How to spot it: if your communications use "must", "it's mandatory", "I decided it", and you don't have the power to enforce them, you're commanding without authority. How to fix it: lesson 2 —swap the order for influence, which is the lever that does work when authority is zero, and doesn't spend but builds the trust—.

Confusing technical leadership with people management (of the wrong role). What happens: the architect concludes that, since they can't influence without authority, they need to become the squads' manager —ask for them to report to them, get into their reviews—. Why it happens: they believe the only way to move people is to command them, so they seek the formal power. How to spot it: if your solution to the influence problem is "give me authority over them", you're confusing the crafts. How to fix it: understand that technical leadership does not require a manager's authority —in fact it works better without it, because earned influence is more durable than forced obedience—; the module teaches leading the technical work over people someone else manages, which is the normal and healthy form of the role.

Exercises

Exercise 1 — Count your own authority gap. Think of a cross-cutting technical decision you've wanted to drive (or imagine one for Mercado: "all squads use the same HTTP client with retries"). List the teams that would have to adopt it and, for each, answer: do they report to you? can you put the task into their backlog without asking anyone's permission? With that, estimate your "formal authority" over the people you must move, as in the example. What does the number tell you about which lever you have left?

See solution

In almost all real cases, the count gives the same as in Mercado: the formal authority over the teams you must move is zero or nearly zero. They don't report to you, you can't put a task into their backlog without going through their manager or their prioritization process, and you can't enforce an instruction. The exact value matters less than the conclusion, which is the module's: if the formal authority is low, the order isn't an available lever —even if you use it, it has nothing to enforce it—, and the only lever you have left is influence. The exercise exists so you feel, over a case of your own, that Mercado's 0% isn't a peculiarity of the example but the architect's default situation. And if by chance you do have formal authority over one of them (rare), you'll notice you'd still prefer not to spend it commanding —for what lesson 2 will measure: the order produces hollow compliance even when you can give it—.

Exercise 2 — The tyrannical conductor. Return to the analogy. A new orchestra conductor, technically brilliant, decides to impose themselves by shouting: they humiliate whoever makes a mistake, never acknowledge their own reading errors, and demand immediate obedience "because they're the conductor". The musicians are professionals and don't quit. Why, even so, is the music going to get worse? Connect your answer with the idea of "borrowed authority".

See solution

The music gets worse because the conductor's authority was borrowed —the musicians granted it in exchange for believing that their reading led them to sound better—, and the tyrannical conductor is burning it. The musicians don't quit (they stay seated, meet the letter: they come in where marked, play the notes), but they stop following them in the sense that matters: they no longer put their judgment and their care at the service of the interpretation, they play defensively —the minimum so as not to be humiliated—, they don't warn when something sounds wrong out of fear of the reaction, and each one retreats to their part. The fine coordination, which was the whole value of the conductor, is lost. It's nominal compliance without genuine adoption: presence without commitment.

The connection to the architect is direct. An architect who imposes without having earned the trust gets exactly this from the squads: they meet the letter of the standard and betray the spirit (they adopt the log format but fill it with garbage), they don't warn when the design has a problem, and they do the minimum so they don't get scolded. Borrowed authority, spent by shouting, doesn't buy coordination; it buys hollow obedience, which is exactly what's no use. That's why the module insists on building the trust (lesson 3) before spending it.

Exercise 3 — Technical leadership or people management? Classify each situation as within the scope of this module (technical leadership without authority) or outside (people management), and say why: (a) the architect convinces the payments squad to adopt a retry pattern; (b) the architect gives the annual performance rating to a payments engineer; (c) the architect spends half an hour in a technical 1:1 helping a developer think through the design of her service; (d) the architect decides who to hire for the orders squad.

See solution

• (a) Convince payments to adopt a pattern → within. It's the heart of the module: influencing technically over a team that doesn't report to them, without being able to order it. The word "convinces" (not "orders") already places it in the terrain of influence.

• (b) Give the performance rating → outside. Evaluating a person's performance is pure people management. It requires a manager's formal authority and decides things (salary, promotion, tenure) that aren't technical. An architect normally does not do this; if they did, they'd be acting as a manager, not as an architect.

• (c) The technical 1:1 helping with a design → within. This is the "1:1" the module does talk about: a technical conversation —a load-bearing conversation from lesson 6— where the architect mentors, influences, and builds trust over a design problem. They don't evaluate the person; they help her think. It's technical leadership.

• (d) Deciding who to hire → outside. Hiring is people management and an organizational decision; it belongs to the squad's manager, not the architect in their technical role. The architect can weigh in on a candidate's technical skills, but deciding the hire falls outside this module.

The rule that separates within from outside: if the action influences technically how the system is built, it's this module's; if it manages the person —their performance, their career, their tenure— it's the craft of management and falls outside. The architect leads the technical work of people someone else manages, and that separation is healthy: they don't need power over anyone's career to influence their code.

Summary and next step

In this lesson you met the thesis that holds up the module: being right isn't having power —the architect leads with borrowed authority, made of trust, not brought down from the org chart—. With the orchestra conductor you saw the form of the craft: the most important person on stage plays no instrument, and they listen to them not because they can fire anyone but because they trust their reading —an authority that's earned and can be burned—. You met Mercado in its human dimension —five squads, three managers, forty engineers the architect must align— and measured the exact size of the problem: their formal authority over those people is 0%, so all their leverage has to come from influence. And you marked the frontier: the bottleneck was installed in M1, communicating was M3, and people management —reviews, hiring— falls outside; here only technical leadership.

Before moving on you should be able to: explain why the architect almost never has formal authority over the people they must move; distinguish borrowed authority (from trust) from formal authority (from the org chart); and separate technical leadership —which this module teaches— from people management —which falls outside—.

What follows is the measured why of the whole module. In lesson 2 you'll see, executed over the five squads across twelve weeks, why influencing beats commanding where there's no authority: how a standard imposed by order gets nominal compliance on day zero and erodes to almost nothing, while the same standard spread by influence starts slower, spreads to the squads one by one, reaches all five, and —this is the important part— stays. It's the step from "I sense that commanding doesn't work without power" to "I have the curve that proves it".

Resources

• Gregor Hohpe — The Software Architect Elevator — the book that defines the architect by their ability to move between the business and the code and to lead without formal authority; the conceptual framework of this whole module. The idea that the architect influences "sideways", through organizations they don't control.
• Will Larson — Staff Engineer — the modern reference on the role of the high-level engineer (staff/principal) who leads without being a manager: how technical influence is exercised without authority over people. Straight to the heart of this lesson.
• L. David Marquet — Turn the Ship Around! — the submarine captain who stopped giving orders and started "giving intent", multiplying leadership throughout the crew. The extreme case —even with formal authority, commanding is worse than enabling— that anchors the module.
• Martin Fowler — "Who Needs an Architect?" (IEEE Software, 2003) — the classic essay where Fowler portrays the architect who teaches and enables (Architectus Oryzus) against the one who dictates; the root of the idea that the architect leads by influencing, not commanding.