Architect or Diplomat?

I was approached by a colleague after a recent architecture design meeting who remarked, “Wow, you are quite the diplomat!”, which made me stop and think. This is a common refrain we hear at client sites. While we believe our technical knowledge and experience enable us to bring significant value to clients, we rely just as heavily, if not more, on our diplomacy to broker architecture designs to conclusion. Creating a great design is just a piece of the architect’s puzzle. This led to some ruminations on an Enterprise Architect’s “soft skills” that are not directly related to core technology capabilities and some thoughts regarding architecture diplomacy.

Our cardinal rule of architecture diplomacy is to include fellow solution stakeholders early and often.

Solution stakeholders are the group of people that have opinions about how a solution should be designed – most typically they are either technology teams that will play a role in building or supporting the solution or they are owners of technology domains within the enterprise, like information security or database management. There are actually a multitude of reasons to make an extra effort to include these stakeholders:

1. Build consensus. Engaging people early makes them a part of the solution – people are always more likely to root for your team if they are on your team. Nobody likes being kept out of the loop. You are not an army of one – even if you are Genius #1, you need some help implementing your brilliance, in which case you want the implementers on your team!
2. Prompt corrections. If you are unsure about the design, brainstorming with a team with varied opinions and experiences will result in design epiphanies. Draft something to depict the target solution – even if incorrect it will be valuable. People are quick to identify mistakes. Don’t take it personally, but use it as a tool to engage your stakeholders.
3. Strengthen the design. If you are sure about the design, reviewing it with a team will undoubtedly result in ample feedback. Some of it will align with the design as you envisioned it. Excellent! There is nothing that ratifies a design as quickly as consensus. Some of the feedback will disagree with the design as you envisioned it or offer refinements to your design. Ask anyone giving only negative feedback on the design to propose changes to fix it. If proposed changes improve the design, you would be a fool not to implement them. If they worsen the design, you would be a fool to implement them. You are a complete fool if you did not seek feedback in the first place!

Finally, remember to keep the tone of these discussions collaborative. Don’t talk at your stakeholders. Talk with them. “Talking with” requires listening and responding as opposed to driving ahead down whatever path you started. People don’t like being “talked at” because it wastes their time – they could be elsewhere doing valuable work while you talk.

Architect and Diplomat.

Comments