7 GTM Tech Stack Mistakes to Avoid - Growth Edition
Your predecessor has done their best to set you up with a solid tech stack, but there are...quirks.
Your marketing automation platform is a bit of a mess, your CRM is usable (but clunky), and customer success is on a different, quasi-integrated system. Now that you’re scaling your sales organization, it’s time to get serious about demand generation and smoothing out hand-offs to customer success.
If this sounds familiar, the company has probably busted the startup bubble and made its way into the growth phase. Congrats! Now the name of the game is scaling efficiently, and by “efficiently,” we mean as low cost as possible.
Fortunately, you have access to enough budget to weigh going with a less expensive product or saving person-hours with a more robust solution. Usually.
Do Remember Everything Was Done for a Reason
If you’ve been with your company from the start, it’s easy to remember there was a reason you customized your systems. The customizations may not be useful today, but at one point in time, someone in the organization needed whatever is sitting there now.
As someone new to the organization, it’s really easy to be insensitive. I’ve been frustrated when someone has assumed I was an idiot for building something a certain way. After that experience I began work at a new organization, and I still was arrogant enough to turn around and do the same thing to incumbent administrators.
Over the years, I learned to seek to understand before giving advice. Ask clarifying questions and get to the root of why something was done.
Suppose the original administrator is no longer with the organization. In that case, it doesn't mean an executive doesn't look at the element as their pet project (even if no one is using it). Tread lightly and then set about doing the hard work of proving there is a better way.
Don’t Die on Every Hill
You will discover old customizations that aren’t being used. And you will also discover people who insist you keep those customizations no matter how much data you gather to show they aren’t being used.
An anonymous RevOps systems leader shared a real-life example:
“One of the company founders insisted on collecting use cases and workflows people were purchasing the product for--which their product team legitimately needed. The founder was convinced there was only one right way to collect the data. This resulted in three tiers of questions with about 20 options to review under each section."
“Unfortunately, the sales team dealt with the requirement by randomly checking boxes, which made it very difficult to conclusively prove that the data was garbage (if only they’d picked the first box every time!). When the founder started demanding the names of people who said they randomly pick options so he could call and chew them out, I refused and gave up trying to change the process. It wasn’t worth betraying peoples’ trust, and there were plenty of other things to fix.”
RevOps professionals typically have a to-do list many pages long, and no matter how many items they check off, new priorities take their place. It can feel like running in place. Don’t make it worse by fixating on every roadblock. Find another battle worth waging and put your energy there.
Do Prioritize Technical Debt
Change requests stack up quickly. Before you know it, the simple request you promised an executive you could knock out quickly ends up happening three months later.
Some things are too important to ignore. We’ve seen teams maintain sales compensation using Salesforce exports and Excel files for years, spend days every month manually merging data from disparate marketing systems, and try to make do with CRM reports with limited object joins rather than purchase a more robust reporting solution.
“I was using a big complicated series of formulas to manage territories. That’s faster the first time you do it, which seemed like a trade-off for assessing territory management systems and taking two weeks to implement something new. What I didn’t account for was that as the number of territories we were supporting grew, it took longer to maintain. I spent 20 hours implementing my own territory solution using a custom object, process builder, and flows in Salesforce. Every time someone needed a territory change (which could happen multiple times per quarter), I saved five hours with the new solution--which means that within four territory changes, I had made up for time spent on the implementation.”
It can be hard to convince people that a RevOps process improvement is worth putting off, say, refreshing a sales process. The way to convince leadership is by calculating your opportunity cost if you continue to put off addressing technical debt. Using the example above, Lance gained the bandwidth to complete one major project per quarter with the time savings gained with the new solution.
Don’t Leave Your Experts Out of Key Conversations
Projects to prepare your business systems for scaling will come at your team fast, and it’s impossible to stay caught up unless your business scales your department to keep up with the organization’s demands. Sometimes, the delay in getting something a business leader perceive as simple to do will inspire them to get “creative.”
This usually means either buying a tool they think will solve their problem or hiring someone to install something for them.
We’re not saying outsourcing is always a bad thing. If you do your homework and hire someone very good, it’s a great way to augment the technical side of your operations team in the short run. However, you can’t expect a fantastic consultant to come in cold turkey and know potential landmines they’ll face during their project.
“I see people succumb to a common mistake: ‘Because my manager/leadership wants this, we need to get this project done now. If system administrators are not available, let’s hire consultants and get it done. No need to involve any of the system admins. We'll figure out everything or the consultants will figure it out for us."
Dhairya goes on to say:
“Before starting a project and hiring an external consultant or consulting firm, make sure you have the following ironed out - Why are you doing the project? Why is this important? What are the business objectives, completion timeframe, time you can commit to helping, and what does success look like? What are the clear and measurable outcomes for the project."
"Last but not least, make sure to involve your System Administrator/Architect so s/he can provide insights about your system setup.”
Do Consider Hiring More Expertise
Contractors are great, but they’re expensive long term. Each time you have to hire a different contractor because your original contractor no longer has time, that’s potentially weeks you now need to spend catching the new contractor up on why your system is the way it is and what has to change. Contractors also have a limited number of hours they can dedicate to your projects.
Hiring a full-time person means 100% of their working hours are dedicated to your company alone. They’re also likely to be at your company a lot longer than a contractor.
Another reason to hire a full-time employee? Overloading your one RevOps professional will lead to missed deadlines, an increase in mistakes as they scramble to do everything themselves, and lost efficiency from forcing a single person to try to master everything. It’s more efficient to hire people with expertise and split the workload. Otherwise, your RevOps professional will burn out and leave.
“I spent two quarters trying to get free trial form submissions to flow through Segment into Marketo and SFDC to only be foiled. Every. Single. Time. And then we hired a RevOps manager who comes in and gets it set up in less than two weeks via Zapier.”
Don’t Get Too Attached to Old Solutions
Switching to something new can seem daunting, but it's essential to be objective. Not selecting a different vendor may mean missing out on the ability to scale quickly. Emotions can get in the way when you’re asked to give something up you've built from day one.
Sometimes the right answer is to stay the course, but make sure you’re doing it for the right reasons.
An anonymous RevOps systems leader said:
"A few years back, I had an opportunity to assess whether a growth stage company kept their existing marketing automation platform, moved to a new platform, or blew up their existing instance and started over with the same vendor. The system's process flows were a mess, but their integrations were working exactly as they should. Seeing that this wasn't the case with other vendors, I chose to overhaul the processes in the existing instance."
“I regretted my decision pretty quickly. We could have replicated the integrations easily in that particular tool and started with a clean slate. Instead, we saved time on integrations but had to investigate every program in the system to figure out what it did, and we were stuck with over 300 junk fields because the vendor didn’t allow users to delete unused fields.”
Don’t Let People Punish You for Being Efficient
This point was in our Startup Edition, but it’s important wisdom for a RevOps professional in any company.
Insist on scaling your RevOps organization proportionately to the departments you are supporting.
I have met a lot of brilliant RevOps professionals, and all of them are stunningly efficient. They can get more done in two hours than most people achieve during their entire workday. Because they prove themselves as competent, capable people, leadership tends to forget they’re also human.
It’s not sustainable to work 60-hour weeks for years at a time. Find a boss who will support you with additional resources when you need them. Don’t spend too much time working for a company that doesn’t value both your work and your health.