Robert Gammon
Whoop Whoop! Looking forward to another GREAT AMA !
GOOOOOOD MORNING / AFTERNOON RevOps Family!!! and welcome to another Ask Me Anything conversation. Today I’m joined by our guest Richard Makara.
Richard Makara
Happy (the dog) and I are ready and excited to talk about growth engineering and all things RevOps! Thanks for having us 🙂
Robert Gammon
We have a ton to talk about today, but for the folks in the group who DON'T know you, can you give us a quick intro into who you are? What do you do? Why do you LOVE what you do?
Richard Makara
Absolutely! Once again thanks for having me 🙏 I’m Richard - Principal Growth Engineer at Paddle, one of the 3 core subteams in our RevOps org. Am originally a marketer - started in events marketing and organization, and as the questions of ROI and lead lists became more prevalent I ended up tinkering with CRMs and integrations (I had no clue what Salesforce was, but i was tasked to pipe Splashthat contacts over to SFDC lol). Over time I also learned software engineering skills and moved to a full Operations role at Paddle 🙌
There my job is to build the commercial data backend of the entire company. Sales, marketing, success, analytics data flow through the ‘engine’ that my team builds and maintains. Currently moving our entire stack to the ‘modern data stack’ model 🚀 Love Ops. It’s a never ending creative problem solving exercise.
Robert Gammon
Wow, great to have you. We love when marketers make the jump, if for no other reason than they’re fantastic story tellers and can bring focus to their craft.
So today we will focus on the tech side of Revenue or Growth for sure. What do you think the driving force was behind your company's push to modernize the stack ?
Richard Makara
Honestly, the main reason to undergo this process was a central piece of kit that did way too many functions for us (ETL, database, event tracking, data manipulation, Reverse ETL) got acquired and is being sunset at the end of this year.
So early in January we figured we need to cover our bases and get out sooner than later. We looked at all the functions that this tool was doing, and reverse engineered from there. We were also excited to join the hype of data warehouses, ETL’s and Reverse ETL’s 😄
So i guess the absolute driving force was necessity. The extent of our new setup however was fueled by talking to professionals around the world, consuming content from a lot of the vendors out there.
Let me get you a handy graph to make a bit more sense of this.
Robert Gammon
I think for most of us in operations necessity reigns supreme as the most common driving force for sure!
Richard Makara
So it's all split into components. Kind of like areas of responsibility. Components explained below, and then a bit of a map with actual tooling 😄
Robert Gammon
I want to come back to a quick comment you made in your intro about sub teams within RevOps org. Can you shed some light into how you all are dividing the lift?
…and wanted to make a quick shoutout to MIRO For the sweet visual architecture diagram! Great tool for anyone who needs to visualize a complex story.
Richard Makara
For sure! Currently the team is divided into 3 core areas, more by skillset/areas of expertise. In our RevOps team we have:
I am happy to dig into more detail in any of the 3 teams if y’all want!
Robert Gammon
I love the focus on USEABLE GTM data. Let's talk about that for a minute.
Can you give us an example of something the growth engineering team may have come across and determined NOT usable? In my experience it can be almost more valuable with the tremendous volume of data these days, to help your GTM teams understand what NOT to focus on and keep them looking at the most impactful insights. what do you think?
Richard Makara
Hmm. At some point we had this concept of intent data and we had spent time to build out some of those signals, and even some dashboards. The type of account level stuff where somebody researching a topic can be attributed to an account in salesforce. had some providers signed up that were sending us data. However, at the same time we had some foundational issues on lead routing, so actually it was far more distracting both for the reps as well as our team. The data was unorganised and we didnt quite know what to do with it. So we straight up suspended our subscriptions to these providers and focused on the basics — we rebuilt our Salesforce instance (a theme here 😂) and didn’t allow any fun and exciting stuff to even make it to our work schedule before the basics were covered. Now that a form submission on our website automatically turns into Account + Contact + Task + Ownership assignment in SFDC, we can finally entertain ideas such as intent data 😄 😄
Robert Gammon
"we straight up suspended our subscriptions to these providers and focused on the basics" <------- THIS is the kicker!
Ok so that is perfectly in line with what we see high functioning RevOps teams doing. Building the foundation and locking in the business process BEFORE spending time / money and the currency of trust your organization has in you.
So I can see where tooling decisions really come to the chopping block for the team. Given one of the three subteams over there are directly responsible for tooling, how does data, insights and engineering weigh in? How are decisions ACTUALLY made?
Richard Makara
Yass, thats a great one. There isn’t gonna be a simple answer to this and the classic ‘it depends on the scenario’ applies here but let me try to elaborate.
So when it comes to expertise specific tooling there’s trust in our sub-teams.
Data & Insights recently ran POCs with 2 data visualisation tools, and they decided to go with Tableau. It was their decision at the end of the day.
Same story with growth engineering, the tooling we are evaluating right now (and that we will mainly “use”) is based upon our expertise and due diligence. So for example, in that graph i posted above — we will decide on the Reverse ETL and the CDP.
Some tooling is vetted and brought in by engineering — Snowflake (our DWH) and Fivetran (ETL).
In terms of peripheral tools (such as Wistia, Metadata, Drift etc) there we heavily collaborate with the end-client teams. That’s sales, marketing etc. With these tools our job is actually to vet and make sure we can integrate them sensibly into our stack and data flow. That essentially means asking some tough technical questions from folk that are selling software to us 😄
Growth Engineering's primary questions are around data we can extract, and data we can pipe back in. We trust our teams to select the best operational tooling.
Robert Gammon
Thats a fantastic explanation. The theme of TRUST is strong for sure. I see this a ton when various solutions deploy marketing and sales collateral intended to "simplify" the messaging but ends up looking to the buyer (most often our partners in GTM) like a fully baked solution that is easy to integrate and will do everything we need it to do. It's always good to ask those tough questions.
Does your team ever look at a software sellers pitch and turn inward to ask yourselves if you could be doing things different?
Richard Makara
Im not sure I understand the question...when we get tech pitched and we re-evaluate if our plans are correct?
Robert Gammon
Basically, look at everything as an opportunity to test the methodology? like "Well, could we change the way we do something to accommodate this provider? And could that change make us even better, faster, more nimble?"
Richard Makara
Ah, mostly no with a little bit of yes. You should not bend over to a SaaS provider's needs / technical deficiency just so you can “use” them. You should be in control of your company’s process, data needs, setup. Simply for the reason that a provider might go bust, or simply not improve. It’s great to work with new tech that adapts to you, but equally need to be acutely aware that this piece of kit might not exist tomorrow. Equally, software should make your lives easier. If it's a pain to get it to work.. maybe it's not meant to be 🙈
HOWEVER, we 100% listen and evaluate what providers discuss with us. Sometimes there are angles we haven’t thought of, and could potentially implement. Recently had a good discussion with a CDP provider that made us realise that we probably should build our events table as one big dataset vs. multiple disjointed tables.
We often and openly share our tech stack and plans with providers we discuss with. The exact same graph and component slide has been shared with the tool providers we’re evaluating. That really helps them to understand what our setup is, and whether their vanilla model will fit us, or if we need to do some custom work.
Robert Gammon
What a great way of looking at this! "If it's a pain to get it to work.. maybe it's not meant to be 🙈." I couldn't agree more.
You hit on an important component of trust when you say "You should be in control of your company’s process, data needs, setup." The organization you support needs to know you "get it" and can guide them in decisions.
Fantastic! We are coming to a close.... any last advice to give ?
Richard Makara
You’re probably never too busy to stop for 15 min and draw a MIRO board, and evaluate whether what you’re building makes sense, fits the overall goal, is working towards your desired outcome?.
Also, the majority of mainstream SaaS providers have free or developer versions of their software. You can literally spin up an enterprise level HubSpot instance for free, and see what you can build. Same with SFDC. Same with Drift.
All in a matter of clicks too. 🙂 Great way to practice 🙏
Robert Gammon
What a rockstar! Great talking with you Richard, and thanks for tuning into the RevOps Co-op community! See you next time!
Richard Makara
Thank y’all for having me 🙏 please feel free to shoot me a DM if you've got any questions, always happy to talk RevOps and everything related!
Looking for more great content? Check out our blog and join the community.
.png)
