Revenue Amplification Platform
Accelerate deal execution
CPQ (Configure Price Quote)
Quote complex products
Streamline contract signings
Renewal, expansion, & upsell
Where buyers and sellers meet
Barry: Jesse, before we nerd out, tell me a little bit more about yourself and your background, how you got into the deal desk role.
Jesse: So first of all, I’m based in New York City. I grew up sort of in the tri-state area and I’ve been in New York for over a decade now. I studied journalism and English literature in school and then went straight into law school.
It had always been my intention to be a lawyer and I loved law school. I came out of it excited and then I took the bar exam. And the trauma of that event and the reality of the job market, made me realize that I didn’t want to put on a suit every day and sit in a law firm for 15 hours.
So I had to pivot and I landed at a tech company on a legal team in a contracts manager role. Really, facilitating contracts, contract signatures, light negotiation with our sales team. And that’s how I got into the tech space of kind of marginally being involved with tech sales and learning about tech sales. And that role eventually kind of turned into a deal desk.
I think throughout that process and that time I started to get closer to sales and kind of reach a little further into their world than just the legal guy and what the legal guy would handle. And that really showed me ways that I could help improve the sales process and quote to cash. And naturally, that turned into a deal desk there and here we are, I’m on my second one now.
Barry: Well, that’s an awesome story. I saw, I think it was Grammarly, they have a legal operations position. Was that your position title when you joined that first company?
Jesse: The title was actually Contracts Lead. So I was leading a small contracts group within the legal team, light operations, but we actually also had legal operations, so they were separate. But I was sort of naturally the owner of our CPQ tool, for example, and deal structure. And that was sort of my entry into sales deals and getting more involved there.
Barry: It’s really interesting to see CPQ touch so many different functions, not just sales, but also legal.
Barry: For our guests that don’t know what a deal desk is, maybe you could elaborate on what that means to you and what it means in general.
Jesse: I think there’s an important reason behind that question because a deal desk looks different everywhere. It’s still this relatively niche concept that’s starting to expand in the industry and in various industries. Now for me, a deal desk is kind of a core cross-functional team that facilitates quote to cash.
Now, what I mean by that is kind of, a deal desk works with sales teams. A deal desk works with finance teams. A deal desk works with legal teams and a deal desk can be part of one of those teams. So at GitLab, our deal desk is part of sales operations. In my previous position at a different company, it was part of legal first and then actually moved to finance.
So I’ve been on a deal desk that was under three different functions at a company. And they’re all similar, you’re spending your day liaising on a deal desk. You’re working to facilitate these deals whether that’s speaking to deal structure, speaking to various business approvals, revenue recognition and other financial needs, legal issues that come into play with deals. Can we structure a deal this way under our policies?
Do we need specific language written to protect ourselves, etc.? It really looks different everywhere, but to simplify what a deal desk is to me, a deal desk is the center of the deal wheel. We’re the hub, right? And on that wheel you got these spokes going out to sales, finance, legal, customer success.
I mean, a deal touches everything. Right? A deal is core to what a company does. If there are no deals, there is no company, at least in SaaS. So ideally, a deal desk is a function that improves sales at a company and improves processes.
Barry: Thanks for elaborating that for me and for our listeners.
Barry: So I told our listeners and you, one of the reasons I found you was just through Google, I found GitLab has this whole handbook on how they function as a company. Not all links are accessible, though it’s pretty open. It’s an amazing site with so much information that I had to stop reading it because I could have just spent eight hours on it to see how GitLab functions.
Talk to me about the GitLab Handbook and how it started, and what your role is with the guidebook and why it’s public in the first place.
Jesse: Yeah. So we refer to it as our handbook. And I’ll start by saying, I very much cannot take credit for the concept. So to go back a little bit, GitLab is the largest all remote company in the world. So the company’s been out here for over 10 years and we have never permanently had an office.
There are more than 1500 employees in almost 70 countries, fully remote, no office anywhere. And so how do you facilitate a productive work environment when that’s the case? There is no office to go sit in a conference room and discuss policies. One of the company’s values is transparency.
And this all sort of comes together into this public handbook, where we give our team members and the public a view into our processes. And we kind of, it’s like we democratize information in that way. We make information available to everyone that we can in order to make us more productive.
With the handbook, I don’t have to spend time explaining to someone at the company what a policy is on X, Y or Z. I can send them a link. And that’s how we operate at this company. And I think it makes us a lot more efficient. I think it makes us more productive. And I think it just makes things easier. Now, my role in the handbook is related specifically to deal desk.
The GitLab handbook is company-wide and it’s really composed of more than 2000 unique web pages. That’s a lot of content and that’s a lot of different varying content. You can learn everything from deal desk processes, to some sales processes, to our CEO’s cat’s name, everything’s on there. Not everything, but most things.
And for me, my role is to oversee and manage the deal desk pages. When we have a process that’s created or changed or removed, we memorialize that in our handbook. Last year we created a new bookings policy that spoke to when we can take bookings. What are the revenue concerns in doing so as we follow ASC 606 and general revenue guidelines? There’s a lot of different processes and policies that touch deals.
And we make those public. Not only for our sales team, but for sort of the world at large, we want to share how we are doing. It’s not perfect. It’s not absolutely right all the time. But it’s really a group of decisions that we at GitLab have come to and that we’re confident in for our processes. And I think it’s great to be transparent and open with the world.
And it speaks to the kind of open-source, open-core background that GitLab is rooted and founded in. So for me, I think the handbook is really exciting. And you haven’t asked, but what’s even more exciting is that we use our own tool to manage it. So anyone on my team can go in and update our handbook page, whether it’s fixing a typo, rewording some language or adding a brand new process.
And I personally have the power to merge that into our handbook. So not only is it something that we manage, it’s something we can self-serve and really manage ourselves without a need to go up to an executive level or anything. So it’s just really exciting to me because it’s like a virtual home base for all of the things that we do. And that makes us, I think, a better function for that.
Barry: Absolutely. It’s really incredible. I recommend everyone go to the website and look at the handbook. But lock yourself at least an hour of your time because you’ll go into it too deep, as Jesse mentioned. How many pages? 2000?
Jesse: It’s over 2000 unique web pages and growing.
Barry: Right. And these aren’t short web pages by the way. And it’s also much more than a knowledge base because a knowledge base answers specific questions, but it doesn’t go into the full processes. It doesn’t go into as much detail as your handbook does. Would you agree with that?
Jesse: I definitely would agree. A great example is this page that we have called sales order processing. So at GitLab, our deal desk is sort of unique in the sense that we’ve actually combined the deal desk in order management functions. So deal desk being sort of quote to signature, if you will, and order management being post signature.
How do we book that deal that we got signed? What are our requirements? And our sales order processing page goes into all of our unique requirements to book deals, to accept deals. And we outline based on route to market. There’s a lot of ways to transact with GitLab. We sell directly, we have thriving channel businesses.
We work with some Alliance partners. And each different kind of route to market has different rules. And we lay them out very publicly in tables in very detailed dropdowns. And that’s for dual purposes, that’s for our sales team. If they say, hey, how do I book this deal? How do I get credit for this deal?
How do I get the customer their license for this deal? Right. What processes do we have to go through? It’s there. And similarly, it’s there for the customer. If we’re asking a customer to sign an order form, because that’s our policy, they can see the policy. This isn’t just a salesperson asking them to jump through hoops.
This is a policy that they can see for themselves on our website. And that transparency, I think, makes it easier to work with us and makes it clearer what the expectations are around transacting with us. And in that sense, it’s more than just a Q&A. It’s very detailed. It’s very specific.
And these are core processes. These are processes that affect how we manage our business, affect the controls that we have in place to keep us safe and compliant. And we keep as much of this online, publicly in a handbook as we can. And like I said before, I think it makes us better. And I think it makes us more efficient.
Barry: Absolutely. I’m curious, if it’s so detailed, it must take a lot of time to maintain and create from inception. Can you elaborate on how much time is required to maintain the deal desk handbook per month? And, how long would it take to create the handbook?
Jesse: That’s a great question because I actually just spent most of my day yesterday doing some handbook maintenance. I would say generally, it’s not something that we spent a crazy amount of time on because anyone can make updates. So anyone on my team can jump in and make updates that they need to make.
But if we are creating good strong processes, we’re not updating them so frequently. Right. So if you’re initially creating a new page that takes some work, but maintenance that I would say isn’t that time consuming, because we’re iterating. We’re making small changes here and there based on need.
We’re not updating this thing every day. But as I mentioned, yesterday I spent the bulk of my day creating a new page that some folks on my team had been working on building. And then it was finally time to go in, kind of put my stamp on it, make some changes and publish it.
And then it goes into, I think of it like, for anyone who remembers MySpace back in the day. How you would have a MySpace page. And we all sort of learned HTML to make our MySpace page how we wanted it. It’s like that. We published a new page yesterday for our order management function and I thought, I don’t really like how these headers are formatted.
And how I’m grouping subheadings under these larger headings and what the order is. And so I sat there for a few hours honestly, rearranging everything, trying to make it more readable because it’s not just that we need to have the good content out there, make it transparent, but it should be readable.
I actually need people on my team, on our sales team, on other cross-functional teams who are interested in our processes. I need them to be able to actually consume this content. It’s one thing to make it visible and to be transparent, but it’s another thing to make it readable. And I think that’s a little bit where my literature, journalism background comes in.
I’m really concerned with making it functional. I want people to be able to actually digest it, take it in. If it’s too complicated, too convoluted, not concise enough. These folks, especially our sellers, they’ve got deals to sell. They can’t spend an hour trying to figure out what I’m trying to say in this handbook.
And so it depends on where we’re at. Anytime there’s a new process, that’s where we spend more time updating this content, updating our handbook. I launched a new team last year, the order management function. So we’ve spent a lot of time building the process, documenting that process, as you would with any new function.
So it’s specific to why we’re updating the handbook. But even when it does take some time, for me, at least it’s a pleasure. Not to evangelize too much, but I genuinely love the GitLab tool. I think we have such a great product. And that’s the tool we use to do this work. And so I think it’s fun. It’s exciting.
Barry: GitLab uses GitLab. You should definitely tell your marketing team about this, and they’ll appreciate that. So it’s not just for our listeners. So absolutely. I think it’s really cool and it’s really nice to see. And I’m sure that it also saves you a lot of time on the flip side.
Barry: I think the next step would be to go deep into what the handbook discusses. And then two, help us learn a little bit more about deal desk.
Jesse: Sounds great. Let’s do it.
Barry: All right. So one of the first parts I saw for the deal desk piece was that there are six types of requests listed in the handbook:
So I was wondering if we could go one by one on those six pieces, talk about what does your sales team need from you when they’re asking for basic quota assistance? What is a basic quote assistance? And how does the deal desk help? And what is a ramp deal? How does a deal desk help with that? What is a flat renewal? I think you get it. So we can start with the first one. And again, how large is your sales team?
Jesse: So I actually don’t have a specific number, but I know we’re definitely over a hundred. Our sales team is global. So like I said before, we operate in almost 70 countries and we have a pretty strong sales presence in North America, all across India and also APAC. So we’re very distributed. So it’s a pretty big team and growing, as you can imagine.
Barry: Perfect. So there’s more than a hundred sales reps. And then how many deal desk people are on your team specifically?
Jesse: So my team fully, including myself is 13. Four of those are order management professionals. So I’ve got a total of nine deal desk team members including two managers.
Barry: So, what are some basic quote assistant questions that you get, for example, on a daily basis, do you get a lot, do you get more from certain people? Is it like an 80/20 kind of rule? Tell us a bit about that.
Jesse: Yeah. So let’s step back even, basic quote assistance. Now at GitLab, we’ve invested a lot of time, a lot of tooling, to make quoting self-service for our sales team. Meaning that in most scenarios, our sales team members are expected to build their own quotes. They are, as folks like to say, the quarterbacks of their deals. Right?
So it’s on them to create the document to memorialize that deal after they spent so much work and time building a deal that meets the customer’s needs and GitLab’s needs. Now that’s not to say that every salesperson is an expert in quoting, how could they be? Right?
And so while we expect our sales team members to manage the quoting process and build their own quotes, there are a lot of reasons why they might need our help. We put thorough instructions on this very page on the actual clicks that you need to make to create most quotes, but like anything else, this is something that gets nuanced.
Especially if you have sales reps creating deals that are a little complex, they might need a review. Or they might say, “Hey, I got this error. Can you help me figure it out?” And in many cases, that error is not an accident. That error is a guardrail we’ve put in place to stop them from doing something that we can’t accept.
And so when we say basic quote assistance, it can be anything from, “Hey, I got this error. Can you review this request?” Or, “Hey, I built this quote. I’m new. I’ve been here for two months. This is my first deal. I’m just not confident in the process yet. And I want to make sure that this is something the customer can execute and we can accept.”
And we will. But our focus on deal desk is on the more complex strategic deals. That’s where we would like to spend more of our time. So that’s why really we’ve created this self-service environment for sales so that we can focus our efforts on the more complex deals like ramp deals.
Now, to get into that, we call out ramp deals here, because the way that our tooling is set up a salesperson cannot create a ramp deal on their own. Now, a ramp deal, kind of high level, is a multi-year deal that is ramping. Meaning, over the course of that multi-year subscription, the customer is either adding users or the price is changing.
So you could have a three-year deal, for example, where each year the customer’s adding or maybe bubbling their user count. Or each year we’re increasing the discount. Maybe we’re using discounting as a strategy to meet the customer’s needs and their budget while also doing what’s right for our company and our pricing.
And we work with our sales team on those because they’re complex. They require some manual elements to our order forms to make sure that we are properly displaying what we’re selling and when, when it’s not a flat multi-year deal, same price, same user account throughout the subscription term. And I think a ramp deal can be a good tool when used correctly in sales.
Because if you’re really being strategic with your customer and thinking about their needs, any company wants its customers to need their tool more and more as time goes on. Any company is going to want their customer to add users to use their tool, right? And so the ramp deal is a chance to bake those additions in advance, right? You can, of course, buy a three-year deal and then at any point add users, talk to your sales rep.
But it’s one thing to have that baked in and you say, “Oh, you know what, March 1st, I’ve committed an additional 100 users in advance. So I don’t have to slow down when I realize I have more needs, I can just keep going because I already have that.” Also, kind of third item here. Flat renewal is a lot simpler than that.
It does not ramp, the customer is just renewing for what they already have, they don’t need more. We are focused on growth and helping our customers grow their functions. I believe that GitLab, the tool, is something that is going to continue to add value to our customers. And I hope that most of our customers continue to expand their usage, because just as I was saying to myself, I love using the tool.
So really these are different ways to sell deals. Like I was saying, we want our customers to expand their usage of the product. I was saying earlier how much I love to use our product to update the handbook. And I would hope our customers use our product and love to use it so much that they have to keep adding users.
So whether we bake that in, or whether we’re working with customers throughout their subscription to add users based on their need, really what you’re seeing here in our handbook is just different ways to transact, different ways to bake in user accounts and sell deals that are the customers.
Barry: I love that it’s so detailed and interesting. Co-terming. I’m skipping a few of the C and D, but you mentioned adding seats in the middle. Maybe you can define for our audience what co-terming is. And I think it said contract reset, which is, I’m not sure what that means. Maybe you can talk about it.
Jesse: Well, co-terming really is co-termination. It’s really creating a second deal that ends at the same time as another deal, right? And a contract reset in many companies might be referred to as a rip and replace. It’s really a tactic that we use to sell a brand new subscription, cancel out the previous subscription with the new one in its place.
And that’s another kind of complex deal scenario that our sales team members can’t execute on their own because of our processes and our tooling and our sort of approval requirements. But that’s just a way to deliver values to our customers based on what they need.
Maybe you have a customer who bought a deal in March for 12 months, we sell 12-month deals minimum. And come the end of the year they say, “You know what? I just got all this new budget, or I have all this budget I have to use before the end of the year. Can we kind of stop here and start over?” And we can work with customers to do that.
We want to deliver the best customer experience. And if that means you’ve got some budget and you want to use it for GitLab, we’re going to find a way to help you do that. Right? So our contract reset is sort of a tool to do that. But I’ll say throughout all of this, right, throughout the conversation of the complex deals, the ramp deals, the contract resets.
These are not hugely common at GitLab. I would say that we have a predictable deal structure and our sales team members largely sell rather simple, straightforward deals. I think our product is so strong that we’re able to do that. The reason we call these items out, these complex deal scenarios, is that they’re not standard. They are by nature non-standard. And we’re calling them out because something that’s non-standard needs to be explained, right?
Jesse: These are not scenarios that our sales team members are encountering every day as they sell and as they craft and structure deals. So we use this page to go into detail about what those processes look like. Because if I’m an enterprise account executive and I’m selling however few deals a quarter, I’m not going to be well versed in the sort of admin side of it. Right?
Because this is just not something I do all the time. It’s not something I do as much as maybe an SMB account executive who is selling a lot more deals in the same period who naturally just has muscle memory. Right? So that handbook is as much a source of documentation as it is a tool for enablement.
Barry: A sales rep might realize that you could do a contract renewal, for example. Or that you could stop a contract and start a new one because it’s laid out there.
Jesse: Sure. In a sense, it’s like a menu. What flavor of this deal can I come up with? Do I want a simple 12-month renewal for what the customer already has, because that’s what they need? That’s my grilled cheese. Or do I want this complex three-course meal that has different elements?
It might take a little longer to cook, but it’s going to maybe satisfy the palate a little more. There’s your ramp deal or your contract reset. I don’t know why I just made a food metaphor, maybe I’m hungry.
Barry: Jesse the journalist, the poet, the food critic. No, it makes a lot of sense. The way I’m viewing deal desk from our conversation is that deal desk helps you create more revenue because it lets you go against the rules and be imaginative within guardrails. It lets salespeople explore things that are not traditional, and creates more revenue. And then without anyone getting really upset then because there’s a support team, the deal desk to help you.
Jesse: For sure. And I’m glad that you mentioned guardrails. I think of the deal desk as walking a very important thin line. So the deal desk at GitLab is part of sales operations. We are in the sales department, we are aligned to sales. It is our role to support sales, to enable them to support deal creation, deal structure, and hopefully drive more revenue.
But at the same time, we are kind of guardians and protectors of this company. Our policies, finance policies, policies around revenue approvals, all the controls that we have in place. The deal desk team, in the same breath we’re driving revenue, but we’re also protecting the company.
And we’re making sure that our deals are compliant with our stated processes and procedures. So I think of the deal desk guard almost as, you’re a little bit like a politician in the sense that you have to please everyone while remembering the bottom line, which is we’re running a business here.
And businesses have rules and processes to protect themselves and that of everyone. So how do we make sure we’re focused on reinforcing those guardrails for sales while enabling them. It’s a careful line to walk, but that’s our role and that’s our function really in this company is to do that.
Barry: That’s so super interesting. I imagine it’s, you want to be friends with the sales team, and the sales team wants to be friends with you because they need you. But you also understand you have to put your foot down when you have to.
Barry: I think that’s another plus one for the handbook because then it’s not you putting the foot down. It’s the handbook that was created as a company and as a team that already has the rules and the guidelines, which might make that conflict resolution a little bit easier from a deal desk perspective.
Jesse: 100%. And a lot of these policies that end up in the handbook, the handbook is the end of the line. They start elsewhere. And we can point our sales team to, where we had this conversation, where finance said we need to have X procedure in place or legal said we need to make sure we’re complying with Y rule and how that entered into a process. But I think what it’s all about is trust.
We have to build trust with our sales team and we have to build trust with our legal teams, our finance teams, our other corporate teams and business functions so that everyone trusts that the deal desk is helping drive the correct decisions for everyone, for the customer first, for the company, for the sales team. Across the board, we have to have that trust and we have to make sure we’re driving results with it.
Barry: I had a previous podcast and we talked about the idea of trust, transparency, and teamwork. I feel like that’s like a recurring thing that I’ve seen on the podcast from CROs to deal desk managers. I think everyone can agree that these soft skills are super critical to revenue.
Jesse: I agree. I couldn’t agree more. And I think for myself and my own personal journey, it’s skills that have enabled my success. No one goes to school and says, I want to do deal desk. Right?
Barry: Not yet.
Jesse: Not yet. Not yet. Although I will plug, there is the Deal Desk Association group in LinkedIn run by someone named Steven Chung, who’s really great. And making a lot of efforts to evangelize and tell the world about the deal desk function. So I hope it’s growing. But for now, we’re in a place where it’s still niche enough that no one plans for that career.
But you fall into it, I think, if you have one of several backgrounds, whether it’s legal or finance, sales, operations, what have you. And I think you have to be a people person. Because like I said, you have to build that trust. You have to build those relationships.
I need my sales team members to be comfortable coming to me or any member of my team to just talk, to say, “Hey I just had this call with the customer. Here’s their budget. Here’s what they want. I’m having a hard time trying to give them what they need based on that budget. Help. How can we structure this?”
And it’s not even always about budget. Sometimes it’s about the product itself. Deal desk, we also have to learn about the product and understand how it works because that influences how we sell it. And building relationships and honestly having casual conversations with folks is a way to achieve that knowledge.
I’m not in a role where it makes a lot of sense for me to meet with our product managers all the time. But I like to, because I like to understand how they’re the product and what changes they’re making and how that might eventually affect our sales process.
And I think that that mindset has made me personally successful and our deal desk function successful because we make sure that we’re involved further upstream than maybe we might be. To make sure that the processes we’re managing, creating, changing, removing, are helping drive the business forward based on what everyone else is doing.
Barry: That’s great. Jesse, I can tell you that I trust you. And so I’m hoping that your sales team also trusts you. I imagine it would be hard not to. Jesse, I’d love to talk more. I think we could talk more about this for hours.
Maybe we’ll have to do that again for season three of our podcast and hear more about your journey next year. But this was amazing. I think everyone here should check out that handbook. Where can they reach out to you if they have any questions about the handbook or the processes or just about deal desk in general?
Jesse: I would say head to my LinkedIn. I’m trying to make my LinkedIn a slightly more exciting place, although I don’t spend much time on it. But I’m definitely happy to connect. I hear from new deal desk professionals all the time and it’s a pleasure to share advice.
Something I’ve learned in participating in this deal desk community is that imposter syndrome is real, especially when you’re in this niche function where no one has all the answers. But some of us have had a little bit more time to explore different ways of doing things. I will never say I have the right answer because I don’t.
And half the time, just like everyone else, I’m shooting from the hip. But I’m happy to collaborate with folks and share ideas and give feedback. So thanks for having me. And I would love it if anyone’s interested in learning more about deal desk or how we do things at GitLab, connect with me on LinkedIn and let’s chat.