All too often, working on a team becomes a never ending sequence of dares. This applies to all teams, but for development teams the problem has some recognizable patterns: Changes are submitted, approved and merged with discussions that take place over the heads of most of the team members -- or without explanation at all; projects lack the supportive tooling that makes work efficient and pleasurable for all of the roles on a team; developers are told to “own” a problem and sent off alone as if on some mythical hero quest. This is a set of dares. We dare you to speak up. We dare you to ask for explanation of code you do not understand. We dare you to figure out how to create your own tools. We dare you to find an end-to-end solution in isolation that the rest of the group will deem worthy.
The dares may not be explicit, but the implied risk involved in speaking up, asking for help, or seeking collaboration is often real: Our reactions to the behaviors listed above are used as indicators of how smart and good we are. These behaviors, and many others that follow along the same lines, create significant barriers to building and operating inclusive teams that can successfully leverage members from varying backgrounds, with varying levels of training, and with varying subject matter expertise.
This presentation will offer ideas for how teams can become more inclusive in order to create a positive, productive environment that allows all members to maximize their efficiency and pleasure. There are quite a few steps an organization can take to improve team structure and processes, but to create an inclusive environment the key concept is support. Putting mutual support, whether requested or not, at the base of every decision we make is the best way to create an inclusive team that builds the commitment and investment of its members while building a product that represents them.