Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Work is not a Dare: Tips for Building Inclusive Teams


Published on

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.

Published in: Technology
  • Be the first to comment

Work is not a Dare: Tips for Building Inclusive Teams

  1. 1. W O R K I S N O T A D A R E B u i l d i n g I n c l u s i v e T e a m s
  2. 2. Hi, I’m Shawn! Shawn Rider Director of Web, Application, and Technology Studies School of New & Continuing Studies Seattle University
  3. 3. Be;er Ways to Team TODO Dare-based Workplaces Cults of Personality Final Thoughts Normalizing CommunicaMon Improving CommunicaMon Second Chances Behaviors that turn doing your job into a competition (and why those kinds of environments are bad). Recent research has identified important elements in high-performing teams. Myths of high-performing individuals and the havoc they wreak. Conclusion and summary type stuff. Making supportive communication the default requirement for everything that happens on the team. Empathy and mutual respect can be increased by improving the communication skills of team members. Expect that everyone will eventually need a second chance, and create paths to education and redemption. SeOng ExpectaMons Unifying diverse teams with diverse needs through clearly stated, humane expectations.
  4. 4. “We just really need you to own this one. Let me feel the urgency!” DARE-BASED WORKPLACES
  5. 5. Signs of CompeMMon Developers are told to “own” things Signals unrealistic expectations and a false sense of autonomy that corrodes team. Code changes without discussion Changes might be wide-ranging and performed outside of work hours as a way to “sneak” in changes. Tech reviews are combative Discussions of technical direction are full of jargon and fail to keep everyone engaged.
  6. 6. Signs of CompeMMon Disingenuous requests for feedback Comments and questions are met with resistance or defensive responses, or are used to shame others. Disregard for the value of documentation Belief that documentation is best performed by “lesser” team members who “need to learn” the system. Expected to solo Each team member is expected to figure out implementation details and supportive tooling or settings on their own.
  7. 7. FEAR UNCERTAINTY DOUBT The dare-based workplace stifles productivity, creativity, and breeds fear.
  8. 8. Mutual respect. Open communication. Empathy. Support. BETTER WAYS TO TEAM
  9. 9. Teams are difficult to assemble Scarcity Rules, Flexibility EnMces We must search all over for good team members, and the cost savings or ease of remote work lures us.
  10. 10. Focus on specific skills or IQ node.js Django Single Page JavaScript Application Frameworks Machine Learning 63% 93% 43% 84% We focus on gathering “Top Tier” minds with specific technical expertise and almost never consider other collaborative skills.
  11. 11. Not everyone on a team wants or believes the same thing. GOALS & VALUES
  12. 12. But everyone unites around the project. Diverse purposes, goals, and reasons for participation are healthy.
  13. 13. OVERCOMING ADVERSITY How > Who It has become clear that HOW a team works is more important than WHO is on the team. Individual abilities are either amplified or suppressed based on how the team interacts.
  14. 14. G o o g l e ’ s PROJECT ARISTOTLE In a metastudy encompassing prior academic work and newly- conducted research on Google employees, researchers found that “Psychological Safety” is the most important aspect of high performing teams.
  15. 15. CONVERSATIONAL TURN-TAKING AVERAGE SOCIAL SENSITIVITY Open, egalitarian communication. Empathy and mutual respect.
  16. 16. TEAMS WITH POOR PSYCHOLOGICAL SAFETY suffer reductions in productivity, quality of output, and member satisfaction.
  17. 17. We can work to become better at open, supportive communication. PRACTICE MAKES PERFECT
  18. 18. The Myth of the 10x Developer and beyond. CULTS OF PERSONALITY
  19. 19. DON’T EXIST10x Developers And even if they did, you wouldn’t want a whole team of them.
  20. 20. TradiMonal views of member value are skewed and dangerous. A few select team members are given the keys to the kingdom and free reign on the project. Precious Performers The larger mass of team members are reduced to following orders. Reliable Producers The people most impacted by the traditional hierarchy suffer severe reductions in performance. The Low Performers
  21. 21. FRAGILE PILLARS OF KNOWLEDGE Preferential treatment, favoritism, and overly-hierarchical team structures create dangerous liabilities for the project.
  22. 22. SMfling lack of diversity When we focus on finding an archetype instead of an individual, we tend to filter based on erroneous criteria and end up with fewer choices.
  23. 23. Diverse individuals with common understandings. SETTING EXPECTATIONS
  24. 24. SHARED HEAD SPACE At best, it works for two or three people. But often it doesn’t work, even at small scales. THE MYTH OF
  25. 25. DEFINE STRUCTURE Bring team members into the fold by introducing your communication and interaction structures and processes. HELP
  26. 26. and sMck to them. DEFINE WORKFLOWS
  27. 27. TEAM WORKING AGREEMENTS Define the tools that enable the process. CREATE AND MAINTAIN
  28. 28. Set expectaMons for Mme commitments Recognize that it is not necessary for every team member to have the same time commitment. Respect that it is vital for team members to avoid burnout by investing too much time in the project. Understand that obligations outside the project do not necessarily compete with the project.
  29. 29. Make conversation and negotiation the regular. NORMALIZE COMMUNICATIONS
  30. 30. ALWAYS ASSUME THERE IS A GAP of understanding of knowledge of experience of vision
  31. 31. EXPECT DOCS & TOOLS Do not provide supportive materials on-demand. Create documentation and support materials or tooling by default, and question why those things don’t exist if they are missing.
  32. 32. Document everything. Ideas Create a historical trail of documents so members can follow along with design and project ideas as they evolve. Code Documentation in code and around implementing code features is critical for removing knowledge pillars and insuring maintainability. For Everyone Documentation should not require high-end technical skills or special tools. Make it easy to participate in documentation and easier to consume.
  33. 33. HABITUALIZE HELPING Create install guides for updates Provide documents, video tutorials, animated GIFs, or anything else to convey how to update code. Distribute support tools with changes Scripts, migration commands, and other tools should come alongside complex change sets. Continuous improvement Dev environments and production processes should always evolve towards simplicity and reliability.
  34. 34. DESIGN REVIEWS FIRST Discuss solutions and direction up-front in order to maintain a clear set of expectations and understanding across the team. TALK ABOUT THE WORK
  35. 35. Code Reviews Include Docs + Tools Code Reviews are not just about assuring technical accuracy or stylistic consistency. These are valuable opportunities for cross- team communication and support. Review the code Explain the changes Verify documentation Approve the update path
  36. 36. Skill building beyond the technical. IMPROVING COMMUNICATION
  37. 37. MOVING FROM DEFENSIVE to SupporMve We often make the mistake during team work of perceiving competition where there should be cooperation. We need to move from a defensive mode to a supportive mode in order to encourage open communication and mutual respect.
  38. 38. Control vs. OrientaMon Gibb categories of communicaMon EvaluaMon vs. DescripMon Strategy vs. Spontaneity Neutrality vs. Empathy Superiority vs. Equality Certainty vs. Provisionalism Is feedback phrased in “I” statements or “you” statements? Are decisions made by and for a few, or by and for the entire group? Are we angling for a desired result or responding honestly to new data? Are participants engaged and involved or distant and aloof? Can everyone participate in the discussion with common understanding? Are opinions held with disregard for evidence, or are decisions affected by data? from Jack Gibb’s “Defensive Communication” in Communication Theory (2007)
  39. 39. WORSE BETTER “You didn’t use the correct syntax here, so your code will fail when this obscure condition hits.” “Why would you do it this way?” “You have used a name for this object that I don’t like. You must change it.” “I think if we altered this bit of code then it will handle this obscure condition better.” “I don’t understand how this works. Can you explain?” “I would prefer to call this object something different. Can we figure out another name?” EVALUATION VS. DESCRIPTION
  40. 40. WORSE BETTER “This will all need to be completed by Tuesday.” “We should use this supporting module because these other two options are for incompetent teams.” “It wasn’t in the specs, so I’m not responsible for building it.” “How can we get this ready in time for the opportunity we have on Wednesday?” “I like this option best, but these other two are also used. What do you think?” “I understand the importance of this feature; how can we accomplish this in the time we have?” CONTROL VS. ORIENTATION
  41. 41. WORSE BETTER Hyperbolic representation of technical issues aimed at replacing unwanted components or requirements. Bringing up unrelated embarrassing information to undermine the authority of others. Unwarranted positive or negative feedback designed to further an alternate agenda. Addressing technical issues with due diligence and a level-headed approach. Responding to relevant information to make others feel supported. Honest feedback, support, and criticism designed to better the project. STRATEGY VS. SPONTANEITY
  42. 42. WORSE BETTER “Let me know when you get to the details I need to hear.” “I’m just working on this while you talk. Don’t worry, I’ll pay attention.” Body language: crossed arms sitting at edge of room using other devices lack of non-verbal cues “I’m looking forward to hearing your report.” “Based on your previous statement, I have a question…” Body language: leaning forward open posture eye contact non-verbal cues NEUTRALITY VS. EMPATHY
  43. 43. WORSE BETTER Use of jargon or advanced terminology without explanation or care. Disparagement of other project-related tasks. Disparagement of background, training, or experience of others. Explanation of terms in order to keep everyone on the same page. Recognition of the value of all project-related tasks and focus on improving everyone’s ability to do work. Recognition of the value of diverse backgrounds and experiences. SUPERIORITY VS. EQUALITY
  44. 44. WORSE BETTER “I don’t care what the heads of QA, Support, and Development say, we will not develop that tool.” “My research shows that orange is the only color a button should ever be.” “If we build this feature then we will get a million users. Build it now.” “If all of our team leads think we should develop that tool, then let’s consider how to fit it in.” “I prefer orange, but we could do some A/B testing to see what color buttons our users like best.” “I think this would be a great feature. Let’s do some research to see if it would actually work.” CERTAINTY VS. PROVISIONALISM
  45. 45. Everyone needs a helping hand eventually. SECOND CHANCES
  46. 46. CONTINUES TO REVOLVETHE WORLDEven ader we make serious mistakes.
  47. 47. W e D e s e r v e Second Chances Security for our job, security for our reputation, and security for our selves are all required to create a supportive environment where good work can happen.
  48. 48. Summary and conclusion. FINAL THOUGHTS
  49. 49. WHO is not as important as HOW Find “good fits” where you can, but realize that your process will make or break your team. REMEMBER ?
  50. 50. A V O I D CULTS OF PERSONALITY They create rifts on teams and a situation of inequality that brings down even top performers.
  51. 51. CLEAR EXPECTATIONS Communicate reasonable expectations about process, communication, and time commitments. Revisit and update those expectations over time. ESTABLISH
  52. 52. EFFECTIVE COMMUNICATION AND SUPPORTIVE BEHAVIOR Make discussion and negotiation part of your regular process. Make documentation and supportive tooling part of your technical requirements. NORMALIZE
  53. 53. WORK TO IMPROVE Communication skills can be practiced and improved like any other. Make time in your team process to consider and evolve your communication patterns.
  54. 54. Defensive communication creates a sense of inequality and leads to confusion, which can derail an otherwise highly capable team. Supportive communication builds empathy and mutual respect while more effectively conveying information to others. SUPPORTIVE OVER DEFENSIVE PREFER
  55. 55. ALLOW DO-OVERS Expect that everyone will make mistakes, and everyone will need help at some time.
  56. 56. T H A N K S Shawn Rider @shawnr
  57. 57. Image credits smoke stacks: lunch atop skyscraper: tug of war: human tower: consensus: bell phone system: bell system coils: trooper and chewie: harvard faculty discussion: cool phone: be kind rewind: blurry woman: nyt aristotle microscope: build-the-perfect-team.html?_r=1 couple on bench: ali: sale sign: git branches: Revision_controlled_project_visualization-2010-24-02.svg book burning: Book_burning_(2).jpg rouse solo: baggage feedback: shuttle astronauts: apollo 17 training: astronaut cabin training: apollo 17 bw: star wars photos are owned by Disney Lord of the Flies: the-Flies-1200.jpg 10x developer: github flow: remote team agreement from lucid: example punch clock: crumbling columns: phrenology: amsterdam crane: multnomah falls: helping hand on old rag: Helping_Hand_on_Old_Rag_(22310055090).jpg black keyboard: components-pictures/black-computer-keyboard.jpg magnifying glass on keyboard: computer-components-pictures/magnifying-glass-atop-computer-wireless-keyboard.jpg astronomy chart: dancer: jumping into sea: "equality" by daniel song: headshot1: headshot2: headshot3: headshot4: bieber fans: job wheel: f2f8cba4b094eee2657b2797487b12f9.jpg crossing guard: practice: practice: practice: red cross collie: