At the DDD Europe 2024 conference in Amsterdam, Diana Montalion and I co-hosted a hands-on workshop titled Using The Iceberg Model to Improve Sociotechnical Systems. We had an agenda for this workshop that was hidden in plain sight: to analyze the lack of gender diversity in the social system of the software development industry itself.

‍

In this post, you’ll learn how to use the iceberg model to glean insights about all kinds of complex situations. I’ll also describe what we learned as a group about the impact of patriarchy on our industry, and how we might change things for the better.

‍

What’s the problem?

I’ve been working in software since the late 1990s, and all the teams I’ve worked in have either been exclusively white and male, or skewed heavily in that direction.

‍

These aren’t just anecdotal observations, they’re a pattern: a 2022 survey found that a shocking 91.88% of software developers worldwide are men. In the USA it’s 78% according to Zippia, and only 8-9% of women hold senior technical leadership positions. When GitHub surveyed over 5000 Open Source contributors in 2017, over 95% of them were men. This cuts across race and gender: black women CEOs in technology are paid 38% less than their white male counterparts.

‍

Apart from anything else, I think this situation makes our industry boring. Working with people who all have homogeneous backgrounds just isn’t as much fun as when they can challenge and surprise you with insights and ideas from their diverse perspectives.

‍

We also could talk about all the research out there demonstrating that diverse teams produce better results, and all those embarrassing stories about companies who shipped products without thinking about how half the population would use them, but for me there’s a much bigger point.

‍

‍

We exist in a sociotechnical system.

‍

As software developers, we have an ever-increasing influence on shaping society through the technology we build. That gives us immense power. Surely everyone, regardless of the age, ethnicity, gender, sexual orientation or wealth they were born into, should have equal access to that power and influence? Otherwise, we risk creating a reinforcing feedback loop: we build technology that works best for the people who have influence over designing it, giving them even more power and influence, and so on.

‍

Not only is that unjust, it’s risky: from a pure percentages standpoint, the less people who can influence technology, the less great ideas we will be able to realize to solve society’s problems.

‍

So how did we get here?

If we focus just on the lack of gender diversity in the software industry, here’s one clue to why things are as bad as they are, in the USA at least.

‍

In this podcast, NPR’s Planet Money explored why so many women started dropping out of Computer science majors at universities across America around the mid 1980s.

‍

‍

What NPR’s team discovered was that bright young women starting out in computer science classes at that time found themselves at an immediate disadvantage. Where the women were working using computers for the first time, the young men they were sitting alongside had already gained a head start from having home computers. This was the time when computers first became affordable, and they had been marketed almost exclusively to men and boys. In the ‘90s, researcher Jane Margolis interviewed hundreds of computer science students at Carnegie Mellon University. She found that families were much more likely to buy computers for boys than for girls — even when their daughters were really interested in computers.

‍

As the cultural stereotypes compounded, such as with '80s films like Weird Science and War Games where a lone male nerd saves the day, this reinforcing feedback loop sent women a signal that computing was not for them. By the mid-1990s, Carnegie Mellon’s computer science was 93% male.

‍

The role of men

A couple of years ago I read the book The Gender Knot by Allan Johnson. That book really opened my eyes to the destructive impact of patriarchy. Johnson describes patriarchy as “a social system of dominance, control and fear.” Not a deliberate conspiracy by anyone, just a stable state that our social system has settled into.

‍

This social system likes to put people into boxes so that it’s clear who, according to its norms, we should fear and who we can dominate. Holding this system in place are social norms, customs and rules that act almost invisibly to sustain gender disparities: giving power to men, oppressing women and restricting us both to rigid norms of masculinity and femininity. Both men and women uphold these social structures, but as Johnson explains in his book: because men are generally given the most power and influence in this system, we hold the keys to change.

‍

As a man with some influence in the software industry, I’ve started to try to use my own privilege to draw attention to this system and its destructive impacts. That’s what we hoped to do with this workshop, by gathering 75 senior software practitioners in a room to study the problem.

‍

The Iceberg Model

The iceberg is a metaphor, representing the fact that in a sociotechnical system, most of what drives, shapes and perpetuates that system is hidden from view.

‍

When using the iceberg to create a model of a system, we try to categorize our observations and hypotheses about it into four categories: events, patterns, structures and mental models.

‍

Events are what we see. Patterns and trends are where we see certain kinds of events happening repeatedly, or with new frequency. Structures are the rules, or customs, or even physical constraints that influence those patterns. Mental models are the thoughts that lead us to create or at least tolerate these structures.

‍

For example, suppose we’ve found a bug in production on our software system. That bug would be a visible event.

‍

Suppose that, rather than being just a one-off, this bug is part of a pattern. We’ve noticed that we keep getting bugs in one particular area of the system.

‍

When we go and talk to the people who work on the system, it turns out that the team responsible for that part of the system tends to work as individuals, each developer toiling in their own lonely furrow. What’s more, they don’t really use any automated tests, relying on an overwhelmed manual tester.

‍

When we dig further, a conversation with the team’s manager reveals their belief that the team will be more efficient when they work solo, rather than teaming in pairs or ensembles. They think that test automation is a pipe dream, and that the developers are already busy enough without having to write test code as well as application code. They’ve heard of test-driven development but they think it’s a ridiculous and expensive idea.

‍

Here we can start to see the relationship between the visible event and the underlying mental models that may need to change if we want to see different events happening in this system.

‍

Very often, when we intervene in a sociotechnical system, we make things worse.

‍

‍

People who know a system often know intuitively where to find leverage points, but they are often pushing the change in the wrong direction.
— Jay W. Forrester

‍

Blaming the wrong things

For example, this team’s manager, responding to the incident caused by this bug, might blame the developers’ incompetence, and advocate for hiring a second manual tester for their team to catch more of their mistakes.

‍

As a result, the developers who had seen that their manual tester colleague was overwhelmed and were doing their best to test their own code before they called it done, now feel safe to throw their first solution over the wall and let someone else find the bugs in it.

‍

Sadly, even though there are twice as many testers as before, they’re still only human and aren’t able to completely regression-test every feature of the system every week.

‍

As a result we get more production defects, not less!

‍

Model the whole iceberg

This is why it’s so important to model the whole iceberg. By digging down to the underlying structures and mental models, we gain greater situational awareness and reach deeper insight about how we can meaningfully intervene in the system.

‍

‍

Applying the Iceberg Model

Once we’d introduced these concepts to the group, we ran our workshop in three phases:

1. Model the current system
2. Model the desired system
3. Look for leverage points

‍

We started by building a model of the current system, starting from observable events and working down towards mental models.

‍

Next, we invited our workshop participants to envision the same system if things were different and gender (or any innate trait) had no impact on whether someone would become a software developer. We asked them to build another iceberg model of what that system might look like.

‍

Finally, we brainstormed leverage points where we could introduce a change in the current system, with the potential to start moving it towards something more like the desired system.

‍

Let’s talk about how that played out in practice with the specific event and system we wanted our workshop to investigate.

‍

Modeling the current system

First of all we drew our icebergs on large flip-chart sheets and, working in groups of 3-5 people, we started to populate ideas for patterns, structures and mental models underlying this event that 91.88% software developers worldwide are male.

‍

Here’s an example from one group:

‍

We encouraged people not to get too hung up on finding the exact right category for each idea, so much as trying to use it to generate more ideas to enrich the model. Some groups captured other events, with women telling stories of everyday sexism they’d encountered.

‍

To help discern mental models, we suggested groups try to imagine “what if you had done this on purpose, what would you have been thinking?”. We found this was a helpful prompt to stimulate creative thinking.

‍

I took photographs of each group’s sheets and synthesized them into the model below.  I think it offers some fascinating insights into what’s wrong with our industry today:

‍

I was particularly struck by the mental model “this is nature”. How many people must shrug and assume things are the way they are because it’s the natural state of things, rather than something we’ve created for ourselves and could be changed? I’ve learned that this is called the naturalistic fallacy.

‍

Modeling the desired system

Next, we invited our workshop participants to envision the desired system: what would it look like? We tasked them with capturing events to reflect what that reality could look like, what patterns you would see, the underlying structures that could create those patterns, and the kinds of mental models that would support those structures.

‍

Here’s another synthesis of what they came up with:

Many groups had similar thoughts about structures around childcare, parental leave and access to education. I loved watching groups of men and women exchanging ideas about how they could work together to effect change.

‍

Looking for leverage points

Finally, we asked groups to come up with ideas about where they could intervene in the current system, to try and change it to be more like the desired one.

‍

Here’s some of what they came up with:

• Pay women equally!
• Use the “yes, and” communication pattern
• Listen
• Focus more on taking care
• Read Proposals for the Feminine Economy by Jennifer Armbrust
• Soft landing after maternity leave
• Equal maternity / paternity leave

‍

I wish we’d had more time in the workshop for this section. By this point we really only had time for a quick conversation, so we didn’t get a chance to dig too deeply into tangible actions we can take in our own workplaces.

‍

Still, the ideas around equal access to pay and parental leave feel very possible to me, and I can only see the upside.

‍

In Conclusion

The iceberg model is a tool you can use at any level to understand a sociotechnical system, but I think it’s best to apply it with an eye on your circle of influence: while it’s useful to understand the context of the broader system, leverage points are only any use if we have the power to pull on those levers.

‍

The four categories in the model don’t have hard boundaries. Instead, what you really have is a gradient from very concrete events, to more abstract mental models. The further you go from concrete to abstract, the more powerful the levers become, but the more difficult they are to change. Still, even changing mental models is possible.

‍

It was striking to me how many of the mental models outlined in the groups’ desired system resonate with the culture I’ve found since starting work here at Mechanical Orchard. We expect high standards from each other, but we are also unfailingly kind, generous, and curious of differing perspectives. It’s a fantastic, creative environment to work in, and one that I witness on a daily basis how powerful it is at solving very hard problems.

‍

For a long time we’ve thought of software development as an engineering discipline, with the machine as the metaphor for the software system we’re creating and even the organization itself that creates it. As I start to see things more as part of an interdependent sociotechnical system, it seems to me that creating software is much more like playing in a jazz ensemble or growing a garden: it can be messy and complicated, and we often can’t control everything. What matters most, however, is building strong collaborative relationships with the people around us, whatever their background.