Interview with Zoe Jong, Director of Revenue Operations at Tasktop

Zoe Jong, the Director of Revenue Operations at Tasktop truly appreciates the science behind her work. Having started out in chemical research, her passion to fix and problem solve led her into the sales ops and revenue world. Zoe joined me all the way from Vancouver, Canada to shed some insight into what she has learnt.

Rory Brown (RB): Thank you so much for talking with me Zoe, it's great to have you. What would be great to start with is just maybe to get a quick steer on your career and how you landed in this wonderful arena.

Zoe Jong (ZJ): I took a bit of an unconventional route. I originally started in electric chemical research in fuel cell catalysts. I have a science and chemistry background in school. I've always loved finding out how things work and the bits and pieces of those things. That's what inevitably drove me to science. But, I think research is for a very special type of person. If you run the same set of systems and tests over and over again, and you publish and that's awesome and then you go back and you do the same thing over and over again, so I found myself looking for something that was just a little bit more project completion based, something that I could dig my hands into and fix and then see what I've achieved and maybe move on.

I found myself stumbling into the sales ops world. As I'm sure all operations professionals can say, it is a very, very changing and interesting job every day. Not only do you get the opportunity to work on much larger projects that could take anywhere from a quarter up to a year or even more, you also get the opportunity to work on these individual little micro problems every day that I think just satiated that need to actually complete something and see progress along the way.

RB: Am I right in saying you moved to rev ops officially in 2017? How would you describe in a couple of sentences the core differences between revenue and sales operations?

ZJ: I think sales operations is as it sounds, very sales focused. You make all of your decisions and you implement everything with sales at your forefront. Not to say that you're wearing blinders to the other departments, but it is so much so you're looking to improve and accelerate sales in any way possible. I think as I transitioned to revenue operations the idea was to look at the entire process a little bit more holistically; looking at everything from our lead generation, all the way through our customer retention. We have an amazing marketing operations side, and the rest of it I think just needed a lot of additional view and optimisation. My personal revenue operations role ended up being more focused on the handoff from marketing to sales and then through all the way to retention. We had such a strong team working on that lead processing and making sure that they're getting all of that right.

RB: What projects that are either recent or perhaps closer to your heart or you enjoyed or perhaps conversely you didn't enjoy that you might want to share?

ZJ: That's a good question… I would say we use Salesforce and what's coming down the pipe is that lightning will become turned on for all organisations. We launched the lightning UI throughout our company.

All of our revenue-facing departments, our customer-facing departments use Salesforce. It was taking each of their individual processes and workflows and implementing that into the new lightning UI, was definitely a challenge in trying to decide what of the new features and functionality would be things that we would want to get in place before we had people in the system just because it would be maybe too jarring for them to make that transition as they're trying to learn the new software. That was a pretty big project for us that spanned over maybe nine months. It was quite a large and extensive to try and get it right.

We've also spent a significant amount of time working on our transition into Zendesk as our new ITSM software. Actually, I've just spent a significant amount of time working on our contract optimisation, which is never the most fun thing to work on. But it is something that as you're growing from a small company to a medium-sized company that you really need to just reevaluate how you're processing all of your inbound and contracts whether it's come from how you're flagging them, handing them off to legal, processing them, making that visible so that everyone can see it. That was quite a big project that I think is always ongoing, but we've made some pretty significant changes using JIRA and Confluence to support that visibility and flow.

RB: So what was life like before the project? What started you guys into action to do something about it?

ZJ: It actually was a hiring of an internal counsel. Originally, we have had external counsel. What would happen is our sales department or I guess any customer-facing department would send through documents to sales ops. We would process them and then hand them off to an external counsel who would run a red line, bring it back to us and we would run comparisons, make sure it was all tidy and get it out to the customer. Once we had an internal counsel come in to play, I think that there's two pieces. The first piece is they are now working on not just sales contracts but also the company's contracts. There's a balance there where you need to be able to differentiate and support their workload. But also, now you have the ability to say, "Does it make sense for our legal to speak directly to sales? Does it make sense to have this bubbled infrastructure? If we continue that way, how can we interface in a really efficient way?"

Tasktop Technologies, the company I work for, does integration software. So much of our life is like, "How can we optimise the flow of information between our departments? How can we make this more visible and understand this process from the start to the end?" I think that there was definitely a sprinkling of that as well.

RB: Brilliant. So that was where you were. When you first decided to do something about it, who was involved and how did you work out what you wanted life to look like once it was finished? Because that to me seems quite a big leap if you've got to start there, right?

ZJ: Yes. We started small. Originally, it was just internal counsel, our sales ops department, our general counsel. We also brought in one of our colleagues, Dominica DeGrandis. She wrote a book called Making Work Visible, and her entire ethos and thought leadership is all around ‘where does your work come from, and what's blocking you’. We actually brought her in to meet with us during this process, as we were just starting figuring out ways that not only we could understand this process but also optimise it.

She helped us just by asking almost very simple questions, things like, "Where does your work come from? What blocks your work? Where does it go after that?" Taking those little, okay, "Let's ignore operations contracts and that other work that the general counsel was doing. Let's look just at that sales contract cycle. What documents are there? What are the differences between those documents? What happens if it's our paper versus their paper?" That was helpful in just getting us to the right questions at the right time.

Then the internal counsel and the ops department took a long time trying to decide what sort of software would be good for this. The ideal is some magical contract management system that tracks all of your special terms and all of the individual clauses so that, for example, if today I'm concerned about warranties, I track all of my warranties in Salesforce contracts. That's very convenient for me because I can run a report on it, but maybe tomorrow, suddenly we're concerned about open source. And I haven't been tracking that clause. This can cause quite a bit of operational overhead to figure out where we are legally with our contracts. We were in that really sweet spot, where maybe with a week-straight of work, we could cover all of our existing customers into some magical system.

There is a little bit of a long-winded answer, but that's where it started. Then it definitely evolved through a number of different softwares where we realised our customer base is the Fortune 1000. They are not interested in using our tiny company’s license agreement. We almost always start from their paper.

What we found is there aren't really contract management systems out there that really meet that need; that are standalone, where you could take bits and pieces. I think that there's a couple that are coming up through their evolution that are starting to get to that point. I think a year and a half ago when we were looking at this; none of them were there quite yet.

RB: Right. Technology wasn't a possibility. Fixing it with SAS wasn't where you should go. If you fast-forward to now, where people get a lot of values, what are some of the things that you implemented? We start there, and then we can talk about how did that impact the various different stakeholders around contracts.

ZJ: First and foremost, we did some pretty significant enablement with the sales team to help them understand what procurement looks like. For a long time, because we had external counsel, we kept that pretty separate. Once there was an understanding of “these are all the documents and this is what happened and here are the type of things that can cause red lines and can cause delays and here are our timing commitments, in mostly just explaining there's no such thing as a timing commitment.” Just as you approach a deal and every single deal is going to give you its own unique beautiful snowflake worth of weird stuff that you have to overcome to close that deal - every contract is like that as well.

As we get into that, it may be that it could take us three or four days to really go through and get all the approvals and everything we need or it could be something that we turn in an hour. It's not fair to say the legal SLA is two days and then miss that 30% of the time. I think it's definitely better to just explain honestly where those complexities come from.

The second step was implementing a system for all of us to track and view and making network visible. It may not be the best system to choose. I think that there are definitely pros and cons so I'm not going to go out and say everybody should do this. We decided to go with JIRA partially because we're a software company and everyone in the company has a user license, so everybody can have access to it. That was a really positive thing that it's really hard to find I think in software companies today, a single system where everybody has a log in albeit they may not be actually logging in. I think that the dual benefit of that is that it ties into Confluence. We created a Kanban board that just is constantly pulling things through starting at ops requested, ops processed, through the legal process, and then ops finalised, and eventually back to the seller; and then presented that board on a Confluence page with also some breakdowns of what other things legal was working on.

I think simultaneously giving them the visibility into where their documents were, the priority of those documents, how far along the process they were as well as providing some context as to, "Hey, there's only three things on the board, why is my thing taking so long?" Where you can see the other workload that's coming against our legal department especially now that legal isn't only like sales-specific.

RB: I like that a lot. So you had one place you could see the progress of your contract, particularly some notes on it if things were being looked at, a salesperson could basically report back to their client or whoever quite easily because it's all on there. Any issues with adoption with that? It sounds amazing and perfect. I've got my head in JIRA all the time, so I know it very well. We use it fairly well to be fair, but how did you find getting people that weren't JIRA users to use a different stylus system?

ZJ: I think even just for the people who have to be in it, so the ops team, the legal team, it took us a little while to get JIRA in a place where it was actually very functional for us personally. There was definitely many iterations of what those steps would look like, what those parts would look like, what the fields would look like. Of course, I don't know if you've ever tried to administer JIRA, but it is very difficult. It's meant for software development. As a result, they give you all of these opportunities to reuse and populate your projects and your views and your fields across all of your projects. Of course, coming into the system and looking to make a project outside of software development, there's maybe like 13 places you have to update. It's like first you create your field, then you put those fields on a custom layout, then you put those custom layouts in a custom type, and then you can assign those types to your project, then in the project, you can pull those in. That was a little complex as well.

Those iterations were easy because we're close. We're all in the same office, so it's really easy to ramp those up. I think from the seller side, it was more of a repetition thing. At the beginning some of the things were like, if you give us an NDA, we need these three things. It's just every time that comes through asking for those things. Then anytime someone pings me on Slack or pings us in an email or in any way, it asks about a contract, sending them the link to that Confluence page and just constantly saying, "You can see that here." Even if maybe that doesn't a hundred percent answer the question they've asked, it's ensuring that they're checking there before coming to us.

That took a long time. I'm a very, very strong believer that nobody wants to make change that doesn't bring them immediate value and saying, “look here and you can yourself read through this thing versus me just telling you,” although it feels like there's value to that and they can go and do that in self-serve without having to get ahold of us, a lot of people, they miss that immediate, "Oh, I can just Slack someone and they'll tell me exactly what's going on and I don't have to go to six other places to figure it out."

I don't actually think it is the sweet, deep value that we wanted it to be, but I do see that now many of them go to that page. We received significantly less ping saying, "Hey, what's going on with this? Hey, did you see I have this? I sent this. This customer really wants this because the customer always really wants this.” I think that it did take longer for the sellers to really absorb that. We did finally reach a point where now if we do receive an email like that, that email says, "Hey, I see it's still on the legal scoped board. It's been there a couple of days now. I'm just wondering is it being blocked by something, what can I do to help?" That, in my opinion, a much more productive type of outreach and communication than, "What's going on? Did you see?" type of things.

RB: I like that a lot. If we fast forward to today's world, what do you think the positive impacts of these changes have been? Do you look back at success criteria for the project? If so, how do you do that?

ZJ: I think that the extra benefit is, with JIRA you get all of the JIRA reporting, which is, of course, meant for software delivery, but it tells you what your burn down rates are and how quickly you're moving between stages and how quickly you're completing your cycle time and things that I think are intrinsic to software development. We were able to use that from a legal side of house and our internal counsel is extremely software competent. When we started this project, we were the bad guys. There's no other way to say it. We worked so hard to get this deal to a point where the customer is ready to purchase. Then there are so many delays or unknowns, or whether those were real delays or felt delays.

There was this idea that procurement's a big black box and things took too long to turn through our procurement and our customers are unhappy. Sometimes we push and lose deals and that's because of procurement. I had been able to, just using emails and my own flow Excel, been able to prove that that was not the case, that our customers were turning documents on an average of 30 days and we were turning them on an average of two. You're like, "Look at this. This is not true. We are not blocking you," but that's just not enough. Somebody saying like, "Oh, well, I did these. I crunched these numbers on this one quarter and I'm telling you it's not true," just doesn't feel like enough. One of the things that has been just insanely positive about this is we were able to, using JIRA, determine that our cycle time is down to four hours, which is insane. Given that you're balancing things that are actually taking probably four or five days, the number of things that we are turning within the same day is high enough that we're able to say, "You're sending it to us and we're sending it back and you're moving on," which I think is something that a lot of procurement and legal departments can't say. They can't say that they're, across a huge period of time, really seeing that improvement trickle down.

Then I think the second piece is empathy. Our sellers see this board, they see what we're working on, they feel like things are moving back faster. What we've seen is a 180 on that type of communication. Our sales leadership is saying at the end of a quarter like, "Hey, thank you so much from the legal team, from the sales ops teams, you guys have been so supportive and really helped us get to this point." I think from the individuals, we're seeing that as well. They're getting what they need when they need it, and if they aren't getting that, they're getting clear communication as to what's happening. I think it really has changed the relationship between those two departments very, very positively.

RB: Awesome. Thank you very much for sharing that. There's one thing, going a little bit backwards here. I'm referring to a comment you made about, was it micro tasks or micro-initiatives that you mentioned at the very beginning. It ties into a question we've asked a lot of people about, when you start off to do something new, how do you know how much time to give it before you either keep going and reiterate it, or you give up on it because it's not working, have you any formula for that or is it like field type thing?

ZJ: So for some of these kinds of micro tasks, these things that come up, I think when you've been with the company for a certain period of time, you look at every task you're like, "Yes, I could do that." You're like, "Maybe it's going to take me 30 seconds. Maybe it's going to take me an hour," but that's not a change that would be a huge barrier.

RB: Maybe if we take slightly more significant task. You've used micro in the true sense of the word! What's a step above micro, small projects? I don't know, say if you're looking to try some efficiency in the funnel and you implement some enablement and you want to see if it works?

ZJ: I think to give context to my answer; I want to rewind myself a little bit. I think when you work at a very, very small company, there's a certain aspect of sweat and blood is going into that company. I think that as these things come up, especially as operations grows and it becomes rev ops, and you start looking at this complete picture across five different departments, you can very easily suddenly become the bottleneck.

I think that there's this desire to say, "Yes, I got it. Yes, I got it. Yes, I got it. Yes, I got it," and then just push yourself and your team to meet all of those things. I've definitely made those mistakes in the past, and I'm really trying to take a step away from that and say, "We need to be more structured in this." I think some of the difficulty of operations is that you're not reporting to a single department. You report to five different departments and my direct boss being their bosses. You're kind of this amorphous blob that maybe doesn't always have its own company objectives on the strategy page, but you impact probably 80% of those objectives.

So the answer to your question is, I have been recently ruthless in terms of what kinds of projects get through. What that means is that we do planning at the beginning of our quarter. We decide what are the most important projects that need to get done in that quarter. There's always a little bit of space to bring in something that comes up that needs to happen. These micro-projects, the things that I was speaking about, these 30 seconds to 2-hour projects, those are quite high. There needs to be some buffer to accommodate for those to make sure that we're still doing maintenance on our previous projects or implementing small improvements that can move those other objectives forward on the strategy board.

As new stuff comes in, I typically push back and ask that department to, instead of having us implement that in this quarter, spend this quarter requirement gathering. Not just requirement gathering but also running experiments with what they think is the right thing. Because I think when we were young, we got to say, "Let's try this," and we did all of that. Then we failed and we're like, "Let's do something different." And that was fine. But time is really our most valuable resource here.

Instead now, for example, our marketing department, I mentioned that I think the operation side is really more around that handoff. We use MQLs, we use Salesforce, but it still feels there are too many places for people to check to make sure that they're addressing our leads and also picking the right amount of touches. That's something that can make you say, "Hey, I want to do this." In fact, you want to take a step back and say, "Actually, you know what, how many touches are the right number of touches? What cadence is the right cadence?"

We think we know but we've never actually enforced it. Is doing something in Salesforce going to actually improve this? Do we know it well enough to actually improve this? A lot of the projects that have come up, I think you send them back to spend a quarter requirement gathering, and by the time they finish, they're like, "We've changed our mind a little bit." I think that that’s positive. It's a positive change for my team and also for the other team. I guess that doesn't really tell you the walkaway time.

RB: No. I love this concept that people will ask for something, you say, "Well, rather than being this quarter," buying yourself breathing space, "let's do some experimenting. Let do some requirement gathering," at which point they probably come back to you quarterly so once you find a bit of a breather with something more specific in terms of what they want and then perhaps sometimes they don't even come back because they sorted themselves or they don't need it.

ZJ: Exactly. Or they find that even after a quarter, they're like, "Actually, we still don't really know it well enough, but we're going to spend another quarter doing that and I'm like, "Great."