Decentralized Architecture Needs More Than Autonomy

Introduction: Beyond the Illusion of Autonomy

Decentralized architecture is often celebrated as a technical design choice – service boundaries, team APIs, infrastructure independence. But autonomy on paper doesn’t guarantee alignment in practice.

When architecture becomes distributed, the challenge isn’t just how the system is designed – it’s how decisions get made, shared, and trusted across teams.

In my organization, that reality became clear as we grew rapidly and integrated multiple newly acquired companies.

Teams were empowered in theory, but still struggled in practice. Architects became bottlenecks. Developers either waited for permission or made decisions in isolation. Autonomy existed, but confidence didn’t.

Reading Facilitating Software Architecture by Andrew Harmel-Law gave me language – and a path – for addressing that gap.

The book offers lightweight, trust-based practices like the Architecture Advice Process, Architectural Decision Records (ADRs), and Advice Forums that help organizations build technical alignment without falling back on centralized control.

This article reflects my personal interpretation of Facilitating Software Architecture by Andrew Harmel-Law (2023), as applied in a real-world, post-acquisition engineering context.

This article shares how we’ve started applying those ideas inside a real, multi-team engineering environment. It’s not a success story – it’s a reflection on what happens when you try to shift from control to trust, from approval to advice, from isolation to visibility.

What follows is a set of lessons, tools, and cultural shifts that have helped us evolve toward a more resilient, decentralized architecture – one where autonomy is earned through shared understanding, not just granted by org charts.

The Real Problem: Decision-Making at Scale

Decentralized architecture isn’t just a matter of system design – it’s a question of how decisions get made, by whom, and under what conditions. In theory, decentralization empowers teams. In practice, it often exposes a hidden weakness: decision-making doesn’t scale easily.

We started to feel the cracks as our teams expanded quickly and our organizational landscape became more complex. As teams multiplied, architectural alignment started to suffer – not because people didn’t care, but because they didn’t know how or when to engage in architectural decision-making. Architects became bottlenecks, and developers either waited for direction or made isolated decisions that introduced long-term friction.

This problem starts earlier than many realize. Every architectural decision passes through three stages, using a simple three-stage model we found helpful:

1. A decision is required – recognizing that a choice needs to be made
2. The decision happens – evaluating options and selecting one
3. The decision is implemented – putting the decision into practice

That first stage – recognizing the decision point – is frequently missed. Too often, only one “obvious” path is presented, and the opportunity to generate or compare alternatives is skipped entirely. This makes architecture feel opaque and disempowering, especially when options are decided behind closed doors.

Even when teams do recognize a decision point, scaling the decision process across groups adds complexity. There’s no one-size-fits-all approach. What we realized is that decentralization isn’t the goal – it’s the constraint. The real objective is to make good decisions quickly, with the right people involved. That means being intentional about:

• Who can initiate, make, and implement decisions
• How we surface and compare options
• When to involve input – and from whom

Without that structure, autonomy becomes a liability.

This insight became the turning point for us. Recognizing that our decision-making model – not our tech stack – was limiting our velocity led us to adopt new practices that supported distributed decision-making without losing coherence. The first step was replacing permission-seeking with advice-seeking, which I’ll explore next.

Trust Over Control: Redefining Governance

Most engineering organizations talk about empowerment, but their architecture processes still rely on implicit control – who’s allowed to decide, who needs to sign off, and how tightly everything is tracked. For decentralization to work, that model has to change.

One model that helped clarify this shift was the Architecture Advice Process: a decision-making model grounded not in authority, but in trust.

The process follows a single rule:

Anyone can make and take an architectural decision, as long as they:

1. Seek advice from everyone meaningfully affected by the decision
2. Seek advice from experts with relevant experience

This isn’t about asking for permission. It’s about seeking knowledge, exposing context, and making informed, accountable decisions – fast.

And that shift matters. We stopped asking ‘Who approves this?’ and started asking ‘Who should I talk to before we do this?’

That reframing – away from permission and toward advice – became a cultural unlock.

We realized what we really needed wasn’t more approval – it was more clarity, more consistency, and more collaboration.

This model doesn’t mean anything goes. It relies on professionalism and mutual accountability, not hierarchy. When decision-makers seek advice visibly – and advice-givers respond with thoughtful, experience-based input – teams build trust.

By emphasizing transparency over control, we created space for better conversations, clearer ownership, and faster progress.

Putting It Into Practice: The Architecture Advice Process

The shift from control to trust requires more than mindset – it needs practice. We leaned into a lightweight but powerful toolset to make decentralized decision-making work in real teams. Chief among them is the Architectural Decision Record (ADR).

ADRs are often misunderstood as documentation artifacts. But in practice, they are confidence-building tools. They bring visibility to architectural thinking, reinforce accountability, and help teams make informed, trusted decisions – without relying on central authority.

Why ADRs Matter

Decentralized teams often face three major confidence gaps:

• Confidence in ourselves and others to make sound architectural calls
• Confidence in the advice process – that feedback was sought and considered
• Confidence in understanding decisions over time, especially when context fades

A well-crafted ADR helps close all three gaps. It gives future readers a clear view into why a decision was made, what options were considered, and who was consulted – which is critical when decisions are distributed and evolve across many teams.

What an ADR Is

An ADR captures a single architectural decision and its surrounding context. Once finalized, it’s immutable (though it can be superseded). It’s written for future teammates, not just the immediate stakeholders. It should be easy to skim for relevance or dig into for detail.

Key components include:

• Title & ID – Clear and uniquely identifiable
• Status & Date – Indicates when the decision was made
• Context – Explains the problem or trigger
• Options – Lists 3–5 real, thoughtful alternatives – not just strawmen
• The decision outcome – Names the option chosen and why
• Advice Received – Captures raw advice from those consulted

Don’t exclude rejected options – “Do nothing” counts too – rejection is still a decision

This structure isn’t just for record-keeping. It reinforces the Architecture Advice Process by tying decision-making directly to the advice that informed it.

Making ADRs Work in Practice

In my own organization, architectural decisions often lived in Slack threads or hallway conversations – easy to lose, hard to revisit. We were informally applying parts of the advice process, but without structure or visibility. Introducing even a lightweight, markdown-based ADR process brought immediate clarity.

Some practices that helped us:

• Start with the problem. Brain-dump the context before listing solutions.
• Seek advice early. Especially on the framing and scope – not just the options.
• Make it visible. Share who was consulted and what was learned.
• Capture provisional decisions. These invite feedback without stalling progress.

Storing ADRs close to the work – in GitHub repos, internal wikis, or project docs – makes them accessible. We treat them as a living archive of architectural thinking, not just decisions.

More Than Documentation

What stood out most to me is that ADRs aren’t just about record-keeping – they’re about trust. They help bridge the gap between those who design systems and those who live with the consequences of decisions. They give new teammates a path into prior decisions, and help avoid repeating the same conversations.

Most importantly, ADRs reflect the culture shift behind advice-driven architecture. They show teams that decisions aren’t made in isolation or by decree, but through transparent, inclusive, and intentional processes.

Creating Shared Context with Advice Forums

Decentralized architecture works best when decisions don’t happen in isolation. Even with good individual practices – like ADRs and advice-seeking – teams still need shared spaces to build trust and context across the organization. That’s where Architecture Advice Forums come in.

We implemented a practice called the advice forums that offer a lightweight structure to support decentralized decision-making without reintroducing control. They aren’t governance checkpoints. They’re opportunities to learn, align, and advise – openly and regularly.

What an Advice Forum Is (and Isn’t)

An advice forum is:

• A recurring session for discussing in-progress architectural decisions
• A forum for advice, not approvals or consensus
• A place where teams present, experts advise, and observers learn

It’s not about gatekeeping or slowing teams down. Instead, it provides transparency and distributed visibility into architectural thinking – especially helpful in organizations with multiple teams or domains.

The Forum’s Core Purposes

Advice forums serve three main goals:

1. Increase visibility into decisions already in flight
2. Build trust through transparent, real-time discussion
3. Create learning moments for participants and observers alike

When these conversations happen in the open, they promote psychological safety, sharpen thinking, and reduce the risk of duplicated effort. It also reinforces accountability – teams that know they’ll be sharing their work tend to think more intentionally about how they frame and justify decisions.

How It Works

Forums are structured but informal:

• Agendas are shared in advance with links to draft ADRs
• Teams briefly present the decision, context, and areas where they’re seeking input
• Advice is offered in the moment or afterward – always recorded in the ADR
• Silence is treated as intentional non-participation, not passive approval

Crucially, no decisions are made in the forum itself. The responsibility to decide remains with the team closest to the work. But the forum amplifies support, challenges blind spots, and exposes patterns worth exploring more broadly.

Why This Works

What makes this practice effective isn’t the meeting – it’s the mindset:

• It normalizes open architectural thinking, not behind-the-scenes approvals
• It enables cross-team alignment without enforcing sameness
• It fosters a community of curiosity, not control

Concepts like coalescent argumentation – where groups acknowledge shared understanding before exploring disagreements – help keep conversations productive. Teams learn not just what others are deciding, but how they’re thinking, what trade-offs they considered, and why they landed where they did.

In my own reflections, I found this practice particularly compelling. In many organizations, great technical work happens in silos. Advice forums help break those silos without imposing heavyweight processes. They create a visible on-ramp for developers and teams who want to engage with architecture but don’t yet feel empowered to do so.

Tips for Implementation

To get started, you don’t need buy-in from the whole company. Start small:

• Create a shared ADR template and repository
• Define the forum’s scope and expectations clearly – e.g., a one-page Terms of Reference
• Emphasize learning and delivery over ceremony
• Keep it optional but valuable

When done well, advice forums become a hub of architectural awareness. They help organizations evolve from disconnected teams making isolated decisions to a culture where architecture is open, shared, and continuously improved.

From Approval to Alignment: Cultural Shifts Observed

The shift to advice-seeking changed more than our process – it changed how people behaved.

Before adopting the Architecture Advice Process, our architecture function had become a bottleneck. Teams waited. Architects felt overwhelmed. Decisions often landed in our laps too late or with too little context. Everyone waited for someone else to make a decision. The more the architects centralized, the less connected they became.

We were holding too much, and holding it too tightly. And it showed, Teams felt stuck. Architects felt responsible for decisions they weren’t close enough to make well.

We replaced approval bottlenecks with a system of shared responsibility. Teams began to proactively explain their decisions, involve the right people, and build more confidence in the process. Not everything shifted overnight, but over time, these patterns emerged:

• More developers wrote ADRs, even for small or internal decisions
• Architects stopped defaulting to ownership and started focusing on support
• Conversations got more thoughtful and less political

This wasn’t just a process change. It was a behavioral reset – a shift from permission to presence, from control to coaching. And it created space for a more inclusive, transparent, and resilient architecture practice.

Conclusion: A Cohesive Culture of Autonomy

Decentralized architecture only works when it’s grounded in intentional practices. Tools like the Architecture Advice Process, ADRs, and advice forums don’t just help us move faster – they help us move together.

One of the clearest lessons from both my experience and Harmel-Law’s book is this:

“Distributed architecture is more social than technical.”

It’s not enough to distribute system responsibilities – you also have to distribute trust. That means replacing command-and-control with guidance and transparency. It means shifting the architect’s role from approval authority to trusted peer and visible collaborator.

“Architects don’t need more power. They need more presence.”

If you’re working in a growing or distributed organization, consider piloting one of these practices. Start small. Try a lightweight ADR template. Launch a casual advice forum. Shift one decision from approval to advice.

Decentralization isn’t just an architectural pattern – it’s a cultural commitment. And it starts with how we choose to decide.