I’m experimenting with a more informal style post today, and I am writing about something that is on my mind – disagreement in the realm of solution architecture. Today, my wife and I had breakfast at 8:30 followed by 30km of biking later that morning. Now, I’m sitting with with my laptop, looking out over Lake Ontario, with some inspiration to write a post that’s important and not written about significantly as part of the wide realm of solution architecture. While I’m lucky to be in a relationship where we often agree and where disagreements are respectful and thoroughly talked through, the corporate world doesn’t always play by the same set of rules.
What is disagreement? I’m not going to define it because we all know what it is. When people don’t agree, they don’t agree. But, why don’t they agree? How does each side handle a disagreement? These are important questions.
I’ve often seen disagreements go well, and in fact – usually they are quite constructive, but unfortunately, I’ve also seen them go bad: From heated war room discussions that go out of control to project managers asking team members the same questions over and over again until all team members submit and change their answers to “conform” to the project managers will. This post will explore ideas that can be used as part of the methodology of a solutions architect to influence people and constructively get to the best ideas to have the highest possible impact.
As part of the responsibilities of a solutions architect, you will be communicating directly with multiple facets of the enterprise and beyond, including, executive teams (CISO, VPs, C-level executives), management teams (managers, program managers), 3rd Parties (vendors, customers, contractors), technical teams, and business teams horizontally across the enterprise. It’s imperative that you have a solid approach and refined temperament as to how you approach disagreement. As solution architecture is as much about relationships as it is technology, your approach to how you engage people, especially when you may not agree, is imperative.
As you continue to refine your strategy for handling disagreements gracefully, your methodology will no longer be dependent on who you are talking to. You won’t be changing how you speak to someone or how you disagree with someone depending on if they are a vendor, the CEO of the company, or someone who reports to you. Now, that can be a bad thing for you if you haven’t refined your methodology – you might not get fired for screaming at someone who disagrees with you within the confines of a “war room” (although, your time may be coming and this is not proper behaviour), but you will get fired for yelling at the CEO. We all know people like this; people who treat others differently depending on who they are talking to and depending on where they see themselves in the hierarchy.
The real reason why the methodology for constructive disagreements is not dependant on who you are talking to is because you form a methodology where listening, mutual respect, and appreciative conversation come into play. You start to understand how to constructively disagree and you understand and have formed effective communication strategies to provide evidence based reasoning for your conclusions. Your methodology isn’t prejudiced on who you are talking to – it’s sole focus is through respect and appreciation and to get to a position that was hopefully better than where you were at before – and that’s good for everyone.
As you start to refine and apply your methodology to have more critically objective and constructive disagreements, consider the following points:
Back up your conclusions with evidence based reasoning – Use evidence and solid objective reasoning to come to your conclusions. As long as you have done the work and have come to your conclusions as objectively as possible, you will be on firm ground. It will facilitate a much better discussion and allow you to objectively state your ideas and the reasoning that lead to your conclusions.
Always be constructive in the face of criticism – Don’t fight. Don’t get defensive. Understand that criticism may not always be constructive, but when you receive criticism, take it lightly – it’s not usually other peoples intention to criticize or attack you, so take it with a grain of salt.
Be firm when necessary – Assuming you have backed up your conclusions with evidence based reasoning, be firm, but be open to the reasoning of other people.
Be wary of cognitive bias – Cognitive bias can lead us to making the wrong decisions when we think we are making the right ones. It is very challenging for some people to objectively challenge their own cognitive bias, so it’s important to, as much as humanly possible, always be in the practice of challenging your own cognitive bias. Challenge your assumptions regularly. Challenge the way you think and ask yourself why you think the way you think. These exercises can provide very powerful lessons that will be very powerful to you as you try to influence people with your decision making. Also, understand that other people may have a cognitive bias that is preventing them from seeing things the way you see them, and as you become more effective at demonstrating evidence based reasoning, the more capable you will be in getting through to people who may succumb to cognitive bias.
Don’t be taken around in circles – It’s important to clearly hear out other people’s arguments, but it’s a waste of time going around in circles. If you feel someone is taking you around in circles without a real cohesive set of ideas to back up their reasoning, you might be dealing with someone who has to be right, has a large ego, or just wants to make things difficult. If you are going around in circles, employ a few different strategies as long as you stay constructive. Try to explain things in a few different ways to make sure you are clearly getting your point across and to validate weather or not you have properly assessed the other person. If it persists, and you are not getting anywhere, regroup with a larger objective group and continue the discussion.
Beware of new pseudo-standards from governance teams that are not real standards – Be wary of ever changing “guidelines” and “standards” that may negatively impact your solution. Oftentimes, people across the enterprise in various governance roles will try to play by a different set of rules by trying to enforce standards or ideas based on how they’d like to see the world. The problem with this is not that they are necessarily wrong, but that these ideas that they are trying to enforce are just their opinions rather than governance and standards that have been signed off by the organization. If left unchecked, it can complicate your solution and cause concern with your business stakeholders. People may have a shortsighted view of the world that does not allow them to see beyond their current domain. Enterprise standards must holistically meet the needs of governance and be balanced with the business goals and agility of the enterprise, so when dealing with people giving you flak for not meeting a certain standard, make sure you are dealing with an actual standard. If you are not, then you really need to question it. (I like this topic a lot and will write about it in a future post)
Gauge why you have a disagreement – Understanding why the other person disagrees with you is very important. Try to see things from their side. Appreciate their concerns and work with them. If you can identify why you disagree, you are that much closer to agreeing.
Don’t get caught up debating things that are insignificant – Focus on the big things. Don’t waste time debating about small things that are inconsequential or when a change in the decision will not make anything more than a small incremental impact. Solution architecture is about the significant decisions, and that’s where your energy should be focused.
Don’t mistake decision making as leadership – Solution architects are leaders and leaders make decisions, but don’t make a firm decision just because you are a leader because that’s what you think you are supposed to be doing. Make a decision. Make it fast if you have to but be objective.
Be willing and able to change your mind – This is of the utmost importance. Don’t hold an ego. Don’t think of a disagreement as right or wrong. Be willing to change your mind, but be wary of changing your mind without reasoning as to why you should do so.
Don’t be a bully – This goes without saying. No one likes bullies. But, if you are in a room with someone who wants to change your mind using bullying tactics, be tough. Use logic and reasoning and be willing to defend your position without being defensive. If you are confident and have done the background work, it’s not difficult to outsmart a bully, and there are tactics you can use to diffuse the situation so that you can turn it into a real conversation, but it does require development of a high emotional quotient.
Don’t be emotional – It’s only business. Emotion interferes with your ability to perform objective decision making. Also, don’t be a robot, and be sure to understand and take into consideration the emotions of others.
Don’t intend to disagree – Intend to get to the right decisions instead.
Continually re-evaluate your position – While in the midst of discussion you should always be re-evaluating your position based on what you are learning from other people in the room. If you are listening and truly interested in considering the ideas of others then this should come naturally. As you re-evaluate your position make mental notes of the things you are hearing and learning and apply that to your own reasoning.
Develop relationships – Always be working on professional relationships. The more mutual respect two people have for each other, the more likely their discussions will be constructive or finish on a positive note.
Don’t assume you are the only one in the room who knows what they are talking about – You may be a domain expert. Open your mind. You still might learn something.
Understand responsibilities and segregation of duties – Some facets of the architecture just are and there are governance and enterprise standards that enforce that. Have a constructive conversation about the implications of the standards, and it might just help educate you on some of the reasoning, however understand that these constraints may largely be outside of your domain and control.
This article was meant as a primer for solution architects on developing effective methodology for handling constructive disagreements and although some domain specific ideas are presented, the ideas are quite transferable to most aspects of every day life. I’d like to understand your strategies. Please let me know if you agree, disagree, or if you think anything should be added.
SA are leaders and modern managers as well in a governance team at Entreprise Service Delivery level. Also to mention that SA is not an official role TOGAF speaking, official role is “Information System Urbanist” and yes, this is different than Entreprise Architects who are in the business team working for pluri anual strategies.
I’m Lead Architect, either SA either Urbanist or EA according to the need as well as carrier manager internally, innovation lead.
Stop describing SA as a Technical Architect (for director managers take that)
I agree that there is a big difference in role and accountability between an SA and Technical Architect. When procuring someone to help with a big project in a Solution Architect role, it’s important to ensure you are getting someone who knows and understands Solution Architect to actual deliver solutions and drive the right value and who understands all of the facets to Solution Architecture and can work and negotiate with stakeholders and sponsors as well as having that technical understanding and evaluation capabilities (I could keep writing about the competencies, but I think you get the idea). Often Dev Leads or Technical Architects try to disguise as Solution Architects, and maybe they can do the job, but it’s a different role the just putting technical pieces together or coming up with a technical specification.