 Thanks everybody. Thank you to everyone organizing open source and fields. Thank you all for coming out This is truly been the best conference that I've been a part of and it's like literally an hour into it Thank you also Nicole for the amazing talk previously, which I'm not going to be nearly as funny as her But I think it dovetails. Well, my name is Sean Ryder I'm the director of web application technology studies at Seattle University I run a web development certificate program that targets Working adults who want to do a change of career into the web development industry I've spent a lot of years building websites about 21 years building websites now I was previously head of technology for the public broadcasting service education group and I've worked with lots and lots of startups and in the nonprofit media sphere and all sorts of things education Technology and then weird stuff on the web or pretty much the three things that I'm really into Today I want to run through a bunch of stuff that is actually what I consider to be quite pragmatic I've worked in workplaces that have become dare-based And I'm sure many of you have worked in workplaces that either have become or were dare-based when you got there I've seen my students encounter this as they've gone out to interview at companies and it's something that really Sort of breaks my heart to see I want to explore better ways to make your team happy productive and stable And that includes turning away from a lot of the traditional behaviors and actually Practicing communication skills to build a supportive and respectful environment that can accommodate a more diverse range of team members So I want to talk a little bit about dare-based work places These are the places where everyone's supposed to always be operating at a maximum level of commitment the urgency you should be able to feel from a square mile away and All of these attitudes Really turn our day-to-day work into Something closer to a competition There's nothing that rankles me Okay, there's two things that rank me one is being called by my last name I'm Sean not writer And but the other thing is I'm being told to own something. I really Hate that term especially as it is applied to people working on projects It's an unrealistic goal. It creates a false sense of autonomy It corrodes the team because it encourages developers and production team members to work in a non collaborative way because you're supposed to own it It's right there in the phrase Often that that makes developers emboldened to change code without any kind of discussion or review when that happens It creates a combative environment so that when reviews are forced then developers often have these these competitive conversations about the code as opposed to actual open-hearted code reviews and And when there are team members with very strong Personalities then you know this kind of attitude and the kind of competition in the workplace forces them into sort of these worlds of dominance Well, other people who either are just not up to it or too smart to really bother playing that game We'll often just back off and eventually kind of fall away from the team and all of that hurts We also find that like a lot of the time in these competitive environments We get these disingenuous requests for feedback people will ask you what you think but they don't actually want to hear What you think and they certainly aren't prepared to deal with whatever feedback you give them This is also an environment where it's easy to disregard the value of documentation or where especially a few strong personalities might say how How much above documentation they are and that's really these other team members who need to document stuff in order to learn more From us, you know And all of this creates a situation where team members are essentially expected to solo on a project And that's not good. If you're just putting a bunch of people up to solo on the projects that they own all themselves Then why are you making a team in the first place? I just go do it by yourself or something, you know And that's fine to do but it's not it's not healthy for a team So all of these competitive behaviors are really dares right? I dare you to question my authority I dare you to expose your ignorance. I dare you to do better than me Or I dare you to subject yourself to the judgment of your peers This is not a healthy competition. It leads to fear among team members Members will become fearful of losing their jobs They might worry about the direction of the project and start to question that And they might just be anxious from the level of expectation that's constantly being thrust upon them And again, all of this begs the question that if this is how you're going to conduct yourself Why do you want to even work with other human beings? You don't appear to like them that much so We are going to explore better ways to team We've struggled to come up with surefire ways of sort of creating organizing and operating high performing team There's a lot of challenges in putting together teams, but over the years We've also been able to recognize some things about what makes team successful and both their mission and in creating a sustainable environment for doing work So we can move past these things, but first let's talk a little bit about some of these challenges Teams are really difficult to assemble We look everywhere to find the right people for our teams Tech projects require specific knowledge often So you're often looking for people with sort of specific knowledge and expertise That's not super common among all the humans in the world In order to find people who can do the work sometimes we have to broaden our horizons And look in places that we are difficult to look Or more broadly than we're used to We have to We can think about ways of organizing teams That sort of open this possibility and more people in the world and that's attractive the idea that oh Well, we could do remote work and we can involve people from all over the globe And that would allow us to seize talented people who aren't sitting right next to me in the room But but even that You know causes problems we like that. Maybe there's a lower cost associated with that Maybe we can get more people But then we have these issues of communication and of working together So we end up having a situation where Scarcity is the rule and that scarcity leads to a cascade of other Sort of challenges that that come up We also often put way too much focus on specific skills or IQ or An individual is in terms of of of sort of what muscles they have to bring to the team We focus way too much on individual actors their individual skills and individual abilities We want to bring in team members who can sort of be productive and help us move forward And so that does require some understanding of some specific technology skills But at the same time What's what this project is today is not what this project is going to be tomorrow And what we really need are people who can move along and learn over time But in technology we continue to primarily focus on hiring people Who basically have the same background which is often a college degree from a well respected cs program And more than that for many large companies It's not just a college degree from a cs program But it's a college degree from a cs program in a school that we really like because they really produce the kind of People that we think work well on our project and as soon as you start thinking that way You're you're reinforcing that notion of scarcity And you're you're just impacting sort of all of the challenges that we feel across putting together teams Another challenge that we have when we're putting together teams is that People on teams often have diverse goals and values and they don't always Want to move in the same directions at the same times This is super challenging and on in technology. It's amazing how bad of a job we do on a project Sort of dealing with that difference of of direction or of or of goals However, at the same time in popular culture, we really love romanticizing this notion of like the team of misfits That somehow manages to come together and unify their diverse perspectives into something that actually accomplishes the goal And in fact That that happens and so another challenge is kind of figuring out well, what kind of You know difference in values and goals is okay in order to still be able to achieve my goal What is really the most important thing when we're trying to unify people around a team Is not that the people are the same or that they have the exact same motivations But that they that they ultimately have the same goal for the project or that they want to reach the same point in the project Um So let's talk about um overcoming all these issues of of putting together teams Which is primarily that how is more important than who? Throughout a lot of research that's happened over the last several decades and all kinds of inquiry from an academic realms as well as Sort of pragmatic experience It's become very evident that the way your team operates is more important than the skills of the individual team members Google's project Aristotle led by julia rozofsky came out With a report talking about both sort of a meta study of all these Academic studies that have been done as well as a study of of over a hundred teams across google For a year and ultimately what they discovered was that the most important aspect of making a well-functioning team Is the notion of psychological safety? Psychological safety allows for open respectful communication and engagement in team processes And it encourages creative production as well as a sense of well-being uh, rozofsky's team identified two Aspects that sort of really suggests that a team has successfully developed a sense of psychological safety And that is conversational turn taking in average social sensitivity Uh conversational turn taking allows for open egalitarian communication Uh among all the members of the team uh discussions aren't dominated by a few personalities and people everybody's contribution to the discussion Is is valid and uh appreciated Average social sensitivity describes the level of empathy and mutual respect exhibited by most of the members of the team The ability to display empathy and respect is absolutely crucial to opening productive communication pathways Teams with poor psychological safety Are pretty much doomed. Uh, if a team is not moving towards psychological safety Then it's a good chance that they're moving towards a more competitive environment That will ultimately consume or burn out the vast majority of members That was a little bit of a slow burn on that one, but I like it Luckily, uh, we as human beings have managed to work really hard at doing a whole bunch of really difficult things We can similarly practice and improve our communication and our 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 and that's what I want to talk about sort of for the rest of Of this talk is how we're going to get there in terms of psychological safety But the first thing that we need to to fully extinguish is the notion that we are In any way shape or form creating teams around cults of personality here. Okay We are not looking for one kind of person with one kind of background We're not looking for two kinds of people with two kinds of backgrounds We're looking for people who have the existing skills to communicate and interact and that's what's most important I'm here to tell you that 10x developers don't really exist And even if they did you wouldn't want a bunch of them on your team Study after study after study of high-performing employees not just in the tech world But across all sorts of industries have shown that the most high-performing Performers on the team Are also the people who tend to have the lower job satisfaction Um ratings they they tend to look for other jobs more quickly And they tend to create an error around them where other people also don't enjoy their jobs as much So being really really like Far more exceptional at your work and being told that you're more exceptional at your work Actually creates a real problem on the team. It's kind of what it looks like We have like our precious performers who are the people who get to do everything all the time And they're the ones who get all that, you know, it's like, oh, yeah, they pushed those changes at 3 a.m Last night, but you know those were really good changes Um, and we want to launch them, you know on friday. So let's do that and um That automatically you are creating this class based system that is privileging these people at the top and everybody else knows that You're not fooling anybody and it's not like everybody just automatically says Oh, yeah, that person should totally be in charge of me and everything that I do That's that's not what's happening. These aren't necessarily managers. These are just performers on the team um So the the rest of your teams are going to um are going to become less committed to the project They're they're more at risk of leaving the project and uh, and they're generally less productive because they're less happy They they don't have as much of a say or as much agency in their work High performers are also responsible for those fragile pillars of knowledge that we find in all of the tech ruins that we come in to explore Um You rely on exceptional developers who do not communicate their ideas clearly They build giant columns of technology that nobody else really understands And then they leave they go to another job. Like I said, they're the people most likely to leave and in the end Um, well documented and well socialized features that are built to an average level of technical expertise Are far better for the project's life Than any technically flamboyant features that nobody understands So the last thing that I want to mention about focusing on the cults of personality is that this is a surefire way To maintain the static level of diversity that you have on the team now So You know If you look for people who have the right background You know if you are too focused on people who are those sort of like cultural fits Right all of that is really focusing on things that don't really matter Like it doesn't matter if people like the same movies you do It actually doesn't matter if they play the same video games Um, and it doesn't matter if they even know exactly the same technologies or love the exact same technologies as you What really matters is that we have people who can communicate Who can learn new things and who can bring just enough creativity to the project to fill in the gaps In order to make everything keep moving forward That's really the bottom line of what we should be focused on are all of those interpersonal communication skills And in the end the rest tends to come along So as long as we can find people who are reasonably Good and interested in continuing that learning and growth path then we can fit them into a team And the way that we're going to do it Is by setting some clear expectations and some clear ideas of exactly how we work We often see situations where people are expected to like, you know go bowling together or something to strengthen the team It leads to this corollary perception that The way to get people to work together is to somehow make them more similar, you know And i'm not saying that team building activities aren't worthwhile as team building activities But they're not actually going to solve all the problems of how your team works together They might in fact make people discover that oh, I kind of like hanging out with you a little more than I thought I would But in the end You know we We need to resist acting in ways that that encourage individuals to become sort of assimilated into the personality of the group Often we do this because we're worried about this mythical thing that we call the shared headspace, right? Like we really want people to get in sync, you know If you're ever like being dialed in, you know, you might be trying to get that shared headspace People should just you know, sort of know what needs to be done next and be able to kind of feel the same Prioritization across a project or feel the same design approach across the project The problem is like, I don't know if shared headspace exists I mean imagine like your closest friend that you can, you know, sort of interact with without having to say every single word Right, and then now pick, you know, any random 12 people off the street and tell me how you would get to that same level Of closeness with all 12 of those people Tell me if you would want to get to that same level of closeness With those 12 random people off the street. I mean, it's just not a realistic thing It's probably not possible and even if it is possible, it's probably not something that would necessarily make you feel really good Right, that's something that's reserved. That's private space Expecting team members to just sort of figure it out is the first place that lots of us go wrong And so it's really crucial to actually go to the trouble of defining structure so It's not about controlling your freedom or creating like a whole bunch of like auditing busy work But if you do not outline The ways that the members of your team work together and communicate together Then you cannot expect them to do those two things So you need to have some kind of defined structure I'm going to suggest that you define a workflow and that you stick to it. You actually use it You should create documentation that allows new members to the team to learn the workflows allows old members of the teams to review the workflows And in order to do that, you're going to have to adopt a workflow And i'm telling you that I think it's actually easier to adopt a workflow that's published by somebody else Because you can take the conversation away from sort of individuals ideas on the team And you can turn it into a critique in a more objective discussion about these ideas that are already out there in the world You already know that these are ideas that legitimately help companies build good products So why not take them and talk about them and think about what would need to change to make this fit our goals here As a team and and that discussion is more open to everybody on the team If it doesn't start with one member of the team, um, what you're looking at here is actually the the chart from the GitHub flow tutorial page, which is I think an awesome workflow to start with as a base of discussion. So, um You want to hone work workflows and processes through group consensus sort of every step of the way And you want to let the group understand that whatever we decide today We're going to be able to come back to this decision. Talk about it work it through and make another decision tomorrow The same thing goes for team working agreements, especially as we try to wrangle people who are local and people who are remote Or people who might work different hours of the day or just trying to give people more flexibility in their personal schedules So that they can take care of all the things that they need to take care of Team working agreements are very very useful. They can let us know how to communicate When where do we post information? What information gets posted where if I have something to say Where should I where should I go to say it if um, if I'm looking for something that was already said Where might I be able to go to find it? Those are actually really important things Um, you know, whether you're using email or slack or the project wiki or whatever it is When your team members want to communicate information or engage with them with others communication Then um, they should know how to do it And this is another agreement that needs to be discussed at sort of regular intervals and brought up and figured out There's all kinds of new communications technology coming out all the time It doesn't mean that you can't experiment with those new things Those new things don't become official mechanisms for doing business until you sort of have that conversation and everybody says Okay, yeah, we're going to try this thing out here, right? So um So that's that's really critical A lot of things that we overlook on technology teams And I think it's usually because what what the managers of the team want is for the answer to be that You're on the clock all the time working all the time Every day all day every day at night while you're sleeping you should be dreaming about the code that you're going to write tomorrow And then it'll go faster. Um, but that's not realistic. We can't be continually immersed in the sense of urgency We can't always be running at full speed. It's not realistic. It's not healthy It will kill you or make you have other related issues that are not pleasant. So I mean, um Issues related to not related to dying But related to working too much. Um Both are probably not pleasant, but the um There there's a lot of factors outside of a project that affect the amount of time that people can actually dedicate And it's really crucial Especially when we're not working on like sort of like employer employee projects But especially when we're working on like open source projects group projects personal projects things like that People don't have to put in the same amount of time to still be really committed to a project You know, not everybody has to be at every single meeting Not everybody has to put in the same number of hours a week or do exactly the same task in order to sort of Demonstrate how committed they are. In fact, it's totally appropriate to have people who have different roles Sort of act in different ways and put in different amounts of time. So that's that's not a problem um If you make these expectations clear then it allows people to operate More easily and it reduces the amount of of sort of misunderstanding or resentment that might occur Because people see others engaging in differing schedules or whatnot. So Every step of the way With with all of these things That we've that we've talked about Like we need to it all relies on normalizing communication So we should expect that discussion and negotiation is a normal part of how we're going to do business And we should make sure that every team member feels like they have a voice in the project And the team should prioritize actually hearing the voices of all of the team members Um, we have to always assume that there's a gap of understanding to not assume a gap of understanding Is is not a problem of the person that doesn't understand It's a problem of the person who's trying to convey the information because that's frankly a rookie mistake, right? um It's it's always we're always going to need to provide materials Um, we don't we should not be providing materials on demand. Oh, let me know if you want me to write this up Right, that's then it's never getting written up. Um, we should never ask people like Oh, do you have questions like who in here is going to stand up and say I don't totally understanding grok everything that you just said No, no, we should say, um, we should say here's the supportive materials Take a look at them. Let us know which parts aren't clear, right? Feel free to add anything to it if you experience anything differently when you're trying to do this thing that we left out Let us know where we made mistakes and how we can make this better That's the discussion that's open and that that can pull everybody in and participate at an equal level Right as soon as we set it up to a single year so far as the the one person in the group who's willing to say I don't understand like you've created a hostile environment at that point. Um Expect documents and tools. Um, so this is my reference to last year This is the actual code from the jango project if you go to github and look in their docs directory What do they have the markdown for all of their documents? Um, and that's the way that projects To be whether it's designers publishing a list of colors that are in hex rgb and cmyk for all the needs of the project Or whether it's um developers creating Migration scripts or automation scripts to update everybody's development environments It's absolutely critical that expecting documentation and supportive tooling becomes a norm for your team and organization No features go into a project without the accompanying documentation and the documentation is actually in triplicate I said I wasn't going to give you a bunch of paperwork, but I'm giving you a triplicate. I'm using that word Um something to explain it to the project team and the other developers Something to explain it to the business and the sales teams and something to explain it to the end users Think about all of those things as you're actually building the project, right? I'm not saying that you have to develop all your marketing materials But I mean you should be able to convey to your sales team like what does this thing do that? We just added to the project. Why was it added to the project? What role does it play in the vision of the project? Especially if you're working with a lot of remote teams It's really important that you provide documentation of everything sort of along the way So if you're having meetings that don't involve everybody you need to document the ideas that come out of those meetings You need to actually write down. This is the thought process around the future direction for this Feature or or where we're going with this Modification you need to document in code things that are relevant to the code And you need to make that documentation for everybody across the organization There should be a place that everybody knows that they can go to to see this documentation Find it and to participate in making it better right um And that participation is really key. We need to habitualize Helping okay, this is something that we often forget on technology teams, right? I mean we think we do it We like we might we pair program some instead and I love pair programming. That's awesome But like um, it's not necessarily helping You know that thing that you did in all by yourself You need to be thinking about the rest of the team while you're doing that So you should um, you know do things like create style guides you should uh, you should um Figure out like All the materials that are needed to accompany a change in order to do this Convance of of information through documentation and the supporting tools And everyone on the team should be available so that like when you run into problems with those tools It's not like just oh so and so is having a problem It's like if there's a problem with your tool it actually indicates that like you might have made a mistake There might be something that you overlooked in developing your tool or your component There might be deeper issues that are there and often the first sign of deeper issues with a change set is when people can't get it up And running properly, you know So it's weird that we turn away from that and leave people on their own to figure that out It's like I made a bug now you solve it, you know Um When possible do design reviews first If you can talk about what you're going to do before you actually do it You have a much bigger conversation that you can have about how you're going to do it Once there's stuff written down and everything the doors are actually closed I love as much as the next person to like just settle arguments by putting down the code and saying look that works But that's not a really supportive behavior on a team, you know And so we have to figure out a way to be able to sort of express those ideas In sort of in in preliminary states so that we can actually have those conversations about how things are going to be when they get built And then when they get built you don't want to make your code reviews just a formality, you know This isn't just a checkbox. It's not like it's just routing through garret so that you have some kind of big Garret log and you can make everybody's lives hell for trying to work with garret like it is about um It's about actually making sure that everything that's there is there, right? It's about reviewing the code It's about explaining the changes to the rest of the team It's about verifying that all of the documentation and supportive tooling is there and it's about approving What is the update plan to get this code actually out in front of our users? All of those things need to be a part of the code review And if we don't have an answer for those questions at the time of code review Then we're really probably not ready to push this all the way through the pipeline Now everything that we did that we talked about Up until now are things that could go horribly awry if we don't do better with communication Um, and we've all seen code reviews go bad. We've probably seen design reviews go bad We've all seen snarky comments written on wikis or in comment, you know and tools and things like that But we can improve our communication and um as representative of this I picked this awesome picture of a phone That has a calculator function That is improved communication right there So we're moving from um moving from defensive to supportive communication is is really what I want to focus on In terms of how you can improve your communication on your team. So, uh A lot of the negative experiences that happen during communication on a team are actually the result of team members taking a defensive posture And even when these are team members that seem like leaders or seem like exceptional performers These postures are are pretty much universally defensive and it's defensive for reasons that You know other talks could probably talk about but uh, but What we need to do is generate more psychological safety a bigger sense of psychological safety on the team And so what we need to do is move towards supportive Uh modes of communication and so I want to use um dat gibbs categories of communication here Um to sort of talk in some very pragmatic ways about how we can change Our communication styles to move from defensive communication to more supportive communication So what gibbs sets up are these uh six juxtapositions And on the left side you find the defensive Modes and on the right side you find The supportive modes, so we're going to move through them. Um, and just look at some examples Uh, so first of all evaluation versus description Um evaluative uh statements use the word you a lot like why would you do it this way or you didn't use the correct syntax So your code will fail, right? Um We can uh change that to descriptive statements because there could be value in those statements like I don't understand this Could you explain it to me? All right, that's a completely valid thing to say Um, I think if we maybe change this a little bit then we could avoid this failure here That's a more a way of stating it that you're you're taking the emphasis of the statement and putting it on yourself That like it's your interpretation that there's a problem here when you use that word you which i'm using to you over and over here In order to try to involve you in my presentation But if I was saying things that you didn't agree with and maybe I am you would be very upset possibly, um Difficult is one of those things that you don't want to think too much about when you're on stage. Um Control versus orientation is a dexter position that talks about um with control We're we're trying to force a decision on the listener, right? Whereas with orientation We're trying to engage the listeners and actually find a common ground or a common solution that works for everybody It's important to realize that orientation does not imply a compromise Which sort of has a negative connotation. You're getting a less good solution by compromising Orientation is the best solution for a team because if you have a group of people who need to be working together The worst possible thing is to have just a controlling statements continually coming down the pipe Dictating to that team exactly what they're going to do at that point in time. You just have you know People who are not engaged with the project just executing on tasks And um and that that really breaks things so um So really critical to try to move those controlling statements into orienting statements and often that actually is a process of opening up discussion Right where discussion would have been shut down. What you actually want to do is engage with the discussion. Um The next juxtaposition is strategy versus spontaneity. Um, this might be my favorite picture in the whole slide show, uh, the um We often operate in strategic ways on tech teams, right? Like we hate that library that we use for that one little thing that like only I always have to work with so When you ask me about fixing that bug in it It's like 10 times worse all the time because I just really want us to replace that library, right? Um, that's strategic strategic statements don't help us get to honest answers Strategic statements are statements that you make in the service of another goal or agenda The contrast to strategic statements are spontaneous statements spontaneous statements happen as a part of the moment They are honest and truthful and they're geared to actually You know engaging with the discussion that's that's happening at the moment Which leads us to the next juxtaposition which is neutrality versus empathy. Um, so neutrality is the state of being sort of disengaged and Pulling back from a discussion whereas empathy is the state of being engaged with the discussion and really showing interest and respect Neutrality creates is one of the big things that creates a real sense of disrespect among a team When i'm speaking if you're back if you're playing with your devices I mean on tech teams we all we have so many devices that we can just use to to sort of While away the day without paying any attention anything that's happening around us and it's like we're so good at that So really I feel like you know It's worthwhile to take extra precautions to make sure that you're broadcasting that empathy to the listeners in the discussion And to just all of the participants It builds respect. It builds that that conversational turn taking Finally or not finally second to finally we have superiority versus equality something that we also get on tech teams a lot where We have people who are just They want to express their superiority over others on the team their understanding of knowledge It might be exhibited through lots of jargon or or a lot of Higher level concepts that aren't well explained to everybody. What's better is to create a sense of equality This this goes back to assuming that there's always a knowledge gap To filling in information for people and to involving everybody in the conversation And then finally certainty versus provisionalism So coming in with an idea that this is the decision we're going to make and nothing's going to change my mind Is a bad thing Coming in saying this is the decision that I think would be best What do you all think about it and then having that discussion and conversation is how we actually open the door And open the lines of communication and respect and empathy and bring in that conversation to the rest of the team Um, so the final thing that I want to talk about in terms of pragmatic Tips is just to always remember that we're giving people second chances Everybody at some point is always is going to make a mistake not always But everybody at some point is going to make a mistake So always assume that you need to find a way to give people second chances because the world doesn't stop Because we made a mistake Everybody deserves that second chance to come back together and make amends And that's a real big part of how we build that psychological safety net and how we get um that sense of psychological safety across the team We need to allow do-overs. So Lightning conclusion, okay Who is not as important as how the way that the team works is more important than the individual skills and abilities of the team members If a team works poorly, everybody works at a lower level. If a team works well, everybody works at a higher level um Avoid quotes of personality They're good for pop stars, but not for um developers or or tech teams um Establish clear expectations make sure that people understand what they're supposed to be doing how they're supposed to be doing it What they've agreed to be doing on the team And how they've agreed to be doing it and uh and where they can go to sort of adjust those things over time Effective communication and supportive behavior is absolutely critical build it in as a habit make everybody Enjoy doing that work as well as the technology work Keep trying to improve we can get better and better and better the more we practice at these things Always prefer supportive over defensive interactions whenever you possibly can And let people have do-overs So that's it. Thank you. The slides are up at this URL We can read all the image credits. There's a lot of really good photos there So Thanks