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's 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, which is a really exciting time for me. And I'm hopefully gonna 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 want to hear a different opinion. Maybe some of you here because you're just lucky to be here. You happen to 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'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. A little more about me. As I said, I've been with Eventbrite since 2011. I started right at the end of 2011 and I started in the role of VP of Engineering. That's what I did for the first six years of my time in the company. And as I said, we got a chance to go through a lot of changes starting from a San Francisco company and making those shifts out of being just in San Francisco. And there's really positive outcomes from having distributed teams for us. The way I think about positive outcomes, there are a few different things that make up a positive outcome. It comes from planning, it comes from great execution, it comes from making really good decisions, and it comes from taking some risks as well. And then there's a fifth 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, you know, seven years at Eventbrite and 15 years at Ticketmaster before I spent five years of my life playing poker for a living and learned an awful lot about luck and positive outcomes as well, because I was lucky enough to win two 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 walk through 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. And 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. And it wasn't just that we were all in San Francisco. It was actually a rule in the company. 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 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 going to 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 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 seven years and two 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 iTeam, I had to be able to hire six 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 six 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 roles like mobile engineers or data engineers, we tried to hire a database administrator for a long time and struggled with that. It's of a lot 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 kept up pretty well, but we definitely had some challenges with that. Let's 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 big presence, business wise, we also have engineers, product managers and designers in six of those 11 offices. So we made a really big shift and move from being a very San Francisco centric company to a global 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 the two big key decisions we made early on. So I want to talk you through those two decisions that we made. First off, in 2013, we made our first acquisition. We'd never acquired a company before, but our CEO at the time, Kevin Hartz, was relatively certain that even though we were growing well in South America organically, we weren't growing fast enough. And there were a couple of companies who were doing had ticketing companies that were very similar to Eventbrite in South America. And at first look, Kevin took a trip down to South America and he met with all three 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 company was their sales were quite a bit bigger than the other two companies. The other two were based in Argentina and in Chile. 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 three 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, because 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 nine, 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 five engineers. But I felt like this guy was probably in our top three 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 going to 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 four or five cities to look at, 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. The 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 a connection that felt really good. So we opened a customer service office in Nashville. Now, the lucky thing that happened was about six 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 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 the developer community kind of ecosystem in Nashville. So they were having this event that was like a speed dating, trying to connect engineers to potential places to work. 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 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 three engineers in Nashville in 2014. So these two decisions, these two kind of lucky breaks for us, getting started in Mendoza and getting started in Nashville, those were the starting point for Eventbrite moving to distributed teams. This is a picture of our Mendoza team today. This is what five years of successful growth in a distributed team can look like. So as I said before, 15 people in the company when we started, five 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 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 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 four years after we started building the team. That's the kind of retention advantage we've had in Mendoza. And what I want to 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 Stake 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 have 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 things that we've learned over the course of time. I'll boil them down into just three 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 going to feel different. I can't tell you what the playbook is going to 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 found over the course of time in starting 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 Going to 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 two years doing hiring in Mendoza, we did not hire probably three, maybe even four 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 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, 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 strength from fluent ever. And high school was a long time ago for me. Anyways, I decided I would take classes to learn Spanish from the same vendor. I started doing that about three and a half years ago. I've been taking classes religiously three times a week ever since. The vendor's incredible. Their name is Lingo Live. 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 have been able to predict is how much that was going to 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, an example 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. 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 five 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 an 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 meeting day with a leader in Mendoza who helped me understand. He started telling me about hiring strategy and what it is he's looking for and what he wants to hire. And what does a Breitling look like? Breitling 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 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 out of 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 people in here who have got distributed teams and I see this done wrong all the time by companies all over the place. 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 my best engineers here, the outcome of giving your distributed teams work that's less important 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 want to come to work for Eventbrite and 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 three 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 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 touch point 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 in 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'd 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 nine day event. Nine separate events that happens in the Netherlands. It's put on by the brewery Heineken and it's called Amstel Light Folk music series. Nine events that happen day after day after day. These events have capacity and their events are about 15,000 people. And we've been doing these events for the last three years. We've been the organizer or 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, 10am, 90,000 tickets go on sale. Actually more like 125. 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 one in the morning because Amsterdam's nine 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 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 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, 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 one 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 1am, 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. What are you doing getting up at one in the morning and like normal. She's right. So I decided like, I'm not going to 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. 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, as you can get these great things to happen while you're asleep. So circling back to what I said before, just 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 the same playbook to Vancouver in Canada and Madrid in Spain and a couple 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 want to talk more. Thank you all very much.