SlideShare a Scribd company logo
1 of 57
Download to read offline
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

More Related Content

Viewers also liked (15)

ResourceSync Tutorial
ResourceSync TutorialResourceSync Tutorial
ResourceSync Tutorial
 
Building high performance teams through psychological safety
Building high performance teams through psychological safetyBuilding high performance teams through psychological safety
Building high performance teams through psychological safety
 
Video Editing and Encoding
Video Editing and EncodingVideo Editing and Encoding
Video Editing and Encoding
 
Social Media & Personal Branding
Social Media & Personal BrandingSocial Media & Personal Branding
Social Media & Personal Branding
 
Video editing
Video editingVideo editing
Video editing
 
We Go: Diversity and Inclusion Framework
We Go: Diversity and Inclusion Framework We Go: Diversity and Inclusion Framework
We Go: Diversity and Inclusion Framework
 
Culture Builder Bootcamp: Building an Inclusive Organizational Culture
Culture Builder Bootcamp: Building an Inclusive Organizational Culture Culture Builder Bootcamp: Building an Inclusive Organizational Culture
Culture Builder Bootcamp: Building an Inclusive Organizational Culture
 
Video editing presentation
Video editing presentationVideo editing presentation
Video editing presentation
 
Intro to Film: Editing
Intro to Film: EditingIntro to Film: Editing
Intro to Film: Editing
 
Film Editing Master
Film Editing MasterFilm Editing Master
Film Editing Master
 
Inclusion ppt
Inclusion pptInclusion ppt
Inclusion ppt
 
Different Types of Editing
Different Types of EditingDifferent Types of Editing
Different Types of Editing
 
Computer Technology Class 7 Movie Editing
Computer Technology Class 7 Movie EditingComputer Technology Class 7 Movie Editing
Computer Technology Class 7 Movie Editing
 
Editing techniques
Editing techniquesEditing techniques
Editing techniques
 
Editing - AS Media Studies
Editing  - AS Media StudiesEditing  - AS Media Studies
Editing - AS Media Studies
 

Similar to Work is not a Dare: Tips for Building Inclusive Teams

What needs to be true? Patterns of engineering agility
What needs to be true? Patterns of engineering agilityWhat needs to be true? Patterns of engineering agility
What needs to be true? Patterns of engineering agilityAndy Norton
 
Cross-Functional Code Reviews - As presented at O'Reilly OSCON 2019
Cross-Functional Code Reviews - As presented at  O'Reilly OSCON 2019Cross-Functional Code Reviews - As presented at  O'Reilly OSCON 2019
Cross-Functional Code Reviews - As presented at O'Reilly OSCON 2019Margaret Fero
 
How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...
How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...
How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...Scrum Day Bandung
 
Go forth and self organise -- building great teams 1st Conference Melbourne 2...
Go forth and self organise -- building great teams 1st Conference Melbourne 2...Go forth and self organise -- building great teams 1st Conference Melbourne 2...
Go forth and self organise -- building great teams 1st Conference Melbourne 2...Edmund O'Shaughnessy
 
Tom - Scrum
Tom - ScrumTom - Scrum
Tom - Scrumd0nn9n
 
Teaming Presentation
Teaming PresentationTeaming Presentation
Teaming PresentationJohnJHarrison
 
Can Agile Unlock Diversity's Potential?
Can Agile Unlock Diversity's Potential?Can Agile Unlock Diversity's Potential?
Can Agile Unlock Diversity's Potential?Ruha Devanesan
 
Managing Matrix Organization
Managing Matrix OrganizationManaging Matrix Organization
Managing Matrix Organizationinformusa
 
Sym18 296 Ae (Dbaccess Case Study)
Sym18 296 Ae (Dbaccess Case Study)Sym18 296 Ae (Dbaccess Case Study)
Sym18 296 Ae (Dbaccess Case Study)La Red DBAccess
 
Scale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing ControlScale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing ControlAtlassian
 
ISOL 533 Project1OverviewWrite paper in sections.docx
ISOL 533 Project1OverviewWrite paper in sections.docxISOL 533 Project1OverviewWrite paper in sections.docx
ISOL 533 Project1OverviewWrite paper in sections.docxvrickens
 
Resilient Design Management
Resilient Design ManagementResilient Design Management
Resilient Design ManagementChris Avore
 
The Future Of Employee Collaboration
The Future Of Employee CollaborationThe Future Of Employee Collaboration
The Future Of Employee CollaborationRichard Harbridge
 
Distributed Agile Development: Practices for building trust in team through E...
Distributed Agile Development: Practices for building trust in team through E...Distributed Agile Development: Practices for building trust in team through E...
Distributed Agile Development: Practices for building trust in team through E...Waqas Tariq
 
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile InstituteInnovation Roots
 
Go Forth and Self-organise, LAST Conference Melbourne 2017
Go Forth and Self-organise, LAST Conference Melbourne 2017Go Forth and Self-organise, LAST Conference Melbourne 2017
Go Forth and Self-organise, LAST Conference Melbourne 2017Edmund O'Shaughnessy
 

Similar to Work is not a Dare: Tips for Building Inclusive Teams (20)

What needs to be true? Patterns of engineering agility
What needs to be true? Patterns of engineering agilityWhat needs to be true? Patterns of engineering agility
What needs to be true? Patterns of engineering agility
 
Cross-Functional Code Reviews - As presented at O'Reilly OSCON 2019
Cross-Functional Code Reviews - As presented at  O'Reilly OSCON 2019Cross-Functional Code Reviews - As presented at  O'Reilly OSCON 2019
Cross-Functional Code Reviews - As presented at O'Reilly OSCON 2019
 
How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...
How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...
How (can) Scrum and DevOps Walk Together to Build a High-Quality Product Deli...
 
Go forth and self organise -- building great teams 1st Conference Melbourne 2...
Go forth and self organise -- building great teams 1st Conference Melbourne 2...Go forth and self organise -- building great teams 1st Conference Melbourne 2...
Go forth and self organise -- building great teams 1st Conference Melbourne 2...
 
Tom - Scrum
Tom - ScrumTom - Scrum
Tom - Scrum
 
Teaming Presentation
Teaming PresentationTeaming Presentation
Teaming Presentation
 
Can Agile Unlock Diversity's Potential?
Can Agile Unlock Diversity's Potential?Can Agile Unlock Diversity's Potential?
Can Agile Unlock Diversity's Potential?
 
Managing Matrix Organization
Managing Matrix OrganizationManaging Matrix Organization
Managing Matrix Organization
 
Sym18 296 Ae (Dbaccess Case Study)
Sym18 296 Ae (Dbaccess Case Study)Sym18 296 Ae (Dbaccess Case Study)
Sym18 296 Ae (Dbaccess Case Study)
 
Scale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing ControlScale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing Control
 
Starting with c
Starting with cStarting with c
Starting with c
 
ISOL 533 Project1OverviewWrite paper in sections.docx
ISOL 533 Project1OverviewWrite paper in sections.docxISOL 533 Project1OverviewWrite paper in sections.docx
ISOL 533 Project1OverviewWrite paper in sections.docx
 
Resilient Design Management
Resilient Design ManagementResilient Design Management
Resilient Design Management
 
Agile thinking
Agile thinkingAgile thinking
Agile thinking
 
The Future Of Employee Collaboration
The Future Of Employee CollaborationThe Future Of Employee Collaboration
The Future Of Employee Collaboration
 
Distributed Agile Development: Practices for building trust in team through E...
Distributed Agile Development: Practices for building trust in team through E...Distributed Agile Development: Practices for building trust in team through E...
Distributed Agile Development: Practices for building trust in team through E...
 
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
 
Scrum master & agile master
Scrum master & agile masterScrum master & agile master
Scrum master & agile master
 
Go Forth and Self-organise, LAST Conference Melbourne 2017
Go Forth and Self-organise, LAST Conference Melbourne 2017Go Forth and Self-organise, LAST Conference Melbourne 2017
Go Forth and Self-organise, LAST Conference Melbourne 2017
 
ALTNET
ALTNETALTNET
ALTNET
 

More from Shawn Rider

Living Syleguides
Living SyleguidesLiving Syleguides
Living SyleguidesShawn Rider
 
Barbarians at the Gate: Games and Culture
Barbarians at the Gate: Games and CultureBarbarians at the Gate: Games and Culture
Barbarians at the Gate: Games and CultureShawn Rider
 
Massaging the Pony: Message Queues and You
Massaging the Pony: Message Queues and YouMassaging the Pony: Message Queues and You
Massaging the Pony: Message Queues and YouShawn Rider
 
Django Forms: Best Practices, Tips, Tricks
Django Forms: Best Practices, Tips, TricksDjango Forms: Best Practices, Tips, Tricks
Django Forms: Best Practices, Tips, TricksShawn Rider
 
Teaching an Old Pony New Tricks: Maintaining and Updating and Aging Django Site
Teaching an Old Pony New Tricks: Maintaining and Updating and Aging Django SiteTeaching an Old Pony New Tricks: Maintaining and Updating and Aging Django Site
Teaching an Old Pony New Tricks: Maintaining and Updating and Aging Django SiteShawn Rider
 

More from Shawn Rider (6)

Living Syleguides
Living SyleguidesLiving Syleguides
Living Syleguides
 
Intro to Yo
Intro to YoIntro to Yo
Intro to Yo
 
Barbarians at the Gate: Games and Culture
Barbarians at the Gate: Games and CultureBarbarians at the Gate: Games and Culture
Barbarians at the Gate: Games and Culture
 
Massaging the Pony: Message Queues and You
Massaging the Pony: Message Queues and YouMassaging the Pony: Message Queues and You
Massaging the Pony: Message Queues and You
 
Django Forms: Best Practices, Tips, Tricks
Django Forms: Best Practices, Tips, TricksDjango Forms: Best Practices, Tips, Tricks
Django Forms: Best Practices, Tips, Tricks
 
Teaching an Old Pony New Tricks: Maintaining and Updating and Aging Django Site
Teaching an Old Pony New Tricks: Maintaining and Updating and Aging Django SiteTeaching an Old Pony New Tricks: Maintaining and Updating and Aging Django Site
Teaching an Old Pony New Tricks: Maintaining and Updating and Aging Django Site
 

Recently uploaded

QMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfQMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfROWELL MARQUINA
 
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...BookNet Canada
 
WomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneWomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneUiPathCommunity
 
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...Alkin Tezuysal
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesBernd Ruecker
 
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...Nikki Chapple
 
A Framework for Development in the AI Age
A Framework for Development in the AI AgeA Framework for Development in the AI Age
A Framework for Development in the AI AgeCprime
 
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...amber724300
 
Modern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better StrongerModern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better Strongerpanagenda
 
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentEmixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentPim van der Noll
 
Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Karmanjay Verma
 
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical InfrastructureVarsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructureitnewsafrica
 
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS:  6 Ways to Automate Your Data IntegrationBridging Between CAD & GIS:  6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integrationmarketing932765
 
Landscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfLandscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfAarwolf Industries LLC
 
Français Patch Tuesday - Avril
Français Patch Tuesday - AvrilFrançais Patch Tuesday - Avril
Français Patch Tuesday - AvrilIvanti
 
Assure Ecommerce and Retail Operations Uptime with ThousandEyes
Assure Ecommerce and Retail Operations Uptime with ThousandEyesAssure Ecommerce and Retail Operations Uptime with ThousandEyes
Assure Ecommerce and Retail Operations Uptime with ThousandEyesThousandEyes
 
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...panagenda
 
Glenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security ObservabilityGlenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security Observabilityitnewsafrica
 
Manual 508 Accessibility Compliance Audit
Manual 508 Accessibility Compliance AuditManual 508 Accessibility Compliance Audit
Manual 508 Accessibility Compliance AuditSkynet Technologies
 
Kuma Meshes Part I - The basics - A tutorial
Kuma Meshes Part I - The basics - A tutorialKuma Meshes Part I - The basics - A tutorial
Kuma Meshes Part I - The basics - A tutorialJoão Esperancinha
 

Recently uploaded (20)

QMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfQMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdf
 
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
Transcript: New from BookNet Canada for 2024: BNC SalesData and LibraryData -...
 
WomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneWomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyone
 
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architectures
 
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
 
A Framework for Development in the AI Age
A Framework for Development in the AI AgeA Framework for Development in the AI Age
A Framework for Development in the AI Age
 
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
JET Technology Labs White Paper for Virtualized Security and Encryption Techn...
 
Modern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better StrongerModern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
 
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentEmixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
 
Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#
 
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical InfrastructureVarsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
 
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS:  6 Ways to Automate Your Data IntegrationBridging Between CAD & GIS:  6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
 
Landscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfLandscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdf
 
Français Patch Tuesday - Avril
Français Patch Tuesday - AvrilFrançais Patch Tuesday - Avril
Français Patch Tuesday - Avril
 
Assure Ecommerce and Retail Operations Uptime with ThousandEyes
Assure Ecommerce and Retail Operations Uptime with ThousandEyesAssure Ecommerce and Retail Operations Uptime with ThousandEyes
Assure Ecommerce and Retail Operations Uptime with ThousandEyes
 
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
 
Glenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security ObservabilityGlenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security Observability
 
Manual 508 Accessibility Compliance Audit
Manual 508 Accessibility Compliance AuditManual 508 Accessibility Compliance Audit
Manual 508 Accessibility Compliance Audit
 
Kuma Meshes Part I - The basics - A tutorial
Kuma Meshes Part I - The basics - A tutorialKuma Meshes Part I - The basics - A tutorial
Kuma Meshes Part I - The basics - A tutorial
 

Work is not a Dare: Tips for Building Inclusive Teams

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

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