Inclusion in software engineering

Foreword

Aristotle made a distinction between two flavours of justice. One treats similar cases alike. The other gives each person precisely what they are owed. These two conceptions are not the same. The first may, under certain conditions, actively preclude the second.

Inclusion in software engineering is not the project of treating everyone identically. The individuals making up the workforce are not fully interchangeable with each other. Instead, it is an enterprise in designing teams, processes and cultures.

As a term, “culture” can be used without much thought to its exact meaning. This document sees “culture” as the idea that every person (regardless of background, identity or circumstance) can contribute fully and be treated with something approaching genuine fairness.

UK Government technology teams serve the whole of society. This is not a marketing slogan. It is a mission. The mission is best served when teams genuinely reflect, understand and value that society.

This document is not a compliance checklist. It is about the kind of people and teams we choose to be in moments that often go unobserved and unrecorded.

Why inclusion matters

The ethical case: responsibility to citizens

Government software shapes access to benefits, healthcare, justice, education and democratic participation. People who build the systems that grant or withhold them are exercising a form of power over other peoples’ lives. This power carries a corresponding moral obligation.

When the people who build these systems do not reflect the people who use them, blind spots emerge which have real consequences for real lives.

the benefit claimant who cannot navigate the interface
the asylum seeker for whom the process has been designed without the faintest consultation with anyone resembling an asylum seeker
the disabled citizen whose experience of the service has not been ‘in scope’

The philosopher John Rawls proposed that the fairest rules are those we accept from behind a veil of ignorance. We accept them without knowing where we ourselves would land.

To apply this to our work: would we design the same systems if we did not know whether we would be the developer, the product manager, or the benefits claimant?

The legal framework

The Equality Act 2010 defines nine protected characteristics: age, disability, gender reassignment, marriage and civil partnership, pregnancy and maternity, race, religion or belief, sex and sexual orientation.

As a public body, government departments are subject to the Public Sector Equality Duty (PSED), which requires them to

eliminate unlawful discrimination, harassment and victimisation
advance equality of opportunity between people with different protected characteristics
foster good relations between different groups

The civil service Diversity and Inclusion strategy sets commitments for representation at all grades, especially at Senior Civil Service level.

The business case and mission

Research by McKinsey for the Cabinet Office shows positive results for diverse teams.

fewer systematic errors
more creative solutions generated
better anticipation of the needs of varied users

For Justice Digital, this translates directly into services that work better for people.

Inclusive hiring and recruitment

The principle: broaden the pool before filtering it

Recruitment is often where exclusion begins.

Job descriptions written in a particular register can narrow the field before a single CV has been read. Roles are advertised only through particular channels. Criteria are shaped by the composition of the current team. It can feel that the mechanisms of exclusion have been built into the process.

Writing job descriptions

A good job description describes what you need someone to be able to do, not the background you assume produced their ability to do it. Creating a job description will require you to be mindful of your own assumptions.

Use plain English. Avoid jargon and acronyms specific to your department.

Clearly separate essential and desirable criteria. Research shows women and people from underrepresented groups are less likely to apply unless they meet every criterion listed.

Avoid degree requirements if not strictly necessary. Many software engineers in the UK enter the profession through apprenticeships, bootcamps, or self-directed study. Degree requirements can correlate more strongly with socioeconomic background.

Use gender neutral language, avoiding terms such as ‘driven, ‘rockstar’, ‘ninja’ or ‘guru’. Instead, use ‘supportive, ‘empathy’ and ‘collaborative’.

Include a visible inclusion statement. Silence implies indifference.

Unstructured interviews are among the weakest predictors of job performance and can underpin the interviewer’s existing preferences. The Civil Service uses structured competency-based interviews aligned to the Success Profiles framework.

Best practice for government engineering teams includes

name-blind shortlisting of applications
standardised scoring rubrics for interviews, agreed before candidates are seen
diverse interview panels (in protected characteristics, seniority and team background)
technical assessments that test real-world problem solving rather than the capacity to perform under artificial conditions (pseudo code should be sufficient)
reasonable adjustments offered proactively - the Equality Act requires employers to make reasonable adjustments for disabled candidates)

Government-specific schemes

The Disability Confident scheme level 3 commits departments to interviewing all disabled applicants who meet minimum criteria.

Digital and Data apprenticeships enable teams to grow talent from non-traditional backgrounds while addressing genuine skills shortages.

Summer Internship programmes are designed to bring underrepresented groups into the Civil Service pipeline.

The Civil Service Returners programme commits departments to take on candidates who have been out of the workforce for eighteen months or more. This is particularly effective for underrepresented groups who have caring/child raising responsibilities.

Tech Track commits candidates to 16 weeks with a government approved supplier. Students are taught to code in a wide variety of languages such as Python and Java and introduced to Agile and how it translates to delivery. After teaching concludes, the developer is embedded in a software engineering team. They should be provided with a support wrap that shapes activities to ensure that production-ready code is released.

Building inclusive teams day-to-day

The principle: belonging must be earned by the environment

The philosopher Simone Weil wrote that the need to belong is among the most fundamental of human needs. It is most commonly destroyed not by cruelty, but by thoughtlessness. Inclusion is not achieved once; it is maintained or eroded by hundreds of small daily choices.

Psychological safety

Google’s “Project Aristotle” found psychological safety to be the single most important factor in team performance. Team members should believe that it is safe to take risks and be vulnerable in front of others. Psychological safety is not comfort, but the confidence that honest contributions will be received with respect.

A lead or principal developer should build psychological safety by

publicly modelling fallibility - acknowledging your own mistakes and uncertainties
responding to challenge with curiosity, not defensiveness
addressing harmful behaviours - dismissiveness, credit-stealing, interrupting - immediately and clearly

Meetings and decision making

Circulate agendas in advance. Not everyone processes verbal information quickly or in the moment. This is particularly important for introverts, neurodiverse colleagues and those for whom English is not a first language.

Actively solicit contributions from quieter voices. The loudest voices in a room are not always the ones with the most to say.

Record decisions and the reasoning behind them. This makes decision-making transparent and accessible to those who could not attend.

Challenge the HiPPO effect (Highest Paid Person’s Opinion). Decisions should be driven by evidence and reasoning, not hierarchy.

Code reviews and technical feedback

Code review is one of the most common sites of exclusionary behaviour.

Review the code, not the person. Avoid phrases that imply incompetence about the author.

Be specific. ‘This could be cleaner’ is not actionable. ‘Extracting this into a named function would make the logic easier to test’ is.

Distinguish preference from requirement. If something is a matter of style, say so. Many teams adopt a shared style guide (e.g. aligned to GDS engineering standards) precisely to depersonalise these debates.

Notice whose contributions attract disproportionate scrutiny. If a pattern exists, it warrants reflection.

Onboarding

The first weeks in a new role have disproportionate impact on long-term belonging and retention. An inclusive onboarding process will include the following.

Written documentation of the team’s ways of working, not just verbal introduction. Written records benefit neurodiverse colleagues and those navigating cultural differences.

Pairing new starters with a buddy distinct from their line manager. They can then ask questions without concern for professional impression.

Explicitly introducing team norms, communication preferences and how decisions are made. There are practices in organisations that are visible to some and not to others.

Accessibility and inclusive technical practice

The principle: accessibility is not an add-on

Accessibility is a legal requirement under the Public Sector Bodies Accessibility Regulations 2018. This implements the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA as the minimum standard.

The curb-cut effect - named after the observation that wheelchair ramps also benefit parents with prams, delivery workers and travellers - also applies to software. Accessible design is almost always better design for everyone, not only disabled users.

Standards and tools

The GOV.UK Design System implements accessibility best practice by default.

Automated tools such as Axe, WAVE and Lighthouse catch a proportion of accessibility issues (but not all, much like a spellchecker proofing a document).

Automated testing should be complemented by manual testing with assistive technology (screen readers, keyboard-only navigation, high-contrast modes).

GDS guidance states that services must be tested with real users, including disabled users, throughout the service design lifecycle.

Publish and maintain an accessibility statement for every public-facing service.

Inclusive language in code and documentation

Variable names, commit messages, documentation and comments are part of the team environment. Some historic terminology - master/slave for git branches or database replication, whitelist/blacklist for security configurations - carries meanings that matter to some of the people reading and writing it. This is not about excessive sensitivity; it is about precision and professional attentiveness to language.

Use practical alternatives: main instead of master; allowlist and denylist instead of whitelist and blacklist; primary/replica instead of master/slave.

Working practices and tooling accessibility

Ensure development environments, internal tools and documentation are themselves accessible.

Apply Civil Service flexible working policies to working patterns where roles permit. Rigid presenteeism disadvantages disabled people, carers and those with health conditions.

Make reasonable adjustments to development workflows (screen reader, voice input, non-standard keyboard).

Career development and retention

The Principle: sponsorship over mentorship

Research on career progression consistently finds that what holds back talented people from underrepresented groups is not mentorship - advice about how to develop - but sponsorship: the active advocacy of senior people who use their credibility and networks to open doors.

Mentorship tells you how to navigate the system; sponsorship changes the system for you.

As a principal developer, you are in a position of sponsorship. That means actively recommending people for opportunities, not just supporting them when they ask.

Performance assessment

The Civil Service uses the Performance Development Review (PDR) process. Bias in performance assessment is well-documented and operates in consistent patterns

women and people from ethnic minority backgrounds receive more feedback about style and less about substance
achievements are more likely to be attributed to luck or team effort than individual capability

Principled assessment is underpinned by these actions.

Assessing against agreed criteria and the Success Profiles framework, not ‘potential’ or ‘cultural fit’.

Keeping records of contributions throughout the year, not reconstructing them from memory at review time.

Calibrating with peers across the team and reviewing for consistency across demographic groups.

Being specific. Replace indistinct phrases like ‘needs to be more visible’ with ‘present your approach to the cross-government community of practice’.

Government staff networks and communities

The Civil Service has active staff networks for a wide range of groups including ethnicity, disability, LGBT+, gender and social mobility. These networks provide peer support and community. They also provide intelligence to leadership about the lived experience of the organisation.

actively enable team members to participate in staff networks during work time, not just in addition to iwe§
listen to what networks are telling you, especially when it is uncomfortable
engage with the cross-government Digital, Data and Technology community of practice inclusion forums

Handling harm and complaints

The principle: intent is not outcome

Most harmful behaviour in workplaces is not malicious. It arises from unconsidered habit, cultural difference, or acting without considering the impact of the act on others. The impact on the recipient is real regardless of the intent. Any idea that the experience of the person harmed is less authoritative than the intention of the person causing the harm should be resisted.

Effective inclusion culture holds both viewpoints simultaneously. Individuals can be held to account for the effects of their behaviour without being presumed to have acted with any malicious intent. In any organisation, adult professional accountability should be based on the following proposition - that the people who work there deserve to be treated as fully human.

Responding to incidents

Address low-level harmful behaviour promptly and directly. If left, there is a risk that it may be seen as a normal part of team culture. A clear intervention in the moment is almost always better than a formal conversation later.

Centre the person who was harmed. Ask what they need. Do not make assumption on whether (or not) they want the incident formally escalated.

Keep information about the incident confidential. Gossiping is itself a form of harm.

Know your organisation (or department) formal grievance and disciplinary policies. Every department has grievance and disciplinary procedures. You do not need to be an expert, but you do need to know where to refer people.

Psychological safety for speaking up

If anyone does not feel their concerns can be raised internally, they can be raised via

Civil Service Speak Up guidance and/or
Civil Service Commission

The Equality and Human Rights Commission (EHRC) provides guidance and enforcement in these cases. Contact information should be made freely available to your team.

Measuring and improving

The principle: what gets measured gets addressed

The philosopher Hannah Arendt observed that before you can act, you must first see.

Inclusion efforts without data to measure their effectiveness may limit their benefits.

Recognised data sources include the Civil Service People Survey, departmental diversity data and team-level pulse surveys. Any data will need to be reviewed and analysed. The main question will be which course of action to take with the results shown in the data.

Practical metrics for teams

Representation at each grade and in senior technical roles. Results should be broken down by gender, ethnicity and disability where data allows. Gaps in data are themselves a form of information about institutional priorities.

Promotion and progression rates separated out and grouped by protected characteristics.

Attrition rates and exit interview themes, disaggregated where possible. Reasons for leaving an organisation can be unclear, but can be defined on further analysis.

Psychological safety scores from team surveys. Teams that score low here require genuine inquiry and structural intervention.

Acting on what you find

Data without action is an alibi. When patterns emerge the appropriate response is genuine inquiry, not defensive explanation. Examples of a pattern include a lack of women in principal roles, lower People Survey scores among staff from different ethnic backgrounds or higher attrition among disabled colleagues.

Engage with the people affected. Form a hypothesis. Test a change. Measure again.

The culture of continuous improvement

Inclusion as a practice, not a state

Software engineers are comfortable with the idea that quality is not achieved once. We build in review cycles, retrospectives and continuous integration. In the context of a moving system, standing still indistinguishable from falling behind. Inclusion is no different.

Run inclusion retrospectives alongside your sprint retrospectives

what could have been built better
who felt unheard during the sprint
why, and whether the structure of the sprint itself contributed to that experience

Learning and awareness

The Civil Service Learning platform provides a range of accredited diversity and inclusion resources, including training for unconscious bias. Mandatory unconscious bias training is a reasonable starting point, but sustained awareness requires ongoing learning.

Read widely on inclusion topics. Government Equalities Office publications, the EHRC’s statutory codes of practice, Cabinet Office diversity data and organisations such as Tech Talent Charter all produce evidence and guidance relevant to engineering teams.

Engage with cross-government inclusion networks in the Digital, Data and Technology (DDaT) profession. You do not have to solve this alone and the solutions being developed across government are available to you.

Leading by example

How you behave as team leader will impact on your team’s view of inclusion within the team and organisation. Your team will notice

whether you acknowledge contributions equitably
how you respond when a colleague is interrupted
whether you make genuine space for challenges
how you handle your own mistakes when no process compels you to handle them at all