Building an Inclusive Engineering Culture

I remember the moment inclusion stopped being an abstract concept for me. A quiet engineer on my team—someone I later learned was one of our strongest systems thinkers—hadn't spoken in a team meeting for three months. When I finally had the presence to ask why, they said: "By the time I've formulated my thought clearly enough to share, someone else has already moved the conversation forward. I don't think fast enough for this team."

That engineer wasn't too slow. Our meeting culture was designed for people who think out loud and respond instantly. We'd accidentally created an environment that excluded deliberate thinkers—and we had no idea what insights we were missing.

Inclusion isn't about checking boxes or hitting demographic targets. It's about designing systems where every team member can contribute their best thinking, regardless of their communication style, background, or identity.

Understanding Exclusion Patterns

Exclusion in engineering teams is rarely intentional. It's structural—built into processes, norms, and communication patterns that were designed by and for a specific type of person. Here are the patterns I've identified on teams I've led:

Exclusion Pattern	Who It Affects	How It Manifests
"Fastest talker wins" culture	Deliberate thinkers, non-native speakers	Ideas only count if stated immediately in meetings
After-hours socializing	Parents, caregivers, people with disabilities	Team bonding happens at bars, excluding some members
Assumed context	Newer team members, career changers	Jargon and references that insiders understand
"Culture fit" hiring	Anyone different from current team	Homogeneous teams that replicate themselves
Visibility-based promotion	Remote workers, introverts	Work only "counts" if leadership sees it happening
Unwritten rules	Everyone not in the original group	Important norms that are never documented

The cost isn't just fairness—it's engineering quality. When you systematically exclude certain perspectives, you get narrower solutions. Diverse teams build better products because they catch blind spots that homogeneous teams miss.

Redesigning Meetings for All Communication Styles

Meeting design is the highest-leverage inclusion intervention because meetings are where decisions happen and visibility is gained. Small changes have outsized impact:

Pre-meeting preparation: Share the agenda and discussion questions 24 hours ahead. This gives deliberate thinkers time to prepare their contributions. It also helps non-native speakers who may need time to formulate their thoughts in a second language.

Written input before verbal discussion: Start substantive discussions with 5 minutes of silent writing. Everyone adds their thoughts to a shared document. Then discuss. This equalizes the playing field between fast verbal processors and careful written thinkers.

Explicit turn-taking: For important decisions, go around the room and ask each person for their perspective. Not as a forced performance, but as a genuine invitation. "Priya, you've been working closest to this system—what's your take?"

Meeting notes with attribution: Document who contributed which ideas. This prevents the common pattern where a quiet person suggests something, it's overlooked, then a louder person says the same thing and gets credit.

Rethinking "Culture Fit"

"Culture fit" is one of the most inclusion-damaging concepts in hiring. It sounds reasonable—of course you want people who work well with your team. But in practice, it becomes "people who look like us, talk like us, and share our hobbies."

I replaced "culture fit" with "culture add" in our hiring process:

Instead of: "Would I enjoy having a beer with this person?" We ask: "What perspective does this person bring that we currently lack?"

Instead of: "Do they share our values?" We ask: "Do they demonstrate our core behaviors (collaboration, ownership, growth)?"

Instead of: "Are they one of us?" We ask: "Will they challenge our assumptions and make us better?"

This reframe shifted our hiring outcomes. We started valuing different educational backgrounds, communication styles, and life experiences. The team became stronger because of the diversity in perspective, not despite it.

Creating Multiple Paths to Visibility

In most engineering organizations, visibility comes from specific behaviors: speaking up in large meetings, volunteering for high-profile projects, self-promoting achievements. These behaviors map to particular personality types and cultural norms—not to actual contribution quality.

I created multiple paths to visibility:

• Written contributions: RFC quality, documentation, async design reviews all "count" for promotion and recognition
• Mentorship impact: Engineers who elevate others are explicitly recognized, not just those who ship individually
• Behind-the-scenes work: Code review quality, incident response, onboarding support are tracked and valued
• Asynchronous input: Important decisions accept written input alongside meeting discussion

When I shifted our promotion criteria to value these diverse contributions, I saw engineers who had been "invisible" suddenly become recognized—not because they changed, but because we changed what we were looking for.

Psychological Safety for Underrepresented Engineers

Psychological safety means something different for people from underrepresented backgrounds. For them, speaking up carries additional risk: confirming stereotypes, being labeled "difficult," having their competence questioned in ways others' competence isn't.

As a leader, I take specific actions to create safety:

Amplify and attribute: When someone from an underrepresented group makes a good point, I explicitly reinforce and attribute it. "I think what Fatima just described is the right approach. Fatima, can you expand on that?"

Address microaggressions immediately: Not "let's discuss this later" but "I want to pause here—that comment about 'not technical backgrounds' excludes several people in this room who bring valuable expertise."

Create multiple feedback channels: Not everyone feels safe giving feedback in person. Anonymous surveys, skip-level 1:1s, and written channels give people options.

Don't burden underrepresented people with fixing the problem: The responsibility for inclusion falls on leadership and the majority group, not on the people experiencing exclusion.

Inclusive On-Call and Workload Design

On-call rotations, late-night deploys, and crunch periods often carry implicit assumptions about who can participate. I design these systems to be genuinely inclusive:

• Predictable schedules: Published far in advance so people with caregiving responsibilities can plan
• Fair distribution: Track on-call hours per person over time, not just rotation position
• Flexible swaps: Easy mechanisms to trade shifts without guilt or explanation
• Avoid "always available" culture: Don't reward people for being available at all hours—reward outcomes during reasonable hours

Measuring Inclusion

You can't improve what you don't measure. But measuring inclusion requires care to avoid surveillance while still tracking meaningful signals:

What I Measure	How	Why
Belonging scores	Anonymous quarterly survey	Trend over time, broken by demographic
Speaking time in meetings	Periodic observation	Identifies participation imbalances
Promotion rates by demographic	Annual analysis	Catches systemic bias in advancement
Retention by demographic	Exit data analysis	Identifies who's leaving and why
Ideas to implementation ratio	Track who proposes vs. who gets approved	Catches whose ideas are systematically overlooked

I share aggregate findings with the team (never individual data) and discuss what actions we'll take based on what we learn.

Key Takeaways

• Exclusion in engineering is usually structural, not intentional—redesign systems, not just attitudes
• Meeting design is the highest-leverage intervention: pre-reading, silent writing, explicit turn-taking
• Replace "culture fit" with "culture add" in hiring to value diverse perspectives
• Create multiple paths to visibility so quiet, remote, and different contributors are recognized
• Take specific actions for psychological safety: amplify contributions, address microaggressions immediately
• Design on-call and workload systems that don't assume universal availability
• Measure belonging, participation, promotion rates, and retention by demographic
• The responsibility for inclusion falls on leadership and the majority, not on those experiencing exclusion

Building an inclusive engineering culture isn't a project you complete—it's an ongoing practice of noticing who's being left out and redesigning systems to include them. The payoff isn't just fairness; it's better engineering through genuine diversity of thought.