Making architectural decisions is often seen as the responsibility of a select few—the senior architects who hand down blueprints from an ivory tower. But what happens when you turn that model on its head? What does it look like when teams are empowered to make their own architectural decisions?
Recently, we had the pleasure of hearing a story from Elena Stojmilova, a Technical Lead at Open GI, who shared her first-hand experience of this very transition. Alongside her colleague Peter Hunter, the company's Technical Architect, Elena recounted a journey that began nearly five years ago—a journey of moving to a decentralised, team-led decision-making process.
It wasn’t a simple switch, but a profound cultural and professional shift. Here’s what she learned along the way.
The Weight of a Decision
The change began during a period of wider transformation. As the company migrated to the cloud and adopted new ways of working, the decision was made to create autonomous teams responsible for their own architectural choices.
“At the beginning, I was like, ‘Okay, that's great,’” Elena recalled. “We will finally be able to decide what technology we're going to use, how we'll make things.”
The initial excitement of freedom, however, quickly met the sobering reality of responsibility. As a software engineer, the focus had always been on code, best practices, and implementation details. Suddenly, the scope of thinking had to expand dramatically.
“When you actually have the power to make that decision, it’s not that easy,” she explained. “You start to think, ‘Oh, there is a cost here.’ Then you think about the other things that are going to be impacted by my decision. I will change how other teams are working; I will change some of the contracts. That’s when the reality came.”
This shift from focusing on a single piece of code to seeing the entire system—with its costs, dependencies, and product implications—was the first major hurdle. But it was also, as Elena reflected, “the most powerful way of learning.”
Finding Our Feet with Support and Structure
Making this leap would have been impossible without the right support systems. Elena emphasised that at the beginning, teams don’t necessarily have all the skills needed to make these high-level decisions. This is where guidance, not dictation, becomes critical.
She pointed to the crucial role of mentors like Peter, who resisted the urge to provide direct answers. When asked, “Should we do this? Is this the best way?” he would respond by encouraging deeper consideration. “He would give us some advice, like, ‘You can try this, but consider this also. See what will happen if you choose another way.’”
This Socratic approach helped build the team’s decision-making muscle. Alongside this mentorship, two key practices provided essential structure:
- Architecture Decision Records (ADRs): This practice became a guiding framework. The process of writing an ADR forced the team to articulate the context, explore different options, weigh consequences, and document the final decision.
- The Architectural Advisory Forum (AAF): This was the forum where teams would present their ADRs to a wider group of peers and architects to seek advice.
These tools were not just about process; they were about creating a deliberate and transparent way to navigate complex choices.
The First Forum: Navigating a Sea of Opinions
The first experience with the Architectural Advisory Forum was a trial by fire.
“When you're first starting, the forums are really crowded,” Elena said. “You have a lot of people there, a lot of opinions, a lot of advice. A lot of people can have a strong opinion, and they will share it.”
This influx of feedback, some of which disagreed with the team’s proposed direction, was nerve-wracking. It’s easy for a team to be swayed or discouraged by the loudest voices in the room. Here, Elena highlighted the importance of two things: good facilitation to ensure the conversation remained constructive, and the discipline to process the feedback thoughtfully.
“We went offline after that meeting,” she remembered. “We had discussions with most of the people that had commented. We took notes and considered each opinion.”
This experience taught a valuable lesson: feedback, even when it feels like criticism, is essential. It helps you see what you might have missed and kicks the tyres on your decision. The key is to remain calm, consider every point, but ultimately retain ownership of the final choice.
Four Years On: A Culture of Collaboration
Today, the process looks very different. The initial challenges have given way to a mature, collaborative culture.
- ADRs are a Team Effort: Instead of the tech lead writing ADRs alone, the entire team now collaborates on them from the start. They discuss the context, explore options, and decide together when a spike is needed for further investigation.
- Advice is Sought Earlier: Rather than waiting for the formal AAF, teams now engage architects and stakeholders earlier in the process, sharing high-level diagrams and ideas to get timely input.
- The Forum is About Advice, Not Just Opinions: The AAF has evolved. While strong opinions still exist, the conversations are now more focused on providing constructive advice. As Elena noted, “Now, I am mostly receiving advice like, ‘Can you try this?’ or ‘Have you considered this?’ not just a strong opinion that ‘This is the best way.’”
- Knowledge Sharing is the Norm: The AAF has broken down team silos. By hearing what other teams are working on, what technologies they’re using, and what decisions they’re making, everyone benefits. It creates opportunities to reuse implementations, share expertise, and build a collective understanding of the entire system.
This evolution didn’t happen overnight. As Peter added, it was also a significant adjustment for the architects. Their role had to change from being the source of architectural truth to becoming facilitators and advisors. “They have to adjust their muscle memory,” he explained. Architects had to unlearn the habit of broadcasting decisions and learn how to engage in a two-way conversation.
Decentralising architectural decisions is more than a process change; it’s a cultural one. It requires creating an environment of trust, providing supportive guidance, and giving teams the tools to think critically and own their work.
Elena’s story shows that while the path can be challenging at first, the outcome is a more resilient, knowledgeable, and empowered engineering community.
