Work is not a Dare: Tips for Building Inclusive Teams

Editor's Notes

1. Hello and welcome to Open Source and Feelings. My name is Shawn Rider, and I run the Web, Application and Technology Studies program at Seattle University. We have a great program designed to help working adults get started in the web development industry. Prior to my teaching gig at SU, I have worked for many years building websites. I have done work with startups, government agencies, and various media corporations. I used to run educational technology for the Public Broadcasting Service’s Education group.
2. I want to talk today about the ways that workplaces often become “dare-based” and what we can do to improve them. This is close to my heart because I have both worked in several “dare-based workplaces” and I have seen my students encounter this behavior when looking for work. We will explore better ways to make your team happy, productive, and stable. This includes turning away from a lot of traditional behaviors and actually practicing communication skills to build a supportive and respectful environment that can accommodate a diverse range of team members.
3. I am sure many of us have experienced the “dare-based” workplace. It’s one where everyone is always supposed to be operating at maximum “commitment” and exuding an unwavering optimism and enthusiasm for the business and product. These are the places where people “own” things and the “urgency” can be felt from a mile away. This attitude, and others that often go along with it, turns our creative, working practice into a competition.
4. There are few phrases that raise my hackles like being told to “own” something. It’s an unrealistic goal that only creates a false sense of autonomy. It corrodes the team because it encourages developers to work in a non-collaborative way. In this situation, developers are emboldened to change code without discussion or review. When reviews do happen, they are often combative. Or, in the case where there are a few team members with very strong personalities, and several with less forceful approaches, reviews become a meaningless exercise that allows a totem of collegiality without actually making an impact on the code.
5. This formalization of process sometimes leads to requests for feedback that isn’t really wanted. If discussion and negotiation aren’t actually practiced, then there is not really a team culture of giving and receiving feedback. Devaluing documentation is not only useful for people who do not want to document their work, but it is also useful for stifling feedback and creating class-based divisions on the team (those who are “above” documentation and those who must document in order to “learn”). All of this creates a situation where team members are expected to essentially “solo” the entire project, which is not the goal of a team in the first place.
6. These competitive behaviors are dares. “I dare you to question my authority.” “I dare you to expose your ignorance.” “I dare you to do better than me.” “I dare you to subject yourself to the judgement of your peers.” This sort of competition is unhealthy and leads to fear among the team members. Members may be fearful of losing their position. They may be worried for the direction of the project. Or they may simply be anxious from the level of expectation being thrust upon them. And all of this begs the question, “If this is how you’re going to work, then why do you need a team?”
7. We have struggled to come up with sure-fire ways of creating, organizing, and operating high-performing teams. There are many challenges in putting together teams, and over the years we have been able to recognize some things about what makes teams successful in both their mission and in creating a sustainable environment for doing work. Regardless of how much progress we’ve made, teams remain a challenge for most of us.
8. We know that it’s tough to find the right people for our teams. Tech projects require some specific knowledge, and often that expertise is not common. In order to find people who can do the work it can be necessary to scour the globe. Luckily, it has become easier to organize teams and work on projects without requiring team members to sit in the same room. There are cost savings and lifestyle opportunities that come with remote teams. But, for every improvement collaborative technology affords us, more weight is put on our process and organization to facilitate the teamwork.
9. We often put too much focus on individual actors and their individual skills and abilities. When working on a project with a specific technology stack, it’s desirable to bring in new team members who have expertise in that area. But we often privilege those skills with an unwarranted emphasis. In addition, we often believe that those skills can only be obtained with a specific background: a university education, preferably from a good school with a stellar CS program. In fact, many tech companies only hire from a handful of pre-selected schools because of a belief that they need “that kind” of developer.
10. Another challenge when putting together teams is that we are often confronted with the diverse goals and values of other team members. Sometimes this is very challenging: We may expect other technologists to have similar opinions and we may be surprised when they don’t. But we often recognize at some level that teams can do great work even when individuals on the team do not have the exact same agenda. We have many stories in popular culture about the romanticized “team of misfits” who come together to solve some grave problem.
11. And, in fact, what is most important on the team is that the goal OF THE TEAM is shared and generally understood in the same way by all members of the team. It turns out that diversity in team member motivation is a healthy thing and can help teams succeed.
12. This realization about the differing motivations of team members is more than just romanticized popular culture. It is reflective of the fact that HOW the team operates is much more important than WHO is on the team. The abilities of all team members are either amplified or suppressed based on the structures that allow the team to interact and the behavior of the team members.
13. Many of you are probably aware of Google’s Project Aristotle, in which a team of researchers led by Julia Rozovsky studied both academic literature regarding teams and the interactions of many project teams across Google. In the end, Rozovsky’s team discovered that the most important aspect of high performing teams was the feeling of “Psychological Safety” on the part of the team members. This sense of safety allows for open, respectful communication and engagement in team processes that encourages creative production and a sense of well-being.
14. Rozovsky’s team discovered two behaviors that most supported a sense of psychological safety on a team: Conversational Turn-Taking and Average Social Sensitivity. Conversational Turn-Taking allows for open, egalitarian communication among members of a team. Discussions are not dominated by one or a few personalities on the team, and everyone’s contribution to a discussion is valued. Average Social Sensitivity describes the level of empathy and mutual respect team members are able to show each other. The ability to display empathy and respect is crucial to opening productive communication pathways.
15. Teams that do not create a sense of psychological safety are, unfortunately, doomed. If a team is not moving towards psychological safety, then they are probably moving towards a more competitive environment that will ultimately consume or burn out the vast majority of team members.
16. Luckily, we have seen humans work hard at doing very difficult things. We can similarly practice and improve our communication and interpersonal skills to create a better sense of Psychological Safety on our teams. It may seem daunting to achieve Psychological Safety, but we can take small steps to get there.
17. Before we get into all the things we can do to improve our teams, I want to thoroughly disabuse us of the notion that when we put together teams we are looking for ONE kind of person or a person with ONE kind of background. The world of technology is full of Cults of Personality, where a single individual’s approach is given preferential treatment. This is a bad thing.
18. For all intents and purposes, there is no such thing as a 10x developer. There may be developers who write code very quickly, but code writing is only one part of a technical project build. Those developers often suffer immensely when their speed is measured in documentation, communication, planning, or prioritization. Research also shows that although exceptionally high performing individual developers can produce a lot of code, they often have lower job satisfaction scores, find themselves in the middle of team conflicts, and are the most likely to leave a job for a higher-paying position. It’s unrealistic to expect to find, or to expect to rely upon, 10x developers for a project.
19. The notion that you would preference your “Precious Performers” directly leads to a class-based system that undermines the cohesion on our team. Although recognizing and celebrating individual achievement is a part of teamwork, creating a stratified culture where one group is subordinate to another is not a good idea. There will either be resistance to the value-based ordering, or there will be resignation to it. In either case, the vast majority of the team members will be doing less well, producing less work, and more at risk of departure.
20. Relying on exceptional developers who do not communicate their ideas to others is also a sure-fire way to create pillars of knowledge in your project. These pillars are doomed to crumble over time as the 10x developers move on to other teams and the remaining team members have little or no idea how components operate. In the end, a well-documented and socialized feature that is built to average technical expertise is far better than a technically flamboyant feature that nobody understands.
21. Finally, the focus on individuals with exceptional skills or the “right” background is not ever going to lead to the diversification of the team. In tech, we often lament the fact that we don’t have more diverse project teams, but then we recruit and select people from the same old pathways. We become fixated on things that don’t actually matter (like whether people know the same movies or exotic libraries we know) and we lose site of the fact that what we really need are people who can communicate, learn new things, and bring enough creative vision to a project to fill in the gaps.
22. It’s often perceived in the tech world that teams must think together very closely. We see situations where people are even expected to interact outside of work in order to “strengthen the team.” This leads to a corollary perception that the way to get people to work together is to make them more similar, and the flip side of that is resisting individuals who come from more diverse backgrounds. (Because how would we ever get into the same head space if we’re all so different?)
23. Shared head space is, probably, a myth. Or maybe it works for special, small groups. But it’s not something you want to rely on for your project’s well-being. We romanticize the notion that people can “dial in” and just “know” what needs to be done next. We think if we can just get everyone to “see” the same vision then everything will come out awesome. But imagine the best relationship you have, where you feel the closest and safest and can communicate without saying everything. Now, how would you get that close to 12 people you have never met? What would be required? Would you want to do that? Is it even possible?
24. Expecting team members to just “figure it out” is the first place many of us go wrong. It’s necessary to explicitly define structure. This isn’t about controlling freedom of expression or creating auditing busywork. If you do not outline the ways members of your team work and communicate, then you cannot expect people to do those two things.
25. Create documentation to let new team members learn your workflows. That means you have to adopt a workflow. Don’t just make one up; adopt a workflow that’s been published by another organization. That will help keep member egos out of the decision and allow for everyone to more openly talk about the pros and cons of the workflow. Hone the workflow through group consensus, and make sure that the process to change the workflow is also defined. Let new team members know they will have a chance to participate in the evolution of the team workflow over time.
26. Many teams have begun adopting working agreements. This is useful because we have so many ways to communicate and track data. Although everyone should be empowered to bring new ideas and tools to the table, it’s important for the team to have well-defined communication and documentation pathways. Team members should have an idea of where something is most likely to be documented or communicated, whether that’s in email, Slack, or on the project wiki. When they want to communicate information, they should know how to do so. As with the workflow, these agreements should be reviewed and updated by the group on regular intervals.
27. Respect team members by setting expectations for time commitments. There may be some expectations that apply to all members, and other members may have different expectations. It’s important to realize that time dedicated to the project is not necessarily reflective of individual’s commitment to the project. There are many factors outside of a project that affect an individual’s available time. Recognize that we cannot operate in a continual sense of “urgency.” Also recognize that in their time away from the project team members should pursue their interests and responsibilities, and that pursuit is going to make them better team members.
28. We often neglect to make time for communication, and this is a mistake. In order to have a high-functioning team, we need to normalize communications. There should be an expectation of discussion and negotiation before major decisions are made. Every team member should have a voice in the project, and the team should prioritize hearing those voices.
29. It is foolish to believe that there is any aspect of the project that will not involve a gap of knowledge of some kind. It’s critical to expect this gap as a default. Do not offer supportive materials on-demand, or ask if anyone has any questions. Create supportive materials up front and ask the group where we missed details or could clarify concepts, how can we make this documentation better? Assume that work will be required to help everyone “get on the same page” and share a common understanding of the task, feature, or vision.
30. Documentation and supportive tooling should be expected at every step of project development. Whether that involves designers publishing a list of colors in HEX, RGB, and CMYK formats for the project theme, or developers creating a migration script to automatically update everyone’s dev environments, it is critical to make this a norm for behavior. No features should go into a project without accompanying documentation. And that documentation should be in triplicate: Something to explain to the project team and other developers, something to explain to the business and sales sides, and something to explain to the end users.
31. Especially when all or part of your team is remote, it’s critical to provide documentation of everything. This includes the evolution of the ideas that go into the project, the workings of the actual code of the project, and the explanation to users of how to use the project.
32. Team members should work to create install guides to help developers keep up, style guides to help design and development communicate, tutorials, and videos to educate everyone about how things work and why they work that way. Changes should always be accompanied by materials and tools to help updates go more smoothly, from developers to end users. And everyone on the team should help improve dev environments and production processes to help every team member keep up and stay involved.
33. Developers often grab a task from a list and begin implementing a solution right away. In some situations that is just fine. But it is often desirable to allow a developer to think about the solution and discuss it with peers before diving fully into implementation. Especially for those large features of a project, it can be critical to make sure something gets built in a way that is going to be sustainable and understandable for the rest of the team. Reviewing the design of a component or feature before it is built allows for a more full set of ideas to be discussed and evaluated.
34. Code reviews are more than a formality. The goal of a code review is to evaluate the code for technical accuracy and avoid any major breakage or catastrophe. But the code review is also the place where we explain changes to other developers, verify that documentation has been provided for both developers and end users, and approve the plan to get those changes into the main branches of the project. These are all valuable aspects of the code review, and we should budget an appropriate amount of time to conduct all of this business around the code we write.
35. All of the communication practices we just discussed are valuable opportunities to build the sense of Psychological Safety on our team. These are all moments when we can have open, egalitarian discussion and where we can exhibit empathy and support to our colleagues. But many of us have been in situations where these behaviors have not led to open and productive discussions. In fact, all of those communications practices can be bent towards evil, and, sometimes even without conscious effort, they could be twisted to undermine the team.
36. A lot of the negative experiences that can happen during team interactions like design or code reviews can be attributed to team members taking a defensive posture. It may be natural to feel like presenting your work is a risk or an uncomfortable thing, but that feeling is actually the result of being part of a team without a good sense of Psychological Safety. In a safe environment, we can present work about which we are not confident because we know that we have mutual respect and empathy. Wherever the code starts, it will be better when we finish the review. Luckily, we can move from a defensive mode to a supportive mode in our communication.
37. I want to review some ways in which we can shift our communication from a defensive mode to a supportive mode, and I feel the Gibb categories of communication provide a nice model for thinking about this. Jack Gibb outlined these six juxtapositions in order to describe the ways in which we make defensive statements or inquiries, and the ways in which we can recast our communication to be more supportive. Gibb’s point is that supportive communication is much more effective, so by reducing defensive communication we are strengthening the meaning of our words.
38. Using the word “you” casts a sense of judgement on the listener. Even innocent observations can become offensive when phrased as a “you” statement. Recasting these statements as “I” statements removes the sense of judgement and is more likely to elicit a useful response from the listener.
39. Controlling statements seek to force a decision on the listener. Conversely, Orienting statements seek to find common ground that satisfies the needs of speaker and listener more equitably. Note that this is not the same as a “compromise,” which carries a connotation that the decision is inferior to the alternative. On a team it’s essential to prefer Orientation statements because it is crucial to make sure everyone’s needs are met as well as possible. If a solution doesn’t work for the whole team, then it should not be forced on the team.
40. There are many times in life when we value Strategic statements. However, in the context of a team that values open communication and mutual respect, Strategic statements are not as valuable as Spontaneous statements. Honest, straightforward communication is more likely to highlight the actual meaning of words and focus attention on issues or problems that need focus. Strategic statements are a way of leading the team off-track to arrive at an agenda held by the speaker. That personal agenda is unlikely to be in the best interest of the team.
41. In the tech world it is easy to “check out” of a discussion. We often have devices whose explicit purpose is to bridge our reality with a virtual space, so it can be easy to accidentally get caught up not paying attention to the conversation around us. But it’s crucial for the good of the team that during discussions and reviews all members are engaged. Neutral postures or responses are likely to create the feeling that we don’t respect our colleagues and don’t care about them. Empathetic statements and postures allow communication to be less hindered by those concerns and more effective overall.
42. There are a lot of ways in which Superiority is expressed in the tech world. Developers often present work and expect their peers to just “figure it out.” Sometimes there is open, vocal disparagement of team members or their roles. Often we neglect to provide background information to help colleagues understand code or approaches. It’s important to move towards a more egalitarian mode of communication to improve the sense of Psychological Safety on the team. This mode also leads to an overall better-informed team and increased sense of mutual respect.
43. The final defensive mode of communication in this list is Certainty, which is balanced by Provisionalism. Certainty is the belief that the speaker is right with total disregard for any other information or insight. This may be because of a totalitarian personality, or it could be due to ignorance of any other approach. Regardless, dealing with instances of Certainty is frustrating and erodes the sense of mutual respect and equality in communication. Provisionalism provides an alternative, where it is fine to come into a discussion with an idea of the preferred outcome, but it is important to weigh all of the information and choose the best solution proposed.
44. Once we’ve put structures in place and practiced to improve our communications, it’s important to remember that we won’t always get it right the first time. Or, maybe, the second time. This is OK. At some point everyone will need a second chance. We should be prepared to give that to them.
45. We don’t operate in a world where you make a mistake and then you crawl in a hole and hide for the rest of your life. We can recover from the mistakes we make.
46. The feeling that there won’t be a second chance, or a way to make up for a mistake, leads to all sorts of bad things. Individuals who feel insecure in their job or professional work experience issues throughout their life. It’s critical to convey the understanding that there are ways to make up for mistakes. The sense of Psychological Safety extends beyond just the words we use. It also means that the team is there to support us and help us recover after a mis-step.
47. So… To review…
48. The way your team works is more important than the people on it. Strive to find great people who you crave to be around, but understand that your team is not limited or enabled by the skills of any individual member.
49. Avoid cults of personality. Favoritism and exceptionalism don’t really help teams.
50. Be very clear about expectations in terms of time commitments, location commitments, and commitments to uphold the functional structures of the team itself.
51. Create a culture that includes conversation, documentation, and supportive tooling. Outline clear expectations for these things to be a part of every design review, code review, and meeting.
52. Make opportunities for team members to talk about and work on improving communications skills just like the rest of the work they do. Evolve your team process and structure over time based on group consensus and feedback.
53. At every step move to supportive communication over defensive communication. Praise and reward supportive behavior, not just outstanding technical or production achievements. Convey to other team members that you value them and their input.
54. And keep an open mind and kind heart for those of us who screw up. We all will make mistakes, and we all deserve the do-over.
55. Thanks so much for listening. You can find the slides for this talk at the link here. You can find me on Twitter and Github: I’m @shawnr. Please feel free to reach out.