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 RiderDirector 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 ExpectaMonsUnifying 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” thingsSignals unrealistic expectations and a false sense of autonomy that corrodes team.

Code changes without discussionChanges might be wide-ranging and performed outside of work hours as a way to “sneak” in changes.

Tech reviews are combativeDiscussions of technical direction are full of jargon and fail to keep everyone engaged.

Signs of CompeMMon

Disingenuous requests for feedbackComments and questions are met with resistance or defensive responses, or are used to shame others.

Disregard for the value of documentationBelief that documentation is best performed by “lesser” team members who “need to learn” the system.

Expected to soloEach 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 EnMcesWe 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 ADVERSITYHow > 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 ARISTOTLEIn 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 SAFETYsuffer 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 diversityWhen 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 STRUCTUREBring team members into the fold by introducing your communication and interaction structures and processes.

HELP

and sMck to them.DEFINE WORKFLOWS

TEAM WORKING

AGREEMENTSDefine the tools that enable the process.

CREATE AND MAINTAIN

Set expectaMons for Mme commitmentsRecognize 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 updatesProvide documents, video tutorials, animated GIFs, or anything else to convey how to update code.

Distribute support tools with changesScripts, migration commands, and other tools should come alongside complex change sets.

Continuous improvementDev environments and production processes should always evolve towards simplicity and reliability.

DESIGN REVIEWS

FIRSTDiscuss 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 + ToolsCode 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 DEFENSIVEto 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 WORLD

Even ader we make serious mistakes.

W e D e s e r v eSecond 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 PERSONALITYThey create rifts on teams and a situation of inequality that brings down even top performers.

CLEAR EXPECTATIONSCommunicate reasonable expectations about process, communication, and time commitments. Revisit and update those expectations over time.

ESTABLISH

EFFECTIVE COMMUNICATION

AND SUPPORTIVE

BEHAVIORMake discussion and negotiation part of your

regular process. Make documentation and supportive tooling part of your technical

requirements.

NORMALIZE

WORK TO IMPROVECommunication 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 DEFENSIVEP

RE

FE

R

ALLOW DO-OVERSExpect that everyone will make mistakes, and everyone will need help at some time.

T H A N K Shttp://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