Enabling, not dictating

Overview

Lesson 4 established the real architect's first verb: they make expensive decisions reversible and communicate their why. This lesson installs the second, which is even more counterintuitive for whoever imagines the architect as an authority: the real architect enables the team instead of dictating to it. They're not the one who decides for the squads; they're the one who puts them in a position to decide well for themselves. The false image it takes apart is the dictator: the architect as technical boss through whose approval every decision passes, who tells each squad what to do and how. The real image is the gardener: someone who doesn't grow the plants by hand —the plant does that— but prepares the soil, sets the stakes, guarantees the water and light, and lets each plant grow strong on its own within those conditions.

The concrete instrument of enabling is guardrails: clear limits within which a squad can decide without consulting. "Use REST for internal communication, Postgres as the store, and meet these SLOs" is a guardrail. With it, the catalog squad can make hundreds of decisions —how it structures its tables, how it organizes its code, which libraries it uses— without asking the architect anything, because it knows that as long as it stays in the lane, it's fine. The architect didn't decide those hundreds of things; they decided the lane, and the lane decided for them. This lesson measures the effect: over a typical Mercado week, how many decisions the squads can resolve alone when the architect enables, against the model where everything passes through them.

Connection with the module. It's the second of the three lessons that define the architect by what they do (reversibility in lesson 4, enabling here, not being a bottleneck in lesson 6). And it's the bridge between the two: enabling is how the architect avoids becoming the bottleneck lesson 6 will measure in its sharpest form. It also connects forward with the ecosystem: the idea of guardrails and enabled teams is the heart of Team Topologies (Skelton and Pais), which module 2 (Conway) uses in depth with its team types —stream-aligned, platform, enabling—. Watch the frontier: the detailed restructuring of the teams and the full org↔architecture dynamic is module 2; leadership without authority in depth —how to influence, disagree and commit— is module 4. Here we install only the principle of the role: the architect enables with guardrails instead of dictating decision by decision.

An analogy: the gardener and the one who plants by hand

Imagine two people in charge of a large garden, with many beds.

The one who wants to plant every plant by hand. They believe that, since they're the expert, they must control every plant: where exactly it goes, how much water it gets today, at what angle they prune it. They walk the garden plant by plant, deciding every detail themselves. With ten plants it might work. With five hundred, it's impossible: the plants they didn't get to tend wither waiting for their decision, they work exhausted unable to keep up, and the garden grows crooked because no one else has permission to decide anything without them. Worse: the helpers, who could tend their beds perfectly, become passive —"why decide, if they're going to redo it their way"— and wait for instructions on everything. The expert became the garden's ceiling: nothing grows beyond what they personally get to touch.

The real gardener. They know they can't —and shouldn't— plant every plant by hand. Their work is different: prepare the soil well, install the irrigation system, put stakes where the young plants need them, define what goes in the sun zone and what in the shade. And then trust that each plant, in the good conditions they created, grows on its own. The helpers tend their beds with autonomy, because the gardener gave them the frame —"this zone is sun, water every two days, prune in spring"— and within it they decide alone. The gardener intervenes little and on what matters: a pest problem crossing the whole garden, a redesign of the irrigation. The garden flourishes more than with the one who plants by hand, precisely because the gardener isn't the funnel every plant passes through.

The point: the one who plants by hand confuses their experience with the obligation to decide everything; the gardener uses their experience to create the conditions in which others decide well. The real architect is the gardener. Their experience doesn't give them the obligation to decide everything for the five squads; it gives them the ability to set the guardrails —the soil, the irrigation, the stakes— within which each squad decides its own with autonomy. Dictating is planting by hand and not scaling beyond one person; enabling is preparing the garden to flourish without you in every bed. This lesson measures how much Mercado flourishes under each model.

Worked example: how many decisions each squad can resolve alone

In a typical week, Mercado's five squads generate decisions: how to structure a table, which library to use, how to name an endpoint, how to handle an edge case. The vast majority are local —they live within a squad—. A few cross squads and are architect-level (we saw it in lesson 1). This lesson's question: under the gardener model, how many of those decisions can each squad resolve alone, without passing through the architect?

# The gardener architect sets GUARDRAILS (clear limits: "internal REST,
# postgres, these SLOs") and lets each squad decide within. The dictator demands
# that EVERY decision pass through them. We measure, over a typical Mercado week,
# how many decisions each squad can resolve ALONE (self-serve) and how many
# cross squads and really go up to the architect.
WEEKLY_DECISIONS = {
    # squad -> (total_decisions, cross_team_decisions)
    "catalog":  (12, 1),
    "orders":   (10, 2),
    "payments": (8, 1),
    "shipping": (9, 1),
    "platform": (7, 2),
}

total = sum(t for t, _ in WEEKLY_DECISIONS.values())
cross = sum(c for _, c in WEEKLY_DECISIONS.values())
local = total - cross

print(f"{'squad':<10}{'decisions':>11}{'cross_team':>12}{'self-serve':>12}")
print("-" * 45)
for squad, (t, c) in WEEKLY_DECISIONS.items():
    print(f"{squad:<10}{t:>11}{c:>12}{t - c:>12}")
print("-" * 45)
print(f"{'TOTAL':<10}{total:>11}{cross:>12}{local:>12}")

print()
print(f"Dictator model: the {total} decisions wait for the architect.")
print(f"Gardener model: {local} are decided by the squads alone ({round(100 * local / total)}%);")
print(f"only {cross} cross squads and go up to the architect ({round(100 * cross / total)}%).")
print("Enabling isn't letting go of the helm: it's setting guardrails and returning")
print("the local decision to whoever is closest to the problem.")

What to expect. Running the file, the output is exactly this:

squad       decisions  cross_team  self-serve
---------------------------------------------
catalog            12           1          11
orders             10           2           8
payments            8           1           7
shipping            9           1           8
platform            7           2           5
---------------------------------------------
TOTAL              46           7          39

Dictator model: the 46 decisions wait for the architect.
Gardener model: 39 are decided by the squads alone (85%);
only 7 cross squads and go up to the architect (15%).
Enabling isn't letting go of the helm: it's setting guardrails and returning
the local decision to whoever is closest to the problem.

Read the two totals at the bottom, because the lesson's argument is in them.

In a typical week, the five squads generate 46 decisions. Under the dictator model, all 46 wait for the architect: every table, every library, every endpoint has to pass through their approval. Under the gardener model, the squad decides alone the ones that fall within its guardrails —39 decisions, 85%— and only the 7 that cross squads (15%) really go up to the architect. The same week, the same work, but in one model the architect is the mandatory step for 46 decisions and in the other they touch 7.

Notice what this means for the architect and for the squads. For the architect: going from 46 to 7 isn't "working less"; it's working on what matters. The 7 that go up are the architect-level ones —the contracts between squads, the quality attributes, the service limits— exactly where their cross-cutting view contributes something no squad has. The 39 they let go were decisions the squads can make better than them, because they're closer to the problem: the catalog squad knows better than anyone how to structure its catalog tables. Dictating those 39 not only drowns the architect; it produces worse decisions, because they're made by someone farther from the ground.

For the squads, the effect is even deeper. Under the dictator, the squads become passive —the garden of helpers waiting for instructions—: they don't develop their own judgment because they never decide, and every block stops them. Under the gardener, with clear guardrails, the squads decide with autonomy, develop judgment, and move forward without friction. The architect who enables doesn't just free themselves; they make the squads more capable. That's the deepest sense of "enabling": it's not delegating tasks, it's building the capacity to decide in whoever is closest to the problem.

And a phrase to nail the nuance the output repeats: enabling isn't letting go of the helm. The gardener architect doesn't disappear or say "decide whatever you want". They set guardrails —"internal REST, Postgres, these SLOs"—, which are precise and firm architect-level decisions, and within them they return the autonomy. The squads' freedom exists thanks to the clear limits, not despite them. A garden with no prepared soil or irrigation isn't free; it's a wasteland. The guardrail is what makes autonomy possible.

As bars, the split is emphatic:

46 decisions/week: who decides them
 self-serve (squads) |###################  39   (85%)
 to the architect     |###                   7   (15%)
                       ─────────────────────
 the gardener touches 15%; the dictator, 100%.

Deep dive: what a good guardrail is (and what it isn't)

The gardener model lives or dies by the quality of the guardrails. A good guardrail enables; a bad one, or dictation disguised as a guardrail, drowns just as much as direct control. It's worth understanding the difference, because it's where many architects who "want to enable" fail.

A good guardrail defines the what, not the how. "Meet these latency and availability SLOs" is a guardrail: it says the result that matters (the quality attribute) and lets the squad choose how to achieve it. "Use exactly this cache library with this configuration" isn't a guardrail; it's an instruction, and it takes from the squad the decision it knows how to make better than the architect. The good guardrail puts the boundary where the decision stops being local —where it starts to affect others— and not a centimeter before. Everything that stays within that boundary is the squad's.

A good guardrail is clear and stable. The squad has to be able to know, without asking, whether its decision is inside or outside the lane. An ambiguous guardrail ("do things well, with quality") doesn't enable, because the squad doesn't know if it's inside, so it ends up asking —and we're back to the bottleneck—. A guardrail that changes every week doesn't enable either, because the squad can't rely on it. Good guardrails are few, clear, and durable: "internal REST, Postgres as the primary store, these SLOs, authentication with the shared token". With those four, the payments squad can make dozens of decisions knowing exactly when it's inside.

A good guardrail explains its why. A guardrail imposed without reason ("because I say so") feels like dictatorship, and the squads go around it as soon as they can. A guardrail with its why ("internal REST so any squad can integrate without coordinating with us; Postgres because we already have the operations and knowledge") feels like what it is —a well-founded architect-level decision— and the squads respect it because they understand it. Here the "why that travels" of lesson 4 reappears: the guardrail also carries its reason.

The flip side: when the guardrail becomes disguised dictation. If the architect sets so many guardrails, so detailed, that the squad has no real decision to make within them, they're not enabling: they're dictating under another name. The test is simple: does the squad have genuine decision space within the lane? If the guardrail says "use REST", there's space left (how you design your endpoints, your resources, your versioning). If the guardrail says "use REST with these exact endpoints, these names, this response structure", there's no space left: it's the ivory tower painted as enablement. The gardener prepares the soil; they don't draw where each root goes.

A note on trust. Enabling demands a muscle many architects find hard: tolerating that a squad decides differently from how they would have, and that it's fine. The dictator can't stand this —"I would have done it better"— and so reopens every decision, which teaches the squads their autonomy is false. The gardener accepts that a plant grows a little differently from how they imagined it, as long as it's healthy and in the right zone. If the squad's decision is within the guardrails and works, that it's different from the architect's preference is not a problem to fix; it's autonomy working. The architect who only tolerates decisions identical to their own doesn't enable; they clone. And a team of clones with no judgment of their own is fragile: it collapses the day the architect isn't there.

Common mistakes

Approving every decision "so it turns out well" (the dictator). What happens: the architect demands that every technical decision from the squads pass through their review and sign-off, convinced that's how they guarantee quality. Why it happens: they confuse "the architect-level decisions turning out well" with "me approving all the decisions", and their experience makes them feel they'd decide each one better. How to spot it: if the 46 decisions of the week wait for their approval, or if the squads say "we're waiting for the architect's OK" for local things, it's a dictator. How to fix it: separate the few architect-level ones (the 7 that cross squads) from the many local ones (the 39), set clear guardrails so the squads decide the local ones alone, and get into only the 7. Quality doesn't come from the architect approving everything; it comes from good guardrails plus capable squads —and from local decisions being made by whoever is closest to the problem—.

Confusing enabling with abandoning. What happens: the architect, on hearing "don't dictate", goes to the other extreme and disappears —"decide whatever you want"— without setting any guardrail, and the squads end up making architect-level decisions (contracts between services, cross-cutting technology choices) each on their own, without coherence. Why it happens: they interpret "enabling" as "being absent", when it's the opposite —enabling is active work of creating conditions—. How to spot it: if each squad chose incompatible technologies, or if the contracts between services are chaos because no one held the cross-cutting view, the architect abandoned instead of enabled. How to fix it: remember that enabling isn't letting go of the helm: it's setting firm guardrails (the architect-level decisions they do make) and within them returning the autonomy. The gardener prepares the soil and irrigation; they don't leave the garden.

Setting guardrails so detailed they leave nothing to decide. What happens: the architect believes they enable because "I gave them a frame", but the frame is so minute that the squad has no real decision within it —every endpoint, every name, every structure is already dictated—. Why it happens: they want the dictator's control but with the enablement label, so they package the instructions as "guardrails". How to spot it: if within the "guardrail" the squad has no genuine decision space, or if the squad feels it only executes orders under another name, the guardrail is disguised dictation. How to fix it: put the guardrail where the decision stops being local (affects others) and not a centimeter before; define the what (the result, the quality attribute) and leave the how to the squad. The test: does the squad have a real decision within the lane? If not, it's not a guardrail; it's a cage.

Exercises

Exercise 1 — Guardrail or dictation? For each of these directions a Mercado architect gives the squads, say whether it's a good guardrail (enables) or disguised dictation (drowns), and why: (a) "all internal services communicate over REST"; (b) "the catalog endpoint must be named exactly /v2/catalog/items and return these 14 fields in this order"; (c) "every service must meet an SLO of 99.9% availability and under 200ms p99 latency"; (d) "use the logging library I chose, configured exactly this way, no changes".

See solution

• (a) Good guardrail. It defines the what (REST for internal communication) and leaves the how to each squad (how it designs its resources, its versioning, its responses). It puts the boundary where the decision affects others —interoperability between services— and leaves the rest open. It enables.
• (b) Disguised dictation. It leaves no real decision to the catalog squad: the exact name, the fields, the order, everything is fixed. It's the ivory tower painted as a guardrail. Unless that endpoint is a public contract consumed by many (where the detail does matter to others), this drowns. The catalog squad knows better than the architect how to structure its resource.
• (c) Good guardrail, of the best kind. It defines the result that matters (the quality attribute: availability and latency) and leaves the how to achieve it completely open. The squad can choose cache, replicas, whatever, as long as it meets the SLO. It's the ideal guardrail: firm on the what, free on the how.
• (d) Disguised dictation. "Configured exactly this way, no changes" leaves no decision. An enabling guardrail would be "emit structured logs in JSON with these minimum fields so cross-cutting observability works" —it defines the what (log interoperability) and lets the squad choose the library and the rest—. Fixing the library and its exact config is control, not enablement.

Exercise 2 — The architect who doesn't tolerate the different. A Mercado architect set good guardrails, but every time a squad decides something within the lane in a way different from how they would have done it, they reopen the decision and change it to their preference. Explain why, even though the guardrails were good, this architect is still dictating, and what this teaches the squads.

See solution

The guardrails were good on paper, but by reopening every decision that stays within them, the architect empties the autonomy of content. A guardrail only enables if the squad can trust that, as long as it stays in the lane, its decision is respected. If the architect changes decisions that were already within the lane just because they'd have done them differently, the guardrail is an illusion: the real decision boundary isn't the lane, it's "whatever the architect thinks". That's dictating, with guardrails as decor.

What this teaches the squads is devastating to their capacity: they learn that their autonomy is false, that deciding is useless because the architect will redo it, and that the safe thing is to ask before deciding —or not decide at all—. They become passive, the garden of helpers waiting for instructions. And the architect, without realizing it, rebuilt the bottleneck the guardrails were meant to eliminate: if every decision can be reopened by them, every decision, in practice, passes through them again.

The correction is the trust muscle the lesson describes: tolerating that a squad decides differently and that it's fine, as long as the decision is within the guardrails and works. That it's different from their preference isn't a defect to fix; it's autonomy working. The gardener accepts that the plant grows a little its own way. The architect who only tolerates clones of their own decisions doesn't enable; they produce a team with no judgment that collapses the day they're not there.

Exercise 3 — From dictator to gardener, concretely. A Mercado architect personally reviews and approves the five squads' 46 weekly decisions, and is exhausted. They want to move to the gardener model. Describe the concrete steps they'd take to get from the 46 to the 7, without falling into the other extreme (abandoning).

See solution

A concrete path:

1. Classify the 46 by level. Apply lesson 1's criterion: which cross squads, are expensive to revert, wide radius (architect-level), and which are local? The example suggests only about 7 are architect-level; the remaining 39 are local. This diagnosis is the starting point —you can't let go of what you haven't identified as lettable-go—.

2. Write the guardrails that cover the 39 local ones. For each type of recurring local decision, define the lane within which the squad decides alone: "internal communication over REST", "Postgres as the primary store", "these SLOs", "logs in JSON with these fields", "authentication with the shared token". Few, clear, stable, with their why. These guardrails are the architect-level decisions they do make —they're not abandoning; they're deciding the frame—.

3. Communicate the handoff explicitly. Tell the squads: "from now on, as long as you stay within these guardrails, you decide alone and don't need my approval; only bring up what crosses squads or leaves the lane". Without this communication, the squads will keep asking out of habit.

4. Tolerate and sustain. When a squad decides something local differently from how they'd do it, don't reopen it if it's within the lane and works (the exercise 2 muscle). And sustain the guardrails: if a squad leaves the lane, there they do intervene —but to reinforce the boundary, not to dictate within it—.

The result is going from touching 46 to touching 7, without abandoning: the 39 weren't left ungoverned, they were governed by guardrails instead of case-by-case approval. The difference between the gardener and the one who abandons is exactly step 2: the gardener prepares the soil (the guardrails); the one who abandons leaves without preparing it. (The deeper form of this redesign —how to structure the teams themselves so the desired architecture emerges— is the inverse Conway maneuver of module 2.)

Summary and next step

In this lesson you installed the real architect's second verb: enable, not dictate. You saw, with the gardener against the one who plants by hand, that confusing one's own experience with the obligation to decide everything doesn't scale beyond one person and makes the squads passive, while using that experience to create conditions —guardrails— makes the whole team flourish. And you measured it: of 46 weekly decisions, the gardener model lets the squads resolve 85% alone and takes to the architect only the 15% that crosses squads. Enabling isn't letting go of the helm: it's setting firm guardrails (the what, with its why) and returning the local decision (the how) to whoever is closest to the problem —which also produces better decisions and more capable squads—.

Before moving on you should be able to: explain why the dictator model doesn't scale and what it does to the squads' capacity; distinguish a good guardrail (defines the what, clear, stable, with why) from disguised dictation (fixes the how, leaves nothing to decide); and recognize the muscle of tolerating decisions different from one's own as part of enabling.

Lesson 6 takes this to its measured conclusion. If the architect does not enable —if they insist everything passes through them— they don't just produce passive squads: they become a bottleneck whose waiting queue grows without end. We'll execute the module's marquee simulation: what happens to Mercado's decisions when the 46 weekly ones pass through a single architect with limited capacity, against the distributed model. The cost of coordination, measured in accumulated wait time, with a number that admits no argument.

Resources

• Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019) — the framework of enabling teams and platforms as products that provide "paved roads" (guardrails). It's the conceptual source of this lesson; module 2 uses it in depth. In English.
• Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. Fowler's "Architectus Oryzus" —the one who mentors and enables— against the one who decides everything, is exactly the gardener against the dictator. In English.
• Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020), on the architect as the one who "sells options" and multiplies the team instead of being the only one who decides. In English.
• Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd ed. (O'Reilly, 2020), ch. 21–22 on architect effectiveness and leading technical teams: guiding by principles and guardrails instead of by direct control. In English.