Intro
Software engineering teams build the digital products people use every day. However, technical ability alone does not guarantee the best results. Teams also need an environment where people from different backgrounds can share ideas, challenge assumptions and develop their skills.
Creating an inclusive engineering culture takes more than a diversity statement or annual training. It requires fair recruitment, constructive code reviews, accessible tools and equal opportunities for career development. Examples from Google, Microsoft, GitHub and Redgate show how inclusion can become part of everyday engineering. For developers and engineering managers, these practices can strengthen teamwork and help create software that serves more people.
Lets Dive In
Understanding Diversity, Equity and Inclusion in Software Engineering
Diversity, equity and inclusion are closely connected. However, each addresses a different part of the workplace experience.
Diversity means having people with different backgrounds, experiences and perspectives. These differences may include gender, ethnicity, disability, age, education, nationality and neurodiversity. They can also include different career paths, technical skills and problem-solving approaches.
Equity focuses on fair access to opportunities and support. Treating everyone identically does not always produce fair outcomes. One developer may need flexible hours because of caring responsibilities. Another may need assistive technology to work effectively. Equity means recognising these barriers and providing appropriate support.
Inclusion focuses on how people experience the workplace. A team may recruit people from diverse backgrounds but still struggle to retain them. This can happen when meetings discourage participation, feedback becomes hostile or promotion decisions lack transparency.
Belonging is closely related to inclusion. It describes the feeling of being accepted as a genuine member of the team. People should not have to hide important parts of themselves or constantly prove that they deserve to be there.
These principles matter because software development relies on communication and continuous learning. Engineers need to ask questions, admit mistakes and challenge technical decisions. When people feel unable to speak up, important problems may go unnoticed.
Google has explored these challenges through research into diverse software engineering teams. Its findings highlight the importance of addressing recruitment, hiring and the working environment together.
The Google research on diverse software engineering teams offers a useful starting point for engineering leaders.
Why Inclusive Engineering Cultures Matter
An inclusive culture can help engineering teams identify problems, evaluate ideas and build better products. However, diversity alone does not guarantee better performance. Teams must also create opportunities for everyone to contribute.
Consider a team developing a mobile banking application. Developers with similar experiences may overlook barriers affecting people with visual impairments, limited digital confidence or different language needs. A team that welcomes a wider range of perspectives has more opportunities to identify these issues early.
The same principle applies to internal processes. A new developer may question a practice that experienced colleagues take for granted. A remote worker may identify gaps in documentation that office-based colleagues rarely notice. These observations can lead to better decisions and more efficient workflows.
Inclusion can also improve employee retention. Engineers need constructive feedback, fair recognition and opportunities to develop their careers. Repeated interruptions, biased assessments and unclear promotion criteria can make talented employees feel that advancement is unfair.
Psychological safety is another important factor. It allows people to take interpersonal risks, such as asking questions or admitting mistakes. In software engineering, this matters when someone reports a production incident, challenges an architectural decision or raises concerns about an unrealistic deadline.
Google’s research into team effectiveness identifies psychological safety as an important part of effective teamwork. Other factors include dependability and clear expectations.
The Google re guide to team effectiveness explains these findings in more detail.
An inclusive culture does not mean avoiding disagreement or lowering technical standards. Instead, it allows people to debate ideas without personal attacks or unnecessary barriers. Teams can maintain high standards while treating colleagues fairly.
Building Fairer Recruitment and Hiring Practices
Recruitment is one of the first opportunities to make software engineering more inclusive. Traditional hiring practices can favour familiar educational and career paths. As a result, capable candidates may be overlooked.
For example, requiring a computer science degree for every engineering role may exclude people who developed their skills through online courses, apprenticeships or open-source projects. Employers should explain degree requirements when they are genuinely necessary. Otherwise, practical assessments can help identify candidates with the right skills.
Job descriptions also deserve attention. Long lists of desirable technologies can discourage qualified applicants who do not meet every requirement. Clear distinctions between essential and optional skills help candidates judge their suitability.
Structured interviews can make hiring more consistent. Employers should define evaluation criteria before interviews begin. Standardised questions and scoring systems can reduce the influence of personal preferences or assumptions.
Technical assessments should reflect the actual work. A short coding exercise may provide useful evidence of ability. An unnecessarily long assignment, however, can place a heavy burden on candidates who must complete it without pay.
Employers should explain assessments in advance and provide reasonable adjustments when needed. They should also consider where they advertise roles and how they reach potential applicants.
Partnerships with professional communities, apprenticeship programmes and organisations supporting underrepresented technologists can widen access to opportunities. However, recruitment changes must be supported by fair working practices after people join.
Finally, employers should review recruitment data. They can examine where candidates leave the process and whether interviewers apply standards consistently. Any use of demographic data must respect privacy and applicable laws.
The goal is simple: remove unnecessary barriers and assess candidates against the skills and potential required for the role.
Creating Inclusive Meetings and Communication Practices
Meetings can strongly influence whether engineers feel able to contribute. Some teams rely on fast discussions and spontaneous brainstorming. These methods may suit some people but create barriers for others.
For example, remote workers may struggle to join discussions across time zones. Some colleagues may also need more time to process information before responding.
Inclusive meetings begin with preparation. Sharing an agenda and relevant documents in advance gives people time to understand the topic and prepare questions. Written design proposals can also help engineers consider technical trade-offs before an architecture review.
Facilitators should monitor who gets to speak. If a few people dominate every discussion, useful ideas may be missed. Inviting wider participation can help, provided nobody is pressured to speak or represent an entire group.
Written communication provides another way to contribute. Asynchronous discussions allow engineers to share ideas without attending every meeting. They also create a record of decisions and unresolved questions.
This approach is particularly valuable for remote teams. Developers should be able to understand why an architectural decision was made, even if they missed the meeting. Documenting decisions reduces reliance on informal conversations.
Teams should also agree on communication expectations. Not every message needs an immediate response, and not every problem requires a meeting. Clear guidance on when to use chat, documentation or live discussion helps people manage their time.
Inclusive communication does not require everyone to work in the same way. It provides different ways to participate while keeping collaboration clear and productive.
Making Code Reviews Fair and Constructive
Code reviews help teams maintain software quality, share knowledge and improve maintainability. However, differences in communication style, seniority and unconscious bias can affect how developers experience the process.
A constructive review focuses on the code rather than the person who wrote it. Comments such as “This is obvious” offer little technical value. They can also discourage developers from asking questions.
Specific feedback is more useful. A reviewer might explain that extracting a function would make the code easier to test. They could also identify an edge case that might cause an error.
Reviewers should distinguish essential changes from optional suggestions. This helps developers understand which issues affect correctness, security or consistency.
Shared coding standards can also reduce unnecessary disagreement. Automated formatting and linting allow reviewers to focus on design, performance and security. They also reduce arguments over personal style preferences.
Teams should establish clear review expectations. These might include response times, approval requirements and ways to resolve disagreements. Senior engineers should follow the same standards as everyone else and remain open to constructive challenges.
Research from Google highlights why fair code reviews matter. In a 2022 article, Google reported that women in the study experienced 21% higher odds of pushback than men. Black developers experienced 54% higher odds than White developers. The research examined perceived unnecessary interpersonal conflict when reviewers blocked changes.
These findings do not mean that every difficult review is discriminatory. Technical disagreement is a normal part of software development. However, they show why teams should examine how reviews are conducted instead of assuming the process is always fair.
Google’s article, Using research to make code review more equitable, explains the findings in greater detail.
Engineering managers can review feedback patterns, turnaround times and recurring disputes to identify potential problems. The aim is to improve consistency without discouraging legitimate technical scrutiny.
Supporting Neurodiversity and Different Working Styles
Software engineers have different ways of processing information, communicating and solving problems. Neurodivergent colleagues, including some autistic people and people with ADHD or dyslexia, may have different workplace preferences or support needs.
Their experiences are not identical. Therefore, teams should avoid assuming that one adjustment will suit everyone.
Inclusive teams also avoid treating one working style as the correct one. Frequent verbal participation, for example, is not the only sign of technical ability. Some developers may communicate more effectively through writing.
Clear documentation can make a significant difference. Onboarding guides, development instructions and architecture diagrams help new starters understand how the team works. They also reduce reliance on memory and informal conversations.
Flexible working arrangements can help people manage concentration, health needs and responsibilities outside work. Where possible, teams can offer flexible start times, quiet periods for focused work or alternatives to unnecessary meetings.
Accessibility adjustments should be discussed with the person concerned. Options may include screen-reader-compatible tools, captions, alternative input methods or reduced-distraction environments. Managers should respect privacy and avoid asking people to disclose unnecessary personal information.
Redgate provides a practical example of an engineering organisation addressing inclusion. In a November 2024 article, the company described an engineering-led group focused initially on neurodiversity and gender balance. The initiative worked alongside wider company efforts rather than leaving inclusion solely to HR.
The Redgate article on inclusive engineering illustrates how teams can identify specific challenges and develop practical improvements.
The wider lesson is that inclusion should not require everyone to adapt to one workplace model. Teams can provide clarity and flexibility while maintaining the technical standards needed to deliver reliable software.
Designing Software for a Wider Range of Users
Inclusive engineering extends beyond the workplace. It also influences the software teams build.
Products can unintentionally exclude users when developers make assumptions about ability, language, income, connectivity or digital experience. Testing with a wider range of users helps identify these barriers.
Accessibility is an important starting point. Developers should consider keyboard navigation, screen-reader compatibility, colour contrast, captions and clear error messages throughout development.
The Web Content Accessibility Guidelines (WCAG) provide an established reference for making web content more accessible.
Teams should also test software in different real-world conditions. A feature that works well on a powerful laptop may perform poorly on an older phone or a slow connection. A form that seems simple to its designers may confuse someone using assistive technology.
Microsoft’s Inclusive Design approach offers a practical framework for addressing these issues. It encourages teams to recognise exclusion, learn from human diversity and develop solutions that benefit more people.
For example, a feature designed for someone with a permanent disability may also help someone with a temporary injury. Captions support people who are deaf or hard of hearing, but they can also help someone watching a video in a noisy environment.
Microsoft’s Inclusive Tech Lab also works with disabled advisers and product teams. This helps bring user feedback into development earlier, rather than treating accessibility as a final check.
The Microsoft Inclusive Design resources offer practical principles and tools for engineers and designers. Microsoft’s work on accessibility and neurodivergent employees provides another example of how lived experience can inform product decisions.
For software teams, the message is clear: involve diverse users early, test real tasks and respond to feedback. Accessibility should remain an ongoing engineering responsibility.
Improving Career Development, Mentoring and Recognition
An inclusive engineering culture must provide fair opportunities to progress. Recruiting diverse talent will not create lasting change if some employees receive better projects, mentoring or recognition than others.
Career development can become unfair when promotion expectations are unclear. Published career frameworks help employees understand how their work will be assessed. These frameworks can cover technical expertise, collaboration, delivery, mentoring and leadership.
Managers should also examine how they allocate work. High-profile projects can provide valuable opportunities to demonstrate leadership. Routine maintenance and support work may be essential, but it often receives less visibility.
If the same people repeatedly receive the most visible assignments, others may have fewer opportunities to progress.
Mentoring and sponsorship can help address this problem. Mentors offer guidance, feedback and career advice. Sponsors go further by advocating for someone’s work and helping them access new opportunities.
Recognition matters, too. Managers should acknowledge contributions such as improving documentation, supporting colleagues and resolving production issues. These activities are important even when they do not produce a new feature.
Employee resource groups can provide peer support, networking and shared learning. However, they need organisational support to be effective. Employees from underrepresented groups should not be expected to carry the responsibility for improving inclusion on top of their normal workload.
GitHub provides an example of connecting employee communities with broader inclusion efforts. Its diversity reporting describes Communities of Belonging, which are open to employees and allies. The company also reports on initiatives supporting developer education and access to technology.
GitHub’s 2024 diversity, inclusion and belonging report provides further information.
Engineering leaders can build on these ideas by making promotion criteria clear, tracking access to mentoring and reviewing career outcomes. The goal is to give everyone a fair opportunity to demonstrate their abilities and develop their career.
Embedding Inclusion into Everyday Engineering Work
Inclusive culture is more sustainable when it becomes part of everyday engineering processes. Teams do not need to launch a major programme before making useful changes.
Sprint planning provides one opportunity. Teams can check whether workloads are realistic and whether decisions have been documented. Retrospectives can explore whether everyone had a fair chance to contribute.
Architecture reviews can include questions about accessibility, internationalisation and the users affected by technical decisions. Definition-of-done checklists can include relevant accessibility tests, documentation and security requirements.
Onboarding checklists can also explain team conventions, feedback expectations and how to raise concerns.
Engineering leaders should make it safe to report exclusionary behaviour. Employees need to know how concerns will be handled, who is responsible and what protections apply against retaliation. Concerns should be addressed promptly and fairly, while respecting confidentiality where possible.
Training can support these efforts. However, it works best when linked to realistic engineering situations. A team might examine a hostile code review, a meeting that excludes remote colleagues or an accessibility problem discovered after release. Members can then agree on specific changes.
Training alone is unlikely to produce lasting improvement if workplace incentives remain unchanged. For example, a company may promote collaboration while rewarding only individual output. It may also favour visibility over sustained contributions that are less obvious.
The strongest approach aligns expectations, processes and leadership behaviour. Inclusion becomes part of professional engineering practice, while managers remain responsible for removing barriers that individuals cannot resolve alone.
Measuring Progress Without Reducing Inclusion to a Number
Engineering organisations need ways to assess whether their inclusion efforts are working. Measurement can reveal problems, but a single diversity figure cannot explain the full workplace experience.
Useful indicators include representation across technical levels, recruitment outcomes, promotion patterns, retention and access to mentoring. Anonymous surveys can also explore belonging, psychological safety and perceptions of fairness.
Qualitative feedback is equally important. Interviews, listening sessions and retrospectives can reveal why a process creates barriers. They can also help teams identify practical solutions.
Employees should not be expected to speak for an entire demographic group. Feedback channels should also provide options for people who do not feel comfortable raising concerns publicly.
Data must be handled responsibly. Demographic information should be collected for legitimate purposes and protected appropriately. Small teams may need extra safeguards to prevent individuals from being identified in anonymous results.
Teams should establish a baseline, choose a manageable number of priorities and review progress regularly. For example, a team might improve onboarding documentation and code review practices, then gather feedback after several months.
It is also important to distinguish activity from impact. Running a training session shows that work has taken place. It does not prove that the workplace has become more inclusive.
Better evidence comes from examining employees’ experiences and checking whether identified barriers have been reduced.
No single metric captures the full experience of belonging. A balanced approach combines quantitative measures, confidential feedback and clear accountability. Teams should also be willing to change their approach when the evidence shows that something is not working.
Recommended Online Courses to Build Inclusive Software Engineering Cultures
Inclusive Leadership: The Power of Workplace Diversity
Platform: Coursera
Level: Beginner
Focus: Inclusive leadership, communication, self-awareness and workplace diversity
This course from the University of Colorado System introduces the behaviours that help people from different backgrounds work effectively together. It explores inclusion, belonging and the role of leadership in creating a respectful workplace.
The course listing reports a 4.9/5 rating from 1,793 reviews and more than 62,000 enrolments at the time of research. It offers a useful starting point for engineering managers and aspiring technical leads who want to improve their approach to team culture.
Explore: Inclusive Leadership: The Power of Workplace Diversity
Inclusive Tech: The Case for Inclusive Leadership
Platform: LinkedIn Learning
Level: Beginner
Focus: Inclusive leadership in technology, team culture and practical approaches to change
Created by Jessica Rose, this course explores how inclusive leadership applies to technology teams. It covers barriers to inclusion, the responsibilities of team leaders and the challenges of changing workplace culture.
The course lasts 1 hour and 29 minutes. It is particularly relevant to software engineering managers who want to connect inclusion principles with the realities of technology organisations. LinkedIn Learning does not display a comparable aggregate rating and enrolment figure on the course page.
Explore: Inclusive Tech: The Case for Inclusive Leadership
Courageous Allyship: Learn How to Build Inclusive Workplaces
Platform: Udemy
Level: Beginner
Focus: Allyship, responding to microaggressions, psychological safety and inclusive communication
This course from Dr. Priya Nalkur focuses on practical ways to support colleagues who experience exclusion. Learners explore how to recognise microaggressions, respond to unfair behaviour and have constructive conversations about inclusion.
The course listing reports a rating of approximately 4.7/5 from more than 2,300 ratings, with over 6,700 students at the time of research. Its last listed update was September 2023. It can help engineers and team leads turn inclusive intentions into everyday actions.
Explore: Courageous Allyship: Learn How to Build Inclusive Workplaces
Final Thoughts
Creating an inclusive software engineering culture requires consistent effort across recruitment, communication, code reviews, accessibility and career development. Examples from Google, Microsoft, GitHub and Redgate show how inclusion can become part of everyday engineering work. Fair processes and constructive collaboration help people contribute without facing unnecessary barriers.
Teams can start by identifying one or two areas for improvement, involving the people affected and reviewing the results. Engineering leaders should model inclusive behaviour, while developers can help through thoughtful code reviews, clear documentation and respectful communication. Over time, these practices can strengthen teams and produce software that works better for more people.
