By Paul Preiss
This article will explore one of the most critical areas to architect success, stakeholders and specifically complex stakeholder environments. This is a topic that we explored during the development of the BTABoK and one we have continuously explored through events and communities across Iasa.
All business requires good skills with handling people, but not that many of those jobs require handling people under constant change. The architect, or at least the good ones, are at the heart of constant transformation and change. As I often say, ‘good architecture is making the best possible decisions at high velocity, within complex ecosystems of business, technology and people.’ That means the architect deals with a lot of people within stressful scenarios… Imagine trying to get good requirements out of a banking branch manager, who is losing their job because of the system you are building.
This shows up in deeply technical environments as well. Geeks are notorious for their technical egos, their ‘agile’ decision making (‘let’s just whiteboard it’) and for their cognitive biases (‘No Java is the Better Language, No it’s Go, No it’s…’)… And by ‘their’ I mean mine… So the architect working with even 2-4 teams has to deal with a huge amount of people management to extract and transform and design the best outcome.
If you are interested in learning this approach we have courses starting online next week and in person in Seattle (Sept 12 for 5 days). You can register at iasaglobal.org.
Understanding the Stakeholder Environment
This means that we need a repeatable and manageable stakeholder-driven architecture practice and set of competencies, and we need to get better at them all the time. This practice needs to be methodical, especially for those of us who are not natural with people… which is why in the BTABoK we have created a standard stakeholder-driven approach and methodology. The point is, the architects HAVE to manage these stakeholders to achieve:
- Better decisions, faster
- More inclusive information
- Strong leadership and communication
- Recognition of architecture value
- Desired outcomes
- Fewer power-based dynamics and more value-based decisions
Why Empathy Comes Hard For (some of) Us and That Is OK
While you may be a natural people person, some people are not. And even being a natural has its limits and some of us get exhausted by people interaction even when they are good at it. I, fortunately, fall right in the middle of the spectrum. There are competencies (see the competency model in human dynamics) even with people skills. Some people are excellent public speakers but less good and one on one. Others are great at leadership but poor mentors/teachers. Etc etc.
The Stakeholders of an Architecture Practice
Let’s talk for a second about stakeholders. Who is a stakeholder? Who is a client? We use very careful naming conventions for architects:
- The client is always the person/company who the architect is doing their jobs for (note: this is not always the employer… as in consulting),
- The customer is always the customer of the client (for example a customer of a bank),
- Stakeholders are always the people who have either power or interest in the architects work,
- And users are anyone who uses the output of the product/project the architect is working on (this could also be a customer/stakeholder).
Get in the habit of NEVER using these terms differently. When you call stakeholders customers they start thinking that you work for them.
The stakeholders then of an architecture practice are all of the people who have significant power/interest in the work of the architects. These people generally define the success of the practice in early stages.
For example, lets say a bank employees 100 architects. The average number of important (I will show you how to derive this shortly) stakeholders for an architect is between 3-5. Oh you may have many more, but when you do the math only a really have high power/interest over your work. So, the architecture practice, would have roughly 400 important stakeholders (with a lot of overlap… so take the number down to 250-300). Those are it, if they say architecture is valuable… well shared opinion is fact.
Stakeholder-Driven Architecture vs Human Dynamics
You should understand there is a difference between a method and the competencies. Leadership is a competency that you can develop over time. So is communication. So is listening well, etc. The SDA (stakeholder-driven approach or architecture) is a suite of tools and methods for understanding and managing a group of stakeholders of a product/project/program. It is more a method than a competency. So don’t mistake the tools for being good at using them. You have to develop in both.
The Intersection of People, Power and Change
The most basic element of our method is understanding people, power (or influence), and change. That is that the average architect is often within a dynamic group of people of all levels. Those people have different influence and interest over things that are changing. The most obvious and common of these is the solution or product level, but that in reality those impact capabilities, value streams and outcomes which may be the center of attention another architect.
Building the Stakeholder Driven Approach
The approach is divided to help understand and utilize it more effectively. We have numerous tools that interact with each other but I am going to focus on the basic Core approach first, then follow up this article with methods for working on initiatives, stakeholder ecosystems, and finally methods for architecture practices.
In the Foundation (Core) Level of the BTABoK we teach the primary stakeholder management tools. These are the Power/Interest Grid, Stakeholder Management Plan, Stakeholder Empathy, then adaptations of customer tools for Stakeholder Personas and Stakeholder Journeys.
Individual Architect Usage
List all of your stakeholders either in the stakeholder power/interest grid. This is easiest if you work visually.
Optionally working only in the stakeholder management plan, list the stakeholders by name or by role and enter a rating on their power over your work and their interest in your work. For example, the CEO may be very powerful but not interested. I almost always use a scale of 1-10 for everything.
Once you have developed the basic list you will want to define your current and target state for the stakeholder.
Stakeholder Empathy
For key stakeholders, you may want to understand them in a deeper way. This is where empathy can really come in handy.
The stakeholder empathy card is adapted from the customer empathy map but taken from a stakeholder perspective. It is possible to do this based on a stakeholder persona in cases where a group of stakeholders is key but is also very large.
The persona card allows you to take stakeholder communities or roles and create an ‘example’ stakeholder who represents that role. This helps to personalize ‘developers’ or ‘bank managers’ within the stakeholder community.
There is a lot more depth to cover in connecting these tools to your product and project so feel free to follow this series, research the BTABoK and Learning Shots or attend one of the Core Courses.