Advertisement
Check these out next
Work is not a Dare: Tips for Building Inclusive Teams
Jul. 22, 2016•0 likes•2,838 views
4 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Technology
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.
Shawn RiderFollow
Educator, Web Technologist, Creative DeveloperAdvertisement
Work is not a Dare: Tips for Building Inclusive Teams
- 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
- Hi, I’m Shawn! Shawn Rider Director of Web, Application, and Technology Studies School of New & Continuing Studies Seattle University http://webdev.seattleu.edu
- 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.
- “We just really need you to own this one. Let me feel the urgency!” DARE-BASED WORKPLACES
- 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.
- 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.
- FEAR UNCERTAINTY DOUBT The dare-based workplace stifles productivity, creativity, and breeds fear.
- Mutual respect. Open communication. Empathy. Support. BETTER WAYS TO TEAM
- 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.
- 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.
- Not everyone on a team wants or believes the same thing. GOALS & VALUES
- But everyone unites around the project. Diverse purposes, goals, and reasons for participation are healthy.
- 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.
- 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.
- CONVERSATIONAL TURN-TAKING AVERAGE SOCIAL SENSITIVITY Open, egalitarian communication. Empathy and mutual respect.
- TEAMS WITH POOR PSYCHOLOGICAL SAFETY suffer reductions in productivity, quality of output, and member satisfaction.
- We can work to become better at open, supportive communication. PRACTICE MAKES PERFECT
- The Myth of the 10x Developer and beyond. CULTS OF PERSONALITY
- DON’T EXIST10x Developers And even if they did, you wouldn’t want a whole team of them.
- 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
- FRAGILE PILLARS OF KNOWLEDGE Preferential treatment, favoritism, and overly-hierarchical team structures create dangerous liabilities for the project.
- 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.
- Diverse individuals with common understandings. SETTING EXPECTATIONS
- 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
- DEFINE STRUCTURE Bring team members into the fold by introducing your communication and interaction structures and processes. HELP
- and sMck to them. DEFINE WORKFLOWS
- TEAM WORKING AGREEMENTS Define the tools that enable the process. CREATE AND MAINTAIN
- 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.
- Make conversation and negotiation the regular. NORMALIZE COMMUNICATIONS
- ALWAYS ASSUME THERE IS A GAP of understanding of knowledge of experience of vision
- 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.
- 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.
- 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.
- 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
- 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
- Skill building beyond the technical. IMPROVING COMMUNICATION
- 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.
- 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)
- 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
- 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
- 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
- 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
- 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
- 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
- Everyone needs a helping hand eventually. SECOND CHANCES
- CONTINUES TO REVOLVETHE WORLDEven ader we make serious mistakes.
- 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.
- Summary and conclusion. FINAL THOUGHTS
- 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 ?
- A V O I D CULTS OF PERSONALITY They create rifts on teams and a situation of inequality that brings down even top performers.
- CLEAR EXPECTATIONS Communicate reasonable expectations about process, communication, and time commitments. Revisit and update those expectations over time. ESTABLISH
- 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
- 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.
- 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
- ALLOW DO-OVERS Expect that everyone will make mistakes, and everyone will need help at some time.
- T H A N K S http://shawnr.net/teams Shawn Rider @shawnr
- Image credits smoke stacks: https://www.flickr.com/photos/usnationalarchives/4266497076/ lunch atop skyscraper: https://www.flickr.com/photos/hanok/14025623919/ tug of war: https://www.flickr.com/photos/muohio_digital_collections/3190906467/ human tower: https://www.flickr.com/photos/carloszgz/15886677940/ consensus: https://www.flickr.com/photos/-adam/6215839735/in/album-72157627704339653/ bell phone system: https://www.flickr.com/photos/internetarchivebookimages/14569253009/ bell system coils: https://www.flickr.com/photos/internetarchivebookimages/14752891571/ trooper and chewie: https://www.flickr.com/photos/tinfrey/16683140266/ harvard faculty discussion: https://www.flickr.com/photos/internetarchivebookimages/14768253694/ cool phone: https://www.flickr.com/photos/andrew_d_miller/4235124889/ be kind rewind: https://www.flickr.com/photos/mandydale/2552385888/ blurry woman: https://upload.wikimedia.org/wikipedia/commons/2/25/Katherine_Maher.jpg nyt aristotle microscope: http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to- build-the-perfect-team.html?_r=1 couple on bench: https://www.flickr.com/photos/martinhricko/8204038502 ali: https://www.flickr.com/photos/78907696@N06/17050425710/ sale sign: https://www.flickr.com/photos/juggernautco/6598456341/ git branches: https://upload.wikimedia.org/wikipedia/commons/a/af/ Revision_controlled_project_visualization-2010-24-02.svg book burning: https://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Book_burning_(2).jpg/768px- Book_burning_(2).jpg rouse solo: https://upload.wikimedia.org/wikipedia/commons/0/05/Rouse_on_wing_of_T-53A.jpg baggage feedback: https://www.flickr.com/photos/hatters/12008932313/ shuttle astronauts: https://www.flickr.com/photos/nasacommons/9458241217/ apollo 17 training: https://www.flickr.com/photos/nasacommons/9457451127/ astronaut cabin training: https://www.flickr.com/photos/sdasmarchives/7142958443/ apollo 17 bw: https://www.flickr.com/photos/nasacommons/9457418687/ star wars photos are owned by Disney Lord of the Flies: http://www.newyorker.com/wp-content/uploads/2015/09/Keohane-Politically-Correct-Lord-of- the-Flies-1200.jpg 10x developer: https://static.pexels.com/photos/7375/startup-photos.jpg github flow: https://guides.github.com/introduction/flow/ remote team agreement from lucid: http://blog.lucidmeetings.com/blog/remote-team-working-agreement- example punch clock: https://www.flickr.com/photos/muchadoaboutnothing/440872101/ crumbling columns: https://www.flickr.com/photos/elwillo/18252145472/ phrenology: https://www.flickr.com/photos/internetarchivebookimages/14781534842/ amsterdam crane: https://www.flickr.com/photos/103313536@N08/12321169345/ multnomah falls: https://www.flickr.com/photos/anupamsrivastava/10351189803/ helping hand on old rag: https://upload.wikimedia.org/wikipedia/commons/e/ee/ Helping_Hand_on_Old_Rag_(22310055090).jpg black keyboard: http://www.public-domain-image.com/free-images/objects/electronics-devices/computer- components-pictures/black-computer-keyboard.jpg magnifying glass on keyboard: http://www.public-domain-image.com/free-images/objects/electronics-devices/ computer-components-pictures/magnifying-glass-atop-computer-wireless-keyboard.jpg astronomy chart: https://www.flickr.com/photos/internetarchivebookimages/14741203876/ dancer: https://www.flickr.com/photos/osucommons/4203242681/ jumping into sea: https://www.flickr.com/photos/macrj/3910242587/ "equality" by daniel song: https://www.flickr.com/photos/danielsong/2984663795/ headshot1: https://www.flickr.com/photos/citrixsummit/24066843590/ headshot2: https://www.flickr.com/photos/jacobhenry/3350722806/ headshot3: https://www.flickr.com/photos/byte/9276286966 headshot4: https://www.flickr.com/photos/danfinnen/5299383856/ bieber fans: https://www.flickr.com/photos/pamhule/10003956743/ job wheel: https://s-media-cache-ak0.pinimg.com/originals/f2/f8/cb/ f2f8cba4b094eee2657b2797487b12f9.jpg crossing guard: https://www.flickr.com/photos/jeweledlion/1502706553/ practice: https://www.flickr.com/photos/mrzeon/5199627392/ practice: https://www.flickr.com/photos/clover_1/6469876953/ practice: https://www.flickr.com/photos/allio/5163787866/ red cross collie: https://upload.wikimedia.org/wikipedia/commons/d/d4/Red_Cross_collie.jpg
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?”
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?)
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- So… To review…
- 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.
- Avoid cults of personality. Favoritism and exceptionalism don’t really help teams.
- Be very clear about expectations in terms of time commitments, location commitments, and commitments to uphold the functional structures of the team itself.
- 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.
- 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.
- 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.
- 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.
- 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.
Advertisement