This post is by Faith Storey from SaaStr
Click here to view on the original site: Original Post
Building a company made up of distributed teams presents a plethora of complex challenges that can derail productivity and impact employee retention. But with it comes immense benefits and competitive advantages such as the diversification of ideas, speedier product development, and representation in important regions and time zones. Come and hear about the typical pitfalls (and how to avoid them) from Pat Poels, an executive with over seven years under his belt leading Eventbrite’s now 300+ strong engineering team that sits across North America, South America, and Europe Want to see more content like this? Join us at SaaStr Annual 2020. Pat Poels, SVP @ Eventbrite FULL TRANSCRIPT BELOW Hi everybody. I’ve never had walk up music before. That’s pretty intimidating, I think. I don’t know if we had a chance to be able to see Brian Halligan’s talk with HubSpot a little ago. When I saw his video,
was really intimidating. I saw 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. I am with Eventbrite, as I said. We’ve been a company since 2016. It was started by Kevin and Julia Hartz and Renaud Visage. 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. We got a chance to celebrate our initial public offering on the New York stock exchange back in September, which was a really exciting time for me. 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. I know you’re all here for a variety of reasons, a lot of empty chairs or two, 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 Eventbrite 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 are 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. 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. 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’ve 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 in my time in the company. 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 just being in San Francisco. The really positive outcomes from having distributed teams for us, and 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. 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, 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. I was lucky enough to win two World Series of Poker bracelets during that time. What we’re going to talk about for the next 30 minutes as I’m going to explain to you why I know that having distributed teams is better. I’m going to 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 going to 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. 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 had this belief that you had to have your teams in San Francisco. In fact, when I took the job with Eventbrite, I moved from Arizona to take the role. 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. 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 event bright and the environment and trying to hire in San Francisco in that moment. 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. 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. That meant that starting with 40 engineers in my team, I had to be able to hire six engineers every year just to stay flat. 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 engineering team just to keep up. 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. 18 hires a year I had to make in San Francisco. Finally, one of the really big problems we had is that the very specialized roles, we’re incredibly competitive. For roles like mobile engineers or data engineers, we tried to hire a database administrator for a long time and struggle 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. 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 bend forward to what it looks Eventbrite right now in 2019. This is a map that shows all the different locations that Eventbrite has around the globe. Now, we’re 1100 employees in 14 offices in 11 different countries. As well as being distributed from a business standpoint, having people in each of the offices where we want to have a a big presence business-wise, we also have engineers, product managers and designers in six of those 11 offices. We made a really big shift and move from being a very San Francisco centric company to a global company. From an engineering standpoint, it’s true as well. 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. 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. There were a couple of companies who were doing … Had ticketing companies that were very similar to EventBrite in South America. 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. This was the direction that he really wanted to go. The lucky decision was, Kevin asked me to meet with the engineering leaders in all three companies. I got a chance to have a sit down with the person leading in each one of these three different companies. As it turned out, the person who was co-founder and the engineering leader in Mendoza, Argentina was an completely world-class engineer. If you’ve ever heard of Mendoza before, you probably know it as a wine region, because they make great Malbecs and stakes. It’s an awesome place to visit. That’s another secondary reason to go there, but the engineer that I met, 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. 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. Basically, I went to Kevin and I begged. Is there any way we can hire this guy who I know is going to be one of our best engineers? 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. He agreed with me, he gave in and we decided to purchase the company in Mendoza. 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. 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. Trying to have a customer service team that was based in San Francisco was very, very difficult. We decided we would look at potentially opening another office just for customer service. 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. 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 is 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. 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. 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. 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. They were having this event that was like a speed dating, trying to connect engineers to potential places to work. They came over and they met us. It turns out they organize 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 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 we 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. It felt like maybe we might have a hiring advantage in this place. We decided to take a chance, and we hired three engineers in Nashville in 2014. These two decisions, these two kind of lucky breaks for us; getting started in Mendoza and getting started in Nashville, those were kind of the starting point for event bright 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. 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 at EventBrite?” 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, that heavy lifting has all been done by this team. The advantages of what we have, 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. In fact, in this office where we’ve experienced this great growth of going from five 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. What I want to say about Mendoza is, it sounds like it’s magical. I’m telling you the 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 few 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. 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 decided to go somewhere else, it’s going to feel different. 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. If you can do that, you can be successful. A couple of 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. 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. 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 is able to help us teach English. That problem is something that goes away, and these people who are engineers, they learn new languages for a living. It’s not impossible to think they can learn to speak a different language as well. 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. We learned 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 use, 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 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, they’re amazing. But, the thing that we never would’ve been able to predict is how much that was going to create a bond between me and the team in Mendoza. The culture and Mendoza’s 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. It created a bond that’s probably had me closer to the Mendoza team over time than I even had been with the San Francisco team. It’s been wonderful to understand how it’s just a small, really not that big of an effort has had a colossal big impact on the team. I think what it’s done is created trust with us. 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. 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. 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. 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. 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 are five hours in front of us meant that sometimes it took them a week to be able to get someone on my calendar. Then, when 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. 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 the leader in Mendoza who helped me understand, he started telling you about hiring strategy and what it is he’s looking for, and what he wants to hire and what does a Briteling look like? Briteling is our name for people who work at Eventbrite. And, how does he close engineers? 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. When I figured that out, that’s when I got out of his way and start letting him higher just without me in the process. That accelerated our ability to hire and grow really, really fast. 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 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 their team people in who had 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 of 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. 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. 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 national office. We started with those three engineers, then we hired a leader who is fantastic, who was plugged into that ecosystem of engineers in the market and he started hiring people. We started off by giving our event creation process over to this team, giving it to them completely autonomously. 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. We gave that project completely to that team and they worked on it ever since. Second team there worked on data engineering. 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. Now, all of our analytics worked, all of it happens out of a team in Nashville. 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. 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. This is a picture of a few of our engineers and our Madrid office. We’ve only been in Madrid for about a year and a half and we just had a pretty big thing happened in Madrid over the course of the last, I guess it was earlier this month or last month in January. 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 in their events are about 15,000 people. 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. One moment, 10:00 AM, 90,000 tickets go on sale. Actually, more like 125 if you count all of them together, go on sale and they all get sold relatively quickly. This is a big customer for us, so every year I’ve been waking up at 1:00 in the morning, because Amsterdam is 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. That’s been a part of my role in leading engineering. This last year, we had a new feature, and the new feature is called embedded checkout. 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. 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. 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 going to work. Because, 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 to go. 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 1:00 AM. I’ve got to be up for this sale. It’s super important.” 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 I’m not going to set the alarm. I slept. 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 let this sale go and I wasn’t there.” 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 these great things to happen while you’re asleep. Circling back to what I said before, just the reward for spending that time and effort. The reward for making the decision of, um, having distributed teams, the reward for giving them the 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 in Google at the end, we have that in both these cities now. We extend this same playbook, we are extending the same playbook to Vancouver in Canada and Madrid in Spain and a couple of other offices that we’ve acquired recently. 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 working 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’ve got for you. Thank you so much for giving me your attention. My name is Pat Poels, Pat at Eventbrite if you want to talk more. Thank you all very much. The post Engineering Your Own “Luck”: The 3 Key Rules of Building Globally Distributed Teams with Eventbrite (Video + Transcript) appeared first on SaaStr.