As Revenue Operations (RevOps) and Business Technology (BT) continue to make their way into more and more organizations, we’re finding that while the two teams are frequent collaborators, they aren’t always aligned on the best way to collaborate. We recently had a virtual fireside chat with two Systematic members who are also experts in BT and RevOps: Greg Paris, Director of Business Technology and Intelligence at People.ai, and Borys Aptekar, Sr. RevOps Manager at Instabase. The two tackle this issue of RevOps and BT alignment, discussing what BT and RevOps mean to them, how to align tech stacks, what goes into building BT and RevOps teams, ways to foster a data-driven culture, and more.
What do RevOps and BT mean to you in your company?
Greg Paris: To me, RevOps and BT are fairly new concepts in terms of how we think about services being provided internally. It’s an evolution and elevation from some of the previous models that we’ve had in those areas. As the name suggests, it’s about two different things, business and technology—it’s really this hybrid space where these two things come together. It largely evolved outside of the historical IT framework, which has become increasingly problematic in the modern day where technology is a more critical part in the success of any business, and traditional IT groups have been fairly disconnected and siloed from the business. So the emergence of BT as a thing largely came out of solving that problem: How do we connect the technology more into the DNA of the business, as opposed to a kind of tech only, siloed, reactive service that is not all IT but a lot of traditional IT?
Borys Aptekar: Evolution and elevation is a really good way to put it. RevOps evolved from a slightly different direction. You had siloed sales ops, marketing ops, and customer success ops—at a certain point, you realize that you’re all playing toward the same end goal, but because you’re playing in these separate teams, that kind of gets in the way. There’s this friction of handoffs and different understandings that get created. One of the things that I’ve seen during the course of my career is that the coalescence of process, technology, and analytics, and having a central ops team that has that full cycle understanding is really, really valuable. Again, don’t just have people focused vertically or focused on a particular piece of function. Technology has become that much more important and that much more of an enabler to the GTM sphere, in all the aforementioned business verticals. RevOps is this kind of coordination layer between all those things.
What components are crucial to having a successful alignment between BT and RevOps?
BA: There’s so much more you can get as RevOps by treating BT as an equal partner, because you’re trying to solve the same problem. So coming to them with your business context, like ‘Here’s why we’re trying to achieve this, here are the constraints that we have, the requirements that we have, can you design a solution for us?’ is something that I’ve found helps a lot on both sides of the fence, whether you’re RevOps or BT and asking for that from your partner. As RevOps, you’re a little closer to the ultimate business stakeholders on the GTM side, and so it’s on you to be that bridge, to understand their problems and work with the BT team to find the solution. You should also be living with your eye to the future, looking forward to six months, twelve months from now and building that roadmap and understanding what the future needs of the organization are. I think that plays nicely into what BT teams need as well—they need somebody to understand where we are going, what we are going to need, and what the priorities are.
GP: Even in the deepest technical discussions of solutions designing or evaluating alternatives, we should always elevate it to checking against our business goals and objectives. In the old model, we had a fairly clear delineation between people that cared about the business and people that cared about the technology, and there was this kind of handoff over the wall. Once those requirements were written down and passed over, everyone on the technical side focused solely on technical solutions with minimal reflection back on the business needs throughout that process, and this is particularly important for long-term projects because the business can be changing while you’re working on something. I’m always telling technical people ‘pull your head off the computer for a minute, look around, keep a pulse on what’s happening in the office around you, so that you can adjust and pivot where necessary.’ The business technologist has to find opportunities to remind everyone how important technology is to the success of the business, that there’s kind of two flavors of technical work that’s done internally: One part of it is keeping the lights on, and a lot of our attention goes to that, but we’re also building the rocket engine, the technical infrastructure, that’s going to help propel the company forward and without that, the company will be challenged to achieve its goals.
How does your technology stack change when you take a RevOps approach, and how do you navigate growing out of your RevOps tech stack?
BA: Generally, you’d have an ops team or RevOps team taking the lead on the GTM stack early in the company lifecycle, and that’s kind of the situation here at Instabase. As a company grows, there’s obviously specialization, and RevOps can take many different forms. At KeepTruckin, it was converted to a systems team, and we started to hire the right people to become basically a BT team. At Instabase, one of the consequences of the approach we’ve taken is we are focused on the GTM piece. We are focused on meeting the needs of the sales people and marketers on the ground, so that’s what has priority in the systems that we evaluate, the tech stack that we built. One of the things that we’re trying to be cognizant of is where we’re going to be in six to twelve months, what new needs are going to come up, and when are we going to have to evolve and say ‘okay, we need a dedicated BT team because we need things that are outside the traditional GTM stack.’
GP: The BT team often follows the ops or RevOps team in its existence, particularly in the early startup. So there is often a handover of technical responsibility of some sort that happens. The focus initially for me at People.ai coming in was inheriting a tech stack that had been put together by a number of different people over a period of time. Multiple people had the same needs and went and bought different apps, accumulating apps instead of building a tech stack—some people call it shadow IT. One of the first things I did working with ops people was to take a look at that portfolio of systems and tools, doing a full scale assessment, and from that, creating a GTM tech stack. We were able to identify the duplicate technology, find the things people weren’t using anymore, and the not so great pieces of software that people went out and procured that we wanted to remove from the tech stack. We then came up with a tech stack and documented it in a way that people could start to have clarity and understanding about what our technical footprint looked like at that moment.
How can you successfully manage the large amounts of data from the customer journey?
BA: In previous teams I’ve been on, we’ve always believed in the power of Business Systems/BT, combined with Business Intelligence (BI) or a data warehouse or a data team in general. It’s something that I’ve noticed plays well together. Especially in RevOps where you own both the process and the systems in the analytics. Well, the data comes from the system but you need to understand how that data is created, what it means, how it’s transformed through the journey, and what you’re trying to measure. I’m a big believer of having those teams intertwined closely, but if not, bringing your analytics team into the beginning of every project. Involve your data team early, make sure they have what they need. If you’re in RevOps, understand what fields you’re going to build, what the automation is doing, and what those data points mean to make sure that you can answer the questions that are going to come in.
GP: As the head of both BI and BT, my vision is that those teams can merge completely together. There shouldn’t be a delineation between data and systems as if they’re two different worlds, and that’s a very traditional model where you have a Business Systems and BI team that can be at opposite ends of the room. There’s a core service that BI provides to RevOps around enablement, more importantly around the underlying data to Borys’s point. To have success with analytics, you have to understand the underlying data, if you don’t, you might as well not even bother, because like it or not, we all have a lot of data. We have different systems tracking similar data and we’re not always consistent in what we call things—there can be a lot of confusion. So the BI team providing services around data model understanding, training, and documentation helps in having a good data dictionary. Systems and data to me need to have a full marriage where you can no longer tell them apart. My dream-team BT team are these multi-players where you’re not just a BI person or a BT person, where you can do almost all that and blur the line between the systems and data layers.
How do you go about building these teams and what are some of the skills or experience to look out for? In the hiring process, is there one way that you would choose to hire generalists over specialists?
GP: When you’re talking about the early stage, hiring generalists is what’s been successful for me. With the precious, limited headcount, it’s not practical to hire specialists. Finding generalists and supplementing that with consultants and contractors that can fill in some of the specialty gaps is really the place where I’ve started. It evolves as your team grows, where you then can have the ability to hire more specialized individuals. At the end of the day, I don’t see myself ever hiring anybody who is kind of one note. I think there’s more value in somebody who can always be broadening their skills. Finding a generalist in BT is not easy, it’s really hard to find people that have that unique combination of business acumen, analytical skills, combined with the technical confidence to be able to pick up tools they may not be familiar with and understand how to get up to speed quickly. Then add a third layer that’s almost equally important—somebody who has really strong project management and organizational skills.
BA: A couple of things that we look for are empathy—the ability to put yourself in the shoes of your stakeholders—because you’re not usually owning the same things as they are, but you need to have their perspective. You need to understand why they’re coming to you with the problems they are having. The other thing is your ability to communicate. Talking to someone in sales is different than talking to someone in BT. You need to have the ability to take the conversation you had, elicit the requirements and details that you need, and translate that into a conversation you might have with somebody that’s totally different.
Join the Systematic community to get full access to this and previous webinar recordings, and attend future events!
