Bala Balabaskaran
===
[00:00:00]
Sean Lane: Hey everyone, welcome to Operations, the show where we look under the hood of companies in hypergrowth. My name is Sean Lane. Normally around this time of year, operators are entering their planning seasons. We're all starting to piece together a laundry list of tasks that we need to accomplish before the calendar or the fiscal year turns over.
So, as a result, I also, at this time of year, usually replay one of our earliest episodes of this show from 2019 that's all about annual planning with the man who helped build the annual planning process back at Salesforce. Bala Balabaskaran. But this year Bala and I both agreed it was time for a refresh because the planning function in RevOps has changed and the tools available to us have changed as well.
Today, Bala is leading the charge in this front as the co founder and CTO of Fullcast, the revenue operations planning platform. After spending his career at companies like Salesforce, Microsoft, and HP, [00:01:00] Bala is unique because he brings a product perspective to operations problems. In our conversation, he teaches me about the five Cs, why you need RevOps policies.
We talk about the difference between workflows and policies. And he teaches me why annual planning is no longer a big one time event. Let's address this word policies though to start. Which is at the heart of the work that Bala and his team at Fullcast are doing. When you first hear policies, it can carry negative connotations, or it can signal the baggage of bigger, slower organizations.
After this conversation though, I think you'll think about policies differently. So, to start, what exactly does Bala mean when he says,
Bala Balabaskaran: Yeah, typically we sort of think of them as rules of the road, right? So in terms of making sure a RevOps organization runs smoothly, you have to have certain [00:02:00] common patterns or procedures, processes, whatever you want to call them.
Typically what happens is these things get written up in a policy document of sorts that nobody reads, but that's the idea. It's a common set of rules on how to engage internally as well as engage with customers and so on. Yeah, that's kind of what we think of. It's a broad definition of policies, but, and maybe incorporates a little bit more than what people are used to in terms of the word policy because.
Usually you think of some security policy or something like that, but for us, it's a little bit broader encapsulating like everything you do in a DevOps organization. And I'm
Sean Lane: certainly a believer, but to your point of like people not actually ever reading or going through these things after you put all this work into place, like Why are they important?
Like, why do you even need to have them if you're going to put all this work in and then no one's ever going to read them? Right, right.
Bala Balabaskaran: So we think of them as the five C's now, you know, I stayed up late one night and put them into five C's, but typically they are [00:03:00] kind of the same few core concepts. The first one is consistency.
So if you can get an organization to repeat something consistently, then you have the ability to write it down and automate it. And thereby scale it, right? And so I think that's the natural progression of things in organization that's maturing is you want the processes, the procedures, the policies to sort of be something that you can write down.
Everybody understands it. They repeat it consistently. And those things are perfect candidates for automation. And you need automation to scale. So I think consistency is kind of the one of the core reasons why you'd want to spend the time to write things down. The second thing I think which gets forgot quite a bit is the customer experience.
Like how does the customer experience your organization working with your people in what context and how can they expect that consistency with your organization? Right. And so it's [00:04:00] important for the organization to remain consistent. But a key effect of that is your customers actually experience you as an organization consistently.
And so policies become an important part of establishing that. So that's the second C, which is customer experience. The 3rd is, uh, in my mind, uh, coaching. So how do you train people? How do you develop them? How do you make it easy for people coming into the organization to sort of understand? Okay, this is how things work.
And so if you have things written down, obviously, it's very easy to sort of coach and train and develop, but also measure performance against. So if you have policies written up in a nice way, you can say when policies were followed and when they're not followed. And how do you measure the performance of an organization against those rule set?
Okay. The other C is compliance. So this is where you have a number of either regulatory or, you know, industry specific compliance requirements, [00:05:00] and it's important to write the rules down so that everybody knows what needs to be followed. And typically things like GDPR or trade embargoes or, you know, there's Quite a lot HIPAA and a bunch of other rules, depending on which industry you're in.
So those policies then determine how, as an organization, you stay compliant with those rule sets that you have to follow by. The other C is conflict resolution. So typically, you would go to policies to sort of say, okay, which way should something be done? And so if you have policies written up, it's easier to use it as a way to resolve conflicts within the organization without it even becoming a thing.
You know, people would naturally say, okay, let me go look at the policy, see what it says. And you can resolve problems a lot easier if you have them written down. The last C is competitive advantage. And I think when you have a streamlined process, when you have a rev ops organization, that's sort of [00:06:00] executing consistently, then I think that becomes a competitive advantage to you as an organization, right?
Against your competitors who may be disorganized in that. And your customers expect, you know, that consistency from you. If they don't see it with your competitors, then obviously you'll have a big advantage. So that's the reasons why you would do it and why it's important. And why, you know, us as RevOps professionals spend quite a lot of time talking about it and why you need to write it down
Sean Lane: instead of just accepting the negative connotation that can come with the word policy, Bala and the team at Fullcast are clearly articulating the business case of this work for the rest of us to recap Bala's five C's of why you need these policies are.
One, consistency, two, customer experience, three, coaching, four, compliance, and five, conflict resolution. And as a bonus, he's teaching all of us that these five C's lead to a [00:07:00] real business outcome, competitive advantage. Your internal customers might not naturally buy that a RebOps policy for holdovers or lead distribution could be a competitive advantage for your sales team.
So, what's the best way to make that argument real for people? Here's Bala.
Bala Balabaskaran: Yeah, I'll talk about an example, actually, which is probably a better way to, to kind of illustrate the point. You know, we have territory rules and, uh, territory rules defined around, uh, geography, around industries and, and invariably you get conflicts around that, right?
You know, you, you pick up an account and you go, Hey, is this account financial services or is this account healthcare? Which team does it belong to if they sell healthcare plans? Insurance. So, you know, these kinds of things come up all the time and, you know, you could have a policy that says, Hey, we haven't written it down.
So somebody in the organization is going to figure this out and make an arbitrary decision, etcetera. Well, that's [00:08:00] what the customer is still waiting on somebody to talk to them. Right. Why you're trying to figure all this stuff out internally. So having it written down means that you can respond to the customer faster.
You're not making the customer wait. You're putting the right person from the organization to address the needs of the customer. So that all happens really Quickly, and that makes you competitive. And that, by the way, is a real life example that we've run into, uh, with those kinds of situations, right? Or trade embargoes or, uh, you know, HIPAA rules or GDPR rules, you name it, right?
These things, if you haven't got it written down, it takes time for people to figure it out and resolve it internally, which then leads to a bad customer experience at the end of the day. So. Hopefully, that answers the question you were asking.
Sean Lane: Yeah, and the thing I appreciate about that example is it shows how all of the different five C's kind of tie in with one another, right?
And like, so, in that example, I think of consistency because it [00:09:00] removes the subjectivity of the party who's asked to answer that question, and it also removes the variability of the next time that question pops up. You know, that person I'm having a bad day. I don't like the rep on the thin side. So I'm going with the healthcare rep because you know what, the other one's been a pain to me the last six months.
Right. So you remove all of that subjectivity. You mentioned a big part of consistency is you kind of reach this tipping point where Nanette becomes time. Hey, we've written all this stuff down. It's obvious to us now that there's an opportunity to start to automate this. Can you talk a little bit about kind of when that tipping point occurs?
Cause I would imagine once you've spent all this time documenting these policies at a certain point, it becomes time to start to automate the. Adherence or kind of the outcomes that these policies are meant to drive. Typically,
Bala Balabaskaran: I think you reach that point under the organization for different processes at different points in the organization, right?
So let's take a simple example, like routing, like lead [00:10:00] routing, right? So you could have a model where, as you're a very small organization, you want to let the managers decide who to give it to based on workload, all that kind of stuff, which is very natural as a very small organization to do that, right?
So in that case, the policy is the. Manager decides that's a valid policy, but at some point that workload becomes increasingly difficult for the manager to handle. And the result of that is that the customer is getting impacted and your business is getting impacted by that. That is a natural thing to sort of look at and say, well, if we automate it, then, you know, we can reduce the time it takes for our team to respond to a customer.
And it takes the manager out of doing things that perhaps is not scalable. So I think for different scenarios, you will reach that point at different part, you know, levels of the organization in terms of maturity. The other example on the other end that I might take is holdouts, right? Holdouts or holdovers, which is not something a small organization will have to deal with, you [00:11:00] know, for quite some time.
But when you get to a point where there is a lot of transitions of people and organization, uh, territories and things like that, it becomes a burden for the sales ops team where somebody is spending time moving opportunities and records back and forth and so on. So in those kinds of situations, it makes sense to automate, to sort of optimize and reduce the impact on the team.
So that's sort of the way I think about that. The
Sean Lane: other thing I appreciate about the routing example is like you mentioned earlier that sometimes people might have kind of a negative knee jerk reaction to the word policy and like routing absolutely falls into the bucket of stuff that we're talking about, but probably isn't something that people would naturally associate with being a quote policy, right?
It's like, Hey, we have to have routing in order to provide a good customer experience. And so I think I would imagine you all are also kind of expanding. People's definition of what they originally think of when you say
Bala Balabaskaran: policies we do. And I think there's an important [00:12:00] breakdown of taking something like routing and there's an important breakdown that we have sort of come upon as part of building the product and automating what we do is that there is a separation between workflow.
And policy, what we're calling policy, right? The act of actually routing record to a person is a simple workflow. That doesn't change, right? What changes is the inputs from a go to market perspective on why it needs to be routed to a specific individual, right? And that's the part that's quite volatile, right?
Because as you change go to market organization, as you decide to roll out a new program, as you decide to do this, you will change the policy. The workflow kind of stays the same, right? Irrespective, the inputs into the workflow kind of stays the same. What we find in a lot of automation is those two things tend to be hard coded with each other, right?
So you might write a an apex class or something on your salesforce instance that says, if postal code equals [00:13:00] blog, go send it to this person. Well, what you've done is you basically hard coded workflow and policy into the same automation. And every time the go to market changes, right? Now you have a much harder time going and undoing that in your automation and takes time and becomes inflexible and so on.
So we sort of take a separation between those two things and say there's workflows associated with routing with holdovers with whatever else you can think of, right? All of those things are fairly static. The input coming into them is going to be determined by your go to market. And when you build your go to market, you also define the rules of the road.
It says, okay, in these postal codes belong to this territory. Well, that's dynamic, but that's an input into the workflow so that you can actually execute for the organization and policies change all the time. They evolve all the time. And when you're building workflows, you want to be careful to maintain that separation.
Sean Lane: I love this distinction between workflows and [00:14:00] policies. Bala is saying that the workflows, for example, the act of actually routing the leads, these do not change once you've built them. The policies, on the other hand, are dynamic and use different inputs from your go to market based on the needs or strategic priorities of the business at that given moment in time.
I've definitely been guilty of pairing these two things together in a single process or system that I've built. If you're hard coding certain names of people or certain territories or products or geos into your workflows, you're setting yourself up for painful unbundling later when your go to market approach inevitably changes.
By separating the definition of these two distinct types of work. Bala says that you're not only making your rev ops team more nimble, but you're also aligning the work to the internal structure of the company and the different roles within that company. So it's
Bala Balabaskaran: interesting. Within a larger organization, [00:15:00] those two things actually fall under different organizations in large setups because if you think about the workflow, That's a Salesforce developer.
That's a Salesforce admin. That's somebody that's building out the workflow, putting it into Salesforce. The policies are your sales strategy folks, right? And people that are looking at the organization and the go to market and saying, Oh, what if we can change this and move this around? Day to day workflow, day to day business of running sales requires you to change things and move things around and whatnot.
So it's, in fact, actually two different organizations for me that handle the two aspects of what we're talking about here, policy versus the workflow. And if you have to rely on an IT organization, given that they're supporting an entire company and they have their own backlog of things, And if you have to go back to them, every time you change the rep on a territory, or every time you change an account in a territory or the go to market definition, their backlog becomes [00:16:00] something of a bottleneck for you to respond to the market.
And we've seen that quite a lot of times where, you know, the lead routing rules need to be adjusted. It's in the I. T. Backlog. It takes about two months to get I. T. Resources to go do it. In the meantime, the routing is sending it to the wrong place. And then the manager jumps on and reroutes it. So now the manager is wasting their time.
Everybody you can see the follow on impact of something like that of not doing that separation. Right? And so if you think about it, you automated in that way, you. You can change, you want your sales ops people, you want your revenue ops people to go in and change the policy anytime they want to respond to the market.
Doesn't require code change in your Salesforce instance, right? So that's kind of the way to, I think, distinguish
Sean Lane: it. And, you know, let's assume for a second that people are able to pull off that split, right? Like you've got the workflows, they're largely in place. You still have to your point, like a pretty [00:17:00] dynamic set of inputs on the policy side that based on market conditions or new products, or, you know, people are being hired or people leaving the business, like just changes all the time, right?
And so I always think it's funny when people are like, yeah, like we just went through our planning process and then we started the year and like, now we're done. It's like, wait, wait a second, like every single time somebody gets promoted, there's a ripple effect of stuff that needs to happen. So how do you coach people through the fact that even if you have that beautiful split in place, there's still so much work to be done all the time on managing the policies and the inputs that drive those policies.
It's easy for
Bala Balabaskaran: us because we don't have to tell them because they live it, right? The reality is that that happens whether you like it or not, right? And sales ops teams typically are buried with these kinds of requests day to day. They wake up and look at the inbox and the inbox is full of these kinds of requests.
Like, can you move this rep from here to here? Can you move this account from here to here? Or by the way, the data on this account [00:18:00] is not correct. And so, you know, they live it. So we don't have to explain that it's a problem. We just point to their inbox and say, look, look at what you're doing there, right?
And what if you can automate and cut all that stuff out? Are you doing that because of this, you haven't made that fundamental separation, allowing you to be more dynamic and flexible. And so if you automate things, right, all it is, is just going in, in a UI and changing the wrap or going through a workflow and changing the rep and everything else would sort of.
Follow, right? Because we managed to do that separation. So that's the basis of kind of what forecast is about and so on. And by the way, we didn't invent it. You know, a lot of us coming from software development background. This is what DevOps did, you know, when they separated the infrastructure and the policies that run that infrastructure.
And so now what you can do is describe those policies in a machine readable format that the developer builds when they're building code. So that the operations people don't have to figure [00:19:00] out. How does this thing run? How does this thing work? How do I scale this thing? Right? So it's a model that's worked really, really well in development and software development.
And so all we did was extend that idea up into the business realm, into the rev ops realm to say, can we take the things that are dynamic that are typically policies? Turn them into machine readable format so you can change them anytime and provide them as inputs into your workflow, right? And that sort of creates that separation naturally allowing you to be more flexible.
Sean Lane: This episode is sponsored by
Fullcast, the right sellers on the right opportunities, making them unstoppable. And the cherry on top. Full cast automates common go to market activities like territory, rebalancing account hierarchies, routing, and more. So the plan is always in sync with operations with full cast, say goodbye to go to market planning headaches [00:20:00] and hello to your own personal planning assistant.
Learn more about full cast today by visiting full cast. Okay, back to Bala. Before the break, Bala was explaining that his approach to building software for revenue operations teams is no different than the approach that has long existed within product and engineering teams themselves. And I've heard this guidance before, that an ops team should serve as the product manager's Of the company itself.
Bala is taking it a step further. He's actually taking the same approach for tools that have become available to developers for making it easier for them to build their products, and applying that approach to building software for RevOps teams. Which got me thinking, why is this not commonplace? There are whole industries around alerting and observability to make products more reliable and easier to update for those teams.
Why are ops and revenue producing teams so far [00:21:00] behind our product and engineering counterparts? In this approach, well,
Bala Balabaskaran: I think there's a couple of things and, you know, we sort of call it internally the industrialization of sales over the last 10 years, right? With with the SDR model and kind of how that works.
So what we've seen is that transaction pipeline has gotten automation all the way from marketing automation through to SDR automation and so on and so forth. So, but it took its time getting to the back office. Right. And so we're far behind because we're getting overwhelmed by all the data, all the efficiency, all of that stuff that's getting driven in the, in the front of that transaction cycle that the back office kind of have to catch up to.
And the other aspect of this is typically this role, this sort of function has remained siloed between marketing, sales and customer success. And each of those organizations sort of looked at this as a spreadsheet and elbow grease problem. [00:22:00] Right. You add more people, just add hire more, you know, analyst and let them go figure it out on a spreadsheet.
And we're realizing that at some point with all the automation driving the front end of it, that doesn't scale. And I think that's what's driving sort of this newfound automation from a rev ops standpoint is okay. We've got to catch up. We've got to have the back office be as as flexible and as responsive to the changes in the transaction cycle.
Right. When I say transaction cycle, I mean the process. The process of, you know, attracting a customer to completing the sale and renewal and all that. Right. So when I think about RevOps, it's the back office for all of that to happen.
Sean Lane: And like, I want to make sure we drill home for folks, kind of the distinction that you're making, which is like, I'm not sure that what the world you're describing necessarily means that you need to have all of a sudden, like all of these wildly technical RevOps folks.
Right. It's more. The tools in their kit that are available to them to do their job. So they were doing more high value work [00:23:00] and less of that spreadsheet scrubbing. That's correct.
Bala Balabaskaran: And I think the interesting thing here is that the technology that's out there now in the rev ops phase is something that you have to be careful and thoughtful.
In how you employ because what I hear from a lot of people is that they have tools for team. They have bought so many tools that their job basically transition from handling all this in spreadsheets to basically. Manually integrating these tools that they're bought. And so the workload simply shifted to somewhere else, but it didn't really solve the problem at the end of the day.
Right? So that's an important thing to consider as you are maturing the organization. And as you're building this really put some thought into how RebOps should scale. And how it's actually going to help you rather than just buying point solutions for every little thing along the way. Like you could buy a tool for routing, you could buy a tool for data, you could buy a tool for [00:24:00] this or that.
And then all of a sudden you have 20 tools that need to be modified in order to make a change to a go to market. In fact, my favorite quote is we talked to a customer who said, well, we need to change the go to market model because whatever we have is not working. But IT just told me I can't do that because all of our dashboards are built a certain way.
And if we change the go to market model, the dashboards aren't going to work. That's sort of, uh,
Sean Lane: that's an example,
Bala Balabaskaran: you just completely destroy any inertia in the organization for change when you have to deal with that kind of stuff. Right. So it's a thoughtful process. You have to sort of consider the organization, the scale, the maturity and invest in the tools. Your
Sean Lane: back office needs to be as flexible and responsive as your go to market transactions.
That's it. That's the punchline. Your back office needs to be as flexible and responsive as your go to market transactions. I can totally relate to the evolution that Bala is describing here. [00:25:00] It started with operators doing manual work in spreadsheets, Then it shifted to playing connect the dots between a whole bunch of different point solutions in your tech stack.
And now he's suggesting that there's a next and better evolution that we all should be striving for. So what is that new and better future? For me, a huge part of working in ops has always been just knowing what was possible. So I asked Bala, what does the end of his evolution look like for operators?
What's next as we move past, just integrating a bunch of tools together to try to keep our go to market held in one piece.
Bala Balabaskaran: I mean, I think for us, the evolution that we see in our customers is a great kind of story to tell in the sense that, you know, we're used to the big annual planning cycles. We build the models, we deploy it.
It takes weeks to deploy it, and then any change requires another two to four weeks to to make happen. What we see with our customers is that they tend to move away [00:26:00] from this idea of annual planning. Simply because you're not changing your entire go to market model every year. You're really tweaking aspects of the model over time.
So what happens is that now you are a lot more flexible because you have this automation in place to tweak things and have that be deployed into your transactional environment with the click of a button. Right. You can push a button and say, Okay, now I have a new routing model. Now I want a new policy enforced on holdouts in the enterprise space.
Right. You can do that all using click and go as opposed to trying to think of it as a I. T. Project. I have to get done in order to get to that point. So ultimately, what that gives you is that agility to respond right? And really, the benefit that you're getting is Mhm. Okay. You want to change the go to market model.
You want to route leads to a different place. Fantastic. Let me go. It takes me five minutes to make that change. Whenever you're ready, we'll push the button and then things happen, [00:27:00] right? Or even, you know, your sales leader wants to do a sales reorganization. Different people are now reporting to different individuals.
Figure out the effective date, go put the change in, in a nice UI. And on that date, everything switches, right? And that we're talking about, right? In terms of being able to do that with the automation that can drive a lot of those policies.
Sean Lane: And I think that ties nicely back to the competitive advantage point you made at the beginning, right?
Which is like, if anybody's going to knock this model, they're going to say, look, like that's going to be too much change. It's going to be too much thrashing. It's like. Well, wait a second, like you can't have it both ways, right? You can't also say, well, we're too slow for the changes we want to make. And now we're making so many changes that people can't handle it.
So you can find, I think, a balance there to make sure that the change management has done well, the communication has done well, but in this way, the technology or the systems are never going to be the bottleneck and therefore you can be as effective as your actual go to market strategy is, as opposed to as [00:28:00] effective as your systems allow you to be.
That's
Bala Balabaskaran: right. And one of the side effects of doing this is that now you can actually push a lot of this self service onto your sales managers. What I mean by that is not giving them more work. It simply means that instead of them typing up an email and sending it into the sales ops team, they can simply jump on a workflow, make the changes themselves because they know all the answers.
Press good and you're done. Right. And the sales ops team is not even involved in those transactions and a lot of transactions. Right. And that's music to a lot of people's ears. It's like, cause that's your backlog. That's what you deal with, right? The managers are not spending any more time than they need to, but everything is sort of self service so they can actually go get the.
People changes, role changes, termination of people, people coming on, assigning them territories, like all of that stuff can be self service, right? And we do that.[00:29:00]
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. I am terrible
Bala Balabaskaran: at reading, so I'm going to tell you that usually it's manuals or, you know, articles that I read online, but, uh, I'm a terrible reader, so I'm not going to you
Sean Lane: a book.
Oh, good. Oh, good. Just
Bala Balabaskaran: podcasts, yeah. They're wonderful. All
Sean Lane: right. Favorite part about working in ops?
Bala Balabaskaran: I think the challenge is different every day. That's the fun part because it's a, no two organizations are the same. No two problems look the same. So the ability to sort of step back, at least for me in my role in the company, ability to step back and look at all these patterns and say, okay, how can we find something that allows us to automate it and make it track faster?
So that's the, that's for me, the fun part of doing this.
Sean Lane: Least favorite part
Bala Balabaskaran: about working in ops. You know, it's usually the hair on fire type [00:30:00] scenarios, right? And most of that we deal with customers. We see the problem, but they have their first stop sign that they have to complete. It's that what do they call it?
The hippo, the highest person, the highest paid person in the room's opinion. And you know, they're dealing with that very true. And that's a challenge for pretty much all ops
Sean Lane: people. Someone who impacted you getting to the job you have today.
Bala Balabaskaran: I would say Maria Martinez, who was at Salesforce and she hired me into the role.
I was a product guy, so I've never in operations for a big part of my career. She pulled me into this role and now it's been eye opening for me. And, you know, she said, you know, when she hired me at Salesforce, she said, uh, I want a product perspective on this problem, which is why I'm bringing you in. And, uh, that's been, I think, a masterstroke for my career, being able to bring those skillsets together.
So definitely would say that,
Sean Lane: sir. And based on today's conversation, I would say you're still doing that, right? Bringing a product perspective to the, to [00:31:00] the ops problem. Absolutely. All right. Last one, uh, one piece of advice for people who want to have your job someday.
Bala Balabaskaran: You have to step back and think broad.
I think that's the key of it. You can't get pulled into the day to day. Even if you have an ops job, you have to take the time like dedicate the time to step back and look at the problem. Because when you step back and look at it from a distance, you'll observe a lot of things that can be made simple.
And that's usually helped me really well in my career.
Sean Lane: Thanks so much to Bala for joining us on this week's episode of operations. Also a special shout out to Ashley from the full cast team for helping to make the interview happen. If you like what you heard today, make sure you're subscribed to our show. You get a new episode in your feed every Bala's.
Earlier episode. If you want to go back and check that one out. Also, if you learn something from Bala or from any of our episodes today, [00:32:00] please leave us a review on Apple podcasts or wherever you get your podcasts. It really helps other folks to find the show. All right. That's going to do it for me.
Thanks so much for listening. We'll see
Bala Balabaskaran: you
next time.
Sean Lane: Today's episode is sponsored by Fullcast, your go to market planning platform. If you've ever spent hours or days building territory and quota plans only to have them be out of date the second the reps hit the street, you need to check out Fullcast. With Fullcast, you set intelligent rule based policies that automate all of the time consuming manual tasks that hit RevOps teams throughout the year.
With virtually no effort. Operations will always seamlessly align with your plan. Learn more about Fullcast today by visiting Fullcast. io.
Transcript source: Provided by creator in RSS feed: download file