Visualising informal influence
Where we look at how we can uncover undisclosed power lines and influence structures in our projects and workplaces to aid our software design.
Many have written and talked about how social structures in organisations influences the software we create. From Conway’s Law1 to Domain Driven Design2, and Diana Montalion’s book Learning Systems Thinking3. But I have so far not seen anyone write about how we can discover the implicit relationships we have that also play a role in design.
Last year I tried something out with two tech leads, something I’ve now started to think of as Influence Visualisation. With the intended outcome of discovering the unspoken, the intrinsic incentives4, the hidden power differentials5, the hidden allegiances and agendas6, that sometimes trips us up. Not in order to change them, not to find culprits or people who have done something wrong. Simply as a way to figure out what is invisible before it catches us off guard.
Influence Visualisation as an idea
The idea has its roots in something I do when I join a new workplace, as a sense making tool. I draw my own org-chart, including both official and unofficial connections. I use this to help me navigate the social landscape I’m in.
After reading the book Learning Systems Thinking by Diana Montalion it struck me that perhaps the same practice could be used to identify new and useful boundaries in software design as well.
As I joined forces with a tech lead to navigate a politically charged initiative I suggested we do the visualisation together. To help us make sense of the situation, and what agendas drove what decisions in the project.
It provided us with a lot of clarity. The tech lead was also free to share this information with whoever they wanted. I always asked their permission given the information could put them on the spot, but not me.
In that particular project it did not provide much information we could act on from a software design perspective, but it did surface important information about conflicting agendas in the project. Information that allowed us to navigate and prioritise things in ways that help them not come to a head. It’s not that any of the agendas in them self were wrong, only that they sometimes pulled in different directions.
A bit later I was mentoring another tech lead. They were unsure about how to divide some of the services, as well as the part within some services. We looked closely at the domain boundaries, which gave us ample information. But during our conversations I could detect some hedging in his reasoning. So I decided to do the same Influence Visualisation with them. This made the implicit knowledge they had clear for both of us. And it helped influence both the architecture and the design of the software. Sometimes in surprisingly detailed ways. Given that some power lines within that social context risked ripple effects that cut through domain boundaries it allowed them to suggest detailed design choices in some part of the services to protect against change. Boundaries that in no way compromised the quality the code, only adjusted it a bit. Yet made sure that when one fickle person changed their mind that would not ripple through to another part of the same module.
Influence Visualisation as a modelling technique
The modelling is kept very simple. I’ve worked on a whiteboard. Usually digital but sometimes physical, which I’ve then transferred to a digital board. This so we can continue to work with it as we learn more over time. This is a technique to help implicit invisible knowledge become visible and explicit. As such it needs to evolve as we learn more, and becomes an important tool in that learning.
I’ve used boxes to visualise people, either as individuals or as groups depending on what’s important. I’ve often used colours to create groupings, to capture stuff like departments or other things that group several boxes together. This can be especially useful when also using spacing to denote closeness. For example, putting the software as a circle or ellipse in one place and the people most involved closer, people less involved further away. Then using colours to show who belongs to what reporting line, department, or company.
I use lines to make connections between people/groups. Using line type to show if an influence is explicit (I.E. a direct/indirect org chart reporting line). Using line colour to denote how powerful the influence is. And using arrows to see in which direction power flows, both informal power in the form of who listens more to who, and formal in terms of who has the power to overrule who.
I have always made sure to maintain a legend, letting it evolve as we work. I know how easy it is to forget what’s what between sessions, so it’s an important means to persist memory between sessions.
That’s it, I have not settled on any formal colour schemes or anything like that. Whatever felt good whilst modelling is what we used. Sometimes changing from session to session, which of course also meant I had to update the previous work when we discoverd a better way to visualise.
The space needed for the conversation to happen
As you may already have realised this exercise can surface some rather sensitive power structures. Structures that participants don’t feel safe sharing with just anyone. To be successful we need to create the space where this can happen.
I have usually started with some preparation. Looking at existing org charts and created an initial board with what I’ve found there, and perhaps some things I’ve learned through word of mouth. This has helped open the conversation. Asking the participant about what’s missing and incorrect. Which is usually close to everything.
I am also very mindful about creating a brave space7 where we can share even controversial knowledge safely. One of the things I highlight is that I don’t own the findings. I don’t share them unless I have explicit permission to do so. On the other hand, they are free to share this with whoever they want. This is their knowledge made visible. And it’s always been them who has skin in the game, not me. I’m there as a facilitator and visualiser. And I want us to be in a brave space where we can discover as much as possible.
I tend to steer the conversation a bit. Trying to discover the power structures we have not yet named or visualised. I sometimes explain concepts like power differentials, and how intrinsic incentives can affect our thinking. How allegiances and agendas sometimes cloud our judgement. Not because any of it is necessarily wrong in the given context. But because when we can see them at play it’s easier for us to figure out how they affect us. And how they can affect the software we build in that social context.
What I haven’t yet figured out
So far I’ve only tried this with one other participant. Where I’ve been the facilitator. So I’ve not had any skin in the game. What I’d like to try next is to do it with more than one person. There’s a few variants here. And I’d like to know how each work. First, there is the option of doing it with one other, then inviting someone else to provide even more information. And in that way expand the group, one at the time. Never being more than two in each session. Then there is the option of inviting more than one into the same session. However, as soon as the group grows, creating a brave space becomes more challenging. The selection of people and size of the group has to be carefully considered to ensure there is enough trust to surface what is important.
I’m also hoping to use this in situations where I have real skin in the game. I think that will change the dynamics quite a bit. It also puts a strong emphasis on me to be very clear about what power differentials I can identify where I am in power. And being a white, senior, middle-aged man, creates quite a few.
I can also see that this may be a useful technique as a retrospective format. Again, brave spaces can be challenging to create so care must be taken to make sure everyone feels safe enough to surface what matters. It’s also very important that what is shared do not have repercussions for the individuals who share. That would erode any trust earned.
I would also, very much, like to learn from you. Have you encountered anything like this before? Have you done it your self? Have you tried any of the different variations I have not? Or will you do so? From software context or other contexts. Please share your thoughts and experiences. I want to learn more about where this can go and how it can or has been used. As well as if you find it useful and/or inspiring to try out. You can reach me through the links in the footer.
Intrinsic incentives are the internal motivations that drive behaviour — personal satisfaction, values, professional reputation, career ambitions, or loyalty to a colleague — as distinct from extrinsic incentives like salary or formal performance targets. Both shape how people act in organisations, often more powerfully than the formal incentives anyone has written down. Incentive on Wikipedia ↩︎
Power differentials refer to the uneven distribution of influence between people or groups — both formal, such as who can overrule who, and informal, such as whose opinion carries weight regardless of title. Kent Beck has written extensively about this in a software delivery context. His post Dimensions of Power is a good starting point and an eye-opening read. Dimensions of Power by Kent Beck ↩︎
Allegiances and agendas in an organisational context refer to the informal loyalties and goals that shape how people act, often independently of their formal role. An allegiance might be loyalty to a colleague, a technology, or a way of working. An agenda is the underlying goal someone is pursuing, which may or may not be the same as their stated one. ↩︎
The concept of brave spaces comes from work by Brian Arao and Kristi Clemens who wrote about it in 2013. The original chapter (from a book called The Art of Effective Facilitation) can be found here. I don’t use it in the context they describe, but I have borrowed the term from them. It’s a well worth read, as is the criticism of it. ↩︎