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!
Director of Web, Application, and Technology Studies
School of New & Continuing Studies
Be;er Ways to Team
Cults of Personality
Behaviors that turn doing your job into a
competition (and why those kinds of environments
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.
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!”
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
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
The dare-based workplace
stifles productivity, creativity,
and breeds fear.
Mutual respect. Open communication. Empathy. Support.
BETTER WAYS TO TEAM
Teams are diﬃcult to assemble
We must search all over for good
team members, and the cost savings
or ease of remote work lures us.
Focus on speciﬁc skills or IQ
We focus on gathering “Top Tier”
minds with specific technical expertise
and almost never consider other
Not everyone on a team wants
or believes the same thing.
But everyone unites around the project.
Diverse purposes, goals, and reasons for
participation are healthy.
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
G o o g l e ’ s
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
Empathy and mutual
suffer reductions in
productivity, quality of
output, and member
We can work to become better at
open, supportive communication.
The Myth of the 10x Developer and beyond.
CULTS OF PERSONALITY
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.
The larger mass of team
members are reduced to
The people most impacted by the
traditional hierarchy suffer severe
reductions in performance.
The Low Performers
Preferential treatment, favoritism,
and overly-hierarchical team
structures create dangerous
liabilities for the project.
SMﬂing 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.
At best, it works for two or three people. But often
it doesn’t work, even at small scales.
THE MYTH OF
Bring team members into the fold by introducing
your communication and interaction structures
and sMck to them.
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.
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.
Create a historical trail of
documents so members
can follow along with
design and project ideas
as they evolve.
Documentation in code
and around implementing
code features is critical for
pillars and insuring
Documentation should not
require high-end technical
skills or special tools.
Make it easy to participate
in documentation and
easier to consume.
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.
Dev environments and production
processes should always evolve
towards simplicity and reliability.
Discuss solutions and direction up-front in
order to maintain a clear set of expectations
and understanding across the team.
TALK ABOUT THE WORK
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
Approve the update path
Skill building beyond the technical.
MOVING FROM DEFENSIVE
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
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
from Jack Gibb’s “Defensive Communication” in Communication Theory (2007)
“You didn’t use the correct
syntax here, so your code
will fail when this obscure
“Why would you do it this
“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
“I don’t understand how this
works. Can you explain?”
“I would prefer to call this
object something different.
Can we figure out another
“This will all need to be
completed by Tuesday.”
“We should use this
because these other two
options are for
“It wasn’t in the specs, so
I’m not responsible for
“How can we get this
ready in time for the
opportunity we have on
“I like this option best,
but these other two are
also used. What do you
“I understand the
importance of this
feature; how can we
accomplish this in the
time we have?”
of technical issues aimed
at replacing unwanted
Bringing up unrelated
to undermine the authority
Unwarranted positive or
designed to further an
issues with due diligence
and a level-headed
Responding to relevant
information to make
others feel supported.
support, and criticism
designed to better the
“Let me know when you
get to the details I need to
“I’m just working on this
while you talk. Don’t
worry, I’ll pay attention.”
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
Use of jargon or advanced
explanation or care.
Disparagement of other
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
ability to do work.
Recognition of the value
of diverse backgrounds
“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
“I think this would be a
great feature. Let’s do
some research to see if it
would actually work.”
Everyone needs a helping hand eventually.
TO REVOLVETHE WORLDEven ader we make serious mistakes.
W e D e s e r v e
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
Summary and conclusion.
is not as important as
Find “good fits” where you can, but
realize that your process will make
or break your team.
A V O I D
They create rifts on
teams and a situation of
inequality that brings
down even top
Communicate reasonable expectations about process,
communication, and time commitments. Revisit and
update those expectations over time.
Make discussion and negotiation part of your
regular process. Make documentation and
supportive tooling part of your technical
Communication skills can be practiced and
improved like any other. Make time in your
team process to consider and evolve your
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.
Expect that everyone will make
mistakes, and everyone will need
help at some time.
T H A N K S
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/
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-
couple on bench: https://www.flickr.com/photos/martinhricko/8204038502
sale sign: https://www.flickr.com/photos/juggernautco/6598456341/
git branches: https://upload.wikimedia.org/wikipedia/commons/a/af/
book burning: https://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Book_burning_(2).jpg/768px-
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-
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-
punch clock: https://www.flickr.com/photos/muchadoaboutnothing/440872101/
crumbling columns: https://www.flickr.com/photos/elwillo/18252145472/
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/
black keyboard: http://www.public-domain-image.com/free-images/objects/electronics-devices/computer-
magnifying glass on keyboard: http://www.public-domain-image.com/free-images/objects/electronics-devices/
astronomy chart: https://www.flickr.com/photos/internetarchivebookimages/14741203876/
jumping into sea: https://www.flickr.com/photos/macrj/3910242587/
"equality" by daniel song: https://www.flickr.com/photos/danielsong/2984663795/
bieber fans: https://www.flickr.com/photos/pamhule/10003956743/
job wheel: https://s-media-cache-ak0.pinimg.com/originals/f2/f8/cb/
crossing guard: https://www.flickr.com/photos/jeweledlion/1502706553/
red cross collie: https://upload.wikimedia.org/wikipedia/commons/d/d4/Red_Cross_collie.jpg
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.