
Inclusion in tech, especially within software teams, shapes more than culture. It influences what gets built, how products function, and who they serve.
For many organisations, there’s still a noticeable gap between the intent to improve inclusion in tech and the lived experience within teams. Bridging that gap calls for a shift in how systems, decisions, and behaviours are shaped over time.
Ayesha Bagus, Head of People and HR Director at KRS, shares her thoughts on building inclusive software teams, the gap between intent and reality, and why this gap directly impacts the quality of what teams build.
What Inclusion in Tech Actually Means
Inclusion in tech is not just about representation. It refers to creating environments where diverse perspectives are actively included in decision-making, product design, and day-to-day collaboration.
In inclusive tech teams, people are able to contribute fully, without needing to filter or adapt who they are to fit in.
The Reality of Inclusion in Tech Teams
I grew up in post-apartheid South Africa, and that context shapes how I see the world, especially the organisations I work in and the industry I’ve chosen to be part of.
Because of that, I find it difficult to engage with inclusion as an abstract concept or a line item in a transformation strategy.
I’ve seen what happens when exclusion is built into systems and structures, and what that does to people over time.
How Team Diversity in Software Development Impacts Quality
One of the clearest ways inclusion in tech shows up is in the quality of the software we build.
There is a well-known MIT study, Gender Shades, which found that facial recognition systems had significantly higher error rates when identifying people with darker skin tones, particularly women.
The reason was simple: The systems were trained predominantly on lighter-skinned faces.
The people most likely to be affected by those errors were not in the room when the systems were designed.
This is not an isolated case. These examples highlight what happens when team diversity in software development is missing from the process:
- Period-tracking apps have been shipped without meaningful input from users
- Voice recognition systems struggle with certain accents
- Products often reflect a narrow set of assumptions
These are not just small oversights but predictable consequences of building software teams without diversity of perspective, experience, and identity at the table.
“When you build without diverse voices, you do not build for everyone. You build for a version of everyone that was always too narrow.”
How Team Diversity Improves Software Quality
The tech sector has made genuine progress in increasing the representation of women and people of colour in engineering and leadership roles. That progress matters and is worth acknowledging.
But representation and belonging are not the same thing, and this remains one of the biggest challenges in inclusion in tech.
Someone can join a diverse organisation and still spend months wondering:
- Do my ideas carry weight?
- Am I expected to fit in or help shape the culture?
- Is my perspective genuinely valued?
Research supports this.
Maslow identified something that feels intuitively true: people cannot operate at their full capacity, cannot create, problem-solve, or innovate, when their more fundamental needs for safety and belonging are unmet. Daniel Pink’s research on motivation makes a related point: autonomy, mastery and purpose are the conditions under which people do their best work.
But none of those conditions can fully take root in an environment where someone is spending energy managing how they are perceived rather than contributing what they know.
“You cannot ask someone to bring their full thinking to a problem while asking them, implicitly or explicitly, to leave part of themselves at the door.”
True inclusion in tech means:
- Different communication styles are accepted
- Lived experience is valued
- Cultural perspective is seen as an asset
That takes intention, not just good intentions.
What Inclusive Software Teams Look Like in Practice
At KRS, building inclusive software teams is not treated as a standalone initiative. It is embedded into how we structure work and how teams operate day to day.
That means looking beyond who joins a team and focusing on how that team operates. In inclusive tech teams, this shows up in:
- How ideas are surfaced
- How decisions are made
- Whether all voices are heard
Here are some examples of how KRS puts this into practice:
Developer Bootcamps
We bring engineers from different teams together, not only to build technical skills, but to strengthen relationships across the organisation. This kind of cross-collaboration creates the conditions for better thinking and more effective problem-solving.
Women’s Forums
We host monthly forums that provide female employees with a safe space to connect, speak openly, and raise issues that may not always surface in formal channels. The insights from these sessions regularly inform how we shape both policy and day-to-day practice. For example, where possible, we aim to ensure that female developers are placed on teams with other female colleagues to support a more inclusive and supportive working environment.
Menstrual Leave
We have also introduced menstrual leave. It is not positioned as a perk. It is an acknowledgement that bodies are different, that those differences have real effects on working days, and that treating everyone identically is not the same as treating everyone fairly.
“Equity is not about giving everyone the same thing. It is about giving people what they actually need.”
Alongside these initiatives, the focus remains on creating an environment where people can bring their full selves – their culture, humour, and perspective – without needing to filter or adapt constantly. Our 35-hour work week also plays a role in supporting inclusion in tech, giving people the time and space to contribute meaningfully without constant pressure.
This is harder to measure than policy. But it’s what builds trust.
Why Inclusive Tech Teams Deliver Better Results
Custom software development is fundamentally collaborative problem-solving. The quality of the solutions we build is directly shaped by the range of perspectives involved in building them.
Teams that prioritise diversity in software teams are more likely to:
- Identify blind spots early
- Challenge assumptions
- Develop solutions that work for a wider range of users
This is not only an ethical argument. It is a practical one.
Homogeneous teams tend to build for themselves. Inclusive software teams are more likely to build for the real world.
Over time, this leads to:
- Stronger collaboration
- More creative solutions
- Higher engagement
- Lower attrition
The outcomes we see in inclusive software teams, namely stronger collaboration, more creative problem-solving, higher engagement, and lower attrition, don’t come from strategy documents. They emerge over time, as trust builds and different voices are genuinely heard and taken seriously.
At KRS, this thinking shapes how we build and support software teams for our clients, leading to better product decisions and more resilient delivery.
Building Inclusive Software Teams: An Ongoing Commitment
The tech industry has an unusual kind of influence. The systems we design shape how people move through the world. That makes it important to be thoughtful about who is included in the process of building them, and how inclusion in tech is applied in practice.
At KRS, this isn’t about reaching a perfect state.
It’s about continuously building an environment where people can do their best work, where different perspectives are valued, and where teams reflect the world they’re building for.
Because ultimately, inclusion shows up in how teams are structured, how decisions are made, and the quality of the software delivered.
software
That’s where it matters most. And that is worth working towards.

