Agile architecture and the behavioural side of transformation

Agile architecture and the behavioural side of transformation

Start fighting the curse of knowledge

An all-too-common scenario

Meet Kevin, the enterprise architect known for his diligent work and extensive experience in our organization. He has grown through the ranks and played a crucial role in setting up our current ERP program, which serves our business well. Kevin does great things and can be regarded as a professional enterprise architect. Ask anyone in the organization, and they would more than likely agree.

Now, one of our business lines is in the process of acquiring a sizable company. This requires Isabelle, the president of the business unit, and her team to make critical decisions to merge the companies and make the ambitions of the merger a reality. Kevin, the capable enterprise architect, eagerly takes on the task of helping the team out.

Without hesitation, Kevin dives right in and quickly devises a proposal to organize the newly formed unit. He promptly shares his proposal with the architecture team for validation and presents it to Isabelle’s team. To his surprise, he faces significant resistance during this presentation. Comments like “The proposal will never work,” “Customers won’t accept this,” or “This will lead to job redundancies” flood the room. From Kevin’s perspective, much of this feedback seems baseless, driven by emotions. Or worse, they don’t have the best intentions for the company.

Kevin quickly schedules a meeting with Isabelle through her assistant, Mario, to address this situation. Fortunately, he secures a 30-minute slot later in the week. As Kevin enters Isabelle’s office, she immediately addresses the matter and explains that his proposal is spot on. But then, out of the blue, she asks him a straightforward question: “Have you taken the time to learn who my team members are, what they do daily for both companies, and what their aspirations are?”

What a strange question to ask

Kevin responds, “That’s an interesting question. I craft a proposal aligned with our strategic objectives and support it with the available facts. I’m unsure how asking those questions would further enhance the proposal.”

Kevin is widely recognized in the organization for his deep expertise and architectural skills. However, he is rarely described as someone who excels in interpersonal relationships.

Upon hearing Isabelle’s feedback, Kevin reacted strongly, expressing shock and frustration. He directs his anger towards Isabelle, making offensive comments about her team’s competency and good intentions and asserting the soundness of the architecture, which he claims has been approved by the architects. Kevin also emphasizes the importance of respecting these decisions.

It is time for a quick debrief

Easing out of the intensity of Kevin’s passionate response, Isabelle sets up a review session with her team. As the meeting begins, the team fires their critical questions at Isabelle. They question Kevin’s role and relevance: “Who exactly is Kevin?”, “Why did you bring him into the mix?” “What does he understand about our business?” “Can he evaluate the capabilities of our recently acquired business?” “Shouldn’t architects focus on IT systems?” and so on. The team and Kevin are in an impasse.

Where did it go wrong?

Despite Kevin's qualifications and expertise, he failed to hit his mark. Like many of us on a similar path, he was blind-sighted by his inability to connect with the team. He failed to realize that the group was unwilling to listen to him even if he had the best possible proposal in his hand. Like many people in such situations, Kevin found himself cursed by knowledge.

“When we are given knowledge, it is impossible to imagine what it’s like to LACK that knowledge."
Chip Heath

Taking a step back

After a tense meeting with Isabelle, Kevin reflected on the daily confrontations. When he heard her feedback, he realized that he may have approached the situation with too much enthusiasm. As a result, he failed to consider that some people might have felt concerned upon hearing his proposal.

Kevin realized that it is crucial to understand and empathize with his colleagues if he wants them to hear his message. This is especially important when two organizations merge, new roles emerge, IT systems disappear, and people feel uncertain about the future.

Kevin’s experience is not unique in the world of enterprise transformations. It highlights a critical aspect often overlooked: the need for empathy and understanding in decision-making.

What can Kevin do differently?

Reflecting on Kevin’s journey, there are key takeaways that any enterprise architect can apply to avoid similar pitfalls. Like many in his position, Kevin is transitioning from a technical expert to a trusted advisor. This is often a lengthy journey that requires continuous development of human-oriented skills. To get started with immediate impact, you and Kevin can begin by focusing on a few essentials:

• Start by understanding — developing a connection.
  Before expressing your opinions, making statements, or proposing something, asking questions is essential. By asking questions, you can learn how people feel about the upcoming change, understand their fears, and gain different perspectives. You can ask for their ideas on moving forward, as they might have inspiring thoughts to share. If not, at least people will feel heard, which helps in reducing resistance to change.
• Create together — To kickstart the change process.
  Involving your stakeholders and representatives from the beginning is crucial to implementing a change successfully. By actively reaching out and collaborating with all parties involved, everyone can give their input and understand how the change will affect them. If you try to create the proposal alone and withhold the knowledge you have, it can prevent others from buying into the change.
• Continuously ask for feedback — to grow your skills.
  If you want to improve your skills and stay relevant, asking for feedback is essential. This can be done simply by asking people for their opinions during or after an interaction. For example, you could ask questions such as "What do you think of my proposal?" or "How can I improve my approach?". You could also ask for specific feedback, such as "What did you like most about my presentation?" or "What could I have done differently?". By seeking feedback, you can gain valuable insights and improve your work or approach while showing that you appreciate people's opinions.

As we’ve seen through Kevin’s story, overcoming the curse of knowledge is vital for successful enterprise architecture. It’s a continuous learning and adaptation journey, essential for any transformational endeavor.

Let’s continue the conversation!

Stay tuned for the upcoming “Agile Architecture and the Behavioral Side of Transformation” series articles if you are interested in personal growth, agile architecture, leadership, and enterprise transformation.

Please get in touch with us if you have a story to share about your transformation experiences and challenges. Your stories fuel our insights!