Inside Salesforce’s Annual Planning Process with Bala Balabaskaran (aka The Guy Who Built It)

Operations-Podcast-Drift

On this episode of Operations, Sean goes back in time – to 2012, to be exact – when special guest Bala Balabaskaran first joined Salesforce as Vice President of Go to Market Technology and Operations. At the time, Salesforce was a $2 billion dollar startup going through hypergrowth. Sean and Bala talk about Salesforce’s operating model and what it was like to be in charge of the go to market planning process at a large company with a startup mentality. Want to know Bala’s step by step approach for building out the annual planning process at Salesforce? Listen to the full episode.

You can get #Operations on Apple PodcastsSoundCloudSpotifyStitcherGoogle Play Music or wherever you get your podcasts. Or listen to the full audio version below 👇

Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Sean on Twitter @Seany_Biz

Subscribe & Tune In

Apple Podcasts Spotify SoundCloud

Full Transcript

Sean Lane: Hey everyone. Welcome back for another episode of Operations, the show where we look under the hood of companies in hypergrowth. My name is Sean Lane. Whether you have five sales people at your company or 5,000, chances are you go through some kind of annual planning process. What you probably don’t have is a planning process that includes 400 people, 1,500 spreadsheets, and eight months worth of iterations, but that’s exactly what today’s guest Bala Balabaskaran found when he got to Salesforce in 2012. Whether you’re a veteran of the annual planning process or you’re about to put together an operating plan for the first time, Bala is your guy. Today we’re going to go step by step through the actual planning process used at salesforce.com, how to navigate that process, and, as Bala calls it, the philosophical horse trading that happens along the way. By the end, you’ll also get to learn what Bala was able to deliver for the first time in Salesforce’s history.

An engineer by training, Bala spent the earlier parts of his career at companies like Hewlett Packard and Microsoft before joining Salesforce as the vice president of go-to market technology and operations in 2012. So my natural first question for Bala, what the hell is a vice president of go-to market technology and operations, and what did Salesforce look like when he joined in 2012?

Bala Balabaskaran: So Salesforce, it was a $2 billion startup at that point, you know? Everything was fast moving. It was a company that was growing roughly around 30% year over year, and we were starting to do big and bigger acquisitions on the marketing cloud side. We were starting to integrate these larger companies that we were acquiring. So it was a pretty crazy place, but there was a lot of fun, great leadership. Enjoyed my time there, yeah.

Sean: And when you come in, what exactly is a VP of go-to market technology and operations chartered to do?

Bala: Yup. So my role was basically to support the distribution team, which was basically the name for everything from lead to renewal, right? That entire flow. And then over the course of my four and a half years there, I slowly sort of broke off the whole responsibility to smaller chunks, but basically it was planning, so the go-to market planning exercise, which is bringing together close to about 400 people across the company to go through the planning process before, and then the rollout of that. And then we were also responsible for the business process, which is Salesforce’s own instance of Salesforce and how we used it internally, so everything from forecasting to all of the validation rules to workflows that we built, and any new features or tools that we deployed for the sales teams, as well as sales leadership, so my team was responsible for sort of the business analysis and really kind of creating the design for what the business process should look like, and then working with IT to actually implementing that.

And then the third part of my role was field operations, so this is basically making sure that the data within the Salesforce instance was good, which is a never ending battle, but also rolling out territories, managing the territories over the course of the year, so just the operational cadence around the field teams, but it didn’t include like deal desk and commissions, so we were mostly responsible for kind of getting the commissions data to the team but not actually doing the commission’s work.

Sean: So I want to take each of those separately if I can. Did I hear you right? You said 400 people are involved in the annual planning process at Salesforce at the time you were there.

Bala: That’s right, yeah. You know, we had this philosophy that the best information really about the market came from our own people at the front lines, and so this planning process really required us to figure out a way to capture that frontline knowledge. So we would involve all of the sales managers down to the RVP level, and it also involved finance and HR, and we call them employee success, and then also a variety of other support teams that needed to be part of this process. The process itself took about eight months, so we will start somewhere around August all the way through to March, and February 1st was our fiscal start.

Sean: Okay.

Bala: And you know, when I started it was about 1,500 reps, and due to the acquisitions and organic growth, by the time I left it was close to 4,500 or so reps, and in a variety of different roles, so we had the core AEs, but then we also have a number of support roles, overlay roles. All in all about 27 or so, I think the last count I had, the different roles that were involved in the selling process and the supporting process, through the lead to [inaudible 00:05:33] process end to end. So it involves working with the managers for all of those different teams and really figuring out how to get them involved into the planning process. So I can work through kind of the major stages if that would be helpful. Yeah.

Sean: Yeah, I guess, I would love to hear those stages. I would also love to just understand from a scope perspective, at a certain point, like does it get easier even as that volume gets bigger? Right? So I’m thinking about it from the lens that I look through every day, which is about 60 reps and a much, much smaller group of people involved in a planning process. When you’re talking about wrangling 400 people into a process for 4,500 reps across 27 different types of roles, at a certain point do you hit this efficiency point where, okay, once we know the process then we can just nail this 27 different times, or is there 27 different flavors of complexity that are going into that?

Bala: There is 27 different flavors of complexity, sometimes even more so because even if you just took the core AE roles, there were many different ways in which the team resourcing was allocated based on industries, based on size of the company, based on special programs like hunter programs that we had, so there was a variety of ways in which those resources were deployed, and it wasn’t necessarily all a one size fits all model. Right? So it does get complex.

When I started, we actually were doing this entirely on spreadsheets, and I think my team had this high value job of pulling all of the spreadsheets together during this planning process, which was not a great value add, not a great way to motivate your team, but something that needed to be done to kind of get data into a central place where we can sort of analyze the impact and so on. So it does get complex.

Sean: I’d say it gets complex. 1,500 reps to 4,500 reps across 27 different roles, 27 different flavors of planning, in a manual process in spreadsheets. So yeah, I’d say complex is the right way to describe the process. By the way, the next time you’re thinking to yourself, “Oh, our processes are too manual. We don’t have enough automation or systems in place,” take solace in the fact that at 4,500 salespeople, Salesforce was still planning their year end spreadsheets with contributions from 400 different people.

Anyways, this whole thing took Bala and his team eight months, eight months. That’s two-thirds of the year spent on this process. So here’s what we’re going to do. It’s a huge process, so we’ve got to break this thing down. If you aren’t satisfied with the way your planning process went last year or you’re already starting to look ahead to 2020, we’re going to break this thing down to the six steps you need to follow to build an operating plan like salesforce.com. All right, ready to go? Step one, analyze and refresh your data.

Bala: So from a stages standpoint, right, we would start in August looking at the data, and the data internally within our Salesforce instance. You know, we had millions of account information in our Salesforce instance, so we’ll pull all that, look at all the data. We would analyze it for total addressable market and what that looks like, what our market share looked like in different regions, all the way down to even states and cities. And then largely, there was an exercise to update or refresh the data, and we had close to 13 different data sources that we bought data from worldwide. DNB of course was one of the main ones, but we got into country-specific data, especially when you get out to South America and APAC, the accuracy of the data gets very specific based on the source that you’re looking at and for specific fields.

So we really had to narrow it down to about 13 or 14 fields that were used in carving in how we built out our territories, and focusing in on the data quality of those from a variety of different sources. So that took us about two to three months just to get that process going. We had built an automation that kind of created a survivorship rule set that would figure out what’s the best data source and what’s the right place to pick a particular field from. So like –

Sean: Is that kind of like a waterfall type situation, where you’re picking the best you can find?

Bala: It is.

Sean: Got it.

Bala: That’s right, that’s right. And part of that data source was also incorporating our own SDR notes. Right? Because they’re on the street talking to a lot of customers. They tended to have the most accurate data actually, believe it or not, compared to third party data sources. So we had to figure out a way to bring that into the process, and so it took us about two to three months kind of getting all of that done. Once it’s all done, then we would do the tab analysis. And because our segmentation in some businesses were driven by the employee size, there was a natural disruption that was caused by just companies growing, right? So they would go from the SMB segment to a mid market segment to a corporate segment and so on, so that analysis was important for us to do so we understood how the customers were progressing into various segments and what’s the best sort of program to support them with, and that’s part of the analysis that we did.

Sean: And did you only refresh companies like that on that annual exercise or were you doing that more frequently throughout the year?

Bala: The pain was so much that we only did it once without … And I think it’s also this annual process of refreshing data. Because we bought data from a number of sources, just the process of kind of pulling all of that together to do a refresh, we only did that annually.

Sean: Got it.

Bala: The easier approach would have been to say there is one source of truth, say, DNB, and that’s all we’re going to take, but when you get out of the U.S. and you go into the international markets, that data becomes pretty terrible very quickly, and so then we were planning with … It’d be easier for us as a ops team, but it would be the resulting plans would not necessarily reflect reality, so we had to sort of take on that burden.

Sean: This is going to be one of those steps that’s hard for people outside of ops to appreciate, but setting up the infrastructure and hierarchy of those different data sources is no joke, and Bala is spot on. It would be much easier to just use one source of truth, stick to that, and ignore everything else. Analyzing, refreshing your data, it’s not sexy, but it lays the foundation for a successful planning process. Okay. Step one is in the books, on to step two: capacity planning.

Bala: And so once we finished with that process, then came the capacity modeling exercise, so this is really taking an ROI lens to the investment that we’re making in sales and distribution. We worked very closely with finance during this process. You know, you get your revenue targets for next year, and again, the targets were a range, because we would be doing this in Q4 and the business wouldn’t have closed yet, so we wouldn’t know where we would exactly land, and so there was variability in the numbers and, as we got closer and closer to the end of the fiscal, we’ll get better numbers, but we needed to be very in tune with the finance to make sure that we were keeping an eye on that.

Sean: Bala told me that part of keeping in tune with finance meant that targets for the following year were constantly fluctuating based on the team’s performance in the last quarter of the year. So if you blow out your number in Q4, guess what? Your number for the following year is probably going up. Or as Bala told me, “No good deed goes unpunished.” The output of this step in the process, most importantly though, is how many people go where. Once you’ve got that capacity nailed, it’s time to get a little bit more specific. Step three: segmentation.

Bala: And then, so the effort sort of breaks off into two different angles, and one is a really looking at our high level segmentation, so this is all of the different business units, enterprise, corporate, some small medium business verticals. So we would start to look at what those high level segmentation would look like for us. This is also where we did a lot of analysis around international expansion, for instance. Right?

Sean: Got it.

Bala: You really have to kind of think about investment in sales, not in a single fiscal year, but a multi-year horizon, because when you’re investing in a area that you’re growing, you probably won’t see results for a couple of years. So those kind of … It’s sort of a balancing act, right? Where do we invest? If we invest, what’s our return horizon look like? And the feeling really is that of a VC investing in a startup, right? And you would really look at the business and say, “Okay, if I put in this much dollars, what do I expect in two years?” And so on.

Sean: That’s really interesting because, I mean, you said that even though the company had been around for 13 or 14 years at that point, by the time you got there, it still had that startup mentality. When you’re going through that segmentation exercise, has Salesforce at that point, have they nailed their segments, “Okay, these are our segments. We know this is how they are going to work,” or are some of those things still in flux, and do any of those things change at that point?

Bala: A lot of things are in flux. So part of being a startup is you’re constantly reevaluating everything, and so there was a mix of what you will see in the data with philosophical debates at the leadership level. Right? You know, should we be expanding internationally? And some people will feel very strongly that you should do that. Others would say, “No, double down on this vertical that’s producing more returns for us.” So again, I always looked at that as like philosophical horsetrading, where people would go back and forth and finally kind of take a [inaudible 00:16:02] or a [inaudible 00:16:03] to come in and settle things down. But at the end of it, we got some numbers, right?

Sean: Philosophical horsetrading has a nice ring to it, doesn’t it? I really liked the way Bala compares investing in a sales segment to a VC investing in a startup. You’re placing multi-year bets on a segment, a business unit, an experiment. Now, not everyone is going to have a couple of years like Salesforce to see if an experiment bears out, but the same principles apply. It’s a balancing act. What are your goals? What’s the timeline? When are you going to see results?

So, okay, we’ve got our segments. Up next, step four: workforce and territory planning. At Salesforce, Bala told me that they set up the career ladder for sales folks in such a way that, when reps got promoted, they got promoted into different segments. So interviews are taking place in the midst of all of this planning to determine how many and which reps would be in each specific role, and also which territory they would be in. So once you have that workforce in place, you move on to step five, quota planning. Using the capacity modeling we talked about earlier, Bala said that they would consider things like ramp, which territory you’re in, which role you’re going to be in, to determine the quotas across the sales team.

Now, one thing Bala and I didn’t go deep into is the world of comp planning, but that is a crucial part of this process and I’m going to save that for a different episode. After step five of quota planning, we got to the part that I really wanted to dig into, step six: the rollout and the aftershocks, the process for taking months of work and putting it out there into the world, the communication involved in that, and how that process evolved over the course of Bala’s time at Salesforce.

Bala: The idea was that, 1st of the fiscal year in February, we would take a couple of weekends to roll out all these changes into Salesforce, and, believe it or not, it actually took us a lot longer than that. It used to be about 60 days after the start of the fiscal that we would have all the roles with their territories and so on, and that was because we were essentially data loading spreadsheets, and we would run into errors and assumptions that were made during carving, and the carving spreadsheets were a point in time snapshot of the data, and reality-

Sean: Right, things have probably changed at that point.

Bala: Exactly. You know, one great example is a we would build out these hunter territories, which are supposed to be all prospects, and then by the time we got to Q4 and we roll this out, 30% of them would have become customers. They were not truly hunter territories anymore. Right? So those kind of stuff, right? So we had to deal with all those while we’re rolling stuff out, and there’s a lot of reconciling of differences. Right?

Sean: Yeah, that’s what I was going to say. So it’s one thing to have everything in a spreadsheet, right? It looks great in a spreadsheet when you’re looking at it in a vacuum, and then when you start to hit that real world component or you’re starting to roll this thing out and put it in front of the teams that are going to have to live within it every single day, first of all, I’m curious, what does it look like on a scale of 4,500 reps the communication around rolling this out, and then inevitably when you get the feedback and the questions and the hand raising after the fact, how do you deal with that?

Bala: Right, right. So we had a process, once the planning stuff was locked down, we had a process of communicating what we called quota letters, and so the quota letters would basically describe the territory that was carved, some of the metrics associated with that territory, and what the quota looks like for that particular territory. So it wasn’t necessarily the comp plan. It was basically the structure of the territory that would go out, and we would provide those to managers and the managers would then have discussion with their people, so we needed to have a way of disseminating all of this. Before we put in some automation, all of this was done using spreadsheets.

And so a manager would get a spreadsheet that explained how the territories were carved and what are the metrics that we used for carving and balancing those territories, so they’ll be able to sort of explain the philosophy behind the territory that someone got. Right? And of course, you know, 50% of the people are happy with it, 50% were not, but that’s kind of the dissemination of information, but the challenge that we dealt with there was, as the … Territories got smaller and smaller and smaller because we were growing at about 30% year over year, which meant that everybody’s territories, we had to take 30% of the accounts out of everybody’s territories to create new territories, and so that was sort of a process that we gave the managers control over, the frontline managers control over which accounts to sort of release, and they did this based on not wanting to disrupt the customer relationship, right? So if they felt like the AE had a strong relationship with the customer, they’d want to make sure that that continuity was there and so on. So, as part of the data exercise up front, we would get this list of accounts that we can pull out of territories and kind of create new territories from.

Bala: So as the territories got smaller and smaller, the impact of, let’s say, bad data, it was pretty huge, right? So you could end up pulling out an account of a sizable potential out of somebody’s territory, and that could totally destroy their moneymaking –

Sean: Their year. Yeah.

Bala: Yeah, exactly. And so-

Sean: I love that you, though, even with the scale that you’re at, are still putting that customer at the center of this entire process, right? There’s process for everything, but the fact that you still have that customer relationship at the center of that is amazing to me. And when you think about like, I think one of the trends that we have talked about in the way that you approach things is you approach it from this kind of architect mentality, and I think one of the things that can be really difficult for folks that are inside of these companies that are in hypergrowth are, one of the things that can be difficult is balancing solving for the problem that’s in front of you right now and planning for the problems that are going to exist tomorrow. How do you think about that? I think the planning for 30% smaller territories is a great example of that. Like how do you balance that all while going through that rapid growth?

Bala: I mean, I think one of the philosophies that everybody at the top leadership kind of subscribed to, as you said, is that the customer experience has to be the center of what we did. And that’s not just from the interaction that the customer-facing roles had with the customer, but also what we did from a process perspective to not disrupt that.

Bala: For a growing company like Salesforce was at that point, if you just kept changing reps around every year, you’re not going to build continued relationships, and especially that was bad for mid-market and enterprise accounts where you needed that 18 month runway to close a deal, right? 12 to 18 month runway to close a deal. So you can’t yank people out and put other people in, and so from a process perspective, it would have been easier for us to optimize for the operations process, but we always kind of looked at two things prior to doing that. One is the customer experience, and the other thing is really the sales team flexibility, right? The way that … We strongly believe that the flexibility that we give our frontline managers in terms of how they manage their business was a competitive advantage compared to other companies, and because they had that-

Sean: Interesting, can you give me an example?

Bala: An example would be being sensitive to what’s going on in a particular region in terms of business, in terms of competition, in terms of partners that are available. So the managers really needed also flexibility on how they allocated the resources. Right? If you had people that were performing well, people that were not performing well, how do you make sure your deals are still progressing while dealing with the challenges of managing a team? We could have been, from a sales operations perspective, rigid and said, “No, you don’t get any flexibility. This is the territory allocated to this person, and that’s the only thing that they can work on,” or you give the managers the flexibility to kind of deal with day-to-day stuff that happens in the course of running your business.

Sean: Let’s face it, everything looks good on paper. The plan always looks great before you have to actually execute on it. While I’m sure Bala and his team believed in their plan, he more strongly believed that the flexibility they gave their frontline managers was a competitive advantage to the team at Salesforce. I was thinking about it, and I think Bala is the first guest we’ve had who has pointed out that the specific practices of his team were a competitive advantage to his company. Not a feature, not a price, but the operations team itself was the competitive advantage. That’s pretty cool.

By the way, did you catch that Bala said this rollout process used to take up to two months? He said that sometimes during this murky transition time at the beginning of a year, they literally used a policy called Sell What You See, which basically means if it’s in your name in Salesforce, go after it. He called this period of time after the initial rollout the aftershocks.

Bala: Once the rollout happened, then we had what I would call aftershocks, right? And so this is we were looking to hire managers in certain regions, so the planning would have to be done by their manager or somebody else in Q4, and so when you finally hire that person in January or February when the fiscal starts, they look at the plans that were created and go, “Oh, no, no, no. This is not how I want to do it. I want to rearrange everything,” right? So we literally dealt with a series of aftershocks.

Once the territories were communicated, of course people disagreed with the accounts that they lost or opportunities or the holdouts that were given to them, so my operations team, which was about 28 people, and they kind of dealt with all of the day in day out data problems and also just arguments around territories. It’s a, “Hey, this account could be mine-”

Sean: Rules of engagement, yup.

Bala: Exactly. Exactly. And believe it or not, at the time that I started, that wasn’t codified into a policy.

Sean: Interesting.

Bala: It was more of an operational document that the ops team operated, so one of my first things to do was actually to make a case to hire a person responsible for sales policies and put that person outside of my team. From a separation of duty standpoint, I didn’t want my team to be the one writing the rules and executing it. Right.

Sean: So this policy person was like Switzerland. It was their job to come up with these policies-

Bala: That’s right.

Sean: … absent of any bias.

Bala: That’s right, that’s right. That’s correct. Yeah. And it was more of a strategy thing, right? And so coming up with this required coordinating across the sales leadership, getting approvals, like what kind of things can we do? What kind of things can’t we do? For instance, a simple thing around splits, how do you handle splits on an international deal, right? Or how do you handle [inaudible 00:27:47] and acquisitions throughout the year? What this meant was if a company was acquired by another one, do you take it out of one person’s territory and put it to where the acquiring company was, or do you let it sit like that until we go through next year? And we decided to take the changes next year.

So these were all policy decisions that had to be made, and those were all written down, and even to the point where changes in employee count that would cross a segment line, for instance, when do you take that change? Do you take that change middle of the year or do you wait for next year to kind of effect that change? And so the stability of the … Yeah.

Sean: I was just going to say, I can’t tell you how good it makes me feel to know that Salesforce at 1,500 reps didn’t have this stuff figured out. For those of us that are like in the trenches every single day figuring these things out, it makes you feel good that the companies that you aspire to be like also faced the exact same problems.

Bala: Exactly. Exactly. And you’ll be surprised, all the bad data issues, how to handle bad data. Like, what is defined as a duplicate, right? Even to that level, those things had to be codified into policies, and then what happens is that once you codify something into policy, that becomes sort of the standard operating model. You are no longer running your business on exceptions. Right? And Salesforce was very famous for this in the sense that we had a ticketing process and anybody could submit a ticket to have something looked at. And my team for 4,500 reps throughout the year, we process about 23,000 tickets.

Sean: Wow.

Bala: Just think about that. And this would be data issues, this would be, “Hey, here’s a subsidiary that should be linked to a company that I own in my territory, but it’s not linked,” kind of those kinds of requests, and this was all international stuff, was really hard to really catch that up front. And all the way up to, “Hey, manager, I want to reorganize my …” An RVP saying, “I want to reorganize my territories because I have a mismatch in the skillset of the person working on that territory.” Right? So, all of those kinds of issues, we would process them as tickets, but what made life easier is when you have those codified as policies, we could actually turn away 30% of those tickets because they were not according to policy.

Sean: Yeah. No way you were able to process that volume without some sort of reference point.

Bala: That’s right. And the side effect of course, of writing down these policies, is that now you can automate it. Right? And so that’s really where we engaged. We had a two dedicated scrum teams to help my team, and we had some of our leadership go fight for budget, and we had a three year program that was really about improving the automation around a lot of these things. All of the automation was done based on the policies that have been documented because now it becomes repeatable, and that’s really the secret sauce is really, if you can make it repeatable, then you can automate it. If you can automate it, then you can scale, and that’s really the learning for me.

Sean: Yeah, of course. And the process that you originally described with 400 people, and I think you originally told me 1,500 different spreadsheets, what does that look like in the after picture once you’ve added some of this automation and scalability to the process?

Bala: Yeah, so we built a system, customized, custom-built on Salesforce within Salesforce, to really be the planning platform. And so we built an environment that would suck data from our transactional runtime system into this org that basically contained data for planning, and we would enable a sync between the two on a periodic basis. But the idea was then all of the planners were working off of the same set of data, right? So you’re not dealing with copies of data, but you’re all looking at the same data at the same time. So when people move things around, you would see that in the system as opposed to on your spreadsheet thing.

So that kind of reduced a lot of the semantic issues that we dealt with, even just definitional issues that we dealt with. Right? Like what is the definition of this segment here versus in another region? In Europe, the mid-market could be from employee range this to this versus in the U.S. that would be much smaller, right? So those kinds of definitional challenges were also easier to deal with now that you had one place that you’re putting everything into.

Sean: Right, they’re all systematized.

Bala: That’s right. And in addition to that, we also had not just the people that were carving the territories, but as I mentioned, you also have the employee success team that’s now … or the HR team that’s actually working on, who do we promote into what roles, and how many people do we need to go hire? What’s the pipeline for that look like? All of that data was also now being put into the same place, which allowed us to sort of compare and contrast kind of the territory structure we were building with the people that would go into them. Right? That allowed for a much simpler process in terms of planning, and we didn’t have people whose sole jobs was to put spreadsheets back. They could do much more higher value stuff like analyze this data and provide suggestions. Right?

Sean: And I would assume that would’ve made it more transparent too, right?

Bala: It did. It did. Now, that transparency also has its challenges, right? Because when you expose a lot of the planning data to even people at the frontline level, there could be adverse reactions to the current year sales, right? So if you know that you’re going to lose these bunch of accounts next year, you probably won’t invest time in. And so we had to be careful about when we revealed what to what level of the organization.

The best part of course, at the end of this, is that we could just sync the data from this planned environment into our live production system, right? And so that process of pushing the data out no longer involved running data loader on like 15, 20 machines at the same time, to now more of an integrated process where the data would naturally flow from this central environment into the production environment.

Sean: Bala’s secret sauce: If you can make it repeatable, then you can automate it. If you can automate it, then you can scale. By the way, for the record, in Bala’s final planning cycle at Salesforce, after three years of tweaks and improvements to the planning process and to creating this centralized system, for the first time in company history, territories were delivered to all of the reps before their annual kickoff. Not two months later. No more aftershocks.

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?

Bala: I’m not a great reader, but one that I read is the Learnings from a Sheep Dog. I actually don’t know who the author is to be honest.

Sean: Learnings from a Sheep Dog. What’s it about?

Bala: It’s basically about the way that a sheepdog approaches what they’re supposed to be doing and things about loyalty and structure and so on. Yeah.

Sean: Cool. I’ll have to check it out. Favorite part about working in ops?

Bala: I think just the variety of challenges. No two days are the same. And especially if you are inclined to problem solving, this is a great place to be because everyday you face a different challenge. As you can tell, even in a smaller organization, you face the same type of challenges that a large organization would face, just that the scale is different, right? But there’s always a lot of troubleshooting.

Sean: Least favorite part about working in ops?

Bala: Late nights, especially when those timeframes come up for rolling out stuff where you’re responsible for production success of the business, right? So those are not really fun, but those are an inherent part of what you need to do.

Sean: I can sense a lot of people listening nodding their heads on that one. Someone who impacted you getting the job you have today?

Bala: The job I have today is, I would have to say my partner, Dharmesh Singh, and we kind of looked at this whole problem and had Vulcan mind meld on if we could do this, and really bring all of our learnings across. You know, I’ve known him for 13 plus years across Microsoft and Salesforce, so we kind of went, “Oh, my God, this is a pain that we can really solve and bring it down to the mid-market who can’t afford to throw resources at this.”

Sean: Yeah, I love that I can take all the pain points you just described over the time we’ve been talking and draw a straight line to the work you guys are doing at Fullcast. It’s amazing. One piece of advice for people who want to have your job someday?

Bala: I think you kind of alluded to it. I believe that you have to think about the longterm, but you also have to balance that with solving something for the short term. Everything that you pick up is not as easy as it seems right away, and so just kind of building that mentality of, how do we think about this in the long term? How do we think about it for scale? Especially in ops, I think that’s the most important thing.

I had a boss of mine who used to say that, you know, “Solve the process first before you solve the problem.” For me, that’s just the thinking that, from an ops perspective … Like, you take a job like you’re responsible for deduping and cleaning up data. Well, you could be doing that forever, unless you figure out how to turn off the faucet that’s throwing in the bad data. Right? So you know, always think about it from that standpoint I think to scale longterm. If you ask those questions, then I think it will reveal a whole new interesting side to ops that you will find very exciting.

Sean: Thank you so much to Bala for joining us on today’s show and giving us that step by step framework for how to build an operating plan. By the way, as we mentioned, Bala now is the co-founder of Fullcast.io, where they’re building software to help link that sales planning process to operational execution, so go ahead and check them out. Thanks so much for everybody for tuning in and listening. Leave us a six star review on Apple Podcasts if you’re enjoying the show. If you have some feedback for Bala or for myself, you can tweet at me, @Seany_Biz. Leave me a message on LinkedIn. That’s going to do it for us for this week. We’ll see you next time.

Related Stories

P.S. Join 20,000 of your peers. Subscribe to the newsletter for hypergrowth.

Every Sunday evening we'll send you a roundup of the best content and events from Drift and around the web. Make sure you're ready for the week! Subscribe now.

Subscribe Here