 Welcome to a building team like an organizer. So we are working now in a world where a lot of really great high quality work in our day jobs relies on laborers of love from volunteer groups and that is a fantastic place to be in. That really opens a lot of doors we wouldn't otherwise have and lets us work past entire classes of problems by just like installing gems and like calling it good a lot of the time. But it also means that we're extremely, extremely dependent on our community to keep us moving forward. And I think it's really important to recognize that the ecosystem we're working in is bigger than us in particular or our immediate networks. So to illustrate this really quickly so we can get a sense of this, will you raise your hand if you have recently written something that relies on a gem maintained by random people on the internet that you don't know personally? All right. And who has recently upgraded something to Rails 5 and found themselves in a little bit of hot water because a gem they were using worked with four and not five and now nobody's maintaining that gem anymore? Common experience. And here's the other side of that coin. Who is working on something for funsies or to fill a specific need and they wish they could hand it off or get some new eyes on it so that like all the work they put into it doesn't fall off when they stop working on it? Nice. So I have some good news. This is a presentation where we're gonna talk about how building community around our work can help us dig out, like dig ourselves out from under these challenges. So to me, part of leadership is making sure that others can build on our work and making sure that the work that we do is sustainable and maintained beyond us. And a thing that I've heard a lot in a lot of the lovely talks I've been to at this conference is that burnout is real and our time and commitment levels go up and down and that is super important and real and we need to really make sure that we account for that in how we work. So this is a talk about how to use some tools from the community organizing toolbox and apply them to our work and our own ecosystem of people interested in solving problems with technology or Ruby or Rails. And here's how we're gonna talk about this. We're gonna talk about how building a team or we're gonna talk about how to build a community and team around our goals. And we're gonna talk about how and why to prioritize individual relationships with other people interested in those goals. And we're going to talk about how it's not that big a departure from the ways we already work. So to set the scene here, I wanna talk about what organizing looks like outside of an engineering context and then we're gonna dig into how it's applicable to our tech work and I don't mean to spoil the surprise but it turns out it's really, really applicable. So I have two stories, one about engineering and one that's not and I'm gonna start with the one that's not. Not too long ago in 2012, I had just gotten this new job as the outer towner who showed up to run a voter contact program for a campaign. My boss handed me a plane ticket to Hot and Sunny, Phoenix, Arizona and a list of 30,000 voters to contact and it was my job to make sure as many of them as possible got their doors knocked on or got a phone call telling them exactly how great this very nice lady named Jackie was and to vote for her in November. And here's my old district. 30,000 people is not a huge amount of people but it's way more than I can possibly talk to on my own even if I spent literally 12 hours a day like hitting pavement, knocking on doors and dialing the phone. And also I am extremely resource limited. Basically anything besides buying a couple burner cell phones and printing handout cards is just like too rich for my blood here. So there's no hiring an army of dialers or door knockers to just like handle it for me. However, there are a lot of people who have lived in Phoenix a long time and they know Jackie personally and they really like her or they really do not like her opponent that year. There's like this very motivated group of people in the 20th district. And then we do some stuff. In this case, the stuff wound up being calling basically every person who Jackie had ever been friends with ever to ask them to help me knock doors and make phone calls. And I got enough of them to say yes and come help me to build out a few groups of people who are down to like help talk to voters and the team we built over the span of a few months wound up running an amazingly successful outreach program and we talked to a pretty big chunk of that 30,000 people. And what's more, we had a lot of first timers who walked away from their experience on this campaign really aware that they could make a meaningful impact on stuff that mattered to them through voter contact and they wound up working on the next selection too after I had left. And this scenario, this is not about engineering not campaigns but the moving pieces as we're gonna see are pretty much the same. In 2016, I have moved out of Phoenix and back to Washington DC and my side volunteer gig is serving on the board of directors of the DC Abortion Fund. For context here, the DC Abortion Fund or DCAF is a community and non-profit all volunteer that spends basically its entire budget on covering the cost of people's abortion care. We're talking in the neighborhood of 95% of the budget going straight to abortion care here. And we need a new case management system because our current system is three Excel spreadsheets that multiple people are hammering on at the same time. And literally an entire organization hates these spreadsheets. The board of directors hates them, the case management team hates them, everybody hates these Excel docs with their entire minds, bodies and souls. However, much like the campaign in 2012, we have a severe level of resource limitation. We have $0 to throw at developing a new case management system. However, there are people out there who might be interested in contributing and they're super down with what we're trying to do at DCAF. And again, some stuff happens, we do some stuff. I go to a lot of code for DC meetings with a co-captain. We meet a lot of people who are interested in the work that we're doing. And I get to know them pretty well and we spend like a year's worth of nights and weekends banging on these problems until we get the DC Abortion Fund out of spreadsheets forever. And everybody's a real bunch of happy campers and our case managers are saying stuff to me like I'm having way better conversations with their patients now or wow, I never realized just how depressed Excel was making me all the time. And also like, and this is like a big deal. Now we have this team of engineers in DC and elsewhere who have spent a decent amount of time thinking about how to apply a tech to the DC Abortion Fund's problems. And they've spent a lot of time really grappling with the problems of abortion funding and that's important because there are not that many engineers who know a lot about the mechanics of abortion funding. So if I were gonna abstract these stories to highlight the common threads here, here's roughly how I would do it. I had a lot of work to do and couldn't possibly do it on my own and there was not gonna be money to throw at these problems. Or maybe I can solve it on my own or take a stab at that but it would take a really long time and even if I did try and solve it on my own there's like a non-zero chance that I'm gonna get bummed out and burned out and just like drive myself through exhaustion. This is tough work and doing it in isolation makes it even tougher. So these are problems we can address with additional personal power and some elbow grease but I also wanna highlight some undercurrents of this. I'm not the only person who cares about abortion funding but right like at the beginning I'm kind of at the center of a lot of this. So if I were to say drop out of life and join a Black Sabbath cover band or something like we got a problem and honestly like I'm always like always like a week or two like a bad week or two away from dropping out and joining a Black Sabbath cover band. So like that's a real concern for me personally. That guy gets it. And eventually I might wanna move on to do something else or get some new energy on there. So I bring in some other people interested in the end goal. We do some stuff and then we got ourselves an accomplishment. So let's really break out the do some stuff here. It turns out to be the same whether it be engineering assistant for DCAF or building a team of volunteers to knock doors in Arizona and that is building a small community around these problems united by a shared goal and getting everyone to press toward that goal together. Excuse me. So the needs here are slightly different but the path and the lasting effects really wind up being pretty much the same. Like the first two bullets are different but everything down from that is identical. Both these problems are solvable with person power and the path to a solution involves building a community around our shared problems and most importantly at the end of it there's a bunch of people who have an example and living memory of how they did this stuff and were successful at it. And also this whole community is powerful and makes us work better toward our shared goals is kind of one of the major premises of open source software development as I understand it. That like having these groups of people working on these challenges together like really does increase our ability as a community to hammer on these challenges. So just to summarize the problem as we understand it here and like really make it explicit. There are some problems where bringing in other people really does make the work go down smoother and that like building a community with shared goals around these problems and tackling them together is a really powerful and sustainable way to approach them and has some pretty serious perks like having other people who share your goals able to pitch in. So we recognize that building these communities has tangible benefits for us as leaders and for people in these communities. So let's talk some about how we shape these communities as leaders or as people working in these, or let's talk about how we shape these communities as leaders. When I ran the field program in 2012 or worked on that engineering team in 2016, the technique I used to build out these communities was called organizing and still is called organizing I should say. The idea here at play is that as a leader you work to build a community of people with similar goals through building individual level relationships and having a structured way for that community to work toward a goal. And this model really does fit really neatly into what we're doing in programming land. There's nothing really different about organizing just because we're working on tech projects together instead of like knocking doors or something like that. So let's break down somehow we build communities around our work. I found organizing to not be that different from software in that there's an art and a craft to it but also you can get a lot of the way there just by like knowing your tools and following the playbook. So let's talk about the playbook more or less. First things first, you need to know what you're trying to accomplish and be really honest and clear about it. For me, like in the examples at the beginning these goals were winning an election and completing the DC abortion fund system overhaul but that's just what I was working on at the time. It can be doing testing a certain way or some Rails plugin or using Rails to build something or literally anything else in the entire world where you would benefit from another person's talents or interests working toward it with you. This is, I would like for us to have something we don't have. Second, now that we know what the goal is we're gonna look around us and seek out other people who share that goal. And the point of knowing your goal in the first place gives you a foundation to build an individual level relationship so that you can say to someone I think we should make it so that DCAF doesn't have to have 10 people hammering on Excel sheets at the same time. Do you think you can help me do something about it? And in fact, individual relationships are like so important to this model that I made a copy of this slide and grayed out all the other words besides individual relationships to emphasize the words like that. And I've been at a few talks or panels this afternoon that talk about burnout and how it's a problem for contributors and let's step back for a second and take a second to think about why people contribute to open source work and why. There's an adage I've heard of before. People show up the first time because they're interested in the work but they come back because they liked you and they think their time is being well spent. And that's pretty much true in my experience. Time you spend on building these individual relationships is what keeps people engaged. It's what makes them feel like their contributions are valuable and it's what makes them stick around even when there's good Netflix to watch. And since there's like always good Netflix to watch like this is really, really important and making this one of your priorities as a leader is really deeply important. So with this community built on individual relationships you all start collaborating toward shared goals making strides together and then you build something that's pretty powerful and you wind up being able to accomplish something more together faster than you would have otherwise. And relationships are so important to this playbook that it's worth taking another step back and popping them out here and talking about a methodology for how to approach it as a process in its own right. You need to start by digging out the answer to this question why you yourself care about this out of yourself. You need to know and then be able to explain why you as a leader care about and why and exactly how it relates to the goal you're working on. For example, I care about the DC abortion funds work because once upon a time I had a really boring day job and cared about feminism and wanted to volunteer somewhere and the only option I could find that wasn't doing business hours was working with my friendly neighborhood Planned Parenthood to help them deal with their protester problem. So for many years I did this thing called clinic escorting which is basically greeting people outside coming in for appointments saying, hey, sorry about the protesters, welcome to the clinic, come on in and just being a friendly face while some protesters are acting out nearby. So I show up for my first day of this and within literally five minutes of hitting the sidewalk, this 70 year old dude just is chasing after this 14 year old and her mom and he's saying really, really nasty stuff and he makes them both cry like five feet away from me like meat of that can of water like is how close they are and it is legit horrifying and awful. It is really, really nasty and it's one of those things that burns out like really sits in my memory. Like I can remember how it smelled when that happened. This is something that had like a really, really deep impact from on me and the lesson I took from this is that access to reproductive healthcare whether that be a Planned Parenthood or another clinic or whatever being able to access that free from harassment and safely is something that's very, very important to me. It's like a major value of mine and my work on the campaign and at the DC abortion fund has wound up being an extension of that and that's what I care about and many, many people who have worked with me at DCAP or elsewhere have heard some form of this story like, oh, that's Colin, like an old man was a jerk outside a clinic once and he got so mad about it he moved to Arizona to try and beat some anti-abortion candidates. So once you know why this work is important to you reach out to interested people personally and say hi and this conversation isn't really, part of it is being nice but part of it is trying to introduce yourself and learn about the other person and here's what you're trying to learn about them. Give them some context for what draws you to this work and then try and figure out why they are interested and this may or may not be as fleshed out as your own personal story and that's perfectly okay but there's a reason that person said yes to you when you asked them for help or when they showed up in your issue mentions and you need to figure out why that is because you're gonna take what they care about and what you care about and find a common thread between your experiences or interests and link that together and you're gonna figure out where those align and you're gonna think about ways you can structure what you're trying to do around this common thread and now you've got this foundation to work together toward these shared goals because each of you know what the other person is about and that's really powerful and then you're gonna ask them to take a concrete step forward. A thing that experience has really drilled into me is that the answer is almost always no unless you ask somebody without asking for help I am dialing the phone 30,000 times in Arizona but with asking for help we have a chance to reach a lot of those people that we otherwise wouldn't even have a prayer. So if anybody saw Joe Dean's talk from on site his talk last year about doing charity work he had a really, really good example of this and I hope he'll forgive me for butchering his story. Joe was teaching a week under learned to code class for some middle schoolers and he's a professional working at a real shop so he's pretty fired up about computers, right? As many of us are. So he shows up with a full on curriculum about fundamentals of programming and conditionals and loops and functions and like all these component elements and these middle schoolers are going through the motions with them and really it's not quite taking and after a few classes where nothing is quite landing Joe asked these kids the magic questions which is like you all don't seem that interested in this what do you all care about and because they're like middle schoolers they say one direction which good choice kids like right on there's some jammers there. So Joe comes back the next week and is like we're gonna write some stories about one direction using computers and he proceeds to show them input and if statements and pretty soon he's got them writing straight on one direction fan fiction using pretty complicated conditionals over the space of an afternoon. So it turns out the shared goal here is these kids learning coding fundamentals but the common thread winds up being fan fiction about one direction and the point being here common threads take some teasing out but they are there and you can get there. So if I were gonna boil this all down to a principle it would be that community is a first class concern and we keep that healthy through having personal relationships with individuals and maintaining those but what does this mean for our day to day? I think it's particularly applicable to our work as programmers or engineers or designers or teammates or whatever because I think a lot of this is baked into the premise of agile already and that means that incorporating this into our work means we don't have to whole hog change anything about how we work. The fundamentals of organizing and teamwork and relationships don't change just because we're using GitHub. This is really a matter of adjustment of being more cognizant of the community and relationships parts of what we're doing already. If you go to agilemanifesto.org this is like right above the fold the first big bold sentence you see individuals and interactions over processes and tools and it has a super clear analog in organizing. In this down a little further about building projects around motivated individuals and trusting them also has a really really clear analog in organizing and another analog from the manifesto about the importance of self organizing teams organizing is at its core like a putting together and running a self organizing team. To really drive it home the organizing model we're using here is as we can see not that different from how we already work. It lines up really close to the agile model and the fundamentals are pretty much identical when it comes to the person stuff. None of this changes just because we're tech people instead of knocking doors or something like that. So we have a good way to build these teams and communities in organizing which we do by building individual relationships and it squares really neatly with what we're doing already. And so now we have we know we get a lot of we get a lot out of building community and we have a tool to do it now in organizing. And now we need to translate this into some concrete steps. All of us are gonna leave here and go back to go back and check email or head back to work in a not too distant future and get back to doing stuff in our normal lives what concrete steps can we actually take here? You probably saw this coming but if it's all humanly possible have a one-on-one sit down with every contributor in your orbit. And if you can't like see if you can make some like a see if you can delegate that out to someone else so that they're the welcome wagon. Like the point is have a welcome wagon what made a lot of the community building it decaf possible was having like a space to shoot the breeze and like get to know each other. We had code for code for DC contributors we had regular meetings and we kept track of our general goings on in Slack so there was a space for me as like the leader to talk to people to get to know them and to ask them what they were about. Having the space is really, really important and useful and it's also worth highlighting here that having the importance of these conversations doesn't diminish just because people aren't in the same room anymore. We have all these fancy tech tools like Slack and text messages and whatever to so that we can have these conversations with people who aren't necessarily in the same room as us and building relationships work the same way. Like we all, well probably a lot of us had internet friends growing up and there's some real bonds there and the same kind of thing applies here. And just because people aren't brand new to the project doesn't mean you should skip this conversation. These conversations are important and everyone should get them if it's possible. It should be a standard issue thing. And it's worth highlighting here that this is a tough thing to do. It's like it's tough to make time for this. When the Code4GC project started to settle into a group I tried to go back and have conversations with basically everyone I could who was still active in the project about how they wound up coming into our orbit and nowadays submitting a PR or posting an issue comment means that I introduce myself to you. I say thanks for the interest and I ask how they found us and why and start a conversation with that and I really can't understate how important this is to keeping new blood flowing into the community and keeping the community around the work we're doing energetic and fun. As a leader a super important thing you can do is reduce barriers to entry. Did anybody here go to Eileen's talk about system testing yesterday? It was great. It was a really, really great talk and she talked about something toward the end that really rang true for me which is that contributing to open source projects is terrifying. Really, really, really scary. A lot of the time it feels like you're putting your brains in like work against literally everybody else in the entire world and that's something I personally struggle with and it's something I hear from contributors at Decaf a lot. I hear I don't wanna screw something up. I know this is important. I don't wanna accidentally break something and I like that Rails has sharp knives as a design principle a lot but I think what this means is that as leaders we need to take a little additional care in being welcoming and make sure that we don't just hand people the sharp knife and assume they're not gonna cut their fingers off. To make that less scary, to make getting involved less scary, I'm a really huge fan of having ways to direct people toward issues that don't require intimate knowledge of problems necessarily, marking them beginner friendly and then directing people toward them. I found that to be a really great way to push people through or read me in a setup and then have a nice layup forum at the end. Last year, Nadia Odenayo gave a talk about the concept of code hospitality and she made this really excellent point that just as it's a good practice to show house guests around your house before you let them just abandon them to abandon them to your home, you should be prepared to help new people get adjusted to what you're doing and I think part of that is having something accessible for them to tackle. And another thing I've gotten a lot of leverage out of is structuring as much stuff as possible into bite sizes so that someone can that someone can knock something out in a limited span of time. Let's take into a pair of examples from decaf that I think do a better job of illustrating this at practice. First, let's look at the all-time worst issue I've ever written for decaf. This is bad for a lot of reasons. Admittedly, it's like a placeholder so it's not a perfect example but I literally could not have written this with less information had I deliberately tried. Let's talk blow by blow about how I blew it here. It's not clear why this is important in the slightest it's not clear what the steps are. It's not clear where to dig in. It's not clear where we need it to end up and in fact, if somebody's life literally depended on it, they wouldn't be able to figure that out because all I wrote is I talked to a user and there's no way to back that out. This on the other hand is one of the more useful issues I've ever written for the project. It's very clear what to do. It's super clear where to do it in like a particular file. It's clear why it's important to make our case managers happy and let them know that like the engineering team is on your side. It gives you a hint to like it gives you as a new contributor a hint to about where to like where to look to contribute and it gives me a chance to say thank you really early because this is a really accessible issue and it also makes it clear that not all the work we're doing is ascended masterly engineering stuff and that there's a way you can have an impact right now just right out of the gate. And I think that's important and meaningful. So step bringing it back to the first slide the alternate title here was avoid burning yourself out through teamwork and here's how this really comes into play. Putting someone in charge of your project as soon as they walk through the door is a surefire way to scare the hell out of them or make them decide that this isn't really for them. So the next step of escalating of not burning yourself out through teamwork or having accessible things to do is to find ways to increasingly challenge your volunteers or your community and make it tougher as time goes on to build on what they've already done. If anybody went to Scott's talk in this room earlier today he said something that really I think got to the crux of this which is about the being a leader is about making other people important and here's a path to that. You ask them to do progressively harder stuff piece by piece. In organizing there's this concept of the letter of engagement. Here's how it shows up in a new media campaigns training book. I know it's hard to read, I'm sorry. The gist of it is that it goes from down to up it goes easy actions, harder actions, even harder actions and then very hard actions at the top. Remember earlier we talked about how the problem of flying solo is that if you drop out of life if I join that black Sabbath cover band then stuff starts to fade away and moving this people in the community up this ladder is how we dig ourselves out of that hole. It's contingent on you as a leader to get people from the easy actions up to the very hard actions and this is something really, really meaningful and powerful. At the beginning you are up top doing the very hard actions and your goal is to bring everybody up with you so you're all doing progressively harder stuff. Another perspective on this if we flip this around this is the ladder of engagement upside down. You all are a tougher crowd than the dads I tried this on. Upside down, ladder, funnel. Yeah, that's right. So this is from Mike McQuade's talk on building communities around open source projects. Concept he calls the contributor funnel and it's basically the same thing as the ladder of engagement except it's got tech terms instead of the word harder and it's upside down. And a good example of this in practice is my own involvement with the DC Abortion Fund. I'm not a founder nor do I know any of the founders but at some point a friend of mine was working on a DCAF fundraiser and pulled me aside to kick in some money. A pretty straightforward thing which falls under easy actions. I can open my wallet and give 10 bucks which in turn led her to ask me to fundraise some more than to analyze some data which eventually in turn led her to ask me to join the board of directors with her. And I would have done exactly none of this without being asked and without being pulled up. And once I was in, my friend kept pulling me up to the point where I was on the board and then I ran that system overhaul and that brings us to today. And also the GitHub guide on, the GitHub open source guide on this is really, really good and talks about a lot of this in some more like concrete depth. And I'd lift up the building welcoming communities section in particular as being like super tight. So to bring this back around, the takeaways I want you to leave here with are threefold. First, that the foundation of what we're doing as people working on open source projects is interpersonal relationships as much as it is making software and that building or that making individual relationships a priority and a first class concern really pays off huge and increased capacity and not driving ourselves to burn out. Organizing by building individual relationships with people is a toolkit that like aims to make dealing with that problem easier but that's a solvable problem. Second, that like knowing your community, what they care about and what your shared goals are is a really foundational block of this. And third, that following these practices is not that huge a departure from how we work already. Raising the interpersonal stuff to the top is a matter of adjustment rather than changing how we work completely. And what this winds up meaning is that as new people become interested in problems we're interested in, they build on our work the same way that DKF has built on Rails work the same way that Rails built on something else which in turn built on something else and that means that we wind up with a strong community and a strong sustainable ecosystem. So I'd be remiss to talk about organizing in community without saying thanks to the actual community here. So I wanna call it a couple people for thank yous in particular. Allison who's back there has been a super amazing and thoughtful track curator and has been a real delight to work with and offered some really, really great feedback that really did turn this into a better talk. So thank you very much Allison. And also we have a couple DC abortion fund contributors in this room. So I see Sarah right there, Alisha might be in here. So if we could like give them a quick round of applause for their work for the people that the DC abortion fund serves like it's really meaningful, really important and has really done a lot to push that forward. I also wanna shout out Justin from Break Men Pro who's like I've been super helpful to DKF and some other people who gave really thoughtful talks last year which I used as a jump off point for much of this. I've watched a bunch of talks in this track so far and they've all been really, really amazing and thoughtful and so up next in this room is a panel on becoming an engineering leader which I'm super stoked to work, super stoked to watch. So let's dig around for more of this I guess. Over there on the right, that's my girlfriend Olga's cat or my girlfriend's cat Olga, excuse me. Yeah, good thing that's forever. Thank you all so much for joining me here. This has been a real blast. The question is what if you have trouble talking to people? So I feel that problem really acutely. I'm a shy person and really what I think the way I've dealt with this, I don't drink either so that doesn't help. The way I've dealt with this is centering the work I'm trying to do in my mind and making, it is an active sacrifice and it is an active challenge and framing it as that is one way I approach it. The other way is I very actively keep my limits in mind. I have an upper limit for talking to people and having these meaningful conversations, they tire me out a lot of ways and I know more or less what my limit is and when I get that limit, it's time to step back a little bit and recenter and take it slow. Part of the things being sustainable, especially around open source work is taking at it the correct pace at the correct time if that makes sense. Does that answer your question? Awesome. Well, thank you all. Thank you all so much for coming.