As Go-to-Market plans evolve changes in the field are constant. In this chat, Bala and Dharmesh discuss: Why it is important to stay on top of the changes? Why is it hard to keep the plan in sync with the changes? How do you think of capacity planning as you think about making changes to GTM plan?
[This transcript has been edited for readability]
Dharmesh: We are back with Bala and myself at Fullcast to talk about two things that we've been working on our side and hearing what customers are asking, which is, how should we think about capacity planning and how do we manage coverages? Incidentally, like everything else in sales operations, they are linked, but they're thought of as separate activities. We always talk about the fact that we are a comp platform that helps shorten the go-to-market planning execution cycle for fast growth companies. So, Bala, as you think about the go-to-market planning execution cycle, I think it will be helpful to define what we mean by that loop, because I think that’s key as we think about coverage assignments and capacity.
[01:45] What is the GTM Planning Execution Cycle?
Bala: Typically, your go-to-market plan includes your territory plan, your coverage model, your capacity models and so on. Operationalizing that end-to-end cycle means taking that GTM plan and being able to deploy it quickly into your operational systems, whether that be your CRM or your HR system or whatever the case may be. But that cycle tends to get caught up in a lot of manual intervention, typically by the sales ops teams or by IT, depending on who's responsible for the operational systems.
So that backlog of things that's necessary to operationalize that plan tends to get in the way of being flexible. And so, what we've looked at is how do we simplify that process? How do we make it a push button delivery? Because this notion of deploying a go-to-market plan once a year is basically done. You're planning more often and you're changing your plan more often. And even if you don't intend to change the plan, just the daily business of running sales changes your plan for you, such as people coming in, people leaving roles, new territories accounts, mergers and acquisitions. There are all kinds of activity happening, which changes the composition of your plan throughout the year. You don't want to have a two-to-three-week deployment cycle, every time you need to modify your plan. There are also re-orgs that you might do to better optimize your sales team. Operationalizing that should not take your time, it should be almost instantaneous, so you can respond to the market faster.
A system that governs the rules of what the go-to-market plan is allows the managers to self-service in the context of the plan, or at least understand the impact of the changes that they're making. So, if you move territories around, if you move accounts around, what's the impact to capacity, what's the impact to quota, what's the impact to the comp plan. These are all things that are related but often thought of as silos. But if your sales quota is based on your territories, that has implications on the comp plan that has implications on your capacity models.
It's something that has to be thought of holistically, so you really need a system to put in those guidelines of the go-to-market plan and then allow managers to sort of be more self-sufficient in those changes. And so they don't have to wait multiple weeks for the ops teams to get to their backlog of tickets or the IT team to get to the backlog of tickets before they're able to get there, to see their change in the system.
[6:45] What is involved in managing coverage assignments? And what are the different ways that organizations manage coverage?
Dharmesh: So, when you think about coverage assignments, what are the kinds of things that fall under the umbrella of coverage assignments, managing coverage?
Bala: Coverage means, simply, you're looking to see whether the different roles that you have within the sales organization are available to cover accounts. And so, that could be a team of people, a sales account executive, a sales engineer, a product specialist, etc., that would work together on a deal. Depending on the type of account, sometimes coverage may simply be defined as a pool of people that will cover the SMB market.
Ideally, what you're trying to do is make sure that the customers or prospects in your different accounts have appropriate sales resources assigned to cover any sort of interaction that you might have with that customer. And so the number one priority is optimizing for the customer relationship and the customer experience.
Dharmesh: Hold on to that thought of least cost, I think I want to touch on that when you we talk about capacity planning. But the best customer experience today, so that alone itself like keeps most ops people really busy. We we've seen this in our past, right, managers are basically, it's a loudest guy who wins, "Oh, I need this account moved or this is in the wrong place," because he's seen so many cases where reps would be selling on a batch only to fall into another rep who's selling into the same batch.
Dharmesh: That is the worst thing they can do, or you can have your stellar rep managing a batch with the lowest potential. All those issues that are tied to managing coverage, how have you seen people handling them in the past? You ran the team at Salesforce, I'd love to sort of understand: What were their issues? How are we solving for them?
Bala: Yeah. I think most people, when they think about the type of resources that you need to have, you know you have different types of roles that, of course the larger the organization gets the most specialized to some of these roles become. So, verticalize and you have specialists in the financial sector or healthcare or government that understand how to sell your products into those verticals. You have product specialists, if it's a deeply technical sale, that kind of a thing, so the roles tend to sort of evolve as you identify deficiencies in the selling process. That's something that clearly would help enhance the customer experience, the buying experience or the journey that the customer has with your organization.
However, these specialist resources typically tend to be fewer in number compared to your traditional sales reps. And so, then it becomes a question of how do you deploy these resources in an effective way? How do you deploy them so that you have the maximum potential for success when you do deploy those resources? And so, people have used a number of aspects, but typically what I've seen is they tend to be driven by deal parameters. They might say, if you have a million dollar plus deal, then yeah, you can bring in a product specialist and you can bring in an ACE and so on. And that's where, unless you have sort of clearly defined rules, what tends to happen is that the person yelling the loudest from a sales perspective will get most of the support. And then all of a sudden, you're out of capacity for supporting the really important deals. It's important to sort of always analyze, kind of where deploying these resources is producing the best productivity for you in terms of deal conversions and things like that, so that you can optimize where you can put these resources.
Dharmesh: How will they be doing that? Like that work of managing, deploying, as I break them down, they're a couple of things. One, great request intake coming in from that, like who initiates the request, who manages to fulfill the request? How does it actually get fulfilled? Did we have dependencies on making things move? What happens when that person is leaving? Do we see the ops guys doing it? Do we think the managers should be able to do that? Just like figuring out that account moves into. We thought it was like a time suck for most ops guys.
Bala: It is. I mean, we had a pretty large ops team when I was running the team at Salesforce that was simply dealing with these kinds of moves that changes, kind of requests coming in. And they're pretty constant for a large enough sales organization, there's quite a bit of movement in people. There are people leaving, people coming in, you're hiring new people and all of that kind of stuff. And ultimately it kind of gets to what I would say is the maturity of the sales ops team. And what I mean by maturity is, if you have defined policies on how things should be done, if there are rules on if a person leaves, then the accounts get assigned to this in this way, the managers can come in and define temporary coverage or whatever the mechanics are that you have set up. If those policies are well-defined and understood, then obviously you can sort of delegate that aspect to the sales managers to sort of do it while at the same time, keeping in line with whatever the goals of your go-to-market plan.
But if you're not mature enough and you do all of these things on a very ad hoc basis. It's like oh, if a manager remembers to do this and this and this task, at the time somebody leaves then yeah, the ops team might know about it and they might solve for it. Or the other situation that was very common in the early phases of my career at Salesforce was, there was a deal made by managers with sales reps and that the ops team never really understood. So, things like effective dating, okay, well, you can be a sales engineer from the beginning of last month because you already doing that job, but we forgot to tell the sales ops team that that was the case, so your comp plans don't reflect that you've been doing that role in a while. So, that's an aspect...
[16:05] What about temporary coverage?
Dharmesh: People leave the company, and people forget to move the accounts over to the new person.
Bala: That's right. Or temporary coverage, so either somebody leaves and you realize they account is inactive in Salesforce, the deals are not coming through, you can assign deals, you can route deals to them. And the ops team finds it out as an exception and then they have to troubleshoot that exception, called the manager and say, "Hey, what happened to this guy?" "Oh, he left." When you get to a sizable organization, it's really, really hard for the ops team to stay on top of things, if you do all of these things in a very ad hoc manner. So that's why policies are important and enforcing policies are important so that you can have a consistent, repeatable process. I think that that really determines who does the work. If you're ad hoc and the policies are not well-defined, then typically the ops teams would shut down access for the managers so that they can keep some sense of sanity in the flow and the process. But if it's more mature enough, the policies are well-defined, then you can start to relegate that control. And more often than not, the managers would be happy to do this and get this stuff done rather than wait for two weeks or three weeks before it's done.
Dharmesh: Yeah. I think we've seen both sides. We've seen people where managers are going in and managing it now because we've been able to sort of codify the policies.
Bala: That's right, yeah.
Dharmesh: That's the other place where, we've codified the policies, but yet the ops team retains control of actually making the moves.
Bala: But interestingly you know, all of those teams that we talk to, because that's a key aspect of our platform, is that self-service idea. But all of those teams that we talked to that retain control today, would love nothing more than to let go.
Dharmesh: Yes. Transition matters for them right now. It's a transition like first, let me get comfortable and get it out before I would like to let go, let the managers manage themselves, get me out of this business of managing, spending my entire day doing what I call is important tasks, but not really urgent tasks. They're like, just do it now, but actually the other way, they're urgent from a rep's perspective or a manager's perspective, but in the overall scheme of the company, they're not really important because they're like, "I've got bigger things to do, but I never get to do the bigger things because I'm stuck doing all of the repetitive type things that need to get done."
Bala: If you've got a million-dollar deal on the way, and you got an opportunity that you cannot close that is pretty important to the organization.
[18:55] What aspects of capacity planning and coverage assignments can be handled by a sales team (vs ops team)?
Dharmesh: The best thing to do is, teach people how to fish. And so when you teach people how to fish, so when you built or started building the platform on our end, how will we be thinking about these things? Because, there is this whole notion of, what are the kinds of things that you've thought that are prime candidates for self-service?
Bala: Yeah. I think there's a few things. One, it definitely is that interconnected nature of things. Changes to territory impacts your coverage, impacts your quota, impacts your comp plans, impacts your permissions that you have within Salesforce and so on. And so, the interconnected nature of this means that when you make a change, it's sort of like a workflow. And the workflow has to go through all of the different stages of analyzing the impact of the change that you are proposing. If for instance, you pull a big account out of an enterprise territory that has three or four accounts, that's a big impact to that territory. And that has to be analyzed in terms of it's called an impact ability for the sales rep to make their money in that segment. So, there's quite a bit of thinking and strategy that goes into, say enterprise accounts. But if you look at an SMB market with thousands of accounts in a zip code, moving around one or two accounts is not a big deal. You probably aren't able to quantify that any way to create a quota based on accounts, so there is a lot of impact.
So, even by segment within the same company, the same operation can actually have a whole lot of dependencies and impacts that you have to understand and analyze. And so, that is sort of critical in the platform for us, is because that process of operationalizing the go-to-market plan means that we have to also have all of these workflows for it moves. There are changes that then allows the sales manager or the sales ops team to understand the impacts of the change that they're making.
Dharmesh: When I think about the workflows, we're talking about effective dating?
Bala: Effective dating is absolutely one of those things, yep. And when we talk about workflows, we just take a simple situation of somebody leaving the business. Our sales rep is leaving the business, the territory now needs to have some sort of coverage. What do you do with the open opportunities? What do you do with the accounts? Who do they need to get assigned to so that you don't screw up forecasting in the application in Salesforce? So those are all elements that you have to think through.
Dharmesh: What about the fact that I am moving the accounts but do not want move this account because I have an active opportunity in that place.
Bala: And so, all of those, like moves are changes in terms of people, in terms of accounts, in terms of territories, in terms of reorganization, in terms of manager hierarchy, manager crediting, all of these things are interrelated. So, a rep may be fine then...
Dharmesh: Think of one of them like this, as you think of the workflows in the scenario that you've spoke about, those are things that you're talking about effective dating, you're talking about tracking relief, you've talking about coverage assignments like temporary, permanent, moving accounts or hold backs. Or somebody might say people call them, hold backs, some people are different other nomenclatures, but basically holding back opportunities that happen, that are in flight with the original guy while transitioning. So all that stuff, that's a lot of busy work. How many people did we have at Salesforce just doing that?
Bala: When I left and this was a while back, it was about 20, 28 people that we had doing that. And so it does require a sizable, depending on scale, it does require, and it does take up a sizable amount of the ops teams capacity.
Dharmesh: It's not just the ops team because it's also the IT support...
Bala: We also needed IT support, so it goes into a backlog with IT in some cases where the infrastructure is not hard-coded. In most cases, I think one of the other big aspects of the platform that we did was to separate the parameters that would come in from a go-to-market plan, like your segments, your coverage, you’re all of that stuff, from the actual workflow. So, your holdout workflow is essentially the same or hold back workflows, essentially the same in whatever segment that you're in. But based on segment, the number of days that you have would be different. So, enterprises have longer sales cycles, so you want to give them more time to close the deal. This is an SMB that might be much more of a transactional sale. So even within the same company, the parameters that are given to the workflow around holdbacks is dependent on your go-to-market plan.
[24:15] What problems can arise with manually implementing GTM plans?
Bala: And so, that is one of the key sort of fundamental architectural thing that we did in the platform is to separate the workflow from the parameters that come from your go-to-market plan.
Dharmesh: I think that's super important because I was like, in fact, I was talking to one CIO of a publicly traded company. When we were explaining to him how we think this has traditionally been done in the past, adding more people, looking for support from IT, or just tracking stuff in Excel sheets. And managers individually basically tracking in their Excel sheets to how we would be thinking about automating this into it. And he was like, "Oh, now I can see how I'm going to add value to my sales counterparts now. Quite honestly, it was selfish, I didn't want my IT guys just doing this break-fix stuff, he considered of break-fix and not really adding net new business value?
Bala: No, because you're simply changing those parameters and because they happened to be hard-coded in your automation.
I'll tell you this example, if you took routing and we related to coverage. If you took routing and you've defined your routing rules and, in a system, where you have to type in the physical name of the people that are being, and sometimes people put that in code, which is like the most insane thing you could do. Because the moment you do that, you hard-coded the routing logic into your system. And if that person leaves, now you've got a problem degree, you've got to go and remove it and that takes IT capacity to go do. And people struggle with these kinds of things all the time. I have talk to prospects who literally hard-coded zip codes into apex code sitting in their Salesforce environment. So, if you need it to change your coverage model right, and say, okay, now someone else is covering the zip code. You literally have to call the it guy to go change code in Salesforce, which is the worst kind of setup you could do.
Dharmesh: We sent someone over to an apex training.
Bala: That's what he was lamenting about. So you know the person we were talking about, "Oh, I just inherited this and now I have to go learn apex coding because my sales manager wants to change the zip code that is assigned to a particular territory." And that's an extreme example, but this happens with holdouts. This happens with industry taxonomy. This happens with all of these things that are sales policies and our policies that are driven by the go-to-market plan itself. That should be flexible enough, so you can change it very quickly. And in a system that that immediately sort of understands the impact of those changes and you want to change it in one place. Now, the problem is that a lot of people have a lot of tools and that also impacts your inertia for change because now if I make a coverage change, I don't only have to change code, I have to change the routing rules, I have to change the...
Dharmesh: ... is as you think about these things; plan, build and excel.
Dharmesh: Movement requests that are coming in tied to, "oh, I need to change here." coming in through email or slack channel updates. Taking that Excel spreadsheet and upgrading Salesforce happens through data loaders, data coding, all that stuff. And behind all this, you have multiple people, different teams essentially.
Bala: That's right.
Dharmesh: We all these things that are disjointed, we do not collaborate and so I think there's a huge opportunity for people as they scale, because those are the things that drive inertia, they'll get it, right. And then of course, the last part is, if you don't get this right, you end up losing your best reps because guess what? They don't want to be in, they want transparency. Did I get the right batch? How fair was it distributed? Why am I not being a number or I was covering that account, so like, I don't want to deal with comp issues, I just want to make sure everything is tracked and there's audit. So, I think that is super important. So, shifting gears now, we definitely help people, we've helped people really re-think coverage. That capacity is an interesting piece because in all our discussions we've had this thing about capacity and you and I have been doing this, like, "okay, should we do it? Should we not do it?" That capacity, but we do have a point of view and how people should think about capacity.
Bala: That's right.
[29:00] How does capacity planning, also referred to as scenario planning, relate to coverage and go to market?
Dharmesh: Especially now, when people are doing multiple scenarios, they call it scenario planning. We call it capacity planning or headcount planning. Do you want to elaborate a little bit on how we think about this and how it relates to this whole coverage and the go-to-market?
Bala: Sure. Yeah. I mean, before obviously you start operationalizing the plan, the first step in the planning process is you figure out how much budget you have and how much headcount can you afford for that budget. And that's really the basis of capacity planning. Now, a lot of times what I see teams struggling with when they figure out what that is, is one, they don't understand the effectiveness of the different types of roles that they have. Which mean that you reduce it down to just a ratio discussion, which is in my mind the biggest injustice you can do to capacity planning because you're saying, "Okay, five sales reps per sales engineer." Well, how effective is that sales engineer? And the dimension for doing that is not really always ratios. It's really about what value is that sales engineer?
And the guy is ramping and all that kind of stuff. For simplicity’s sake, because you're modeling this in Excel, what people do is okay, I’ll just use a ratio, one is to five reps and I'll put a sales engineer, I get five reps with the coverage. That is a very rudimentary way of thinking about it because you're not really analyzing what is the impact of what sales engineer on your deal cycles. When you put somebody in there, what happens? When do they need to get engaged? When is the complexity required? So, that I think is it takes a productivity lens to look at each capacity, each type of resource and say, "What is the net impact this person's going to have on my ROI essentially, at the end of the day?"
There are some roles that you might put in, especially business development roles, where that becomes a difficult discussion to have, because you are trying to develop a market, you're trying to develop an environment. So, it means that you should consider that as investments into a multi-year horizon, rather than thinking about that at the deal level. Each role requires a different model for how you think about the effectiveness of that role.
Now, once you come up with something and I think the ROI, it's a great way to kind of think about it is, what is the net impact? What is the net productivity gain? What is the net revenue gain that we gain from these different roles? And you very quickly find out and we've both been in large companies where there are 1 million roles that are involved in a sales cycle. And at some point, you know that you hit a plateau where it's not effective anymore when you have like eight people in eight different roles, show up to a customer meeting with one customer in the meeting. It just doesn't work. And so, that results from just this thinking that, oh, it's just a ratio game that I'm playing. And I just have to hire, every time I hire five sales reps, I have to go hire a sales engineer. That's just the wrong way to think about it. That ROI lens, that productivity lens, I think is a very important one when you're thinking about capacity.
The second biggest thing that people struggle with when they figure out the capacity model is figuring out what capacity you have right now. Unfortunately, a lot of people don't track what's going on with people in the sales org, especially when you get to a certain size. You don't know who's on what, who's ramping, what is your effective capacity, who's doing what roles, who is temporary...?
[32:30] What do we mean by net effective capacity?
Dharmesh: I want to pause you there: it is effective capacity. So, there's a difference between, when you asked most people in the planning, “How many reps do you have?” and they go, "Oh, we've got a hundred reps." Well, you don't actually have a hundred reps because 10 of them just joined last month. And if they take longer to ramp, that's the exposure that they have to quote on a number. And so, most managers end up playing the game of, I'm just going to assign all of my assigned call out to my existing reps, which again, it's a fine balance.
If you consistently you'd demotivate a whole bunch of high performers.
Bala: And no wonder 50% of people don't make their numbers. And so, that I think is the fine tuning that a lot of people don't know. It also comes with maturity. It comes with a bit of experience running a certain role. So, the first year you deploy your role, you don't really don't have data, so you're going with the hypothesis that this would be the case. So, in that sense, you take an investment lens on that role, but once you get one- or two-years’ worth of data under a particular role, then you can start to fine tune that role in terms of how you're deploying that capacity. And as you said, figuring out what the current capacity is the accounting work. And typically, what happens is you don't worry about that until the QBR comes along or you have to change plan and says, okay, what is our capacity? Your HR system is woefully inadequate to tell you who's covering what territory and what your effective capacity is and you don't know.
And so, you've got to have something where you're keeping track and accounting and being counting all of these things, including effective dates of when a person is on a particular role. When they're changing those roles, where they are, what is the ramp situation? And to your point, how do you get to that effective capacity? Then you have a position to start from and say, "Okay, if I add 10 more people here is the capacity that I'd been looking at" and you start to build out a hiring plan, that says, okay, you can't hire everybody in Q1. If you need to hire 50 more reps, you're not going to do that all in Q1 because your hiring team is not one, going to be able to keep up. And two, your budget is not going to allow you to do that. And so you have to build out a hiring plan, which effectively is capacity added throughout the year. But all of those resources are ramping, which means that you don't have access to that capacity from a selling perspective. You have to get to this idea of a net effect, we call it the net ramp resource in the system, which is effective FTE of what you have in terms of selling. So, I think that takes up quite bit…
Dharmesh: .... And that is, I think the fundamental underlying denominator. You need to know what is a net effective capacity first, and to understand the unit of scale that you can build off that, to take the different lenses that you might have. Because someone can say, "Hey, I want you to build a capacity model based on this revenue target." right? The other person can say, ""No, no, no. I want you to build a capacity model based on this expense on route that I'm giving to you." And so, you figured out based on whether you want an AE on a CSM and IM, you know exactly. But essentially, I'm optimizing for children, am I optimizing for net new acquisitions, or somebody could just say, I'm going to give you X number of head count. Either I'm giving you people or I'm going to take back some people. We'll figure out a new capacity model, which has then impacted how the accounts gets distribute and all those things. But underlying all of that, is that effective?
Bala: It is. It is. And we talked about productivity is one of the angles to this in terms of ROI. Now, productivity numbers are very different, whether you're calculating based on effective capacity versus actual capacity.
Bala: Right. And so, you could get a false sense of what the productivity looks like when you're looking at actual capacity when most of your resources are ramping. And so, I think that that's an important angle to kind of bring to the picture. And the other big challenge during planning is that the reality is changing all the time, which means that you set out Q4, beginning of Q4, you have some sort of a guidance from finance. It says, okay, here, how much budget you're going to get and you start building your capacity model. You say, okay, next year, I'm going to hire this much to get to the sales calls, blah, blah, blah. What happens is during those three months before the end of the year closes, a lot of people leave and people change roles or people are not there anymore. And you've taken a snapshot at the beginning of Q4, which you're working with, which has nothing to do with reality where a whole bunch of people have changed...
Dharmesh: Or who might just get a different budget envelope from finance, into the fifth period, you say, "by the way, we've now locked the books and we've looked at the numbers and this is a new number," and like totally our calculation has gone off again.
Bala: And so, it could be higher, which is a good state to be in, or it could be lower, which means that now you have to come back and re-plan all of your numbers that you just did. You really can't do this without a system that keeps track of reality. You have to continually be in a view of what's going on in ground reality, so that you have an accurate picture at any point of time "what is my existing capacity?" And "what is the net new capacity that I need to add?"
Dharmesh: It’s not even Q4 now, and I don't know, most of our customers, they're almost planning quarterly. They're been doing some sort of a scenario plan every quarter. I know one of our customers just raised a huge round of funding. And that huge round of funding means comes with a go-task operations...
Bala: Pressure to add more..
Dharmesh: Hire people~ and they are in the middle of the fiscal year, technically. They just locked the funding and so they have to get back into planning mode. And that is going to be constant. And they'll have to figure it out, now what revenue numbers are we signing up for?
Bala: That's absolutely right. When we talk about our point of view, in terms of capacity modeling, our point of view is that one, you have to have something that keeps an account of where your existing capacity is. You have to know at any point in time what your effective capacity is, who's covering what, and you've got to know, you have to have a good bean-counting system in a sense, an accounting system and that's transparent.
Dharmesh: And it has to be transparent.
Bala: And it has to be transparent. And then the second thing is that it has to be an effective dated, which means you have to be able to know when this person is going to change roles. When is this person leaving? That effective capacity is absolutely important. The next aspect of that is thinking about these resources, the different roles, looking at the productivity of those roles. Like what does your ramp look like for each of your roles? How long do they take to come on board? What does the ramp look like in different industries? We have customers that have for the same exact role, different ramp profiles in different industries. Because selling into the public sector has a much longer sales cycle and a lot more things for you to learn as a rep compared to selling into another industry or other vertical. So even for a sales executive, you might actually end up with multiple productivity or ramp profiles based on which industry you're selling into. And so by business unit that could change. So you can't apply like a generic ramp profile of three months - people somehow just pick three months out.
Dharmesh: Yeah, and that is I'm going back because it, there are so many moving parts and so many ways to slice and dice of things. Under time pressure and time crunch, when ops is always woefully understaffed, they are expected to do more with less, hence we end up taking a swag. And in the most simplistic scenario and our answer to everything is let's over-hire. We don't say let’s overhire, we tell our people that or assume 50% people all meet quota, which is a way of being that, 50% it's like any expert right here, like a weather forecast, it's half the time.
Bala: It is like weather forecast, but you would in any other profession, you would have a hard time hiring where 50% of the people don't make their targets. You can't build an engineering team and say 50% of my developers don't write correct code and 50% do and I'm going to count on the 50% that does. It's ludicrous. But in sales, we kind of take that attainment number and shove a lot of bad habits under that. And so, this exposes, I think you need a system that exposes all of these and gives you fine tuning of capacity. We see people reducing capacity down to two things. One is they take a swag at what the ramp will be and most people pick a quarter and say, "oh, it just three months” irrespective of what happened, it's three months away. Then the second thing they do is ratios. They say, "Oh, two is one, three is to one, five is to one kind of ratios." And that makes the capacity models simple, but it's devoid of reality. You've just picked these numbers out of thin air.
I think what we really need to focus on in terms of capacity planning, is that fine tuning, is that ROI lens that you can apply to each role. Have a model that you're applying to each role like engineers. Sales engineers, I have this model of looking at a contribution by deal size. For business development managers, it's new markets, so I'm going to look at what new pipeline they're going to generate. You have to kind of think about it in that way. Like if you're thinking about SDR, you have to actually look at what marketing activity is going to generate a whole bunch of traffic for your SDR capacity to handle it.
So the method that you're using has to be different. The productivity angle, the ROI angle is something that is crucial for us to think about when you think about capacity modeling. When you're new and when you're starting out, when you don't have a lot of data, I guess it's okay to say, "Okay, ramp is three months and ratios are this." I think as you scale and mature as a sales organization...
Dharmesh: And the other part is, it's okay to start with an assumption, but then you have to start automating a ramp tracking.
Bala: Ramp tracking, yeah, exactly.
Dharmesh: You want to continue to optimize your capacity models and the coverage policies model. So, like, when should I hire? Like when there's one of our large customers that we have been talking to, and they had this weird notion that it was six months ramp, default. But really, that they don't have is they have is any ability to track ramp. And they actually missed last quarter simply because they underestimated ramp. You're a fast-growing company, you're bringing in a whole bunch of new reps on board, and what they've done now, in order to fix that is taking that piece and they've correlated to the enablement team. So, the enablement can be informed with how much time ramp is taking, so they can figure out a way to sort of make some enablement investments.
Bala: That's right. Yep, absolutely.
Dharmesh: Those are actually, we could go on and on. I'm just looking at the clock and we are on a minute over here, I think...
Bala: I think we can pose a question to our viewers and see if they would like a more in-depth discussion on capacity planning or coverage. We can certainly do that on a future date.
Dharmesh: Yeah. But I think that's absolutely there and I will. Actually, it might be interesting to sort of at some point, talk to them about how we think about building capacity modeling plan as well. It's been great chatting with you and then now like always this is always, this is our daily discussion. Excellent. Thank you.
Bala: Thanks, Dharmesh.