Engineer in Diversity & Inclusion - Tangible Steps for Teams
summary
Engineers get concrete steps: add preferred naming fields (implemented at Snapdocs, shipped after months of work), run accessibility checks with WAVE Chrome extension and Lighthouse, and require accessibility in PRs so reviewers catch issues early. Change agile rituals: use trained facilitation and mob programming to rotate roles, reduce bugs, and surface quieter voices. The claim is that these practices increase inclusion, lower defects, and make products usable for more real users.
AI-written summary · about
chapters (18)
- 0:00Start
- 3:53Who Am I
- 7:46What Is Dei as an Engineer
- 9:37Systemic Awareness
- 10:19Action
- 12:32Agile Workflow
- 13:11Key Themes of Agile
- 13:58Self-Organizing Teams
- 14:12Customer Collaboration
- 16:24Facilitation
- 17:37Mob Programming
- 20:45Accessibility
- 22:09Html
- 23:16Incorporating Accessibility into Your Prs
- 24:51Collaboration
- 26:59Preferred Naming
- 34:35Closing Thoughts
- 34:59Communicate and Collaborate
related talks
33mDiversity in Engineering; a community perspective
34mThe Future State Of Diversity and Inclusion In Engineering
10mNeurodiversity: From struggles to solutions, tips for leading a team
28mCreating an inclusive engineering culture
32mBuilding and Cultivating Diverse Design Teams
31mDIY Tech Inclusion
34mSquashing Diversity, Equity, and Inclusion Bugs in Open Source
45mEmbracing DEI Enhances Agility