Introducing Accord: A Better Way to Make Technical Decisions

Gunnar — Sun, 16 Mar 2025 20:12:28 +0000

I'm thrilled to announce the launch of Accord, a platform designed to transform how engineering teams make and document technical decisions. As the CTO and Co-founder, this launch represents the culmination of years of experience and a deep understanding of the challenges teams face when making critical technical choices.

The Genesis of Accord

Early in my career, I was fortunate to work for a company developing a highly complicated technical product: a real-time auction engine handling high-value transactions. What set this experience apart was how rapidly I was able to gain expertise, almost exponentially. A significant factor in this accelerated growth was the company's well-documented Architecture Decision Records (ADRs) for many of their technical choices, coupled with bi-weekly sessions where engineers could meet and discuss directions and decisions for the engineering organization.

These practices provided invaluable context that allowed me to understand not just what decisions had been made, but why they had been made. This transparency and knowledge sharing became a cornerstone of my engineering philosophy.

"The decisions we make today become the architecture we live with tomorrow. Documenting not just what we decided, but why we decided it, is crucial for building sustainable systems and teams."

What Are Architecture Decision Records (ADRs)?

For those unfamiliar with the concept, Architecture Decision Records (ADRs) are documents that capture important architectural decisions made along with their context and consequences. Each ADR describes a specific architectural decision, the problem it addresses, the options considered, and the reasoning behind the chosen path.

ADRs serve several critical purposes:

They provide a historical record of why certain technical choices were made
They make the decision-making process transparent and accessible to all team members
They help onboard new team members by giving them insight into the evolution of the system
They prevent the same discussions from happening repeatedly
They create accountability and clarity around technical direction

Effective collaboration is key to creating meaningful Architecture Decision Records

Bringing ADRs to Every Team I Joined

Years later, as I evolved into a position as a Tech Lead, one of the first initiatives I championed was implementing an ADR process. This wasn't just about documentation. It was about creating a framework for thoughtful decision-making and knowledge sharing. The results were remarkable: we were able to move fast in a very organized and robust way.

A former colleague once told me that the ADR process I established was "a very nice tool to keep track of why the idea was decided and implemented or not. And also for onboarding, it's great to be able to throw this kind of history at new hires."

When I joined another company later in my career, I implemented the same process with equally positive results. The decisions made became more widely known, discussions around them were more thoughtful, and changes didn't come as a surprise to team members. Most importantly, when new decisions had to be made, we had the context of prior ones. This brought a new level of clarity and traceability for technical decisions that had not been present before.

The Problem with Existing Tools

Despite the clear benefits of ADRs, the tools we used to manage them were cumbersome. We tried various approaches:

Atlassian Confluence

Too slow and inflexible, with poor search capabilities and difficult version tracking.

GitHub Repositories

Not helpful when sharing and receiving feedback from non-technical stakeholders.

Asana

Too flexible, causing important information to get easily lost in the noise.

After years of using the ADR framework, it became apparent that teams needed a proper tool, one specifically designed to help them make decisions and keep track of them. Not just technical decisions through ADRs, but also product decisions and even business decisions.

Enter Accord: Decision-Making Reimagined

When large language models became available to the public, I immediately saw the potential to create something transformative. Accord was born from this vision: a platform that helps engineering teams write and manage ADRs throughout the entire process, with AI assistance to make the process smoother and more effective.

Accord isn't just about documenting decisions after they're made. It's about:

Facilitating thoughtful discussion around technical choices
Creating a structured approach to decision-making
Building an accessible knowledge base that grows with your organization
Bridging the gap between technical and non-technical stakeholders
Leveraging AI to make the process more efficient and effective

Looking Forward

As we launch Accord, I'm excited to see how it will transform decision-making processes for engineering teams around the world. The platform represents not just a tool, but a philosophy, one that values transparency, collaboration, and thoughtful decision-making.

We're just getting started, and I invite you to join us on this journey. Whether you're already using ADRs or are new to the concept, Accord can help your team make better decisions, faster, while preserving the valuable context that makes those decisions meaningful.

Here's to better decisions and stronger engineering teams.

Ready to transform your team's decision-making?

Explore our pricing plans to find the right fit for your organization, or join our customer pilot program to get early access to Accord's full feature set.

View Pricing Plans

Interested in our pilot program? Email gunnar@getaccord.co

About the Author

Gunnar Gylfason, CTO and Co-founder

Gunnar is passionate about helping engineering teams make better decisions through improved processes and tools. With over a decade of experience in software development and team leadership, he has seen firsthand the impact that good decision-making practices can have on product quality and team morale.

Interested in learning more about Accord? Visit getaccord.co or follow us on X for updates.

Good engineers have mechanical sympathy

Gunnar — Wed, 19 Jul 2023 09:13:27 +0000

You don’t have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy.
Jackie Stewart, racing legend

You don’t need to be a devops engineer to be a good software engineer. But it helps to have mechanical sympathy.

One of my favorite terms in the industry is mechanical sympathy. Its defined as having an understanding of how a tool you use, operates best (AWS Well-Architected).

A lot of engineers work or have worked or want to work in environments where tools like Kubernetes is being used to orchestrate the containers for the applications which they develop.
Even though most of these engineers do not need to concern themselves with interacting the underlying infrastructure. I argue that in most every case, having mechanical sympathy helps them become better engineers. They understand the limits, constraints and most importantly the capabilities for the system their application is running.

When I was transitioning from a Fullstack engineering role into a more backend specific role in 2017 one of my former coworkers held a mini workshop on Kubernetes during lunch at the company we used to work for. This workshop explained to me the basics of Kubernetes with a hands on approach and I started to gain some level of understanding what this was all about. The course gave me the exact amount of information that I needed to understand my company’s conversations around infrastructure and allowed me to build upon that knowledge and figure out more things on my own when I needed to. Since then I have worked on almost the entire spectrum of the stack and the transition was smoother because of the mechanical sympathy I had.

I honestly believe that gaining that small amount of mechanical sympathy helped me to become a better engineer than I would have been without it.

Another purpose of this post is that I want to tell you about how I want to pay it forward. I am creating a course which I am going to launch at the end of the summer. The course is a practical hands-on course on Kubernetes and like the name indicates it is designed to help you understand and make peace with this controversial and complicated subject. You can find it at https://zenkubernetes.com.

If this is something that you think might be useful to you feel free to sign up to the mailing list for a earlybird special discount.

P.S.
The course is still in closed beta but any feedback you might have on the topics or modules is greatly appreciated.

DEV Community: Gunnar