Scaling Engineering Teams in a Remote-First World
The Power of Storytelling Through Architecture Decision Records (ADR)
Introduction
For years, scaling engineering teams meant building out offices, adding more people, and ensuring everyone was physically present in the same space, or at least in the same time zone. In today’s distributed and remote-first world, that assumption no longer holds true. As teams grow and span continents, engineering leaders face the challenge of maintaining effective communication, alignment, and decision-making — without the luxury of everyone being in the same room.
The solution lies in a shift towards asynchronous communication and a culture of storytelling through writing. One tool that has emerged as critical in this transformation is the Architecture Decision Record (ADR). By leveraging ADRs, engineering teams can document key architectural decisions in a structured, accessible format that encourages clarity, transparency, and thoughtful collaboration — even across time zones.
In this post, we’ll explore how ADRs can help you scale your engineering organization and create a culture of written decision-making that drives clarity and alignment.
The Shift in Scaling Assumptions
Traditional approaches to scaling often assumed that more people meant more in-person meetings, quicker decisions, and better alignment. But that model doesn’t work in today’s world of remote-first teams, where developers, architects, and engineers could be scattered across different continents. The challenges are immediate: how do you ensure everyone has access to the same information? How do you enable effective decision-making when team members are working asynchronously across different time zones?
The answer lies in storytelling through writing. Engineering decisions, just like product decisions, need to be communicated clearly and thoroughly. When decisions are written down, they are accessible, reviewable, and shareable. They can be revisited as the team grows, or when a new person needs to get up to speed. Written communication also encourages thoughtful deliberation over snap judgments, leading to better-quality decisions.
This shift is essential for scaling. The larger your team, the harder it is to maintain alignment without clear, consistent communication. And in the world of remote-first engineering teams, alignment doesn’t happen without a cultural commitment to written decision-making.
The Role of Architecture Decision Records (ADR)
An Architecture Decision Record (ADR) is a lightweight, structured document that captures important architectural decisions made within a project. It’s an essential tool for modern engineering teams, especially those working remotely or in distributed environments. The power of ADRs lies in their ability to document decisions transparently, providing everyone in the organization with access to the context, rationale, and outcomes of key architectural choices.
But what exactly goes into an ADR?
Key Sections of an ADR:
Working Group with DACI Roles
The first section of an ADR defines the decision-making group, using the DACI framework to clarify roles. DACI stands for Driver, Approver, Contributor, and Informed. Each role helps structure decision-making and ensures everyone knows their responsibilities.
The Driver is responsible for pushing the decision forward and organizing the discussions. The Approver is the final decision-maker who has the authority to approve the solution. Contributors provide input and help shape the decision, while Informed stakeholders are kept up-to-date on the decision’s outcome.
This structure ensures that the decision-making process is clear, reducing confusion and improving accountability. In a distributed team, it’s especially important to know who is driving the decision, who needs to be consulted, and who needs to be kept in the loop.
Problem Statement and Context
The problem statement articulates the issue the team is trying to solve. Without a clear understanding of the problem, solutions can quickly go off-track. Including the context — whether it’s technical, organizational, or business-related — helps provide the necessary background.
In a remote-first world, it’s especially important to document context. Without in-person discussions, it’s easy for misunderstandings to arise or for team members to overlook important background information. ADRs ensure that context is communicated clearly to everyone involved, regardless of when or where they’re working.
Solution Proposed
This section outlines the recommended solution, providing enough detail to understand how it will be implemented. The goal is to be specific enough that others can evaluate the decision and understand the reasoning behind it.
In distributed teams, where informal hallway conversations or whiteboard sessions are rare, documenting the solution in writing is critical. It ensures that all stakeholders have access to the same level of detail and can give thoughtful feedback.
Alternatives Considered
One of the most valuable parts of an ADR is documenting the alternatives considered. Why did you choose this solution over others? What were the trade-offs? What risks did you assess?
Include all alternatives, even those that seem infeasible. By documenting every option considered — regardless of its viability — you provide more context for the decision. This transparency not only helps the team understand why a particular decision was made but also serves as a valuable resource for future reference. What seemed infeasible today might become a feasible option down the line, or it might provide a lesson on what to avoid.
Async Comments via Shared Document
One of the key advantages of ADRs is that they facilitate asynchronous collaboration. Instead of requiring everyone to be present for a meeting, ADRs allow for feedback and comments to be collected via a shared document (e.g., Google Docs, Confluence, etc.).
This is particularly beneficial for teams distributed across time zones. Asynchronous comments ensure that everyone has an opportunity to provide input, even if they are asleep when a decision is being discussed. It also allows for more thoughtful, reflective responses, as team members can take time to digest the information before commenting.
The Hard Part: Driving Consensus
While ADRs are a powerful tool for documenting decisions, one of the hardest parts of scaling an engineering team remotely is driving consensus on key decisions. In an environment where team members may be working in different time zones or regions, it can be challenging to get everyone on the same page, especially when there’s disagreement or ambiguity.
To make the process of reaching consensus more structured, consider the following approach:
List All Working Group Members at the Top of the Document
The first step in the ADR is to list all members of the decision-making working group. This ensures that everyone who needs to be involved in the discussion is named upfront.
By identifying everyone from the outset, you create an environment of clarity about who will be responsible for driving the decision and who will be consulted.
Allow Members to Express Agreement or Dissent
Each working group member should be given a space within the ADR document to express their level of agreement or dissent. This could be as simple as adding checkboxes or comments indicating whether they agree with the proposed solution, disagree, or have concerns.
This practice ensures that everyone has a chance to weigh in on the decision asynchronously. It also helps to highlight potential areas of conflict early on, allowing the group to address them proactively before the decision is finalized.
Document Status: Draft, Proposed, Accepted, or Retired/Superceded
The ADR should include a document status field that tracks the progress of the decision. This status could be one of the following:
Draft: The ADR is in the initial stage, and feedback is being gathered.
Proposed: The ADR has been shared with the working group and is open for review and further feedback.
Accepted: After consensus is reached, the ADR is considered final and accepted by the working group. This decision is now part of the team’s architectural history.
Retired/Superceded: If a decision is no longer relevant or has been replaced by a new one, it is marked as retired or superseded.
This status tracking helps everyone involved understand the stage of the decision-making process, reducing ambiguity and setting clear expectations around timelines.
Driving consensus is critical to making good architectural decisions. The ADR process provides a structured approach for doing this asynchronously, enabling teams to come to agreement despite geographic and time-zone differences. By giving everyone a voice and tracking the document’s status, you build a culture of transparency, participation, and ownership, which ultimately leads to better decisions and stronger alignment.
The Role of Engineering Managers: Ensuring All Stakeholder Groups Are Represented
A critical part of ensuring the success of an ADR process is the role of the Engineering Manager in guiding the decision-making group and ensuring that all key stakeholders are represented. This is especially important in remote teams, where it’s easy to inadvertently overlook perspectives or fail to involve the right people early in the process.
The Engineering Manager’s role includes:
Reviewing the Working Group Composition
Before kicking off the ADR process, the Engineering Manager should review the working group to ensure that all relevant stakeholder groups are represented. This could include product managers, technical leads, ops, security, and even customer-facing teams, depending on the nature of the decision.
Ensuring the right stakeholders are involved helps avoid missing a better decision. When the right voices are at the table, you’re more likely to identify and evaluate all viable solutions and make decisions that account for all perspectives.
Guarding Against Second-Guessing
Another key responsibility of the Engineering Manager is to help avoid second-guessing once the decision is made. If the decision-making process is structured properly, and all key stakeholders have had their say, there is less room for doubt or revisionist thinking later on.
The Engineering Manager can help ensure that ADRs are comprehensive, inclusive, and well-documented so that once decisions are made, there is a clear, compelling narrative to follow. This narrative ensures that future team members, or even the future self, can understand the rationale behind decisions and can easily follow the story — even if they come back to the ADR months or years down the road.
Relying on the Team, Not Just the Approvers
It’s important to note that relying too heavily on an Approver — a single person with final say — can lead to misalignment of responsibility and authority. In some situations, you might have zero-sum trade-offs — where only one option can win. But more often than not, there’s an opportunity to create win-win solutions that satisfy multiple stakeholders.
Instead of deferring to an Approver when consensus isn’t immediately clear, drive to consensus within the team. The collective strength of the team is the best asset in making decisions that balance diverse needs and perspectives. It’s through collaborative problem-solving that you will uncover better solutions that everyone can get behind.
This approach not only strengthens your team’s decision-making but also builds a sense of ownership and alignment, where every voice matters in shaping the future direction of the project. In the long term, it helps scale your organization by fostering a culture of trust and shared responsibility.
Leveraging Slack or Teams for Asynchronous Discussion
In a remote-first environment, tools like Slack or Microsoft Teams are invaluable for promoting asynchronous communication and collaboration. However, they should be used for discussions — not as the record of the decision-making process.
Use Slack/Teams for Discussion, Not for Decision-Recording
Slack or Teams channels should serve as the space for real-time or asynchronous discussions around architectural decisions. Team members can ask questions, raise concerns, or propose ideas. But remember, Slack/Teams is not where decisions are documented.
Answer Questions in the ADR Document
If a question arises in the Slack or Teams channel, always answer it in the ADR document itself. This ensures that all answers are in the same place and that no one misses important context. The goal is to create a single source of truth that anyone can refer to, now and in the future.
Document the Narrative
Think of an ADR as a story you are telling. Just as with a joke, you can’t just give the punchline — you need to build the context and explain the reasoning behind the decisions. Don’t assume that your future self or others will remember the full context of a decision. Tell the whole story clearly and in detail, so anyone in the target audience — whether that’s a future developer or your successor — can understand it.
By following these practices, ADRs will not only document your decisions but also serve as a compelling narrative that explains the journey of your architectural choices.