Make Operations Your Startup’s Incubator with LeagueSide’s Zubin Teherani

Sean Lane: Hey everyone. Welcome to Operations, the shows where we look under the hood of companies in hyper- growth. My name is Sean Lane. We can get caught up sometimes on this show on what the most ideal and advanced versions of an operations team can look like. When our companies grow up, will we be ready, will we be mature and sophisticated enough? It's easy to forget the early days of startups and the beginnings of hyper- growth when an ops team might be the crew that's just, well, responsible for anything and everything that doesn't yet have a home. That's exactly what happened with today's guest, Zubin Teherani. Zubin is the co- founder and COO of LeagueSide, a company that makes youth sports sponsorships easy by bringing together over 16,000 youth sports leagues with big brands. Zubin and his team have used operations almost like an incubator for every core function within the company. In our conversation, we explore how and why they used ops as a catchall, we talk about the UI/ UX of operations, and why Zubin's stint outside of operations was what unlocked a whole new way of doing things inside of operations. Zubin and his co- founder Evan Brandoff started the company back in 2015. So to start, let's talk about how the meaning of operations at LeagueSide has evolved over the years.

Zubin Teherani: Operations for us has kind of been the bucket that we just throw into when we didn't have a functionality for the team. So every early on, ops was the SDR team, it was the people ops team, it was the marketing team. Ops at LeagueSide, we didn't know where to put it, don't know who should own it, just throw it in the ops bucket. And it's been interesting over time, because as a result of kind of that catch- all bucket, the ops team has always been generalists. So we've always just hired people who are amazing at solving problems, amazing at building systems. And over time we've taken those generalist skillsets, spun them off into their own departments, and kind of built specialties around that. So, operations is still that catch- all bucket, but we're starting to specialize a little bit more and more.

Sean Lane: And so, over the years I would imagine kind of, as you've had a few different cracks at it, like SDR, people ops, marketing, you've probably gotten better at figuring out when it's time to actually specialize it, and when it's time to spin it off. How do you know when it's time, and you know the generalist catch- all phase of that particular department has reached its kind of conclusion?

Zubin Teherani: Yeah, I wish I could say that we were really great at predicting problems, and being proactive. But typically, the way we found out is our systems would break. So, the ops team is all about 80-20, can we just figure out a way to duct tape systems together, get it so it's good enough. And then once it starts breaking, realizing that A, maybe we can just optimize it a little bit, or B, it needs to be owned by someone, run by someone, needs a little more thought, care and experience going into it.

Sean Lane: Got it. And so, when you did that kind of graduation process from ops running it to a specialty, that also usually coincided with maybe a new leader coming in, or someone that was going to actually have a functional expertise in that area?

Zubin Teherani: Yeah, that's exactly right. I'll use the example people ops for us, is, our operations team is really just building all of the backbone of what a hiring process looks like. So, everything from what does an intro call look like, all the Google forms that go in with vetting and tracking candidates, all the test projects, what are the workflows for all those things? We basically built an ATS without an ATS. And so, as the team kind of scaled and grew, and we were starting to hire more and more, that whole system of copying forms, putting them in a place, the whole thing kind of broke down. And at the same time, we need to elevate our hiring practices and bring in that experience. And so, we brought in a head of people. Her name's Emily, she's awesome. Came in, was like, " What are you guys doing? Let me bring in an ATS out, some structure out, some process to this." And now she owns a whole process, and kind of taken out of the ops bucket, and more into a specific people ops bucket.

Sean Lane: I would have to imagine though, when the Emilies of the world come in, I'm sure there's an element of, " What are you guys doing?" But I also would imagine there's an element of, " Hey, thank you," because you've already built a lot of the foundational stuff that that person will need to measure their business, the instrumentation for that business. Is that kind of the theory, or the hypothesis behind having the ops team kind of stand up those foundational building blocks?

Zubin Teherani: Yeah, 100%. I think what we've... We started to do a lot better as an ops team is map the process, and abstract it away from implementation. What I mean by that is, I think the classic example is just whiteboarding, just understanding who are the different users, where are the different handoff points, and what are the large thematic pieces? So, thinking with hiring, there's initial phone call, just vetting. There's a test project phase, there's a test project review phase, and there's a final round interview phase for us. And within each of those buckets, just high- level describing what we were trying to achieve, or what we we're trying to do there. And then building a system that kind of implements that high- level thought and process. And so, as long as we kind of map the larger flow and the intention and goals, it is very easy for someone who comes in and starts running people ops to understand at least the rationale and the goals, and ultimately what we're trying to achieve in a certain place. They might rip out the actual implementation later. But, they understand this is generally the workflow and user flow for what we expect for an interview process, both from candidates, admin and indos running the interviews.

Sean Lane: What Zubin and the LeagueSide operations team have built is basically an incubator for the core functions of a startup. They piece together the necessary building blocks, stand up some basic functions, and evolve that function until the Emilies of the world show up to add their expertise into the mix. And this incubator has served them really well. I like Zubin's piece of advice about mapping out a process separate from that process' implementation. That's exactly how growing companies evolve. The implementation of a particular process, like hiring, will inevitably change countless times. And it sounds like the more times they've gone through this incubator process at LeagueSide, this transition from generalist to specialist, the better they get at it. So I was curious if they felt like they also got better at transitioning not just the map that they drew, but the context and the institutional knowledge behind that map.

Zubin Teherani: When we started LeagueSide, we were very much, duct tape a bunch of systems together. So for example, our CRM was also our database. So, when we would try to... The way our business works is, let's say a regional brand wants to sponsor a youth sports organization that plays within five miles of each of their restaurant location. And the process for us early on was that you would basically ping our CRM database, you would give it some parameters around where you want to target. Our CRM would then use Zapier to push it to like a Google sheet, we'd use a Google sheet to take an address and geo code it to pins on a map. We would take those pins on the map, put it on a Google map, and then share it with a client, be like, " Here's our database of organizations around all your restaurant locations." And so very much like a lot of duct taping of systems, integrations, very heavy ops system work there. And generally, for that process to go well there's so many steps in it to go right. You need to hit the right end point, and have the exact data in the CRM. You need to make sure all your formulas are right in that Google sheet, and then you need to copy and paste all those points, and get it into a Google sheet, and lay it all down. And so as a result of scaling all those systems, you have to do all these steps to make it work perfectly right. And so a realization for us is that operations might be solving problems, but it's really hard for our internal users to follow all those steps and do it. And so as we were scaling, what we started rethinking about is the UI/ UX of operations internally. We're kind of defining what is the interface that a salesperson, or what is the one action, or maybe even no action that a salesperson should do. And then all that magic kind of happens behind the scenes, and they just get the output that they're expecting and they want. And so, we started rethinking a lot as we scaled these systems, what's the way to avoid institutional knowledge in a way you could just press a button, and then magic happens. And then have operations handle all the plumbing behind the scenes, but doesn't matter for internal, external users.

Sean Lane: Avoid institutional knowledge with the press of a button. Sounds easy, right? I talk with my team at Drift all the time about designing with the end user in mind. End users in our case often being internal customers, like salespeople, marketers, customer- facing folks. But I have never thought to take it as far as Zubin did, with his idea of the UI and UX in operations. This magical experience for internal customers though, this is still being built and designed by the operators within LeagueSide. Someone needs to know how the magic trick is done. So, how has Zubin ensured the same thinking extends within his own team? It turns out he ensured this by taking a tour of duty in a role completely outside of operations.

Zubin Teherani: When the pandemic hit, our engineering team... We had to lay off a bunch of people on our engineering team, and the result is I actually ended up writing a bunch of code myself. And so, it was an interesting experience, and very formative in kind of my ops career. Because from that, I took away a lot of different software principles that I think apply to operations as well. And so, speaking to maintaining and building these systems, some of the takeaways from that engineering experience was, these systems should... The concept of keep it simple, like these systems should be so easy and human- readable and understandable for you to jump in, and understand what happens. So for example, let's say you're operating with some Excel formulas, and you probably play with those really deep, nested if statements. Like, if this happens, and this, or this happens, and this, blah blah blah blah. That's a good example of like, yeah, maybe it's an elegant solution. But, it's not simple, it's very hard to open up that formula and actually understand what's happening there. And so, a concept there is to abstract all of those inner if statements into their own columns or own data. And it's more information, but it's more human- readable to understand all the inputs, outputs and things that are happening there. I think related to that, another software principle we pulled away is like the single responsibility principle, where a piece of your system should do one thing and one thing only. It shouldn't necessarily have all of these other dependencies, or try to do too much. I'll try to use an example for LeagueSide. We use AirTable for managing events. And, events have a lot of moving parts to it. There's collecting the event information from the youth sports league, there's sending it to the sponsor for their approval, and then there's making sure the league executes all of the promotions leading up to the actual event. And when we initially built this, we just put it all in one big air table base. We were like, " All right, this is all of our events, this is the process, this is kind of how we'll do it." But the result of that is like, that system was responsible for three different things. So if you change the sponsor workflow, or the sponsor approval workflow, it'd break the whole system. Or if you change how events are collected, it would break the whole system. So instead, we kind of decoupled each of those steps, put them in their own place, define the interface. What are the inputs and outputs of each system? Keep those consistent, and then make it super simple and step- by- step within that specific, certain function. And so the result is like, we have a system that's more extendable, more reusable, and easier to maintain, and anyone can more easily step in and understand what's going on. I gave you a super- long winded answer to your seemingly simple question.

Sean Lane: No, no, that is super interesting. No, no, no, no, no, this is great. I would also have to imagine that when you do break those things down into those unique steps, then all of a sudden it's not just bringing those particular steps together for that particular event process. But now, step two might be reusable inside of a season- long sponsorship process, as opposed to a single- event one. And so now all of a sudden, it almost becomes this library of operation steps that they can pick and choose from. Am I going too far with that?

Zubin Teherani: No, that's 100% right. And that's also a software principle, you're talking about dry. Don't repeat yourself, just reuse code wherever you can. That's 100% on the money.

Sean Lane: That's super interesting. And so, you were talking really... Right at the beginning of our conversation about this idea of, the blueprint's going to help you to prioritize... I think you said what to ship today, and what to ship tomorrow. And so, I would have to imagine that this experience as going to actually having to be the person who is helping to write the code for your company, is probably influencing the way that you now prioritize in ops. Is that accurate?

Zubin Teherani: Yeah, 100%. I think with software it's even more hyperbolized, that you don't have enough time, you don't have enough resources, there's too much stuff to build, we have to prioritize. And we've kind of taken that to ops, too. Ops time is really... You can automate everything, but automations also come with a cost, right?

Sean Lane: Mm-hmm (affirmative).

Zubin Teherani: You have to maintain the system that you've automated, and you have to make improvements, you have to change all of those pieces. And so that ruthless prioritization, and saying like, " Is this good enough?" To your point before, what's the metric? Are we getting a pass, fail, is it good enough? If not, we can come back and revisit it. But, just prioritizing shipping this, sold it good enough, it's maintainable enough, it's simple enough, those are the things that are really important in case your mind changes later.

Sean Lane: I've got to say, I admire Zubin so much for this. He, like so many founders, was faced with an incredibly difficult situation during the pandemic, and he dug in. He learned these new principles as an engineer, and translated them into specific operating systems for his team. In some ways it was just the LeagueSide incubator in reverse, keep it simple, the single responsibility principle, dry, or don't repeat yourself. These were all tried and true software principles that the generalists in ops could take advantage of, even if they weren't the ones that went through the six month stint in engineering that Zubin did. So, are those other ops folks actually getting something out of the product principles?

Zubin Teherani: It's a lot of repetition. So, you'll hear us say like, " Reduce dependency, single responsibility, all of those pieces. Or simplify it, or you need to abstract the logic in a place that we can understand it. It's a lot of that repeating. And then we take another software principle, and we introduce pairing on the team. So, people will sit together, just like two engineers might sit and look at the same screen, and try to solve the same problem, one person's driving, one person's talking and switching off. Trying to pair also in operations, so when building systems, having a lead, or swapping, or being in the same place and trying to use the same language to reiterate that in all our systems.

Sean Lane: That's amazing. Is there a particular kind of category of activity that lends itself best to that pairing? Are you guys doing it in a whole bunch of different types of ops work, have you identified like, " Hey, some of this doesn't really work, some of this does work better with that system?"

Zubin Teherani: I would say it's pretty much across the team. For operations, talking about the evolution of ops at LeagueSide, because of this generalist skillset that we've built, and everyone's able to do kind of everything, operations has become responsible for the entire supply side of our marketplace, meaning the youth sports organizations in our system. Because when dealing with the supply side, you have to do everything. You have to market to organizations to onboard them, you need to sell them to onboard them, you need customer support for once they're onboarded, you want to figure out those network effects so they're referring other organizations. And then for us, we're running a systems- driven process to make sure organizations run campaigns correctly, and execute what they're supposed to execute.

Sean Lane: The other thing that just hit me is like, you probably... And you can confirm or deny this. With kind of the approach that you've taken, and now just thinking about every kind of step of the customer journey that you just outlined, it kind of feels like you've built this operational, this system- driven mindset into the DNA of the company. And so now as these folks on your team kind of move and migrate to other parts of the company, they're already going to have that type of thinking. Is that what's happening?

Zubin Teherani: I think that's 100% right, yeah. We often talk about specifically our league operations team as like a great place to start your career at LeagueSide, figure out if you love the generalists doing all of the above, or a specialization. And then you can go into our marketing team, you can go into the sales team, you can go into the customer, or client success team from there. And so, we do often use it as like a training ground to figure out, now you understand LeagueSide, you're very close to the product, you figure out the part that you really... The functional area that you really enjoy, and go off to the other team or group if that's what interests you.

Sean Lane: I recognize that I'm biased, and I'm sure people from other functions would probably disagree with me here. But that to me is amazing, because then you have that everywhere in your organization, right?

Zubin Teherani: Yeah.

Sean Lane: And people feel ownership over the systems, and the processes, as opposed to, " This is what ops handed to me," or, " This is what the company has handed to me," instead of taking ownership over it, finding where stuff breaks, finding places where things can be simplified, they just kind of work around those things. And I think by instilling that in the DNA and instilling it so early, you guys really have this leg up now. Because everyone in the company who has gone through at least some version of that is going to be part of the longer- term system solutioning for your team.

Zubin Teherani: Yeah. I'm also biased because that's my team, but yeah, I crosstalk that too.

Sean Lane: Before we go, at the end of each show we're going to ask each guest the same lightning round of questions. Ready? Here we go. Best book you've read in the last six months?

Zubin Teherani: Oh. It is a product book, I think it's called Inspired? It's around product sprints. I forget the name of the book.

Sean Lane: We'll go with Inspired and update it after if we need to.

Zubin Teherani: Okay, cool. Yeah, it is called Inspired, I just looked it up.

Sean Lane: Perfect.

Zubin Teherani: It's by Marty Cagan, yeah.

Sean Lane: Awesome, I'll have to add it to the list. Favorite part about working in ops?

Zubin Teherani: Love building systems, love solving problems. I'm sure that's a common answer.

Sean Lane: It is, it is. Least favorite part about working in ops?

Zubin Teherani: It's often hard to... We spoke to prioritization before, there's so many problems, it's like trying to boil the ocean. Which is a double- edged sword, because that's also my favorite part about it. But it's also oftentimes my least favorite part about it.

Sean Lane: Tricky balance, for sure. Someone who impacted you getting to the job you have today.

Zubin Teherani: This is a shoutout to the Venture for America community, I know that's how you and I know each other.

Sean Lane: It is.

Zubin Teherani: But Venture for America, that community is incredible. I'm fortunate to know amazing entrepreneurs and startup veterans like yourself, and I think that's pushed me to be a better startup person, better founder, better person, just an amazing community all around.

Sean Lane: That's a nice shoutout. And also, obviously the fact that what you and Evan and the team at LeagueSide have done is a pretty nice, shiny example for folks coming into the program today, so you should give yourself a little bit of a clap on the back for that one as well. All right, last one for you. One piece of advice for people who want to have your job someday.

Zubin Teherani: I think most people say learn software engineering. That's not my advice, my advice is to learn the heuristics and the principles, and just the high- level concepts of it. Because it is super- applicable to operations, you don't need to write a single line of code. But a lot of learnings from a lot of people coding and building a lot of software, making a lot of mistakes are very applicable for operations and scaling an operations team.

Sean Lane: Thanks so much to Zubin for joining us on this week's episode of Operations. If you liked what you heard, make sure you are subscribed to our show so you get a new episode in your feed every other Friday. If you felt like you learned something from our show this week or any other week, leave us a review on Apple Podcasts, or wherever you get your podcast, six star reviews only, all right? That's going to do it for me. Thanks so much for listening, we'll see you next time.