Engineering Your Own "Luck": The 3 Key Rules of Building Globally Distributed Teams with Eventbrite

Hi everybody. I've never had walk-up music before. That's pretty intimidating, I think. I don't know who had a chance to be able to see Brian Halligan's talk with HubSpot a little while ago. When I saw his video, that was really intimidating. I saw like this incredible story of HubSpot for about a minute, lasers, all kinds of stuff. It was awesome. I'm going to try to do this just with slides and a little bit of energy on stage. That's my walk-up music. So, I am with Eventbrite, as I said. We've been a company since 2006. It was started by Kevin and Julia Hartz and Renaud Visage, and I've been with the company since 2011. As far as I know, the mission of the company has been the same ever since the start. It certainly has been since I've been there, which is bringing people together through live experiences, and we got a chance to celebrate our initial public offering on the New York Stock Exchange back in September. September, which is a really exciting time for me. And I'm hopefully going to come up here and tell you some awesome things about distributed teams. We've made some big changes. Our mission has stayed the same, but the changes we've gone through have been moving from being a very San Francisco-based company to a company that's got distributed teams all over the world. And I know you're all here for a variety of reasons. A lot of empty chairs here too, but you're all here for a variety of reasons. Some of you are here because you know distributed teams are terrific and you want to hear more about it. You want to get more information about how how Eventbrite's made that switch to distributed teams. Some of you are here because maybe you don't agree that's the right thing to do and you, you, you want to hear like a different opinion. Maybe some of you are here because you're just lucky to be here. You happen to like pick a, pick a room to come to and this was it. If that was the case, you really were lucky because it's going to be pretty good for you. But I'm pretty certain there's at least some people in the room who don't think it's the right idea. You, you've been told that you have to start your company in San Francisco, or in the Bay Area. You've been told that's where all the talent is, and you believe it. And what I'm here to tell you today is that it's not only possible to build world-class, great development teams in places outside of San Francisco, but in actuality, it's better. Little more about me. Uh, as I said, I've been with Eventbrite since 2011. I started right at the end of 2011. and, um, I started in the role of VP of engineering. That's what I did for the first 6 years of my, my time in the company. Uh, and I, as I said, we got a chance to go through a lot of changes starting from a San Francisco company, uh, and making those shifts out of being just in San Francisco. And there really positive outcomes from having distributed teams for us. Um, and, and I, the way I think about positive outcomes, there are a few different things that make up, uh, a positive outcome. It comes from, it comes from planning. It comes from great execution. It comes from making really good decisions, um, and it comes from, uh, taking some risks as well. And then there's a 5th element that always is there if an outcome turns out right, and that's luck. There's always some luck involved. Now, I have some background with luck because in between some long stints with other companies, uh, you know, 7 years at Eventbrite and 15 years at Ticketmaster before, I spent 5 years of my life playing poker for a living. I learned an awful lot about luck and positive outcomes as well because I was lucky enough to win 2 World Series of Poker bracelets during that time. So what we're gonna talk about for the next 30 minutes is I'm gonna explain to you why I know that having distributed teams is better. I'm gonna give you a little bit of a walkthrough that journey of how we got from being a San Francisco-based company to one that was much more distributed. And hopefully, I'm gonna create a situation for you where you don't need as much luck to be successful in scaling your own teams, as we needed when we did it at Eventbrite. So this was what Eventbrite was in 2011 when I started. Everything was based in San Francisco. The company was 145 people, 40 of which were engineers. That was the area of the company that I was leading. Um, and it wasn't just that we were all in San Francisco. It was actually a rule in the company. We, we had this belief that you had to have your teams in San Francisco And in fact, when I took the job with Eventbrite, I moved from Arizona to take the role. And I came into a company that was growing really quickly, which was fantastic. But in my role, I was told I needed to be able to grow our engineering team fast enough to keep up with the needs of a very successful, very growing business. And like, that's not a real hardship. That's a great world-class problem to have, that you need to grow your teams fast enough to keep up with the business. But there were a few things that were true about Eventbrite and the environment in trying to hire in San Francisco in that moment. And maybe you'll hear some things that sound familiar to you now. First off, there were companies who were later stage companies who had a lot deeper pockets, and it was very difficult for us to compete with a company like Google or a company like Facebook. When we were up against those companies, trying to compete from a talent standpoint, if we had to try and compete from a money standpoint, it just wasn't gonna work. We had to find other ways to be competitive. Second thing that was true for us is that, I don't know if you've heard much about Eventbrite and company culture, but it's something that we're very, very proud of. We've got, you know, people in the company who have worked very hard to build a very strong company culture. And because of that, the turnover ratio in our company was actually far less than a lot of other tech companies in and around San Francisco. I'm proud to say that when I started at Eventbrite with 40 engineers in the company at that point, 21 of those engineers are still there. I've been there 7 years and 2 months and we still have 21 out of 40, which is terrific for San Francisco, but we still had a turnover rate of 15% a year. So every year, 15% of our engineers who were in the company left the company to go do something else. Startups, go to Facebook or Google, whatever it was they left for. So that meant that starting with 40 engineers in, in my team, I had to be able to hire 6 engineers every year just to stay flat. And remember, my charter was I needed to be able to grow the team faster than the business. Business was growing by a really good clip. We estimated at least 30%, if not 50% of what we had to do every year in growing the engineering team just to keep up. So if I wanted to grow by 30%, it was 6 to be flat and then another 12 to be able to grow by 30% a year. So 18 hires a year I had to make in San Francisco. And then finally, one of the really big problems we had is that the very specialized roles were incredibly competitive. For, for roles like mobile engineers or data engineers, um, we tried to hire a database administrator for a long time and struggled with that. For all of those roles, if we wanted to hire those roles at all, we had to overpay, otherwise we just got none of them. So this was the reality of the situation that I walked into in San Francisco in 2011, and we were still able to grow. We still, you know, we kept up pretty well, but we definitely had some challenges with that. So spin forward to what it looks like for Eventbrite now in 2019. This is a map that shows all the different locations that Eventbrite has around the globe. So now we're 1,100 employees in 14 offices in 11 different countries. And as well as being distributed for, from a business standpoint, having people in each of the offices where we want to have a, you know, a big presence business-wise, we also have engineers, product managers, and designers in 6 of those 11 offices. So we made a really big shift and move from being a very San Francisco-centric company to a global country— uh, company, and from an engineering standpoint, it's true as well. So there were a couple of big things that happened, decisions that we made along the way that got us from being completely San Francisco-based to being more of a global company, and there's an element of luck in, in the, the two big key decisions we made early on, so I want to talk you through those two, um, those two decisions that we made. First off, in 2013, we made our first acquisition. We'd never acquired a company before, Um, but our CEO at the time, Kevin Hartz, was relatively certain that even though we were growing well in South America, uh, organically, we weren't growing fast enough. And there were a couple of companies who were doing, uh, had ticketing companies that were very similar to Eventbrite in South America. Um, and at first look, you know, Kevin took a trip down to South America and he met with all 3 companies, and at first glance it looked pretty obvious that the company that was based in Brazil was the one we wanted to go with. The, the company was, their sales were quite a bit bigger than the other two companies. The other two were based in Argentina and in Chile. Um, and the outlook was better because Brazil's a much bigger population base. So this was the direction that he really wanted to go. And the lucky decision was Kevin asked me to meet with the engineering leaders in all three companies. So I got a chance to have a sit down with the person leading in each one of these, 3 different companies. And as it turned out, the person who was co-founder and the engineering leader in Mendoza, Argentina was a completely world-class engineer. And if you've ever heard of Mendoza before, you probably know it as a wine region, you know, 'cause they make great Malbecs and steaks and it's an awesome place to visit. That's another secondary reason to go there. But the engineer that I met was, He was one of the top 10 contributors to the Rails project lifetime. And he actually hadn't done any contributing for more than a year, but I look up the list of people who contributed to Rails and he was like number 9 lifetime. If you don't know what Rails is, it's the development framework for Ruby. So if you ever hear Ruby on Rails and people building their websites with it, this guy was one of the top contributors there. And they were a small company. They were 15 people and 5 engineers, but I felt like this guy was probably in our top 3 engineers total. We were about 70 engineers at that point, and I really felt like he could be one of our best. And so basically I went to Kevin and I begged, is there any way we could hire this guy who I know is gonna be one of our best engineers? And as it turns out, Kevin had formed a pretty good relationship with the CEO of that company, and he really had a very strong belief in engineering and that being the future of how companies are successful. So he, He agreed with me, he gave in, and we decided to purchase the company in Mendoza. So that was lucky decision number one, and it turned out fantastic, and I'll tell you a lot about Mendoza in the next few minutes. The second decision was the next year, 2014. So we had been still growing in San Francisco, one extra office in Mendoza, and in scaling our company, we were finding that customer service was a really big expense for us. and trying to have a customer service team that was based in San Francisco was very, very difficult. And so we decided we would look at potentially opening another office just for customer service. So we spent some time looking around different cities around the US. We picked 4 or 5 cities to look at, uh, looking for a place to expand our customer service team. And in looking through that list of cities, it turned out Nashville was the one that was closest to us. It felt the most like us. The people in the city were fun. City's a little bit weird, and it was close to our mission because we were bringing people together through live experiences, and they love live music experiences. So we had, we had a connection that felt really good. So we opened a customer service office in Nashville. Now, the lucky thing that happened was about 6 months in, we had a company party for the office in Nashville, and they rented out a room at this restaurant, and I guess they were having fun and drinking and having a good time. It got a little loud, and there was a party going on next door, a different room in the same restaurant, and the people over there decided they wanted to come over and see what the commotion was. It turned out the next room was having a meeting of, uh, the developer community kind of ecosystem in Nashville. So they were having this, this, uh, event that was like a speed dating trying to connect engineers to potential places to work. And so they came over and they met us. It turns out they organized their event on Eventbrite, and a little connection formed there, and that's the first place that we learned that actually there were companies developers in Nashville that might be good developers. We had absolutely no, like no thought at all about trying to create a development center in Nashville. But because of that first meeting, we decided to start doing some research. We looked in and found that Nashville had good universities. They were teaching great computer science programs. And probably most importantly, there weren't any companies who felt like us. It felt like a lot of the places people were going to work were older, kind of more mature, maybe healthcare companies of that sort. So it felt like maybe we might have a hiring advantage in this place. So we decided to take a chance and we hired 3 engineers in Nashville in 2014. So these 2 decisions, these 2 kind of lucky breaks for us, getting started in Mendoza and getting started in Nashville, those were the, the kind of the starting point for Eventbrite moving to distributed teams. This is a picture of our Mendoza team today. This is what 5 years of successful growth in a distributed team can look like. So as I said before, 15 people in the company when we started, 5 engineers. Now there's 140 in this office, 110 engineers, product managers, and designers. And they're awesome. I've been in the company for a long time, and because I've had an opportunity to, to do a lot of traveling and be around a lot of people, I get asked the question a lot, "What's the thing you're most proud of in Eventbrite?" And I always come back to this team. But the truth is, I was involved in the initial decision, and I've been involved in a few things through the course of time, but the reality is, other than just being there for travel and being there for support and everything else, the heavy lifting has all been done by this team. And the advantages of what we have are, they're numerous. First off, the salaries in Mendoza are roughly 30% what they are in San Francisco. So that's pretty awesome. That's not even the best thing. The best thing is retention in these offices has been just amazing. If I look at Mendoza and Nashville together over the course of the time we've had these two offices, the total turnover we've had in these two offices combined has been less than 5%. Less than 5% a year across these two. And in fact, in this office where we've experienced this great growth of going from 5 people to 110 on the engineering and design side, we didn't lose our first person until 2017, a full 4 years after we started building the team. That's the kind of retention advantage we've had in Mendoza. And what I wanna say about Mendoza is, It sounds like it's magical. I'm telling you a story about a place where there's Malbec and there's steak and there's these great engineers. There's nothing magic about Mendoza. It's a thing you can do really anywhere. The thing that we found in starting in these first two places is that truthfully, the thing we were trying to do ahead of time before we started to extend to other cities is really the hardest thing to do. The hardest thing to do is to try and build and scale an engineering team in the most expensive place and the most competitive place on the planet. Basically, if we'd started anywhere else, we would've made better progress. We really kind of lucked into that decision as well. So a few different things I can tell you to try and distill down the, the things that we've learned over the course of time. I'll boil 'em down into just 3 rules. First rule is it's really important that you realize that your development centers are going to be different. If you think you understand the playbook for how to run your team in San Francisco or in San Jose, I can promise you that wherever you decide to go somewhere else, it's going to feel different. And I can't tell you how it's gonna feel different. I can't tell you what the playbook is gonna be for different places. What I can tell you is it's really important to observe what's going on in these locations and be willing to adjust to whatever you see. And if you can do that, you can be successful. A couple quick examples of things that we, we found over the course of time in starting these, these different offices. Starting point in Mendoza. One of the first things we went into believing, it's kind of a bias that we had, was that the native language in Mendoza is Spanish and the native language of all our engineers in San Francisco was English. And so if we're gonna hire engineers in Mendoza, we must hire engineers who are fluent in English, just full stop, we have to do that. And over the course of the first 2 years doing hiring in Mendoza, we did not hire probably 3, maybe even 4 great engineers purely because they didn't speak English very well. And this was a colossal mistake, really big mistake. As it turns out, as we learned over the course of time, we found a vendor who was able to help us teach English. So like that problem is something that goes away. And these people who are engineers, they learn new languages, you know, for a living. So it's not impossible to think they can learn to speak a different language as well. And the other thing is, if you have a person on the team who is very fluent in English, you can have communication happening in the local market in Spanish and still get the communication back to San Francisco just fine. So we learned that that was a big mistake, and actually, after we decided to hire recruiters in Mendoza, that sped up our ability to hire for sure. The second thing we learned, also language-related, and it's different, but it's similar, the language vendor that we used, um, We were working with them for about a year and we were trying to go through contract renegotiations, and I wanted to know if that vendor was really solid or terrific or not. I had one year of Spanish in high school, the farthest thing from fluent ever, and high school was a long time ago for me. Anyways, I decided I would, I would take classes to learn Spanish from the same vendor. I started doing that about 3.5 years ago. I've been taking classes religiously 3 times a week ever since. The vendor's incredible. Their name is LingoLive. If you ever want to like look for a great vendor for language learning, like they're amazing. But the thing that we never would've been able to predict is how much that was gonna create a bond between me and the team in Mendoza. So the culture in Mendoza is very, very connected. People are close to their friends, they're close to their family, and my just spending a little bit of time trying to reach out and learn the things that they're doing in the same way they were trying to learn our language, created a bond for us and it created a bond that's probably had me closer to the Mendoza team over time than I even have been with the San Francisco team. It's been wonderful to understand how just a small, really not that big of an effort has had a colossal big impact on the team. And I think what it's done is created trust with us. And I think trust is a big part of what you need to build with these distributed teams. And that gets to my second rule here, which is, You need to hire leaders you can trust and you need to get out of their way. So it probably makes a lot of sense that you should hire leaders you trust. You feel that way in anything that you're doing with any of your teams, whether they're local or whether they're distributed. But the getting out of their way part is actually pretty hard, or at least it was for me. Um, an example of, of how I was in their way. So I've been hiring engineers for 23 years now. In and around surrounding the poker time. But other than that, 23 years of hiring engineers, and I've always felt like I've gotten really good at telling the story of why an engineer should come to work for us and the value proposition of the company I work for. And I also feel like I'm really good at being able to identify the characteristics that will indicate success in our company. So I'm able to sort of spot what it looks like to be a terrific engineer. But as it turns out, over the course of time, what I didn't realize is I was in the process to try and hire every single engineer we had. I was in the interview process with all of them. I was in the hiring process, I was in the closing process, all of that. But with the team in Mendoza, what I was actually doing was not adding value. I was a bottleneck. I became this bottleneck because as our company got bigger and there were more and more of these interviews to do, I couldn't keep up with the flow that they were bringing me from Mendoza. Combine that with the fact that they're 5 hours in front of us meant that sometimes it took them a week to be able to get someone on my calendar. and then when we did talk, because I was still learning Spanish and I wasn't really fluent at that point, our interviews took longer and I wasn't able to get to a decision as easily as I could if I was having the interview with someone in English. And it took me a while to figure out that I was doing this wrong. It wasn't until finally I had a day, like a, a meeting day with a leader in Mendoza who helped me understand. He, he started telling me about hiring strategy and what it is he's looking for and what he wants to hire and like, what is it? What does a Brightling look like? Brightling is our name for people who work at Eventbrite. And how does he close engineers? And what I heard in that conversation was just over and over again, minute by minute, this guy thinks about the world exactly the way I do. We are super aligned on strategy. And when I figured that out, that's when I got out of his way and start letting him hire just without me in the process. And that accelerated our ability to hire and grow really, really fast. And that's also told me that over the course of time, it's important for me to be able to bake in that trust in the process when we're like growing new teams in different places. We've acquired other companies since these two. And when I'm looking for engineering leaders in these different distributed locations, I'm actually looking for people who have that strategic alignment with me. So I know from the start that I can just get outta their way. It was a really aha moment for me. It was super important. but it's not the most important thing. The third rule is definitely for sure the most important. Treat the distributed teams as equals and give them important work, trust, and autonomy. Now I know there are team people in here who have got distributed teams and I see this done wrong all the time by companies all over the place. The, the playbook seems to be, okay, I've got a team, there's more to do than they can possibly get done. If I had a distributed workforce, I could offload some of the things that are a little less important. I could give that distributed workforce like bug fixing or static landing pages or whatever, whatever you have in your head is not at a core what you really have to do. And let's keep the really core stuff for like my best engineers here. The outcome of giving your distributed teams work that's less important is is you will not have distributed teams who are excited to come to work. You won't be able to have them attract other great engineers in market. You won't be able to build what we have at Eventbrite right now, which is engineering teams in our distributed locations are not the junior varsity teams. They're the varsity. They get the hard stuff. They get the really important work. And the benefit of doing that is we've created a situation where all the engineers in those markets wanna come to work for Eventbrite. and it's— there are world-class engineers everywhere. All you have to do is to be able to find them, attract them, and give them really important things to do. Examples for me would be our Nashville office. We started with those 3 engineers, then we hired a leader who was fantastic, who was plugged into that ecosystem of engineers in the market, and he started hiring people. And we started off by giving our event creation, um, process over to this team, giving it to them completely autonomously. So for us, event creation is— it's the way that inventory shows up on Eventbrite. It's the touchpoint for our main customers who are our event creators, the people who organize these events and put them on. That's the way that they create events on our system. That's the way that we create inventory to be able to sell to people. And we gave that project completely to that team, and they've worked on it ever since. Second team there worked on data engineering. So we had a hard time finding competitive data engineers in San Francisco, but once we had invested, in a big way in the engineering team in Nashville, it turns out we could actually find great data engineers there and build a very strong muscle. So now all of our analytics work, all of it, happens out of a team in Nashville. And then finally, third, and this one's super important, all of our financial engineering comes from Nashville as well. All of our ability to be able to make payouts to our creators or to make sure that our books close on time month after month after month, that all happens out of Nashville. And I promise you, when we started that office, we never would have believed that Without the work happening in Nashville, IPO never happens for us. Just full stop, we never have an IPO if we didn't get ourselves to a place where our books could close regularly and consistently. One more quick story about autonomy. So this is a picture of a few of our engineers in our Madrid office. We've only been in Madrid for about a year and a half, and we just had a pretty big thing happen in Madrid over the course of the last, I guess it was earlier this month or last month in January. So every year there's a big event that happens. It's actually a 9-day event, 9 separate events that happens in the Netherlands. It's put on by the brewery Heineken and it's called Amstel Light Folk Music Series. 9 events that happen day after day after day. These events have capacity in their events are about 15,000 people. And we've been doing these events for the last 3 years. We've been the organizer or the, the vendor for Heineken. Now every year on the day of the first event, they put all the events on sale for the following year. So one moment, 10:00 AM, 90,000 tickets go on sale, actually more like 125,000 if you count all of them together, go on sale and they all get sold relatively quickly. And this is a big customer for us. So every year I've been waking up at 1:00 in the morning 'cause Amsterdam's 9 hours in front of us, being on the phone with the team, watching to make sure what happens is all positive, explaining to the organizer if it doesn't, you know, on the phone with Heineken. And that's been a part of my role in leading engineering. But this last year, we had a new feature, and the new feature is called embedded checkout. And for us, what that means is using our APIs, it's basically dropping a widget onto a creator's website or onto their mobile app that allows people to transact through that widget that widget without having to link to Eventbrite. So all of the activity actually happens on the creator's website. It's a new feature for us. It's one that's been produced by our team in Madrid. And when we had the on-sale the first week in January this year, um, they did load testing all through the holidays to try and make sure this was gonna work, 'cause it's a new thing for us. It's not all happening in a controlled environment on our site. It's actually happening on the organizer's website. They did all the work to do all this load testing, and it looked like everything was great. We were ready to go. So the night before the on-sale, I set my alarm for 1 o'clock, and my wife saw what I was doing, and she said, "What are you doing?" I said, "I'm setting my alarm for 1:00 AM. I've gotta be up for this sale. It's, like, super important." And she said, "Haven't you been explaining to me that you're trying to get out of the way of your distributed teams? Didn't you tell me that they've been doing all this load testing and that they're ready to go? What are you doing getting up at 1:00 in the morning?" like normal, she's right, so I decided like, I'm not gonna set the alarm. I slept, and I slept kind of, fits and starts. I woke up at 2:30, like in a panic. Oh my God, I can't believe I just, I let this sale go and I wasn't there, you know, so I got online real quick, and I looked around and I saw that we actually had sold twice as many tickets in the first half hour as we did the year before, and all I was there to see was a bunch of high fives from everybody around all the things that they did right, and I had nothing to do with it. It all happened while I slept. That's what you get from giving autonomy and really difficult challenges to your teams outside of your home office is you can get to these great things to happen while you're asleep. So circling back to what I said before, just the, the, the reward for spending that time and effort, the reward for making the decision of having distributed teams, the reward for giving them that trust and autonomy has been we are the place to work for engineers in both Mendoza and Nashville, full stop. We are the best place to work, and it's known by everybody. That advantage that Google used to have over us in San Francisco where we couldn't hire if it was us and Google at the end, we have that in both these cities now. And we extend this same playbook. We are extending this same playbook to Vancouver in Canada and Madrid in Spain and a couple of other offices that we've acquired recently. And what I'm here to tell you is that if you do these things, if you'll remember to observe and adjust and not be locked into what the rules are in every location, if you can hire leaders you trust and get out of their way, and if you can give these distributed teams meaningful work and autonomy, maybe you'll get a chance to find that you get to give a talk like this at some point and just say how lucky you were to be in the room. That's all I got for you. Thank you so much for giving me your attention. And my name is Pat Pools, Pat at Eventbrite, if you wanna talk more. Thank you all very much.