By Chris Lockhart, Director at Point Management Group
Enterprise Architects are on the hook for a variety of tasks. Typically, they’re involved in defining current and future state business capabilities, working with business processes and their technical enablers, dealing with data sources and decision support based on them, shepherding various applications and how they interact with each other as well as other products and services. They’re also involved in various change initiatives and transformations, helping guide projects as they deliver products and services, and generally work to ensure the overall enterprise portfolio is executed with due diligence for risk and cost.
The word “architecture” in this sense can take on a variety of meanings depending on context.
One of the biggest mistakes that an Enterprise Architect can make is not recognize that they operate in this wonderful, terrible, varied landscape of scope and context. When this happens, they often fail to deliver information at the right level of detail for their audience. This typically occurs with subject matter that may be too complex, too detailed, too broad, or too vague. It also typically involves the Enterprise Architect answering every question with a blanket “It depends…” (because let’s face it, it often does).
Getting the detail level wrong causes the audience to lose interest and reduces their level of trust and comfort with the content being presented. If there is a call to action included as part of the message, an audience that doesn’t understand what is being told to them or asked of them is less likely to act, or care.
An audience that doesn’t care is bad news for an EA.
So, what are some things that an EA needs to do when presenting to an audience to ensure they care about what is being said?
One: Get Data
Whatever you’re saying to the audience at hand is meaningless unless it rests on a foundation of data. The data may be qualitative or quantitative in nature, it may be mathematically precise or directional and squishy, but without something to establish your story as grounded in truth, you will come across as unprepared or worse. In any event, your case will be perceived as made up, untrustworthy and ephemeral. By extension, you will be perceived that way as well.
The data underpinning whatever your saying is going to naturally come from different places depending on the situation. A business case or cost related issue will invariably rely on data from Finance or Accounting or the Vendor Management Office, for example. Presenting information related to program or project status will require data out of JIRA or Planview or whatever tool is being used. Architecture views will depend on information from a Business Owner, Product Team, Data Steward, Application Team or other Architects. The main idea here is that there is data forming the foundation of the point you’re trying to make. Even a mere opinion or hypothesis is based on some bedrock of data. You may not need to present the data itself, but you need to use it and reference it.
Two: Know Thy Audience
This almost seems like a no-brainer or even a trope. Knowing the audience of nearly any situation would appear to be paramount. Wedding speech, book report, magazine article, architecture discussion. Everyone needs to know to whom they will be speaking and what those people might be most interested in hearing. We intuitively know this is a requirement and yet it is so often missed as an element of the storytelling.
Architects (Enterprise or otherwise) invariably care about the material they’re discussing. The mistake is believing or assuming that the audience cares as intently. They may. They may already be familiar with the content. This may simply be a status update on the latest digital transformation project and everyone is knowledgeable about the subject matter. And yet, even in these scenarios, there’s usually one or two people that haven’t attended every meeting or paid as close attention to the finer points. Generally speaking, the audience isn’t going to automatically care as much about the material as does the Architect presenting.
The key to this step is usually the hardest of all the points made in this article. The key is empathy. Thinking what you would do or what you would be interested in if you were the listener is not empathy. That’s simply you projecting your own headspace onto the audience. Trying to understand how that person is receiving your information is the key. Why do they care, what aspects will they be interested in. To do this requires knowing in advance who you will be speaking to and knowing their background, their education, their professional position, their issues or problems with the subject at hand… knowing, in effect, through what lens they will be viewing your content.
In his book “Supercommunicator: Explaining the Complicated So Anyone Can Understand,” Frank J. Pietrucha said that to be better at this part, work on ways to find commonalities with your audience and develop empathy with them.
Yes. It is hard. And it requires work. But fail this and no amount of data is going to matter.
Three: Frame it Up
Conveying the data behind any argument, position, perspective, draft architecture, case, model or deliverable will require some sort of structure. That structure will largely depend on the audience, what you know of them, and how they will likely want to consume the message.
You’ve armed yourself with data. You know what the audience is like. But you can’t regurgitate the data. Data is data.You’re trying to convey information. Even if you’re using raw data as part of the message, you still have to structure it so it supports the point you’re trying to make and resonates with the audience.
This requires a framework.
The framework can be as simple as:
- Tell them what you’re going to tell them
- Tell them
- Tell them what you just told them
It sounds flippant, but it is the simplest framework out there. With more experience comes the ability to structure stories according to commonly used frameworks such as the SWOT analysis, Porter’s Five Forces, Value Chains, the PEST analysis, BCG Growth-Share, Current State-Future State-Roadmap, the Gap Analysis and others. Google these if you’re unfamiliar. They’re really useful. In fact, start a slide library and keep it someplace you can always access it.
The structure of the story, the corralling of data to support the way in which the audience will most likely be able to consume it… absolutely critical to convincing someone you know what you’re talking about.
But while frameworks are helpful in structuring the narrative, they can often become ends unto themselves instead of merely the means. Limit yourself to 1-3 frameworks in any given argument. More than that and the story becomes muddled.
Four: Ask The ‘So What?’ Question
A data-driven argument that properly targets the audience and is well structured will still only get an Enterprise Architect so far. The story isn’t particularly useful unless it asks a question of the audience or answers a question they already have. In other words, unless it has value.
One method for getting to crux of the matter is to ask the ‘So what?’ question. For example, let’s say time-study and incident data shows us that in order to reduce the number of tickets being opened against application xyz, the UI design needs to be changed to make it easier for users to complete an order. That’s the story you’re telling to the assembled stakeholders. Yes, you’re backed by data from ServiceNow or wherever. Well ask yourself, so what? What does that mean or imply for the audience? Why should they care? In this case, it may mean an investment is needed by some team or that further analysis is needed to ferret out root cause, or something else.
Ask and answer the “so what?” questions before presenting. If you can answer that question, you have a better understanding of why the audience should care. You stand a better chance of engaging them and keeping their interest. If you know the “so what?’ and you answer it in your presentation, then the audience will know why it matters to them or what you’re asking them to do. At the very least you’ve opened the door to a valuable conversation about the path forward.
The Enterprise Architect needs to be asking why anyone cares about the topic at hand. If “so what?” can be asked at any point of the story, the story is incomplete and the presentation may go off the rails.
Fifth: Be Human
Let’s be honest, not everyone is great at recognizing how they come across to others. Enterprise Architects are usually good communicators and able to translate technical concepts to business speak and vice versa. But they can often be in their own heads, use their own lingo, and be perceived as too serious… like Professors or Academics or Management Consultants. The worst is to be perceived by the audience as having some sort of hidden agenda.
A story may have the data foundation, be targeted at the audience’s ability to consume, leverage a framework and be valuable to those listening, and yet still fall flat. The last piece is simple. It is to be a human being.
Being human in this context means that while the topic may be serious and complex, there can be room for levity. It means while the audience members may have conflicting needs, there is room for discussion and cordiality. Absolutism is usually a bad idea. Arcane technical language that no one can understand is counterproductive. The point of telling the story in the first place is to convince, connect, or confirm. Being the kind of person no one wants to be around isn’t helpful.
To sum up, for an Enterprise Architect to be better at presenting there are 5 main things to consider:
- Get Data: You have to have your story rooted in supportable data of some sort
- Know Thy Audience: Employ empathy to understand the people you’re speaking to
- Frame it up: Leverage one of the common frameworks to structure your story
- Ask the “So What?” Question: If you can’t answer why anyone should care, no one will
- Be Human: Try telling a joke or something. You’re not a robot.
There are plenty of other tips and tricks and whatnot to being better at communicating. But for Enterprise Architects who are called upon to address many disparate topic areas at varying levels of detail, these five steps will make for better conveyance of ideas, better reception of proposals and asks, better value delivered by Enterprise Architecture.