 Hi, I am Juan Pablo Burítica. I'm from Bogota, Colombia, and I live in New York City. When I first accepted to give this talk, I was the VP of engineering at a music company called Splice. There, I led a distributed engineering team focused on building tools and services that helped musicians make more and better music. A month ago, I joined Stripe as the head of engineering for Latin America. Now, I'll get the chance to help build financial infrastructure for startups and developers in the region with the team I'll get to build. This next talk is about something I hold very close to my heart. I've been building communities and teams for quite some time. A long time ago, I had a boss who said our company was like a family. At the time, I didn't really get why that statement rubbed me the wrong way, but it did. Today, after having led a few teams, I understand why I felt that way though. Families aren't famous for being the most functional organizational structure. I could have begged my mom to put my brother on a pip because he kept leaving his dirty clothes on the floor of the bedroom we shared. But my mom would have never gone along with it. Believe me, I tried. So when we're dealing with family members, we lower our boundaries and tolerate things we wouldn't usually because we are family. I'm not the first person to notice that families are not a great example to mirror when you're building engineering teams. Netflix is famous for calling it out in their culture deck. I don't think my boss was ill-intended when they thought of our team as a family. But I've learned to recognize it as a flag in the culture of organizations or teams I encounter. It usually leads me to ask more questions. Another common analogy used to talk about teams is sports. Sports teams give us excellent examples of what collaboration can look like. High-performing sports teams achieve incredible feats when they work together. So when I was trying to think of ways to shape my principles around building teams, I thought about sports. There's some excellent metaphors about teamwork. But the biggest problem I had was I was terrible at team sports. It's not because I was a poor team player. I was just horrible at playing most team sports, not all of them. Just those you play with other people. That's why I loved skateboarding. The only one I'd be letting down would be myself if I couldn't kickflip. Imagine growing up in Colombia and not being good at playing football. I'm not joking when I say my friends would fight over who wouldn't have me on their team. But don't be sad, it was actually good. It meant I spent some of my research time at the library working around IT to try to get SimCity installed. So now I get to keynote next to someone who has been to space, just like the big nerd I am. But sports weren't something I could base my leadership principles on. And families aren't right either. What then? Outside of computers and science, music has had an enormous influence on my life. Now, if you ask my partner Melanie, she'd tell you that those screams I'd listened to shouldn't be qualified as music. And in some cases, she'd be right. But there's something beyond those screams. I played my first show when I was 13. Somewhere in the middle of Bogota, Colombia, I stood on a stage and I screamed at the top of my lungs, right next to four of my best friends. I looked at the mosh pit and I felt like I belonged. The hardcore punk community gave me something I didn't have before. It was a place where people from very different backgrounds and shared values came together towards a common goal. Some people worked towards animal liberation, others towards increasing social and political awareness, or even fundraising for benefit causes. DIY as a subculture comes from punk. This is where Tutorial Zines come from. I am who I am today. Thanks to the communities that I've had access to. I learned JavaScript thanks to all the jQuery contributors who took the time to write tutorials on their virtual zines or blog posts. Without being conscious about it, I started building teams around principles that were very natural to me. Community principles. I used everything I learned from putting shows together in Bogota to start a few community conferences in Colombia. At the same time, I was granted the opportunity to build high-performing software teams for startups. I'd like to share with you some of the community qualities I've tried to replicate in the organizations I lead. Maybe these can help you build healthy organizations of your own. The first of these community qualities is collectivity. Many of the challenges a team faces can only be solved collectively. We're not talking specifically about the business problem that the team is supposed to be addressing, but rather obstacles that the organization faces from within. For example, I prefer to lead and belong to teams that aren't homogenous. Lack of diversity is a collective challenge. As a leader, I am responsible for shaping the organization, but it isn't something I can do alone. This doesn't mean that I ask the only woman on my team to convince others to join us. On the contrary, it means that everyone in the group understands the problem and actively works to change it. So when we are solving collective challenges, we come together as a community to work towards them. The next quality I value is education. The communities I admire invest heavily in the education of all of their members. This is how they grow together. This is where, as I mentioned before, the DIY movement comes from. Learning how to tackle technical tasks and sharing expertise gives tools to everyone. Hardcore punks, or punks in general, wanted other people to learn how to print t-shirts, how to organize shows, how to record, how to share cassettes. DIY scenes were the beginning of tutorials. As a manager, I have to create the space and provide the resources for community education to happen in my company. Whereas open-source communities rely on volunteers, and so can music communities, my business shouldn't. It's a business in the end, and everything we do is for the sake of the business. So by combining the community's spirit of education with the business resources, we can provide support and foster community education, which leads to a better team. Communities also characterize themselves by their shared culture. They create an identity, and they shape it from their values. Communities at work can bridge cultural gaps by creating a culture of their own. Emojis, memes, and anecdotes are all artifacts that connect members to their community. For example, you can all agree that when you use the tomato emoji, it means that some behavior needs to be talked about. You need feedback. It wasn't cool. Someone didn't take it the way you thought, and then that little emoji takes meaning, and it can help everyone communicate around something that may have been uncomfortable before. If you show this to any of the engineers that I hired at Splice, they'll know exactly what it means. It's an artifact that we created from a phrase we coined in our first onsite. We met in New Orleans, and we agreed that we wanted a team that was supportive of everyone. The bass, not the bassist, is a supportive instrument. It carries the rhythm, and it has no ego. It helps everyone else shine. It's what we wanted our team to be. I've come to value communities that care about me, especially when I am someone who tends to be different. I am an immigrant. I don't play sports. I don't like the music everyone else does. The JavaScript community is a great example. The Borough GIS community is in New York City, providing it with a place where I can learn about a beautifully terrible language that I love. It has also become my backbone as an immigrant. I haven't just been accepted. I've been embraced. Many of my friends have come to learn and support the place where I come from. I love to provide this experience of support to everyone I work with. Belonging helps us work better. Another quality I value from communities and try to replicate at work is the concept of community leadership. The authority of being an engineering leader or a manager doesn't confirm me engineering knowledge. On the contrary, it removes me from the context of building software. The only way I can get a deep understanding of the challenges that my team members face is by building trusting relationships with them. This helps me learn and also make better decisions on our behalf. I've also learned I'm not the only leader. The authority over the technical domain belongs to everyone who writes code. Every line of code is a decision that they are making on behalf of our collective. In the end, creative workers are problem solvers and have come to appreciate punks who don't take my authority for granted. I like to think that even though I am frequently wrong, we are collectively right and my team members will help me see it. This way of leadership can be challenging for people who favor traditional management structures. So I don't recommend everyone goes out and hires a bunch of punks who consistently question their authority. But it's worked very well for me. I like being questioned and pushed on every decision I make for the business or for our team because I may have blind spots that my team helps me realize, identify and usually fix. An additional quality I appreciate of communities that value learning is how much effort they put towards making it safe to make mistakes. If you've ever sat through the intro of BrooklynJS, which is almost 30 minutes, you've witnessed firsthand how much the organizers emphasize on being a welcoming environment. When we feel safe, we can focus on solving problems other than those that affect our safety. Here's where I show you the Maslow's Hierarchy of Needs diagram. You laugh because it says Wi-Fi. And then I highlight that after basic physiological needs, safety is the most important thing in the pursuit of self-actualization and learning. When we're building software products, we embark in a process of continual learning. And this requires that we make many mistakes. Shout out if you've ever dropped a production database before. I know I have. But if our workplace mirrors a community that values safety, then it can foster a learning environment where asking questions or making mistakes in the pursuit of learning isn't just honest. Communities that value safety are also very quick to correct behaviors when new members threaten to safety. They build the language to give feedback when new individuals come from places where tending to be constantly right is the norm. You can think of these reactions as the immune system for our team. Since our community cares for its members, it also develops non-threatening ways of giving feedback that could otherwise lead to conflict. For example, I gave my team at Splice an emoji of my head that they could use whenever they felt like I was getting in on their business. I should be trusting them instead, and they could use the emoji reaction to tell me this. Finally, the way healthy communities foster and value less glamorous work is something I admire. Members take on tasks because it's the right thing to do for the group, and they have to get done. For example, door duty at a hardcore show. You'll inevitably miss a band or two, maybe even your favorite, but you know it is necessary. In return, the community may compensate you by giving you a free ticket. At work, managers aren't always in a position to take on all of the administrative tasks needed for the operation of a team, so community support can lend a hand. If you go down this path, I recommend that managers ensure that there's an equitable distribution of any administrative work. Randomizing may be a better idea than asking for volunteers. I've been fortunate to have the chance to build organizations filled with wonderful humans. I like to think that the community environment we've built at work is one of the main reasons why these talented engineers chose us in today's competitive environment. But you have to ask them. The one thing I can tell you, the supportive culture beats startup perks every time. I believe everyone deserves an opportunity of doing their best work in a supportive environment. And I hope that what I've shared today helps you shape the teams you build or join into supportive communities at work. If you'd like to learn more about my work or have any questions, you can follow me on Twitter. Thank you for having me and thank you OpenJS for the invitation.