Fridays are the new recording vibe, Jess is going to see the Backstreet Boys, and today’s episode has a lot of moments you don’t want to miss (especially on video). There are moments of laughter and moments of full on head in hands disapproval for the challenging topic of the admin as it relates to RevOps and the CRM.
Audio:
Video:
Additional Resources:
- [Blog] What Is System Design & Why It's Crucial For Smart Growth
- [RevOps Show] Episode 22: Get in to the Zone - The 3 Zones of Execution
Show Notes:
Why and when do you need an admin?
Jess thinks the why and when are about the same thing – when your CRM gets to a place where it becomes unruly, when you have anarchy and you need to bring order. That’s the why. The when is when it becomes an issue – when things are starting to slow down, when you lose productivity and the ability to track what you need to track.
Doug would agree with Jess that that’s what the world thinks, but give more context to anarchy. Anarchy is when you can’t do the things you need to do, can’t track what you need to track, or even can’t find the things you need to find.
Now, put yourself in an advisor's shoes. Someone comes to you and says we’re using XYZ CRM. Here’s my problem, what should I do? Is your answer to put in a CRM admin?
No. Jess explains we need to diagnose why the issues are happening and figure out the cause of the problem. And then that’s how you come up with a solution. It could be that you need an admin. Jess says it could be that you need an admin because if no one is paying attention to the CRM, if no one is maintaining the system, then you need someone in place. She doesn’t think that’s THE solve, but it could be one of the components of the solve.
No one is paying attention to the system, so you need someone to pay attention to the system. So we put an admin in place and is the problem solved?
When Jess says no one is paying attention to the system she means that no one is looking at it holistically. No one, for example, creates a form and a bunch of fields for the form and looks for redundancy. Are those items already being tracked? Where do you want those things tracked? What are you actually hiring the form for? People are just doing stuff to solve whatever the immediate issue or need is.
How is that different if you put an admin in place? It’s not necessarily different, but if you have an admin in place and they are overseeing the system holistically, they can be there to ask those questions and make sure when things are implemented that they are implemented in a way to not create redundancy.
With the admin in place, now the marketing person theoretically who wasn’t paying attention to the system puts in a request to the admin to create a form. If no one is paying attention to the system and I put an admin in place, now people need to clear things through the admin. But if no one is paying attention to the system, will they put in a request to the admin? No.
Jess said something that Doug believes is a false premise. In the beginning she shared the symptoms of when you begin to think you need an admin. When a different question was asked it wasn’t that the admin was the solve, it was that the issue with the system needed to be identified.
Doug believes you can’t not be paying attention to the system. Why? (This is a place where Jess pushes back.) The system is whatever is happening. This isn’t the system Jess was talking about. She was talking about the system as in the application/software.
The problem isn’t the software, the problem is the system. What does this mean? The system is the structure, the processes, the methodologies. What Jess is saying is we aren’t paying attention to the intent. If you have a CRM admin, they don’t have a holistic view because they’re living and using the CRM. The CRM is supposed to be an enabler, so instead we need to figure out where there is lack of clarity in the underlying business process.
There was a tweet that Doug found about the admin role that said, “It’s not marketing, sales or customer services job to keep the CRM clean, to make sure reports are accurate. It’s the RevOps System Admins job.” This is where Doug has a head in hand moment because he just can’t handle these types of posts, and this is what started the conversation we’re having today.
Taking a slight turn, lets say Frank is our admin. Frank wants to talk to Jess. Why? This is the question that would be asked if anyone was called in to talk to Frank. If this happened and you were in sales, you’d probably be thinking - what property did I fail to fill in? That’s unfair to Frank when you have to go and clear everything through. Going back to our forms example from earlier, if you create a form and need Frank to approve it, no one wins in that situation. Do you know whose job it is to “keep the CRM clean?” Everyone’s. Every person involved. Every person that touches it. When this doesn’t happen it’s not the admin’s fault. It’s not the admin’s job. If you tell Doug it’s the admin’s job to make sure there’s no redundancy, then he can guarantee that a whole bunch of redundancy is going to be created because that’s Frank’s job. What incentive does Frank have to eliminate redundancy? None because if his job is to address a redundancy issue and eliminate it, what do you need Frank for?
What Doug is saying is in the traditional sense of the admin’s job, Frank owns the CRM, but here’s the problem. Does Frank own the results that the CRM is responsible for? No. Is Frank responsible for figuring out how to create all the reports? No! The underlying idea of the admin is building low value friction. You’re creating an artificial bottleneck.
How do you build strong system design? We must remember the problem is almost never the technology, it’s the business process behind the technology. Is the admin who’s responsible for the CRM also responsible for the tech? Are they given authority over the business process? No. Is the admin responsible for sales results? No.
Is Doug anti-admin? No, he’s anti-dominant execution of admins.
What should an admin be doing?
An admin should be an analyst. If you’re solution designing, an expertise is needed that has a full understanding and a deep understanding of the technology. In very large organizations, Doug sees the admin role where they have specialized knowledge of the technology, but what gets brought out of balance is when the technology ends up driving the business process. This analyst role should be asking questions like, “How can we generate more juice for the squeeze?” and “What are the experiments that we’re taking?”
When the admin is the solution, you’re reinforcing an ineffective system and that’s where technology becomes heavy. That’s where bottlenecks come in. An admin should be a manager, they should be figuring out how to get compliance without anyone having to comply.
There are times when the tool isn’t being used correctly. There are times where the tool is not designed right. So when Doug sees people “not complying” he looks to see if the business process is clear to see if people aren’t complying with the tech protocol or the business process.
Doug isn’t anti-admin, he’s a fan of having people in that position. He thinks they could be doing things that would be more meaningful and valuable. Doug thinks a big mistake that happens in business today is we throw way too much data at way too many people. One thing the admin can do is make sure that people are getting the right inputs at the right time.
The role of the admin is a difficult and challenging topic to discuss because it’s a new role that everyone is talking about. The biggest takeaway from today’s episode is that the admin should be an analyst, a curator and a context creator.
Next Steps:
-
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
-
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
-
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
-
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
-
-
Subscribe to the show on Spotify & Apple Podcasts
-
Check out Let's Play RevOps on Twitch for more commentary on this topic
-
Listen to Episode 28: Is Revenue Operations a Wartime Discipline?