30 June 2021
As consultants, we are challenged by our customers not only with the issues that they are facing in the technology space but also how it affects the organisational structures and the culture. Based on our experiences, EventStorming is a great technique to expose the underlying cultural aspects of an organisation, while focusing on the value streams and technology. In this post, we are sharing what we have learned, by giving examples from our experiences that hopefully inspire you to use EventStorming as a cultural assessment.
But before that, a bit of theory (yeah, we know, can be boring, but we promise that it’s short)…
We operate in sociotechnical systems, where the social practices, our cognitive processes, and technology are at play. The definition used in this post is from Jabe Bloom:
A sociotechnical system can be summarised as the collision space between the social practices and cognitive processes with the technology, and how we (humans) perceive and use it. Think about smartphones (and their predecessors): what started as a mobile device to make calls on the go, evolved to have more capabilities, to a point where we are able to do most of our shopping on the device. There are even regions around the globe where the usage of smartphones is higher than computers. The use cases for the usage of a smartphone increased, and it shaped how we (society) operate: from making a call on the go, to being able to book a table in your restaurant of choice in a few clicks.
Looking from a distance, we can see our behaviour changing, and the value creation based on technological advancements. As our behaviour as humans change, the culture also changes. Culture lives between us, and, most of the time, we are not aware of it. It is the unwritten set of protocols and expected behaviours, and all of this knowledge is implicit. It becomes visible when a person doesn’t use the expected protocol when communicating with others.
Here, in The Netherlands, we start with greetings, a bit of chit-chat, and then dive into the content. Imagine if I skip the first two? Could feel awkward to the other party. Culture influences how we act, and in a sociotechnical system how we interact with technology and how we produce technology. Culture impacts technology. At the same time, every time that there is a technological enhancement, and it goes mainstream, it starts to affect culture. You can think about the smartphone and its impact on our culture. Technology impacts culture. It’s a dance, and most of the time we are not aware of it.
As such, it is necessary to take a holistic approach, and an ongoing effort, to maintain a sound culture. One-off interventions will not produce the awareness that is to sustain the culture within your organisation. Although it sounds simple, it is a complex challenge.
EventStorming is a technique created by Alberto Brandolini. Born inside the Domain-Driven Design community, it started to be used to create useful software models based on the Domain-Driven Design tactical patterns. It evolved as more practitioners adopted it, and we use it with a dual purpose: the original intent to create useful software models, and as a cultural assessment. The latter almost happened by accident. “How come?”, you may ask.
Let’s take a few steps, starting by explaining a bit about EventStorming, our facilitation approach and how it can be used as a cultural assessment.
EventStorming is all about collaborative modelling; designing boundaries, a shared language and understanding. It’s a technique that depends on the knowledge and behaviour of people. The sessions aim to have people with questions (usually teams that create software) and people with answers (domain or subject matter experts) in the same room. Having people together, and using EventStorming as a visual collaboration technique, triggers discussions about processes and the underlying software (famously known as build the right thing).
EventStorming is not the only tool in our toolbox, but it is our go-to tool to engage with organisations that want to improve their software development process (from any angle). As such, we prefer to have at least two facilitators in a given session. The idea is that one person actively facilitates the group, and the other(s) observe the group. When observing we are paying attention to non-verbal behaviour, facial expressions, who speaks up, or if there is any knowledge being suppressed. It works in-person as in remote, although the way to facilitate and the way to observe are different.
After each session, the facilitators debrief the group about what happened during the session. It is important to do it just after the session, where the experiences are fresh in the memory, where together with the session notes can generate new insights into the group dynamics.
As time went on, and we facilitated more sessions, we started to discover patterns based on the EventStorming sessions. At that point, we started to use our scientist hat, and we formulated different hypotheses for what we were observing. From there we run different experiences in different sessions, trying to understand if our hypotheses were correct or not.
Our conclusion was that EventStorming exposes group dynamics and cultural norms, which influences the process of creating software, in its essence the sociotechnical system. Interestingly enough, when we cross-check the observations with field interviews, we were able to verify the weak signals and collect more stories that allow us to have a broader picture of the organisation. Note that EventStorming sessions are usually not a longer term engagement. That means we will only observe a moment in time. Nevertheless we feel that these observations are a good foundation for follow-up conversations about culture.
Today we can state that EventStorming is one of the tools that can be used in sense-making, as described by the Cynefin community. Sense-making is critical to understand the different perspectives of people and the thinking/opinion overlaps (if any) in a heterogeneous group. Bring it closer to software, in an organisation that creates software, there are different opinions about the process or even the products to be created, and it is important to understand and manage the difference of opinions. We will share some of our sense-making techniques in a follow-up post.
There are lots of signals - weak and strong - that tell something about the culture within a group of people, team or organisation. Over the years, we have identified a couple of categories that affect the social, cognitive and technical aspects of the sociotechnical systems we’re living in. Allow us to discuss a few of them with you.
Ranking is a phenomenon that we all have experience with. How we perceive ranking, and whether it’s hindering or helping us, depends on our personal rank in different situations. Ranking in itself is not a bad thing. It helps us to make sense of the world and process information quickly. It can become a problem when we are not aware of its presence and effect on our culture.
The main distinction we have to make here is between explicit ranking (organisational chart position, job title, a formal level of power, etc.) and implicit ranking (gender, skin colour, perceived level of charisma, level of informal power, etc.). Ranking is also very much present in collaborative modelling sessions. It determines who speaks more, who takes the lead, who expresses an opinion and who decides not to share an opinion. That last example means that ranking can lead to missed opportunities, or suppressed knowledge in these sessions.
We are all conditioned to have a “symbolic ideal” of what is dominant/strong, and what is dominated/weak. That’s not a judgement, it’s just how society is wired. We all share a similar picture. The more traits someone has from this infinite list, the more we see this person subconsciously as dominant/strong. And we are conditioned to yield more power to dominant/strong people. (If you want to know more about symbolic violence, make sure to watch this talk from Romeu Moura).
Especially during EventStorming sessions, ranking is present because we invite a lot of people from different departments and ranks. This can hinder the process, if the group isn’t aware of it or if people play their high rank to their own advantage; speak the most, don’t ask others to pitch in, downplay other perspectives. It’s up to us as facilitators to spot these patterns and break them. We do this mostly by asking questions and sharing so-called weather reports: “what makes you say this?”. “Is there anyone that has a different perspective?”. “We observe that not everyone is participating in the conversations, does anyone recognize that?” Whatever you do, NEVER put anyone on the spot by addressing them personally. That can create a very unsafe environment.
If you’re aware of your rank, make sure you act upon it. First of all, own your rank. If you’re the CEO you are not equal. You own budgets and can make decisions. That’s fine. Do make sure that you share your rank. Because of your rank, others might feel hesitant to share their opinion and knowledge. Make sure there’s room and psychological safety to do that. Ask questions, ask for other opinions and make it clear that you are looking for expert opinions from the people in the group.
There is so much information coming at us that we need to process continuously. Preferably in an optimal manner. So what we do in order to make sense of the world - to cope with all this information without going crazy over it - is creating our own “subjective reality” from our perception of the input we’re getting. Our brain is searching for patterns, familiar situations and recognition in an attempt to simplify information processing. This often results in cognitive bias.
A cognitive bias is a systematic error in thinking that occurs when people are processing and interpreting information in the world around them. It affects the decisions and judgments that people make. You can imagine that especially in collaborative modelling sessions, (new) bits of information are flying around. So we can use all the help we can get to make sense of it. Cognitive bias is a familiar guest at these sessions. Recognizing them and being able to challenge and/or counter them will benefit the outcomes of your session.
As facilitators, it’s easier to spot cognitive bias, because you’re not “part of the group”. Signalling “functional fixedness” for example. This bias keeps people from seeing the full range of solutions to a problem and affects the ideas that are generated and considered. What we know and are used to hinders us from taking on new perspectives and limits ideation and problem-solving. After signalling it, we try to counter this functional fixedness by encouraging people to “model something wrong” on purpose. Express the wild and crazy ideas to see if we can overcome our limitations. A quick example: in our training, we use the cinema domain. As part of searching for solutions “outside-of-the-box”, someone suggested removing all seats and letting everyone enter the cinema in an inflatable bubble. This is what will counter functional fixedness. Plus, it’s super fun!
EventStorming shouldn’t be done in isolation, which means you’re always dealing with group dynamics, relationships, conflicts and polarities. Group dynamics can amplify ranking, power play and cognitive bias. It can also bring conflicts and polarities to the surface that need to be managed properly in order to get the most out of a collaborative modelling session.
Let us be clear: conflict is not a bad thing. It’s often very helpful if managed properly. To us, conflict doesn’t mean raging anger. It means that there are underlying dilemmas that result in opposite views. The problem we see very often in organizations is that conflicts arise because both/and polarity is treated like an either/or conflict (problem) that can be solved. ‘Where are we going for dinner?’ is an either/or conflict we can solve, ‘When do we go from collaborative modelling to coding?’ is a both/and polarity that we need to manage. If you want to know more about this important distinction and how to map polarities, this blogpost is everything you need.
During EventStorming sessions, it’s not uncommon that people are convincing each other of why they are right and the other person is wrong. But what if they’re both right, but neither is complete? Incompleteness combined with our conviction of being right (accurate)—fed by cognitive bias—is an important source of a potential problem when managing polarities. As facilitators, we always strive for completeness rather than being accurate; making sure all perspectives and knowledge is included on the (digital) brown paper. Facilitate the conversation so everyone can let go of their view in order to see the other. That way, we can move back and forth in that polarity and leverage the benefits of both sides.
How conflict and polarities are managed during an EventStorming session can provide a lot of signals about the culture within the team. Are people open to other views or are they holding on to their version of the truth? Is there room for counter arguments? Does the group find it more important to be right or to be complete? Do people feel safe enough to share their (minority) view and thereby adding a polarity? There are a lot of observations to discuss based on this group behaviour.
From our experience, EventStorming can help you assess the culture of a company. Due to the short term nature of these sessions, you have to be mindful of generalizing. Nevertheless, the signals and observations you collect will help you to continue the valuable follow-up conversations. Be on the lookout for ranking and power play within the group, cognitive bias affecting decisions and collaboration, and the presence or absence of (un)healthy conflict. Based on this, you can determine follow-up actions. Not only regarding the discovered process, but also in terms of organisational and team development.