Skip to main content

Search...

Diversity in Software Teams: More Perspectives in the Product

Diversity in software teams matters: homogeneous teams build products that reflect only one perspective. Design, psychology and sociology fill the gaps.

• • Updated: • 11 min read
Cover of the expert talk on 'Diversity in Software Teams: More Perspectives in the Product' with Claudia Nass Bauer and Richard Seidl.

Diversity in software development means building teams that include people from other disciplines, such as design, psychology or sociology, and not only computer scientists. Whoever is missing leaves a gap, because products reflect the values of the people who build them. Interdisciplinary teams make better decisions, since they cover the blind spots that any single perspective has.

Key Takeaways

  • When a software team consists only of computer scientists, the products it builds inevitably reflect only their values and worldview, and important design questions never come up.
  • Disciplines such as psychology, sociology and design bring methods that computer science programs barely cover, for example user research and ethnographic studies.
  • According to a questionnaire study, many female graduates in design, sociology or psychology don’t know that they could make a concrete contribution to software development.
  • Everyone has unconscious thought patterns and privileges, and becoming aware of them is the first step before any method or structure can work.
  • Small teams and agile ways of working actively support collaboration in diverse groups, because their structure keeps hierarchical communication patterns from taking hold.

Why Diversity in Software Teams Leads to Better Products

Diversity in software teams produces better software, because more perspectives end up in the product. When a team has only one perspective, that perspective shapes the result. Nobody intends it that way. It is simply an effect that no one fully controls.

People carry their values into design. Claudia Nass Bauer describes this with an example from her own work. Innovation and creativity rank high for her, sustainability less so. In a data-heavy system, she might celebrate a recommendation feature as a cool idea and hardly give a thought to how many resources it consumes. If everyone on the team shares a similar worldview, nobody asks whether a leaner version would do the job.

This is where diversity makes a difference. It brings together values, methods and experience that no single discipline covers, and it keeps important aspects from getting lost when decisions are made.

What Design, Sociology and Psychology Bring to Software Development

The benefit of diverse teams shows up in their methods: people from different degree programs bring different tools. Design teaches other methods than computer science, and sociology and psychology teach others again. That mix helps teams design better software.

User research is a concrete example. Conducting interviews, running ethnographic studies, talking to real users: these are skills from the social sciences, and many computer science curricula barely touch them.

In practice, this work is often done by people who never learned it and picked it up on the job. Claudia Nass Bauer puts a blunt question on the table: who is actually doing this? The answer is often sobering.

How the roles are split matters here. The point is not for computer scientists to learn sociology and design on the side. Loading too many skills onto one person doesn’t work. It is better to bring people with different knowledge together and build real collaboration between them.

Diversity Creates Friction, and That’s Part of the Price

Different perspectives mean more conflict, not less. Someone with a design background wants to approach things differently than someone from computer science, with other methods and other criteria for decisions. That causes friction.

Human instinct pulls the other way. We like to surround ourselves with people who think like us, because things move faster. On a rational level, the value of diversity is obvious. In everyday work, though, there is still that thought in the back of your mind: now I have to discuss everything, now there will be other opinions. The tension is emotional, not logical.

That’s why diversity requires skill building. Communication skills are one side of it. The other is dealing with the unconscious thought patterns that everyone brings along.

Minorities on the Team Face Extra Pressure

In a strongly male-dominated field, members of minority groups carry additional pressure. The only designer on a team who struggles to get her ideas heard will often look for something else within a year or two. Being the lone fighter doesn’t last.

Testing shows a particular pattern. The share of women is comparatively high there, and research offers one explanation: when things get uncomfortable, men like to put women forward for these tasks, because they are good at raising and discussing difficult topics. In the short term, the team benefits. The women affected benefit less if they are expected to step up for every awkward issue while everyone else sits back.

So the task is not to play one group against another. It is to organize collaboration in which the different roles and perspectives actually count.

Awareness of Bias and Privilege Comes First

A more open team culture starts with awareness, because the processes that matter most happen unconsciously. Nobody is free of bias. Everyone is prejudiced in one way or another.

Privilege is hard to claim for yourself. You either have it or you don’t. In our society, being white is a privilege, and so is being a man, and there is no serious way to deny that. Being aware of that advantage changes how you act in specific situations.

“I already have a few advantages per se, which I can perhaps use, not only for myself but also to help my team or others who may not enjoy these privileges.”

(Claudia Nass Bauer)

The attitude that follows from this is not that of a judge but of a supporter. You can use privilege to back up colleagues who don’t have it.

And here comes the uncomfortable part. Using your privilege for others can mean giving up or sharing some of your own advantages. Not every organization and not every person is ready for that. Saying that a colleague without a computer science degree has just as much right to make decisions about a product is easy. Living by it is hard.

Simple Methods That Break Up Communication Patterns

Once there is awareness, concrete methods help soften stereotypical thinking in day-to-day work. None of them fixes the problem once and for all. They only work if the team keeps them up over time.

A few approaches that work in everyday team life:

  • One person is given the job of noticing when stereotypical remarks come up.
  • In meetings and dailies, everyone gets a fixed amount of speaking time before the main discussion starts, so that everyone has room to talk.
  • Retrospectives cover not only features but also collaboration: what went well, where things got stuck, where someone needs support.

Behind this lies a finding from research on communication systems. In large meetings and in heavily male-dominated groups, hierarchical communication patterns take over, and men tend to be well practiced in them. In small teams, non-hierarchical patterns are more common, and they encourage collaboration and bring everyone along.

That gives teams a practical lever: agile methods with small teams are better suited to diverse collaboration. With five to seven people, hierarchical communication has little room to develop. The small group forces a different way of working together.

What doesn’t work is letting go and hoping things will sort themselves out. A culture that supports diversity grows over the long term and has to be actively maintained.

Why Career Changers Often Don’t See Their Potential

Many qualified people from other disciplines simply don’t know that software development needs them. The WISE research project, run by Mainz University of Applied Sciences, Fraunhofer IESE and LMU Munich, looked into this with questionnaire studies. The result: most female graduates in sociology, design or psychology had never considered that they could work in software development.

There are two reasons. First, the curricula in these subjects are rarely interdisciplinary. Students go deep into their core topic but don’t see where else that knowledge could be applied. Second, software development is seen as a highly technical, male-dominated field, and many don’t picture themselves in it from the start.

The project addresses this gap with two formats:

FormatGoalParticipants
Solar SessionsShow female students that their social science methods fit into software developmentFemale students and graduates
Activation workshopsWork on a real problem from a company and bring both sides togetherSMEs and recruited female students

The activation workshops last between two and five days and are run by Fraunhofer IESE as creativity workshops. A company brings a topic, such as an old product that needs modernizing or an idea for a new service. The students get a first taste of how creative software development can be, and the companies get to know potential talent.

Industry and Education Have to Work Together

Winning new talent is pointless if those people have nowhere to go afterwards. That’s why WISE actively involves companies. Many small and mid-sized companies still lack interdisciplinary teams, and the activation workshops bring both sides together on purpose.

The need is real. There is a clear wish for more interdisciplinarity, more women in software development and more diverse teams. Behind all of it stands the argument that carries the whole discussion: better products.

For teams, this means taking an honest look at how they are made up. Where is only one perspective represented? Which stereotypes have become ingrained? Where would another discipline change the discussion? Answering these questions is the first step toward more diversity.

Frequently Asked Questions

Why isn’t a team made up entirely of computer scientists enough to produce good software?

A team passes on the values it brings to the table. Claudia Nass Bauer describes this using herself as an example: Innovation and creativity are strongly pronounced in her, while sustainability is less so. In a data-intensive system, she therefore hails a recommendation feature as a cool idea, while its resource consumption hardly figures into her thinking. When people with similar worldviews work together, no one asks about the more resource-efficient alternative.

What skills are most often missing from software teams?

User research is the most glaring gap. Conducting interviews, carrying out ethnographic studies, surveying real users: these methods stem from the social sciences and are rarely featured in computer science curricula. In practice, this work is often handled by people who never formally learned it but picked it up on the job.

Should computer scientists simply pick up design and social science methods on the side?

No. Piling too many skills onto one person doesn’t work. The better approach is to divide roles: bring together people with different areas of expertise and foster genuine collaboration, rather than expecting computer scientists to also cover sociology and design. The benefit of diverse teams lies precisely in this mix of methodologies.

Does diversity make teamwork more difficult?

Yes, and that’s part of the cost. Different perspectives mean more conflicts, not fewer: Someone from a design background wants to approach things differently than someone from computer science, using different methods and different decision-making criteria. The human tendency is to gravitate toward like-minded people because it speeds things up. This tension is emotional, not logical, and requires developing communication skills.

Why is the proportion of women in software testing comparatively high?

There’s a pattern behind this that research points to: When things get uncomfortable, men tend to suggest women for these tasks because they’re good at raising and discussing difficult topics. In the short term, the team benefits from this. For the women involved, however, it’s stressful to have to step up every time a sensitive topic arises while others sit back and relax.

What are the concrete benefits of becoming aware of one’s own privileges?

It changes how you act in specific situations. It’s hard to attribute privileges to oneself: you either have them or you don’t. This awareness doesn’t lead to a judgmental stance, but rather a supportive one: using your advantages to support colleagues. It becomes uncomfortable when this means giving up some of your own advantages, such as sharing decision-making authority with a female colleague who doesn’t have a degree in computer science.

What team size fosters the best collaboration in mixed-gender groups?

Five to seven people. Research on communication systems shows that in large meetings and heavily male-dominated groups, hierarchical communication patterns (in which men are well-trained) tend to dominate. In small teams, non-hierarchical patterns are more prevalent, which foster collaboration and inclusion. Agile methods with small teams are therefore better suited for diverse collaboration.

Why do so few female graduates in design, sociology, or psychology apply for jobs in software development?

Most are unaware that they are needed there. Survey studies conducted as part of the WISE research project show that female graduates in these fields do not even consider a career in software development. There are two reasons for this: The curricula are rarely designed to be interdisciplinary, and the field is perceived as highly technical and male-dominated, so many do not see themselves fitting in there from the outset.

Share this page

Related Posts