Sean Lane 0:02
Today's episode is sponsored by the DevOps experts at full cast with me is their Head of Customer Success. Tyler Simon's Hey Tyler, revenue efficiency, sales productivity are everything today. How does full castes go to market planning platform help Reb ops teams achieve these types of goals.
Tyler Simons 0:18
Well, forecast lets you build better territory so that the right resources are always focused on the right opportunities. When reps are motivated and zeroed in on their targets, they'll be more successful and bring in more revenue.
Sean Lane 0:32
That sounds great. I do a lot of that planning and spreadsheets today. And I'm pretty happy with my spreadsheets. How is full cast any better than that? You
Tyler Simons 0:41
must get rid of the spreadsheets because spreadsheets create lag and errors with forecast planning and updating happen automatically, all in one place. Best of all, it automates all common headache inducing planning activities like territory rebalancing, account hierarchies, routing, and more. So when you're faced with those go to market plan changes which you know what they happen all the time forecast has your back.
Sean Lane 1:08
Alright, you got me convinced? Where do I learn more about forecast? Our
Tyler Simons 1:12
website forecast.io.
Sean Lane 1:28
Hey, everyone, welcome to operations, the show where we look under the hood of companies in hypergrowth. My name is Sean lane. Most ops teams are notoriously strapped for resources, we scrape and we claw to build our teams and design them to make meaningful impacts on our organizations. But sometimes we just don't have the resources internally to get some of our projects done and get them done well. And that's what operators will typically turn their attention to the fragmented, overwhelming and slightly intimidating world of operations consultants. This is particularly true of Salesforce projects and the Salesforce consulting ecosystem. But luckily for us, our guest today is an expert in that very system. That guest is max Mater, the CEO of found HQ, a hiring platform that connects companies with vetted Salesforce freelancers. And Max isn't a novice in this space. Prior to found HQ, which he's run since 2020. He was also the founder and CEO of 20 Pine, a consulting and headhunting firm that specializes in Salesforce and sales ops related roles. In our conversation, Max teaches me about the reasons why ops teams seek out outside help, we talk about how companies should decide how much control they truly want to set the direction of their projects. And why Max fundamentally believes that the go to market tech strategy should not be run by Reb. Ops. Let's start though with the situation that we all might find ourselves in right now. Or someday soon. Why do operators look outside their four walls for help in the first place?
Max Maeder 3:09
It's an interesting perspective, because I have been in the Salesforce and rev ops arena for really the last 10 years. And so sort of saw the function evolve when it was I guess what we were calling sales ops. And it was this sort of nascent function that I think a lot of executive teams still needed to be convinced of the value of hiring sales ops, and they were figuring out where to put it within the organization. Now there's general buy in and it's widely adopted that revenue operations is how you go to market. I think one of the challenges with how quickly the function of Rev ops overall has expanded is how much is now stuffed under like one individual leader, right. So it's not just sales ops, marketing ops, CS or CX ops, but it's also deal desk. It's the AI and data analytics team sometimes, and it's the entire go to market stack. And I think that last one is really where we see the need for companies to go external, is just you look at the scale of most companies go to market stacks, just how many individual tools there are in place, I think a lot of that's been driven just by the kind of market of point solutions really exploding over the last five years. And so I'm sure we've all read those various studies where it's, you know, the average number of tools that a sales rep uses to get their job done is, you know, something like 15 or 12, something like that. So, just managing those number of tools. I think point solutions on the surface look like, Oh, here's an easy tool to kind of tack onto my existing Sales Cloud instance. But when it comes time to start thinking about V two, what is the next phase of our go to market tech stack evolution, you really need narrower, more specialized experience across This individual areas of the go to market stack, if not individual applications within the go to market stack, and you simply can't get a team of Salesforce admins who's going to intimately know every single tool within their go to market stack. And that's when I think you then need to look outside and say, What specialist knowledge do we need? What's the best way to kind of bring that into the fold to fully leverage the tools that we're spending quite a lot of money on?
Sean Lane 5:27
It's interesting that we've already reached this point in robots evolution where people are already worried that there's too much on robots plate. We've talked about this on the show before that the charter may be getting too broad and Max's point about tools, specific knowledge here is a good one. That's really where depth of expertise comes into play. And in Max's world, that's where he sees operators seeking that outside help. And why shouldn't we sales ops, customer ops, marketing ops, big deal desk, it's so much, but we can't just throw up our arms. So what's the alternative?
Max Maeder 6:05
Here's Max. I fundamentally do not believe that rev ops should be owning, go to market tech strategy, and therefore Salesforce strategy. The one caveat to that I will say is that the earliest stages of a company right when your sub 50 reps, you probably don't even have a full time Salesforce admin, or if you do, you just have one. Other teams don't have established systems specialists in place yet, that's fine, you sort of need somewhere to talk like an individual systems specialist. And it makes sense to put the Salesforce admin into Reb ops. But I think a lot of companies will reach scale, where they have hundreds, if not 1000s of users, they have a dozen go to market systems specialists. And they're still reporting into rev ops. Meanwhile, the HR team has started to hire workday administrators, the finance team has NetSuite administrators the you know, marketing ops team, under potentially a different director, level leader under the VP of Reb. Ops has Marketo administrators or HubSpot administrators. And it becomes an unbelievably fragmented system strategy, where each individual business unit is charting the course for the tools that they use. And I think that that is a poor way to build a scalable enterprise applications infrastructure. I think a lot of Reb ops leaders that I talked to don't love when I call that out. And I think that's totally fair. I think that a lot of leaders have been in organizations where there is a difficult dynamic between the technology team and between the stakeholders. And as soon as the trust is lost, and the business side feels like their needs are going unmet. That's where things can start to break down. So it's not as simple is just saying, let's remove the go to market tech piece from rev ops, and let's stick it in this other team and have everything structured and running as it was before, you need to take a very methodical approach, not just to the reporting structure of those teams, but specifically how those teams are resourced. And I can go into some more detail around that. But I think back to the original question, if there's one area of Rev ops that I see as being a little bit of a runaway train, that is the easiest to carve out and give you know that charter to another team. I think it has to be the the tech piece. Yeah,
Sean Lane 8:35
I think I would agree with you, we took a pretty similar approach as we matured at drift, right, very small, centralized function for everything when we were smaller. And then as we grew, start a car about data engineering systems bi into slightly separate versions of the group. So we could do a whole episode on the pros and cons of where those things sit. But But I want to go back to your point about the resources. Right. So I think part of one of the reasons why companies go outside to try and get help here is they are naturally usually under resourced in these robots groups. And so you mentioned kind of going out and trying to find like as you get bigger, that very specialized knowledge about a particular tool or about a particular skill set. How should people think about balancing their internal folks with those external resources? Is it more generalist internally and specialists externally or is that not the right mix?
Max Maeder 9:29
Yeah, I mean, it's, it's so it's so contextual. So it is highly dependent on just what the appetite for investment in the product roadmap is within an organization. I think generally you do see and want to see internal teams going wider. Because you do want to develop a model where your internal team on the Salesforce and go to market system side is really set up to drive strategy forward. All right. So functioning like what I, you know, kind of call them what other leaders call like a true product. Org, right? You look at product and engineering teams and cultures, they're not doing anything reactively they are developing core product roadmaps with years of planning into the future, accounting for you know how the business is going to evolve accounting for technical limitations and hurdles.
Sean Lane 10:23
And when you say, right product roadmap, you're not talking about the product that that company is selling. You're talking about internally, the roadmap for what you're going to build to support the organization. Right.
Max Maeder 10:32
Exactly, exactly. And saying that I think the way companies approach building their core product that they're taking to market and selling is very different from the way companies approach internal product, internal tools development, but I don't think that it should be, I think it should be that proactive, strategic, very much forward looking type of discipline. The challenge is often to your point resource constraints, that you need to have not just the headcount allocated to solving those problems, but also the right level of headcount and make a meaningful investment in terms of seniority level, and everything like that. But I think that's why your internal team in an ideal state is set up to do that type of strategy, architecture, roadmap planning work, and it is easier to then fill in some of the execution oriented gaps with outside specialists, right, I think like a good example of that is something like CPQ, which is an absolute beast. And in order for someone to be an effective CPQ, product owner, CPQ, business analyst architect, whatever the title is, they need to be so deeply ingrained in the business, right, they are a technologist, they know all of the capabilities, they know the underlying platform architecture, they know how to do what needs to get done. But they have to spend their time embedded within the business actually figuring out how to do those things correctly. And so it's hard to approach these problems in the right way, and then still have the capacity and the bandwidth for that same person to then execute on all of this work. And so unless you're the largest enterprise companies who have 3040 50, internal Salesforce specialists, you just can't cover that amount of ground. And so, own the strategy in house, delegate the actual execution with full time or fractional contractors depending on what you need, because you can be so precise in getting specific skill sets for specific stages in the delivery all under the kind of guidance and direction of your full time internal team who gets the implications from your unique business case.
Sean Lane 12:46
Max's split is simple. When you distill his message, own the strategy in house delegate the execution. He believes that the internal product development of your company, or how you're building systems and processes for your internal users shouldn't be any different from how your company's product team builds what you actually sell the customers. Now look, any product manager, designer or engineer that actually builds a product will tell you that it isn't quite that simple. And a huge part of it is the people doing the building. Max has been inside the Salesforce ecosystem for years first as the founder of that Reb ops headhunting firm called 20. Pine. And now it found HQ. And he's seen the maturation of the resources available in that ecosystem. When it comes time to as he puts it on the strategy in house and delegate the execution, I wanted to understand how he goes about finding the right people for the right jobs. First and foremost,
Max Maeder 13:45
the the way that the ecosystem, the Salesforce ecosystem is sort of divided is three main buckets in terms of resourcing strategy, you've got consulting partners, you've got your full time staff, and then you have freelancers or independent contractors. Each of those have a very distinct lane, there's a very distinct sort of time and place, when those resources should be leveraged for different initiatives internally, historically, and still to a large part today. The default for all things external is Salesforce consulting partners, Salesforce has invested tremendously in building this ecosystem of partners, there's two 3000 could be off, you know, on that data in the US alone, but there are incredible capabilities out there to tap into with partners. The biggest thing that I saw at 20 pine that sort of informed on why I launched found about three years ago, is that there's an enormous gap that exists between when the partners job is done, and when the full time team is able to kind of pick up the roadmap and run with it themselves. And so a lot of this sort of filling in the gaps in the middle either immediately post go live on a new implementation when the park or, more often than not stays on for some urgent support work, but they kind of move on to the next project, or in the cases that we were just talking about sort of your ongoing incremental product development that happens internally, and figuring out how to kind of fulfill those. So consulting partners are easier to identify, you've got the App Exchange, which is effectively a directory of partners, you know, companies will go to their AE and ask for recommendations of the right partners to use, that's a reliable way to get plugged into the partners that you need. The Freelancer side of the market, which is the problem we're really looking to solve with found is a incredibly fragmented, right, so there are a lot of people who are freelancers, but you need to have an added layer of skill set verification and experience before engaging with someone and partners, obviously have that level of due diligence with the Salesforce kind of certification and partner tearing programs. So there's quality controls there, where the Freelancer market is a little bit of the Wild West. And then the second part is identifying who is a good Freelancer is certainly part of it. But even just identifying who is a freelancer is hard enough, there is no real effective way to do that. Even on something like LinkedIn, you could get on you could search, you know, freelance Salesforce developer, and you'll come up with very little. So we are effectively trying to bridge that gap by building what I sort of refer to as a managed marketplace. So in the world of freelancers, platforms, you've got your open marketplaces, which is like an Upwork, or a fiver, they're designed to be fully self serve, anyone can sign up to be a freelancer and say they've got XYZ experience, anyone can sign up as a company post a project, and then they're sort of networking and, you know, meeting each other organically on the platform. I think that's great for scale. There's challenges there, because there are no quality controls in place. So it is fully to the risk of the company going on and selecting someone and just trusting that they can do what they say they can do. And so as a managed marketplace, what we do is we actively identify, recruit, and extensively vet all of the Freelancers before they're given access to our platform. So when a company comes on and registers a project, you know, we have almost 4000 global Salesforce contractors, but 100% of them have gone through one extensive vetting process, before companies get visibility into them. So I think it's sort of a two part challenge of one helping companies understand that this contractor piece is a resourcing option, partners have an absolute time and place where they are best suited. But there are a lot of projects where using a partner is a little bit of a square peg round hole, in my opinion. And so understanding that contractors exist, and that there's ways to kind of reliably connect with them, I think, is the problem that we're
Sean Lane 17:50
trying to solve. So in the three categories of staffing that Max broke down full time staff, Salesforce consulting partners and freelancers, his work at found HQ is really focused on these freelancers. And managing the vetting process for 4000 Plus, freelancers has to be quite the process to be able to competently stand behind. Max told me that in their process, they do three things, one, a behavioral interview, where they cover previous work and projects, to a technical assessment that's reviewed by top tier talent, and three a reference check. To me as a potential hire of these freelancers, the value is so clear, I can get a Salesforce consulting referral from anybody, but having Max and his team put their third party validation on my choice really helps to de risk what could be an expensive mistake. But Mac said that even though his vetting process is important, and the allocation of resources is key, that's not actually where he spends most of his time. Where
Max Maeder 18:51
we spend actually more of our time, then on the delivery of resources, and making recommendations of who you should hire as a contractor is helping companies figure out what kind of contractor they should be hiring in the first place. So the majority of the conversations we have, and therefore the majority of the content that we produce is around resource modeling, from the perspective of various Salesforce customers. So what is the right sequencing of hires for my stage of growth at both a full time level as well as a contractor level? I have such and such project? Let's say it's Phase Two for CPQ. I think I need a Salesforce developer. Is that right? Or do I need a CPQ? Architect or do I need a CPQ? Administrator? Right. So I think the the good and bad thing with the Salesforce ecosystem over the last five years is that it has gotten enormous and it has grown in complexity as they continue to acquire and tackle on tools. So you know, five, six years ago, a Salesforce developer was a Salesforce developer, that is is no longer the case. Now. Do you want a Salesforce CPQ developer or you want a developer specialized, inexperienced cloud and front end development? So it's narrowed in terms of the skill set, you need to identify. And I think a lot of customers are, are still struggling with understanding what do I hire, when and for which project. And so our ability to help guide them through that conversation means that we can land on on actual skill set alignment, that will set the project up for success, which, you know, you could put a good resource in the wrong role, and that project is still going to be troubled. And so again, that's where we spend the majority of our time with clients, which is not, you know, that's non revenue generating for us, we're not trying to build out in a consulting or advisory model, that's just to get them in the position where they know what they need to hire so that we can facilitate that introduction.
Sean Lane 20:46
And I think there's value to that guidance piece too, right? Like, like anything else, like any company, you do this every single day. And I might need to resource a project like this four times a year, right. And so like your level of expertise, for this particular type of project, or this particular type of search, I think is probably the thing that actually is very, very helpful as I go through this process. This episode is sponsored by fool cast, a company that helps operators build better sales territories, their platform focuses the right sellers on the right opportunities, making them unstoppable. And the cherry on top, forecast automates common go to market activities like territory, rebalancing, account hierarchies, routing, and more. So the plan is always in sync with operations. With forecast, say goodbye to go to market planning, headaches, and hello to your own personal planning assistant. Learn more about forecast today by visiting forecast.io. Okay, let's get back to max. What we've heard so far about staffing internal ops projects with external resources is that you have a choice between Salesforce consulting partners and freelancers. And as you're picking the right partner, you need to one figure out the skill set alignment that you're looking for, and to scope the number of hours were the resource management capacity required for that project. But how do I even know if working with say a bigger group versus an individual is the right choice, the outcome of my project will ultimately be a reflection on me, my team, picking wrong here is not an option.
Max Maeder 22:25
One of the big considerations and this this sometimes happens kind of upstream of our conversations, sometimes we're encouraging companies, you know, to think about it from this perspective, is really understanding to what extent do you as the customer, have the ability and the desire to set the direction of this project. So the reason Salesforce partners are the default option for implementing a new Salesforce product. And we would only ever do that at the smallest scale, right, we're not trying to assemble large delivery teams to implement a 2000 seat service cloud instance, you want to go to a consulting partner that has a structured methodology, all of their resources live under one roof, you're implementing service cloud for the first time you haven't done it, you don't know what the edge cases are, you want someone that is going to get to know your business, but drive the end to end strategy, design delivery, you want to be contributing to those goals, those objectives and those plans, but you don't really want to be owning them, because you don't have the capabilities to do so. Some companies as you get into the maturity state, and you're managing an existing instance, and making incremental changes to it will be well set up internally with, you know, go to market systems leadership and architects and product owners that know the business intimately. And they are able to set the strategy as we were talking about earlier, and really give give the roadmap planning and guidance to outside consultants who they just want to help execute. And in other instances, the company isn't resourced in such a way where they can or should set that strategy. And so I think that's really where you need to start is just a real honest look of do we have the ability to make the decisions that we need to make from an actual Salesforce architecture perspective? If yes, that dictates the shape and profile and obviously skill set of the person that you need. But if no, it's a totally different calculus of the sort of team based approach that you'll then need to take with finding an architect or two and a team of doers. And then you can sort of use that to back into okay, what is the specific composition of the team needs to be how much development work is here versus configuration that an admin is going to do etcetera. So, that stuff will obviously be very specific to the project, but I think it has to start at that level of Just what can we what can we actually drive self sufficiently? I think
Sean Lane 25:05
like that that ownership piece for me is really interesting. And it's honestly been an area where I've personally struggled when working with outside consultants or, or partners, because, you know, maybe it's me, maybe I'm, maybe I'm a control freak, and I gotta let go. But like, part of working with folks like that is the amount of time you need to spend bringing them up to speed, giving them the business context, giving as much direction as you possibly can, for them to be able to go off and do the work that you're asking them to do. And so at a certain point, the amount of time and investment you put into scoping teaching, bringing that business context like starts the lesson for me the impact that they might have, by having an external party actually do the work, right. Same thing when you're bringing in a brand new tool that's not Salesforce, and you have to train people on it, like, I'd much rather our own team train our reps, or whoever the end users are on the drift context of how we're going to use that, as opposed to just the cookie cutter version of how they're ever they might roll out that new tool helped me overcome that, like, am I thinking about that the right way? Should I eat like just Shawn let go? How should I think about that ownership piece when having these types of consulting conversations? Well, I think that's the
Max Maeder 26:18
the big reason why when we sort of talk about resourcing options, we really do try and take as unbiased of a view as possible and saying, Hey, look, these are the benefits, the advantages, the times that you should use a consulting partner, here are some alternatives. And when we recommend looking at contractors, I think the biggest reason why we see at least larger project work is because consulting partners do want to take more control within the project. And there's a lot of reasons for that. They feel like they are bringing the expertise, and they want to set the project up for success. And, and in order for them to do so they need to be in full control of the decisions that are getting made. So that the final solution that's delivered is what they think is the best solution. That's valid, you know, if they have kind of customer success in mind, which they do, I can see that frame of mind, and how that translates to the end goal. And there's also reasons why I think they want control just from a delivery methodology and a project planning perspective, if they are controlling the full roadmap all the timelines every step of the way, it's a lot easier for them to slot in the resources that they have on their team. And as a professional services for managing bench utilization is like the hardest thing that you have to do as the company scales. And it's easier when your projects are predictable, because you are calling the shots. A lot of companies when they are in a position to drive strategy, and or training and change management themselves, to your point, they absolutely want to do so. And that's where I think there can be a little bit of conflict between how customers want to get the project done, and how consulting partners want to get the project done. And that's one of the very specific reasons why companies do bring in contractors is just because inherently the expectation of that engagement is they are an embedded member of your team. Whether they're embedded on a full time 40 hour a week project or they're embedded as a 15 hour a week Salesforce administrator, they function in terms of how they interact and collaborate with you as if they are a member of your organization in a way that consulting partners just aren't designed to function. And so I do think that that is a big advantage for the kinds of companies who, you know, are looking for that level of control and sort of continuity from an internal resource standpoint.
Sean Lane 28:44
Max says that found HQ is not itself meant to be a consulting company. But his expertise on how companies can best work with consultants clearly sets him apart as someone that hiring companies would be smart to listen to. And as he worked with so many Reb ops teams and the same types of needs, his opinion about the purview of DevOps has only gotten stronger. I
Max Maeder 29:07
think that rev ops as a team, and organization wide, really stands to benefit from loosening control over how much they want to own Salesforce. And I think that this is one of the biggest challenges because of the fact that the evolution starts with Reb ops managing Salesforce and go to market systems, they hire a Salesforce admin, they're still fully in control, because that's how it starts in almost 100% of use cases. It's always the situation where something is now being taken away from the Reb ops team, something that used to be within their purview, their control is now being taken away from them. And in no context is that feel good? Especially if you've been doing a competent job with it up until that point. But I think centralizing that system strategy has enormous benefits, not the least of which is just getting technology strategy off the plate of Rev ops, I mean, how many Reb ops leaders actually want to be spending the time managing the tech stack versus how many of them would prefer to control this tech stack, because they're worried about what it means if they don't, because I think the vast majority fall into that second camp, they've seen scenarios and structures that didn't work. And so this is the best scenario for them to get what they need, where you can set it up in such a way that Salesforce is the team is spun out, you stand up business analysts and product owners that are basically embedded within the business anyway. So they effectively have a dotted line into Reb ops, but you don't need to manage the people, you don't need to manage the technology, you don't need to manage the support. So I think that taking that perspective in mind is a big piece of advice for for rev ops teams that have the option or opportunity to kind of rethink some of these structural things. And
Sean Lane 31:11
I think what you're recommending, will be really hard for some people, right. And, to me, the best way to think about it is as if you are an individual as opposed to a team, right. So as an individual, if you want to grow in your career in any way, shape, or form. At a certain point, you need to teach other people how to do the stuff that you do, because you can't grow until somebody else does the stuff that you do today. Right. And so even if you look at it from a purely selfish perspective, teaching other people how to do that stuff, takes it off your plate opens up more opportunity for you likely something more strategic, right, like and allows you to grow. I think if you take that that same example and insert the Reb ops function there, it's the exact same thing that you're saying, right, in order for the function to become the strategic partner that I think every operator wants to be, you have to get out of the weeds of some of that stuff, right. And like to your point, there's going to be ripple effects of system decisions on the you know how you run your go to market. But like, in order to do that, you've got to give up something because if you just try to do all of it, at the same time, in my opinion, you're going to do a mediocre job. And every single one of those, you know, seven buckets that you said at the beginning of the show. Exactly.
Max Maeder 32:26
And I think that's a big one. So I've got a prime example, I was just talking to the former head of big tech at Envision, which is, you know, SAS prototyping tool. It's kind of like a figma like Miro before Miro existed, raised a ton of cash. And I think this example really speaks to a the the value and benefits of that go to market systems can provide overall to the business. And be speaks to why I think it needs to be run like a technology and product discipline and not to take anything away from rev ops leaders and their capabilities managing systems strategy, because there are plenty out there that we talked to who are incredibly sharp, technically, from an application architecture perspective, they understand it, but they are still business folks. They are ops folks, they are not technologists, and I think we were just catching up the other week and this example was such a clear AHA in terms of the value you can realize as a Reb ops team by loosening control a little bit. And it was, you know, she had been talking to the product and ENTJ team about a use case that that identified and there was just no capacity within the the core product and engineering team to approach this this initiative. And so what what she and her team had seen was that a lot was being invested in low dollar high volume, SMB selling motions, low dollar expansions and renewals. So they prototyped, the big tech team prototyped and designed a self serve model that was built leveraging Salesforce, and Zora, which is a subscription billing tool and Pendo. So all internal tools, that was a solution that nudged customers that were up for renewal or close to or over utilization, to run their own renewal and expansion within the kind of in product purchasing that they had built. That is a prime example where you're kind of flipping the ITN biz tech team from a reactive sort of build the features that you're getting requests for to a legitimate product strategy organization that is now doing the kind of work that is ordinarily found in the core product team building in these kinds of features in the core product offering that you have this entire team that's capable, that has off the shelf tooling that can do these kinds of things. So it's probably not only more efficient to build and ship this within Salesforce and Zoho Rather than build this into your product, but it's something that can be surfaced from a group that has capacity has the knowledge of the business, they've basically connected rev ops, and they spotted something in the rev ops data as the Systems team and said this, this is a problem we shouldn't be doing, we shouldn't be spending the time on these kinds of things that we are, it doesn't make business sense, and running that self sufficiently. And I just feel that you put a ceiling on the level of capability you can acquire to a biz tech team when it is housed within Reb ops, because at the end of the day, Reb ops owns tech. And when you spit it out, and it's a function like this, I think that you can see performance like that.
Sean Lane 35:40
And I think like the other beneficial domino effect that you just uncovered is that it actually brings the internal systems closer to the product itself, right. And if you're an envision or Amuro, or in one of those types of companies that you're describing, where product lead growth is at the core of what you do, connecting information, data's subscriptions, from the product to your internal systems, is something that probably a lot of those systems teams at other companies would be complaining about, right? Or saying, like, Man, I wish we could just be tighter with the product in order to do this. And I think by setting up the the org structure in the way that you're describing, an incredible benefit of that is to actually bring those internal systems and the product closer together in a world where that basically has to be table stakes now, because otherwise, if they operate completely independent of one another, like you're going to be in big trouble.
Max Maeder 36:35
Yeah, for sure. Well, you bring up something interesting that I'm curious to maybe pose something to you and change direction a little bit, which is bringing the systems teams into the product context, more, particularly in plg. And I think plg is everyone's talking about it as an identity. It is it is the go to market identity, which I take I take a little bit of issue with, I think that it needs to be viewed as sort of an emotion or a piece of the puzzle. But I think what it has uncovered, and and I'm starting to talk more about is the areas in which rev Ops is extending into different parts of the business, especially in something like PLT. When is it time for us to pick our heads up and say 80% of Rev ops leaders today, and I think it's something like that maybe a little bit less come from a sales ops background. Is that the right background for our heads of Rev ops today, and I had posted a poll on LinkedIn last week, basically saying what is the right function for your head of Rev ops to come from sales ops, marketing ops, CS, or finance. And then a lot of people had sort of added product and analytics to that. And it opened up this really interesting conversation, which goes back to what we've been talking about, related to the fact that rev ops, just Oh, so many different distinct functions that why are we defaulting to saying, Yeah, this one function that falls under REV Ops is where all rev ops leader should come from? And then that's not even taking into account the context of plg versus sales lead, like should those rep ops leaders look the same? Because I think a lot of them do. And is that the right background? So I know, I took us on a huge kind of segue. But I'm curious if you, as someone in the space have have thoughts on that, and sort of the evolution to come? Yeah,
Sean Lane 38:30
so I believe very strongly that there's going to be this intersection between kind of what you would traditionally think of as customer ops, what you would traditionally think of as customer marketing, and what you would traditionally think of, as we'll call it, product ops, but just product in general, right. So customer ops, product and customer marketing, I think there is going to be a very small subset of people who can operate at the center of those three things that are going to have like the superpower in the world that you're describing. Because what you need to be able to do is you need to be able to understand product usage, you need to be able to understand how that product you should should trigger specific communication to customers. And then you should be able to understand what humans on your internal teams should be able to do with that product usage and communication information. Right. So like, that's a lot. But I think that operators who set themselves up to sit at the intersection of those things, if plg is going to be the primary go to market motion for your company, those people are going to be able to set themselves apart and being really, really high demand, right? And so like, if you're talking tools, right, like maybe you know, your Pendo example, if you can be an expert in that and an expert in Gainsight, and then an expert in whatever you're using to send out the communications Gainsight to like, all of a sudden you are incredibly well positioned to take advantage of that particular motion. Does that make sense? Yeah,
Max Maeder 39:55
yeah, fully. Yeah. And I agree. I mean, it's just it is so I mean, obviously analytical, but I think the rigor of Rev ops analytics is getting so much deeper and extending beyond just sales analytics, and, you know, pipeline forecasting. On the pure sales side, which really was the the early origins of sales ops, Reb. Ops, and you get into things like product analytics. And that's when I think a lot of folks start saying, you know, head of Reb, ops and plg should come from a product or analytics or even finance background, I've heard a lot because by nature, they're just more sort of quantitative individuals that have been stressing that and kind of flexing that muscle for so long. So it's interesting to see where it'll go.
Sean Lane 40:49
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?
Max Maeder 41:00
Hmm, there's a book that I pick up regularly, but have been back at it recently, which is called think on these things. It's an Indian philosopher really just sort of helps shape perspective and view of the world, our life, our place in it. So I enjoy that to kind of, you know, help take a step back from things.
Sean Lane 41:22
Let's check that out. favorite part about working in OPS, I'm giving you an honorary in OPS here.
Max Maeder 41:28
I would say the ambiguity is again, like, as we touched on, like, these are the conversations that we have day in and day out is there is no right way in all contexts. It is all situational and contextual. And so I think the ability to just absorb from seeing so many different things, and then figuring out how to apply that to the, you know, ambiguous challenge that you're trying to solve is what makes it fun and continuously interesting.
Sean Lane 42:00
Flipside least favorite part about working in ups or with UPS?
Max Maeder 42:05
I think, I think the also touches on on some things that we covered, just the strain on the dynamics between various functions. I think it's brutal to see the directions that ops gets pulled in the number of people and teams that ops needs to please I think sometimes it can be a little bit of a of a thankless job. And so, you know, I talked to a lot of folks that that can be a frustrating piece. And it's just a reminder to kind of keep evangelizing for yourself and keep, you know, showing the impact and value of the work. But I know it can be easier said than done.
Sean Lane 42:41
For sure. Someone who impacted you get into the job you have today, I would have
Max Maeder 42:46
to say my wife who I was just talking to her the other day, and I was like, I would never be working for myself, if it wasn't for you who encouraged me to quit my second job when I was 24 years old, because I was like, I think I can do this. I can start a recruiting firm, and she was like, you should you should go ahead and do it then. So my girlfriend at the time now wife, I think I gotta give credit there. That's awesome.
Sean Lane 43:09
All right, last one, one piece of advice for people who want to have your job someday,
Max Maeder 43:13
I think well, for for me, specifically, I think it's and I say this also as a reminder to myself, but embrace the the mundane. I think what a lot of people will say about success is that your superpower is having the ability to do the things that other people aren't necessarily willing to do. So there's a lot of times running, you know, a small business where you're doing things that you don't feel like you should be doing at this stage in your in your career. But I think, you know, there's plenty of ops leaders that have gone to early stage startups and are back in a tactical role, I think, to get through to the other side, and particularly for folks who want to build something and really kind of leave an impact on that. It's just a reminder to sort of embrace the mundane
Sean Lane 44:09
thanks so much to max for joining us on this week's episode of operations. If you liked what you heard, make sure you're subscribe to our show, so you get a new episode in your feed every other Friday. Also, if you'd prefer we have a YouTube version of the show now you can find operations with Sean Lane YouTube channel. Last but not least, if you learned something from today's show, please make sure you leave us a review on Apple podcasts or wherever you get your podcasts six star reviews only. Alright, that's gonna do it for me. Thanks so much for listening. We'll see you next time
Today's episode is sponsored by fool cast 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 this Can the reps hit the street, you need to check out full cast with full cast that you set intelligent rule based policies that automate all of the time consuming manual tasks that hit Reb ops teams throughout the year. with virtually no effort operations will always seamlessly align with your plan. Learn more about full cast today by visiting full cast.io
Transcript source: Provided by creator in RSS feed: download file