During my professional life I had the opportunity to cover different positions (as developer, project manager, architect), within different industries (logistics, energy, finance, telecommunications), and several companies, although always in the IT departments. As such, I was exposed to several working environments, mindsets and cultural setups, and I must confess I had few issues fitting in at the beginning.
In fact, together with a good dose of Peter’s Principle applied to my newly acquired roles, I had sometimes failed recognizing the challenges connected to the position, trying to win over the situation with a bunch of hard skills (standards, best practices, diagrams, presentations, etc.): that helped, in some cases, but not always.
The natural attitude of many (myself included, at least until few years ago), when thrown outside of our own comfort zone, is to react with arrogance and anger, fueled by the insecurity and frustration: those from my generation might testify that showing weakness and admitting ignorance was not seen perceived, until recently as a positive behavior, especially in Southern European or Slavic cultures, like the ones where I grown up1.
At this point of the post, you are probably starting to wonder what do these personal, psychological and cultural elements have to do with the functions of enterprise architecture and why you should care. Am I right?
Difficult Talks with Difficult People…
Well, I believe that many of you architects (who are still reading) have always executed your duties diligently, identifying the relevant stakeholders of the organization you belonged to, or that you were consulting, and then working with them, extracting their requirements and inputs. And I also believe that during this first phase of the architectural process you had to deal with some hidden or crossing lines, when important stakeholders, not even listed in the organization chart (eg. long-time employed developers or customer support personnel on the warfront), held an important stake in one or more of the systems you had to investigate.
The conversation with such people might have been quite challenging for you, because of many reasons, such as the different lexicon, different background and knowledge, different functions, hidden agendas; in many cases these difficulties might have also been increased by personal or philosophical views on your role as architect, perceived as useless or distant from their daily challenges (eg. incidents, bugs, nervous customers, etc.), unable to capture problems and propose valuable solutions.
Other common cases of conflict might have been driven by politics, power games or personal ties: reasons that initially appear as irrational, when parametrize with the objective instruments of an architect, but that have a lot of (hidden) meaning for the ones challenging you over them.
In such situations, entering in conflict with those individuals, despite of bad attitudes, lack of collaboration, poor professional behaviors, would not help your work, but rather make it harder and more frustrating: with some good motivations, especially in agile working contexts, organizations have the tendency to value daily operations more than future plans, and those ‘difficult people’ represent the engine that makes the train going (today), while you are the ones trying to sell a possible future state.
This is the moment when your soft game must scale up, applying some of the skills that will help you in settling down any conflicts that might arise in conversations or deals, using all your emotional intelligence, trying to understand who is the person you have in front, before considering her/his role and function: speaking with the human and not with the role will make you achieve more than appealing to the formality of the professional relationship and duties between you.
While treating those individuals as your colleagues, who must support you, fulfilling some organization chart duties, might even still work, at least in your investigations and analysis phase, such forced collaboration model will likely fail in the next phases of your work, when you will be asked (and you will not be able to refuse) to follow-up on the implementation of your own architecture.
Bad personal relationship might, in fact, cause pathological behaviors of the organizations, such as shadow-IT, procrastinations, processism, etc., which will affect directly your work and the impression, feedback and reputation you might wanted to build on yourself.
Traversing over the challenges of conflictual situations and negative environments, applying a calm, steady, resilient and oriented visionary approach has ultimately succeeded for me in most of the cases, while I can tell that when I entered in conflict over some objective factors, as opposed to non-objective ones, never generated value, neither for me nor for the organization.
Experiences of failure on that methodology and communicative strategy made me ultimately consider how the role of the architect must now take in considerations those soft-skills, that can be considered architectural enablers for the success of your organization, your teams and yourself.
1 If you want to learn more on the topic of multi-culturalism in work environments, I recommend the foundational book The Culture Map (by Erin Meyer)