The Architect's Way of Empowerment: How to Make Teams Smarter

The highest good is like water—water benefits all things and does not contend. — Tao Te Ching

The true architect is like water: not standing on high to issue orders, but flowing through every level of the organization, bridging the fractures and filling the gaps. They do not seek to be the smartest person in the room; they seek to make everyone smarter. This ripple effect of empowerment ultimately gathers into the force that moves the entire system forward.

This is a summary of the NDC talk Thinking like an Architect (https://www.youtube.com/watch?v=xtxfrxf0mfE) that I watched several months ago. Claude Code wrote the first draft; I handled review and added more perspectives.

Introduction: What Exactly Is an Architect?

At technical conferences we talk about architecture all the time—distributed systems, decoupled design, patterns and principles of every kind. We think we understand what architecture is, but if you ask three different people “what is architecture?” you will very likely get three completely different answers.

More interesting still: when we turn our gaze to the role of the “architect,” the confusion becomes even more pronounced. What exactly is an architect? Is it a title on a business card? Is it the person who makes all the decisions? Is it the one who is smarter, more experienced, and greyer at the temples than everyone else?

Let us begin with a fundamental misunderstanding: the architect is supposed to be the one who makes decisions.

On the surface this seems reasonable—architects usually have more experience and a broader view. But think a little more and the problem emerges: aren’t the people on the front line, the ones who must live with the consequences of a decision, better positioned to make it? An “oracle” sitting somewhere else, no matter how brilliant, can never possess the contextual understanding that team members have.

The Core Idea: From Decision-Maker to Enabler

If architects shouldn’t make decisions for the team, what should they do? The answer is both simple and profound: help the team make better decisions, and make them smarter.

What does this shift mean? Imagine a scene like this:

This is not merely a change in how one works; it is a fundamental shift in values. The architect becomes an enabler—their value lies not in how great their personal intelligence is, but in how many people they can make more intelligent. This multiplier effect ultimately produces an avalanche of positive impact.

The First Dimension: Cross-Layer Thinking—Connecting the Organization’s Levels

A large organization is like a skyscraper, with different people working on different floors:

• Penthouse: the board and executive layer, setting strategic decisions
• Middle Floors: middle management, responsible for coordinating and communicating
• Engine Room: the development teams, actually building the system

The problem is that these floors are often disconnected.

This kind of “loose coupling” makes everyone look satisfied, but it is catastrophic for the organization. The development team may be working on something with no relation whatsoever to company strategy, while the strategy set at the top may be technically impossible to implement.

The Architect’s Cross-Layer Ability

An architect’s value lies not in how high their rank is, but in how many levels they can connect. Architects need to move fluidly between the organization’s different levels, understanding each layer’s language, constraints, and goals.

But here is a key principle: the architect does not exist to speak like a native at every level—telling people at each level whatever they want to hear. The architect’s true value is in translation and connection:

• Translating technical constraints into business impact
• Translating business requirements into technical requirements
• Helping each layer understand the real situation of the others

Have you ever wondered why architects should write code? Not to produce code efficiently, but to stay connected to reality. It’s like digging a tunnel: if the two ends aren’t aligned, no amount of digging speed will help. Architects need to pick up the shovel now and then, feel the direction of the tunnel, and make sure the two ends will actually meet.

The Second Dimension: Metaphor—Making Complexity Simple

The technical world we face is extraordinarily complex: distributed, cloud-native, event-driven, asynchronous, machine learning… To non-technical people these concepts are like a sealed book. You can’t walk up to an executive and say, “I need more funding to configure a Jaeger tracing system for our Kubernetes cluster”—they’ll just stare at you blankly.

Metaphors in Practice

Let’s look at a few powerful metaphors:

1. The Car Metaphor Series

Leaky abstraction: Americans call the accelerator pedal the “gas pedal”—a terrible abstraction, since electric cars have no gas. A better abstraction is “accelerator,” which describes the function rather than the implementation.

// Good abstraction: describes intent, not implementation
trait Accelerator {
    fn increase_speed(&mut self, amount: f32);
}

// Bad abstraction: exposes implementation details
trait GasPedal {
    fn inject_more_fuel(&mut self);
}

Platform thinking: the concept of a car platform—multiple models sharing the same chassis and core components. This is a perfect analogy for the value of a software platform.

Halo products: some cloud services are like the Yangwang U8—everyone loves it, but the provider’s real revenue comes from practical services like the “Qin Plus” and the “Han.”

2. The Train Metaphor: Automatic Correction vs. Hard Limits

How do train wheels stay on the tracks? Not because of the flanges, but because the conical design of the wheel keeps it automatically centered. The lesson for us:

Architectural insight: don’t just set up “guardrails” (hard limits); also provide “lane assist” (automatic guidance mechanisms). For example:

• Not just code review (guardrails), but also auto-formatting and powerful linters (lane assist)
• Not just rollback on deployment failure (guardrails), but also continuous health checks and automated testing (lane assist)

3. The Steam Engine Metaphor: The Nature of Transformation

When traditional companies see agile competitors, their first reaction is to “burn more coal”—more overtime, more pressure, more people. But this only leads to a “boiler explosion.” True transformation requires replacing the engine—swapping the steam engine for an electric motor.

The Deep Value of Metaphor

Metaphors are not cute little stories or rhetorical flourishes. Their real value is this: they let the audience reason within a domain they already understand, and arrive at the same conclusion.

When you say, “we need lane assist, not just guardrails,” even an executive with a non-technical background immediately understands: prevention beats remediation, and continuous small adjustments beat a big crash at the end. They may even draw the conclusion themselves: “Then we should be investing in automated testing and continuous integration!”

The Third Dimension: Multidimensional Perspective—The Architect’s Superpower

Imagine a simple architecture diagram: four boxes, three lines. An ordinary person sees four boxes and three lines. But what does an architect see?

• Layered architecture: the embodiment of separation of concerns
• Dependencies: the degree of coupling between components
• Replaceability: each layer can evolve independently
• Performance impact: each added layer has overhead
• Change propagation: how modifications travel between layers

We can discuss this simple diagram for 20 minutes! This is the architect’s unique perspective—seeing complexity in simplicity, and simplicity in complexity.

Multidimensional Thinking: Breaking the Binary Opposition

In reality, arguments like this come up constantly:

• “We should shorten the project timeline!”
• “But we can’t sacrifice quality!”

Each side digs in and they never reach agreement. Why? Because they are thinking in one dimension—time and quality are seen as opposite ends.

The architect’s value lies in introducing new dimensions:

• Time and quality are not opposed: with test-driven development, you can improve both speed and quality at once
• Cost and performance are not opposed: with better algorithms, you can achieve better performance with fewer resources

A Multidimensional Analysis of Lock-In

Let’s look at a concrete example: the “lock-in” problem with cloud services.

The conventional view: using cloud services locks you in, and that’s dangerous.

The architect’s multidimensional perspective:

Key insights:

1. Lock-in is everywhere: even open-source software has version lock-in (remember the pain of Python 2 to 3?)
2. Mental lock-in is the most dangerous: once you start thinking about architecture in your vendor’s terminology, you’re already locked in
3. Lock-in is a manageable risk: the key is to understand the risk and make sensible trade-offs

The Fourth Dimension: Reinforcing the Middle Argument—The Architect’s Art

When faced with a requirement like “we need an API management standard,” an architect’s first reaction is not to pick a tool, but to decompose the problem:

• Does that include message queues?
• Do event streams count?
• Are synchronous and asynchronous APIs the same thing?
• Do internal and external APIs need the same governance?

Through decomposition, one decision becomes several independent decisions, and the solution space expands dramatically.

The Architect’s Tracing Mindset

This is a powerful mode of thought—trace back to the root, then return to the solution:

The key is: don’t just step back and analyze—come back and provide a solution. Otherwise you’ll be labeled “too academic.”

Reinforcing the Middle Argument

Many technical proposals follow this pattern:

1. A pile of buzzwords and promises (“AI-powered cloud-native microservices”)
2. A vague middle section (“and then… magic happens”)
3. Enormous resource demands (“we need 10 people and a budget of a million”)

The architect’s job is to reinforce the middle—to build a logical chain from problem to solution.

The Fifth Dimension: Learning Architecture from the Real World—An Architect’s Required Course

Starbucks as a Distributed System

Starbucks doesn’t use two-phase commit! Their system looks like this:

// Starbucks' asynchronous processing model
struct CoffeeShopSystem {
    order_queue: Queue<Order>,
    payment_processor: PaymentService,
    barista_pool: Vec<Barista>,
}

impl CoffeeShopSystem {
    async fn process_order(&mut self, order: Order) {
        // Process payment and preparation in parallel
        let payment_future = self.payment_processor.process(order.payment);
        let coffee_future = self.make_coffee(order.items);

        // Start making the drink without waiting for payment to complete
        tokio::join!(payment_future, coffee_future);
    }

    fn apply_backpressure(&mut self) {
        // When downstream is under pressure, the cashier chats more
        // to slow the input rate and avoid queue overflow
        if self.order_queue.len() > THRESHOLD {
            self.cashier.be_more_chatty();
        }
    }
}

Architectural insights:

• Asynchronous processing raises throughput
• Queues decouple components
• Backpressure prevents system overload

The Ordering Guarantee Problem at the Supermarket Queue

Standing in a supermarket queue, you come to realize: ordered message delivery is extremely expensive.

Why don’t cloud services guarantee message ordering? Just look at the supermarket:

This is precisely why systems like Kafka use partitions—to find a balance between ordering and performance.

Architectural Insights from Elevator Systems

Observing the elevator system in a building, we can find much of the essence of architectural design:

• Priority scheduling: certain floors (like the lobby) have higher priority
• Batching: the elevator waits to collect multiple requests
• Load balancing: multiple elevators intelligently distribute tasks

These are all core concepts of distributed systems!

A Practical Guide: How to Cultivate Architectural Thinking

1. Practice Cross-Layer Communication

Challenge: explain the same technical decision in three different ways:

• To a developer: technical details and implementation impact
• To a product manager: feature and user-experience impact
• To an executive: business value and risk

Example exercise: explain why we should migrate to a microservices architecture

To a developer: “Microservices let us deploy and scale each component independently, use the most appropriate tech stack, and reduce the cognitive load of the codebase.”

To a product manager: “Microservices let us ship new features faster, make A/B testing easier, and a problem in one feature won’t affect the whole system.”

To an executive: “Microservices reduce time-to-market, improve system reliability, let teams work in parallel, and accelerate innovation.”

2. Build Your Metaphor Library

Pick a domain you know well (cooking, gardening, architecture, music) and practice using it to explain technical concepts:

• Cooking: batch processing is like preparing a banquet; stream processing is like running a restaurant
• Gardening: technical debt is like weeds; it needs regular weeding
• Music: microservices are like a jazz band, where each player can improvise but must stay in harmony

3. Multidimensional Analysis Practice

With any technical decision, ask yourself:

1. Which dimensions does this decision affect? (performance, cost, complexity, maintainability)
2. Are these dimensions really opposed?
3. Can I introduce a new dimension to break the deadlock?

4. Real-World Observation

Each day, pick one everyday scene and look for architectural patterns:

• Elevators: request scheduling and priority
• Traffic signals: synchronous vs. asynchronous coordination
• Restaurants: pipeline processing and batching
• Libraries: caching and indexing strategies

5. Practice the Tracing Mindset

The next time you receive a requirement:

The Three Realms of the Architect

The First Realm: Technical Expert

At this stage, the architect focuses on:

• Choosing the right tech stack
• Designing elegant systems
• Solving complex technical problems

This is the necessary foundation, but it is not enough.

The Second Realm: Connector

The architect begins to:

• Move between the organization’s levels
• Translate between technical and business language
• Build shared understanding

Now the architect’s influence begins to expand.

The Third Realm: Team Enabler

The highest realm of the architect:

• Doesn’t pursue personal brilliance, but makes the team brilliant
• Doesn’t make every decision, but helps others make better ones
• Doesn’t provide answers, but provides frameworks for thinking

// The three realms expressed in code
trait ArchitectEvolution {
    // First realm: technical expert
    fn solve_technical_problem(&self) -> Solution;

    // Second realm: connector
    fn translate_between_domains(&self, tech: Technical, biz: Business) -> SharedUnderstanding;

    // Third realm: team enabler
    fn amplify_team_intelligence(&self, team: &mut Team) -> ImprovedDecisionMaking {
        team.provide_multiple_perspectives();
        team.expand_solution_space();
        team.see_more_dimensions();
        team.make_better_decisions()
    }
}

Deep Reflection: The Architect’s Philosophical Propositions

1. The Balance Between Control and Delegation

Have you ever wondered: why do some architects fill a team with vitality, while others drain its motivation?

The key is to understand: control the architecture, not the people. Define clear boundaries and interfaces, but let the team play freely within those boundaries. It’s like an urban planner designing the road network without dictating the route of every car.

2. The Trade-Off Between Simplicity and Completeness

“Should we build a complete solution, or a simple one?”

The architect’s wisdom lies in recognizing: simplicity is not the absence of features; it is the well-organized handling of complexity. The best architectures are often those that look simple but can gracefully handle complex scenarios.

3. A Bridge Between Present and Future

How do you find the balance between “meeting current needs” and “leaving room for the future”?

Remember: over-design and under-design are both risks. The architect’s art is in identifying which decisions are hard to change (get them right now) and which can be deferred (keep your options open).

Case Studies: Turning Theory into Practice

Case 1: An Empowering Approach to a Microservices Migration

A team wants to migrate a monolith to microservices. A traditional architect might say, “Following domain-driven design, we should split it like this…”

An empowering architect would do this:

Provide multiple perspectives:

• Technical: module boundaries, data consistency, network latency
• Organizational: team structure, communication cost, ownership boundaries
• Business: release cadence, feature independence, scaling needs

Use metaphor: “Think of the monolith as a big shopping mall, and microservices as independent specialty stores. The mall is convenient but inflexible; the specialty stores are flexible but require more coordination.”

Expand the option space:

• Option A: full migration to microservices
• Option B: modular monolith
• Option C: progressive extraction (Strangler Fig Pattern)
• Option D: hybrid architecture (core monolith + satellite services)

Let the team take part in the decision: organize a workshop where team members, based on these perspectives and options, decide together on the most suitable path.

Case 2: Tracing Thinking in Technology Selection

The team says, “We need to use GraphQL!”

The tracing process:

Result: the team understands the many choices and makes a more balanced decision.

The Architect’s Daily Practice

Morning Ritual: Multidimensional Thinking Exercise

Each morning, pick a problem you encountered yesterday and ask yourself:

1. How would this problem manifest if it happened at a different level?
2. What metaphor could explain it?
3. Which dimensions does this problem involve? Which dimensions are being ignored?

Midday Reflection: Connection Exercise

Over lunch, review the morning’s meetings and discussions:

• Where were the moments of “talking past each other”?
• How could I better translate between different domains’ languages?
• Which metaphors could help build shared understanding?

Evening Review: Evaluating Your Empowerment Impact

At the end of the day, evaluate your empowerment impact:

• How many decisions did I make today? (the fewer the better)
• How many better decisions did I help others make today? (the more the better)
• Did the team become smarter because of my involvement?

Conclusion: The Wisdom of Water

Back to the Daoist wisdom from the opening: the highest good is like water.

Water does not try to become the highest mountain; it flows to the lowest places, connecting every space. Water does not forcibly change the terrain; it follows the terrain while quietly shaping it. Water looks soft, yet it can wear through stone and break walls.

This is the highest realm of the architect:

• Non-contention: does not fight for decision-making power, but empowers others
• Benefiting all: makes every person and system it touches better
• Connection: flows through every level of the organization like water
• Adaptation: changes form according to the environment while keeping its essence
• Persistence: generates enormous long-term change through continual small influence

The next time you face an architectural challenge, ask yourself:

Am I trying to be the smartest person, or am I making everyone smarter?

Am I building high walls, or am I building bridges?

Am I providing answers, or am I providing frameworks for thinking?

Remember, truly great architects are not those who make every decision, but those who enable everyone to make better decisions. They are the organization’s enablers, the bridges across fractures, the translators who make complexity simple.

In this era of ceaselessly changing technology, we don’t need more decision-makers; we need more enablers. We don’t need more heroes; we need more gardeners—those who can make the whole ecosystem flourish.

Three Questions Worth Pondering

Before you set out to put these ideas into practice, consider these three questions:

1. In your organization, which “tunnels” are misaligned? What can you do to make sure they eventually meet?

2. What are your most-used metaphors? Do they genuinely aid understanding, or do they add confusion?

3. When was the last time you helped someone make a better decision than you could have? How did that feel?

The art of architecture is not in building perfect systems, but in building systems that keep evolving. An architect’s value is not in personal excellence, but in the team’s excellence.

Let us all be team enablers rather than domineering decision-makers. Let us all be connectors rather than isolators. Let us all be inspirers rather than controllers.

This is the architect’s way—flowing like water, illuminating like light, accelerating reaction like a catalyst, yet never changing its own essence.

May you be the one who makes the team smarter.