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. While I believe my technical knowledge and experience enable me to bring significant value to my clients, I rely just as heavily, if not more, on 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.
The cardinal rule of architecture diplomacy is “Include fellow solution stakeholders early and often.”
Solution stakeholders are the group of people that have opinions about how a solution should be architected – 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:
- 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 implementors on your team!
- 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.
- 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!!
- 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. It seems obvious, but when you are listening, you will hear others “talking at” and not “talking with”. People don’t like being “talked at” becuase it wastes their time – they could be elsewhere doing valuable work while you talk.
