In any organisation that empowers its teams, a critical question eventually arises: what happens when an architect, tasked with guiding the technical vision, fundamentally disagrees with a team's decision? It’s a scenario fraught with tension, testing the balance between autonomy and architectural coherence.
Continuing our conversation with architect Pete and tech lead Elena, we explored this exact challenge. Pete shared that it’s often the first question people ask when they hear about their advice process: "What about a decision you didn't like?" His answer reveals a crucial shift in mindset, moving from control to influence and self-reflection.
The First Reaction: "This is Wrong"
Pete recounted an early experience with their advice process. A team was keen to try a new technology, driven by the excitement of pushing boundaries. "I used the phrase 'kids in the sweet shop'," he explained. "They wanted to try something new, but you could see that it wasn't quite right and it wasn't well thought out."
This is a familiar feeling for many architects. Your experience and perspective tell you a decision is heading in the wrong direction. The immediate emotional response is to intervene and correct the course. However, in a culture built on trust and autonomy, that’s not the answer.
"It's really difficult to have a conversation when your emotions are telling you it's the wrong decision," Pete admitted. But his reflection on this moment is where the real lesson lies.
The Turn Inward: Was My Advice Good Enough?
Instead of focusing on the team's choice, Pete turned his focus inward. "A lot of it is actually about you," he reflected. "My feedback was clearly not good enough. If I had a more persuasive argument or given some bit of information that would've helped change their mind, perhaps the outcome would have been different."
This is a powerful re-framing. The responsibility shifts from policing decisions to improving the quality of your own advice. Before concluding that a team is making a mistake, an architect should first ask:
- Did I provide the necessary context?
- Was my argument clear and persuasive?
- Did I help them see the bigger picture they might be missing?
This introspection is even more critical when emotional attachment is involved. Pete candidly shared how Elena’s team made a decision to replace a part of the system he had worked on extensively. "Elena was effectively throwing everything I'd done in the bin," he said. "But it was moving forward, and I knew it was the right decision. You have to take your emotion out of it."
Creating Guardrails for Good Decisions
Of course, this doesn't mean leaving teams to fend for themselves in a "candy shop" of infinite technological choices. For the model to work, teams need a framework to help them navigate complex decisions. From her perspective as a tech lead, Elena highlighted two elements that were essential.
- Architecture Principles: "Whenever you're making any architectural decision, you should go through the architecture principles," she explained. These principles acted as a guide, prompting the team to consider crucial factors like cost. A principle can turn an abstract idea like "be cost-effective" into a concrete checkpoint, forcing a team to ask, "Should we spend this money, or is there a better option?"
- A Supportive Culture: Skills like asking good questions, understanding financial implications, and communicating trade-offs don't always come naturally. Elena emphasised the role Pete and another architect, Andrew, played in coaching the teams. "It's important to have someone who will support and advise you," she said. Their role wasn't to make the decision for the team, but to help the team build the skills to make the right decision themselves.
Navigating Boundaries and "Context Wars"
The complexity multiplies when a decision impacts more than one team or blurs the lines of ownership. These situations can quickly escalate into what Pete calls "context wars," where teams become defensive over their domains.
The solution, once again, is not top-down command but facilitated communication. Their primary tool for this was a Context Map, derived from Domain-Driven Design. By mapping out the system and defining team boundaries, they aimed to give teams the autonomy to work independently.
This wasn't a simple exercise, especially when applied to a legacy application rather than a greenfield project. The initial boundaries weren't always clean, but the map provided a shared language and a starting point for conversation. When disagreements arose at the boundaries, the goal was to get people talking, understand the impact, and, if necessary, redraw the lines together.
Ultimately, handling disagreement in a decentralised environment is less about winning an argument and more about fostering a resilient system of decision-making. It requires architects to become better advisors, teams to be equipped with principles and support, and a shared commitment to open communication when boundaries are crossed.
It’s a process of letting go of direct control, trusting your teams, and, most importantly, looking at your own role first when things don't go the way you expect.
