What It Really Takes to Sell To Developers and Engineers with CRO @ Komodor

When I started, about 40 employees, a little under 100 right now in less than a year. So we're growing, but we are purely enterprise motion. So no commercial, no SMB, no PLG.

Yeah, I think that's super helpful context, especially since we're going to be talking about sales today. And then yeah, just one other icebreaker question before we let you get into your slides that we like to ask everyone. We chatted about this a little bit before we went live. We usually ask folks what's their favorite, like, one app that they're using and their tech stack. But it sounds like you've got like a whole suite of products that you're using that's working well for you. So, you know, tell us a little bit more about that. What do you like? What's working for you as a CRO?

You know, I, I, it's a composite of, of SaaS products. Um, and it depends in, in sort of collaboration with marketing. We use things like Seamless. Um, we use Outreach. We use products, everyone that I know pretty much uses HubSpot and Salesforce. We use both of those. I would say though, like, you know, you're managing different processes, parts of the sales process with different tooling. The one thing as a leader that I probably like the most, because I'll always build it from scratch until we have a strong skeleton model for it, is forecasting tooling. Salesforce has never been strong enough in this area for me. So I've used Aviso and Clary, but mostly Clary. So if I can say something that saves me a ton of time once we get big enough to fully utilize it is forecasting tooling. And Clary would, Clary would probably be my favorite.

Awesome. No, they've been a past partner of ours, so that's a good, good shout out there of a few different tools. And with that, yeah, we'll let you take it away. And as always, guys, if you have questions as we go along, drop them in the chat. I'll help moderate questions either during or at the end. Um, without further ado, uh, let's talk about what it really takes to sell to developers and engineers.

Yeah, so I want to open up with everybody. Uh, one, thank you for even giving me the time. Um, I, I believe strongly in community and specifically the sales community. I even have my own Slack channel with about 60 other, um, CROs, heads of sales ops, that we always are talking about things like this, uh, enablement, comp plans, of just ROE, rules of engagement. So just to have the opportunity to speak with all of you today and share some knowledge is, is great. We'll quickly cover my background. We'll get into understanding the developer DevOps audience. So the type of engineers that I've historically sold to. I do want to sort of begin it before getting into detail, talk about what I've learned working for Series A through C startups, and that's don't boil the ocean. I think when you're sharing knowledge, talking about fundamentals is extremely important. And then the, I don't know, the onboarding success plan, that's a bullet that we'll have to edit out. I thought I deleted that, sorry. But you know, my background real quick, I've been selling now for over 20 years. I've been out in the Bay Area since 2002. I think it's important to note my expertise in the area of selling to developers and DevOps is really 10+ years. But also, like, when we're talking heads here and we're sharing our knowledge, no one has the perfect playbook. And I see it all the time. Everyone's like, oh, what I know is sort of— I'm omniscient. And the answer is no, I'm not. So if I can give you 10 to 20% of additional knowledge that you can learn from today, that would be phenomenal. But I'm as much of an expert as my experience lets me to be, but so are all of you. And so if you have questions, if you have ideas during the session, please feel free to share. And then in closing today, what I'll make sure we do is if we don't have time, I'll try to give SaaS to the SaaS team, leave behind different assets that if you want from the presentation, you can use. But I'm not going to go through my whole background. Below is just who I am. So working with Dev and the DevOps audience. First, a lot of things come into play. And when I was, I was asked or given the opportunity to present today with all of you, it wasn't as easy of, oh, let me just share my knowledge, because the hard part about these discussions is it depends on your vantage point. Like, so your product market fit influences a lot of what we're going to discuss and what you take away from it. So selling motion matters. And if you're, so if you're high velocity commercial mid-market versus enterprise, the type of land and expand could be different versus what we're covering today. So again, what I present is meant to be at a macro level. However, you know, if you have questions specific to your situation, we're happy to take them if time permits. The other thing is Commodore is the first company out of the last 5 that isn't a product-led growth motion. This is where purely sort of sales-led enterprise inbound outbound, that matters a lot and we'll get into that. So again, your selling motion and how you look at these personas in this audience and where they are in sort of their flywheel or their sales cycle matters. Where does your target company profile land on the technology adoption curve? This is the sort of crossing the chasm, you know, innovators, early adopters, early majority, late majority, laggards. This also matters when we're talking today because it's all about positioning and selling to the right audience. And the last thing is, you know, how mature is the market in recognizing your solution? I generally like to work for companies that are solving, provide a solution to an existing problem versus trying to create the space. And so again, if you have to educate people on, So the existence of the problem before helping them understand how to solve the problem. Some of this could sort of— the impact that we're talking about today could vary. So again, a lot of things come into play when we're covering the topics we're covering today. But again, that's why I would love to have questions from all of you because I think opening up to a broader discussion will help. Second, and this is really important as we get into sort of the personas. With this audience, specifically, you know, going back to when I started working with the developer DevOps audience in 2013, 2014, what I learned, which is so different from selling to finance and HR and sales and marketing, was depth matters. These people, like, if I go back to when I originally started my career, it was Anderson Consulting, became Accenture. Part of my job as an analyst was programming, and I learned COBOL and C++, and I was horrendous. Potentially the worst developer I've ever met. This being said, what I learned was this is a craft, and, and what this audience does is they're artists. And just like in sports or athletes, there's a top 10%. You'll see that here too. And, and they really are passionate about what they do. They're passionate about the products they leverage to help them do their job better. But like, they're artists. And if you see really clean code, if you can see what these guys, what these individuals do, You'll be amazed by like how you sell to them and, and what matters. So I'd say the thing I know about this audience is they get us. They know you're selling them a product. They don't necessarily love salespeople, but again, they do love their craft. And so they're never thinking you're gonna sell them the silver bullet. They— and if you promise them that you are, they're not gonna trust you. So there's no BS in this audience, but the quality of the experience, like how you follow up, how your product delivers in the POC, that's what really matters. And so it's more like project management and, and running a plan than it is about sort of your artistic ability to sell. So normally, uh, we're startups and we're selling, we're a lesser-known company, we're selling to enterprises, we're selling to mid-market. Um, they want the product, they have a certain desire for the product, and like, like all of our audience, they want low risk, high reward. So they don't want to take a ton of risk in what they're buying. They want to know like what you're gonna sell to them, you're gonna deliver on, but they also want high reward, high outcome. So you always hear that term, well, no one ever got fired for buying Microsoft or IBM, name the huge company. But if we're gonna get in there, you know, we need to win them over with trust, with support. And so the buying experience really matters. Like keep it as simple as possible with this audience and be very direct with your value proposition. And like I already said this, but the don't BS, the truth will come out. Again, they build these products, they know the ins and outs, they are forgiving. But if you're not honest and you try to sort of sell them something that is, I don't know, like bulletproof, they're not going to believe you. I would say, you know, so as a person selling them this product, know your audience and be hyperfocused on targeting and learning from that target. By learning, what I've learned about this audience is Feedback loop matters. They want to know they have a true partner, and they want to know that they can be a product partner. So you don't have to tell them that you have everything from a success criteria that they need on their list, but you got to talk to them about what you do have and what you don't have. And if what you don't have is a must-have, be honest about whether or not you think you can fit it into the roadmap, but show you're listening. Um, they want to build with you. They're builders. Um, no product is perfect. You know, I already covered this, but just knowing your product market fit, knowing who to anchor on is super important. So the developer and, and DevOps is a component of sort of the engineering org. But back in 2011, Mark Andreessen wrote, wrote an article in the Wall Street Journal, uh, as an op-ed of why software is eating the world. And what's really interesting is, as I've sold to this group over 10 years, you saw the dynamics and the culture of companies change. You saw marketing and manufacturing companies go from thinking that they're marketing and manufacturing companies to becoming, thinking they're software companies. And you could see this in the, like, if you go look at insights in LinkedIn and you look at the composite and employee makeup, you'll see that a lot of these companies that historically had low developers, low engineers grew dramatically. So I would say Andrew J. Sonnenfeldt was right. We saw that software did eat the world and companies generally became or thought of themselves as software companies. And, you know, this sounds like a negative term, but again, Andreessen coined this phrase back in the 2010s and said nerd power. And what I believe Mark was saying and what I saw in selling across the globe over the past 10 years was the, the perspective of how people saw the developers from a cost center to a revenue center. The, the developers create revenue just as much as the salespeople and marketing. And so if every company sees itself as a software company, what does it say about the person responsible for building that software? Well, it says they have power. It says they have influence. And, you know, that's why you can do a lot of sales versus top-down, bottom-up with LANS. You can get a lot of power through developers at lower levels and, and sort of lower-level first-line managers than you could in other types of sales. I will say something with a caveat. I was, I love selling to this group because they, they generally have the power to buy and buy quickly. What I did see was after COVID in '21, '22, the pendulum swung back a little. And so where they had absolute power and budget, you saw sort of the typical top, top-down stuff come back into play. So when you're thinking about this audience, you always have to think about being multi-threaded now. Where before maybe you could move quickly and be single-threaded, like FinOps and, and just finance has come back into play much more than they used to. And so when you're winning with this group and you've got momentum, make sure you're mapping to sort of true power. And if you're going to have someone come top down, what has come back into play is finance coming in and saying, whoa, slow down, you know, you can't just buy everything you want and you've got to be able to manage through that. So just a quick note there. Great group to sell to. They can move quick, they can evaluate quick. But you know, you do have to map like you would historically in enterprise sales. So selling to engineering, I wanted to cover ICP. And if a lot of you know these first couple of slides, great, but I wanted to make sure for a broader audience we cover this. And then I want to go into specific personas you see when selling to engineers in this sales cycle. I'm pretty sure all of you've seen, um, these two charts on the right before, but when we're talking about our ICP or our ideal customer profile, I think it's really important, especially if you're at a younger startup and you're working with founders. Um, founders like, in my experience, I shouldn't sort of paint with a, a wide brush, but in my experience with founders, they generally think their product can help everybody. Because they were the initial people selling and they've sort of caught, they brought in a couple of deals that run the spectrum of different types of company profiles. But this can be super dangerous. And I would say when you're thinking about your audience in this sector, know them, like don't boil the ocean. Yes, we can help everyone, but who can we really help? Like who really cares about the solution we're providing for the problems we think we're solving? So Again, when you're working with founders in your earlier stage startups, make sure you're hyper-focused and you agree on ICP and you agree on top targets. The other thing I'd say is beware of the left of the chasm down below. So your, uh, innovators and your early adopters are amazing. A lot of times in the West Coast of the United States, these are all the big logos that we all want. They are builders, they are phenomenal, phenomenal engineering organizations. Why would they need you? And you have to think about this with, especially with PLG open source. Like you're putting a lot of yourself out there, which is great, but you're giving it to an audience that is very much put together. You know, I'll say it, they have very large egos and maybe they should. But like when you're thinking about selling to this audience, definitely know who you can help and do they want your help? Because, you know, zero times zero is zero. And I often find that while I love talking to innovators and early adopters to the— from the— on the left side of the chasm, I do worry that they're more just trying to learn from us. They're never really feeling the pain or think they need us. So I generally like to look to the right of the chasm. Which segment has the best product-market fit? Totally your call, but you really do need to know this from a velocity standpoint and enterprise versus commercial velocity because it has a lot to do with your partnership with marketing. Your enablement, your messaging, your assets as soon as possible, try to lock in and fixate and focus. And then, you know, developing a top target list and testing. I generally find for this group when I'm trying to build, you know, I will say, well, let's go boil the ocean. Let's pull everything that we can globally, at least out of the major APAC, EMEA, and AMER markets. And we'll figure out, like, we'll boil down that list from from, okay, there's 50,000 potential companies down to maybe 10,000 based on their tech stack. You know, are they using competing products? Are they hiring for certain roles in their job boards with certain sort of technical requirements? And then one thing I generally would say, you know, software is eating the world. I want to find early adopters of technology. I generally find that if there's a percentage like 15% or more, depending on the, the industry or sector, of an engineering-to-employee ratio. So hey, I'm looking at Company A, they have 2,000 employees, but 500 of those are, um, developers in IT. That tells me 25% of that group is focused on, on building technology. That is a really good target. And so I'd say is you need to know your own attributes for how you want to build and focus on this audience. But building a top target list early so you can break down the world and then be hyper-focused on top targets goes a long way to finding momentum. So again, enough of, of me preaching there, but I wanted to make sure at least, you know, we're talking about ICP, you have a, an approach that works because this is the area, like what's not on our side is time and where we can just spin useless cycles is thinking we can help everybody. And this is ultimately where we fail, because if we can't build pipeline quick enough, we're not going to hit our numbers and we all get replaced or the company goes under. It's as simple as that. Way too much on this slide, but I, I, I wanted to show you like each and every one of these except for engineering leadership. When we talk about engineering and Dev and DevOps, like these are all different areas that could have their own sort of ecosystem. And generally you can sell to some, specifically just one of these personas or all these personas. But when you look at the general breakdown of a software org or an engineering org structure, this is how we see it. Leadership is pretty consistent from CTO, CIO. It's like, you know, a Fortune 100, Fortune 500 company, the CIO might be more relevant than the CTO. But like VP, SVP of engineering, engineering managing directors, and then the engineering teams, a lot of your products in this space will be specifically focused. Mine is more on front-end, back-end engineers and DevOps. That's where similar if we were focusing today, and maybe data engineers. Those are the, the groups that we would sell to. But for all of you, you just need to know who your audience is and you need to make sure your messaging relates. And then there's, there's support teams. There's— this is very vague. I could have added like 5 more bullets, but again, very generic breakdown before we get into the personas. What I'm going to focus on today is sort of the core ones around developer DevOps and really the how these sort of where they, where they play a role in the general sales cycle. Anything yet, Amelia, that you want to cover? Are we good?

Yeah, I think there's like 1 or 2 questions here that are relevant before we get further in the weeds. There's one from Alfonso, which is relevant on, I think, the last slide you were on about AI, right, and its impact on this ICP. So the question is, AI has made executives believe dev expertise is less valuable and necessary. Do you feel like your product specifically advocates vertically up to executives or horizontally to devs? And there's kind of a related question on the livestream too.

I don't know where I am in agreement on the first point. I, I don't know that. That executives or senior leadership feel that AI has made developers, I don't, I'm not gonna use the right phrasing here, but less impactful or less necessary, that skillset. I think when you look at AI, it is a facilitator. It's a complement to expediting velocity and productivity. I don't see a lot of ones that have total faith at least in the sectors that we sell to around the world, that that would be a truth. What I do think, like, the AI component, Claudia of Commodore's product is awesome. And I say it's awesome because when we see it play out, like, it works as a partner to the developer and to DevOps and SRE and platform engineering. And it has, it's had a ton of use and we can see a ton of value just in the past 6, 7 months since we've rolled it out into our product. And so I think what people do is like, You know, this is like all of us, they're, they're juggling a bunch of things. Like, and, and developing and shipping is just one thing what they do. And so if it can help them problem solve and troubleshoot faster, they are elated. Now the problem is quality of AI. A lot of AI is, is hallucinations and there's a lack of trust. And that's also why I don't think executives think, oh, AI can replace because even AI, like, depending on how you've built it, can be trying to boil the ocean. And if it's not hyperfocused on the problem at hand, you, what you get is a lot of vague answers, a lot of sort of superficial things that actually could cause you to waste time. Because it's, it's not relevant. The answers are incorrect. And so I think it's how tight the AI model is, the AI product is. But overall, I think people really believe in it. It's used to facilitate and make us much more efficient and effective. But I don't think it's, it's sort of lessened the value, but I might not, I don't wanna sort of, That person's question, I might not seeing it from the right angle, but it's a great question.

Yeah, it's a good question. And then a related point, you know, you, you started the presentation talking about selling to dev, and then now we're going into engineering in the sales cycle, right? With, with basically that asterisk you mentioned of CFOs are getting more involved too. Like, I mean, who do you see now in the buying committee, right? Like, it's, you know, For this audience specifically, I think it's hard to do it. I think on both sides, who do you see, right? That's kind of the question we've gotten on the livestream is like, who do you see on both sides of the table? So like if you are selling to developers, who do you see on their side? And then who are you bringing on your end, right? To make sure like if you've got, you know, I don't know, a junior rep that maybe can't speak all the technical language, like who are you bringing in to make sure the deal still gets done?

Oh, so those are two different questions for me. One is like, who do I see involved in the buying cycle, which we're about to go into? And then two is like, how do you bring in someone? I think, like a more junior rep, you, you go to where your strengths are and you take it as far as you can. But like, at the end of the day, our goal is to bring on revenue, right? And so a lot of times, especially when we're earlier in our career, we want to do it alone. We want to prove ourselves. But like, as I learned, as I've grown in my career, like, I will pull people in early and often and, and consistently because I know I know where I'm strong and I know where I'm weak. And all I care about is, is getting that deal done and bringing in that partner and developing that partnership. And so anything that can enable me to do that, I will do that. And so I think it's situational. It comes down to your experience and where you're comfortable. But what I would tell you is don't try to do it on an island or you're probably going to get stuck in that island. And the best thing you can do is figure out how to leverage resources around you. To get the deal done. So, you know, at Commodore, we're always doing that. It's the best company I ever worked at for like the executive involvement in helping us get deals done. And like normally I have an ego and I don't want Ben, our CEO, to come in, but Ben's involved all the time and it helps us get deals done. And so even for me, I know where I don't have Ben's technical expertise. I don't have experience. He built the product. And so when I think I'm going to get stuck with a certain persona, I will prep with, with Ben, I'll prep with the SEs in advance and like we'll all know our part. But I, I sort of try to, I try to, if there's kinks in my armor, I try to sort of make us, make it so we're bulletproof and to remove those kinks by involving as many people as possible.

Yep. Makes total sense. So there's one more question I want to hit on Kareem before we go to your next slide. So let me see if he'll come on here. Kareem, you wanna come off mute and ask your question?

Yeah.

It's related to the ICP curve. Yeah. Go for it.

Yeah, so you can waste a lot of time on customers who aren't in the right, like, part of the curve for you, as you were saying. Do you use any tools to figure out where a company or a profile might be on that curve and to understand if it's a fit for you?

Well, Kareem, and I don't mean to sort of throw a question back at you, but it would help me. Are there tools in general that you're thinking of? Because I've built a lot of stuff from a top target list internally. But I also might not be fully hearing the question. So if you can maybe narrow it down for me of, of type of tooling you think would be an example.

Yeah, I, I don't know of any out there, but I'm just wondering, you know, if there's like a Salesforce app or some integration that'll tell you, okay, this account looks like they're at this stage of the technology adoption curve for whatever data we have for whatever reason. And so you should prioritize this account, for example. But I haven't seen anything out there.

But yeah, and I, that's why, because there's no silver bullet on this one of a specific tool yet. Like, we'll use Clearbit or ZoomInfo depending on the market to pull in data to back up. Like, but what I normally see is we're aggregating different tooling to build a model. And then with marketing, we'll have sort of a, I won't call it an algorithm, but a model built that tells us as things are coming in and they're going through our marketing platform that the, they're getting scored based on the attributes that we apply and they're telling us something is hot. There are things like SixSense. Gosh, I'm forgetting the one in open source PLG that's phenomenal for sort of scraping the whole world and telling you, hey, these people are using your open source. There's a variety of tooling that we use to build a model to tell the AE and give the AE daily reports in their dashboards like, hey, this is what happened. But I don't know of a tool that systematically covers all these things. You generally build it in collaboration with marketing.

Okay.

By the way, I'm jealous. I wish I was walking outside right now.

It's a better way to digest the content.

Yeah. Excellent question. I really appreciate it. Cool. Awesome.

Alright, Jim, let's, let's, let's have you get back to your slides for a little bit and then, yeah, we'll, we'll, then we'll keep going.

There's about 7 to 8 personas I'm gonna cover today when selling to engineering, and, and specifically the world today we're talking about is dev developer, DevOps. One area I wanted to start off with was commercial because this is a, a flat hierarchy and you can actually get things done. There's a reason it's high velocity is a lot of the times the people you have to win over are also your decision maker and economic buyer. So when we're looking at sort of the engineering leaders, SMB startup tech leaders, they don't even have like a C-level title. They could just be a generic or general title, but they carry a ton of influence, a ton of power. And so when you think about where these people are and, and their perspective, they're thinking about, I need to deliver technology efficiently and safely. Basically, I can't blow up our little company. I cannot kill our momentum. And they're focused on failing fast and iterating quickly because like, like all of us, they don't know what they don't know. And so they're gonna fail forward. So they need something that's going to work that they don't have to worry about, that will make an impact, doesn't have to be perfect. They don't have to worry about too much risk. They're just go. So distractions and complexity, like if you have a long POC, these people are wearing anywhere from 2 to 5 hats. They're wearing, they're doing many different roles. And so if your product from a POC perspective is too much of a lift, this audience probably won't work for you. They don't have like proven practices. So again, you're here to help them do that. They may even build around your product. And value messaging I just took from some old assets, um, when I was selling to specifically to dev. Um, but you know, for this group, you know, accelerating their team's development, improving and securing processes, and increasing developer productivity and happiness, that's what they care about. Now getting to more enterprise, um, this is a persona that has a ton of influence. Developer, their own developer tooling, DevOps teams, architects, principal engineers. These are maybe people that are not with leadership titles, but they're a circle of excellence. They are the 10Xers, like in a sports team, like these are the people that are your rock stars. And, you know, what will happen is the top-down groups, the VP, SVP of engineering, the CTOs, CIOs will look to these people for their say. And if you don't win this group over, or you— they're a blocker, you're in trouble. And so, you know, they're a technical decision maker, um, they're trying to benefit— they've grown in their career, so they're in a new role where they're looking at the bigger problems for the whole company. And they're trying to reduce complexity, uh, the tech stack, and they're trying to find things that make, you know, the people around them, the people they support, uh, more effective. Um, So pain, it's like they've, they've bought a lot of tooling, the tooling doesn't work. They built a lot of stuff in-house, but they're not seeing the gains from the automation. There's conflicting tools that don't integrate with each other. So it's actually creating more problems for solving. And then this one is, this last bullet is pretty important. Over the past few years, what we've seen is while there was endless spend several years back, there's not endless spend anymore. And so what they're trying to figure out is how to narrow down their tooling, just to get the most bang for their buck. I don't have to read value messaging for each one, but their, their whole concept is transformation and progress. This one's easy. This, this is your final approver. This used to be called the economic buyer, and they're not really the economic buyer. Even the person that's signing on the contract, I don't really see as the economic buyer, but this is the person ultimately when you're thinking about business value and business objectives, like when I'm talking to someone about our product, if the pains that someone at the mid or lower levels are really excited about, that the things that we're doing they love, um, they're like, are, are not business objectives, if they're not part of the roadmap for this persona, I'm probably not going to get the deal. I may have gotten this deal done a couple years ago before things changed, but if this person's not on board, especially as the ARR, the ASP, the landing price goes up. Like if this, if we don't align to business objectives with our value, this person is not gonna approve. They may not, it may not even be like maybe the VP of engineering's budget, they may be the economic buyer, but if this person's not on board, the CXO, the head of engineering, like you're done. And so they're focused on just, you know, bringing the best product so they're, their people can build the best products and ship fast. Like, that's what they care about. But my thing is, like, you need to understand— and I don't think this matters whether it's developers or some other type of persona or sector— like, this group, you need to understand what matters to them. Does it align to business value? And if it does, you should be okay. Um, they don't want complexity. They just want to know that the people under them are going to buy in and they're happy. And they don't want to— they want to make sure that it's not going to become shelfware. It's not gonna become something that, like, sits there. They bought it, but no one uses it. So usage metrics and sort of the ROI in those metrics matter. In my world, I only have about 2 years in the past 12 of selling to, selling security. And so now if you're selling directly to the CISO and security products, this whole persona flow can change for you. But this person very much is part of the decision process. Going back to, CB in the Challenger Sale, or now Gartner, like this person has always been there. And if you can't check off security, if you can't get through security review, you're, you're probably dead in the water. Depends on again what you're selling and, and from what does it touch as far as impact. But like the, the security person, often they're not there to be a blocker. They just wanna make sure they wanna, They see the developers as their customer. They, they're aligned with the CXO on making sure that things are getting done, but like they have to do their job. And so, you know, they're, they're happy with technology coming in, but it better align with sort of best practices and standards or you're, you're gonna have a lot of friction in the sales process. So, you know, they, they do have this sort of cultural pain point of security seen as an obstacle to innovation. But like, You really need to befriend this person. And just like red lines in a contract in a deal, don't avoid the obvious. I try to have my teams seek this person out early in the POC process because you're going to run into this person no matter what. And you might as well find out early, early on, like, do we, do we sort of do our success criteria from a requirement standpoint, meet his or her needs? And then, you know, their value messaging is keep development teams safe. You know, with end-to-end security, but like, you know, just making sure every step of the process is covered so they can freely work. Development team leader, engineering director, this is like, this is my person. When we're doing discovery, we want to get to the developers, we want to get to maybe first-line DevOps people, we want to sort of win them over so we can get to this person. And, you know, they're maybe a climber when you think about the different Challenger personas. By the way, I love Force Management. If I'm talking about Challenger and Force Management, I think Challenger sort of wrote the book originally and then Force Management took that book and it's like Challenger on steroids. So when I'm looking at personas here, I— this person— I would say that this person is your buyer influencer. They're the one, they're the one ultimately that's going to go to the final approval person, say why they want this. But they're generally the person you want to latch yourself onto. And if I can turn this person to a champion, develop them into a champion, that is the ideal state. Because they're, they're trying to sort of grow within the organization, make an impact. They're the ones really involved with the day-to-day, and they live the stuff that we're selling and the impact we can have. So if we were to focus on creating a positive working experience for developers, that result— and I wrote high-quality products, but like, as, as an outcome for them, but really just developer happiness, developer productivity. They just want to build and ship faster the right way, and they want to grow the company. So they care about like where ROI matters with this group. It's like meeting deadlines, it's keeping people happy, helping them sort of evolve, helping them be productive, and also simplifying. Like don't, you know, they have everyone selling to them all the time. So there's, there are too many ways to do anything. So getting them to focus on what your product can resolve, why it won't be shelfware, and why you can hit the ground running right out of the gates matters to them. And I already covered the value messaging here. This is my, these are my disco calls, my discovery calls. So when I'm trying to map the organization in the selling to engineers, I wanna understand first, right? I, it's great to say, oh, I'm gonna go top down, but something I wanna make very clear to you with this audience, the engineering audience, if you don't have buy-in from the bottom, then the top will not care. And that sounds obvious in other industries. It is paramount in this industry that like, again, developers from their perspective are, they drive revenue. Developers being happy, developers working as a team. But if you try to sort of force something on them, they will reject it. And see, CIOs and CTOs have experienced this over the past 10, 20 years because the developer has power. And if you're gonna give them some BS sort of rules they have to follow, like they have so many rules, restrictions, um, before they sort of ship of what they have to follow. They have so many sort of, you know, we talk about shifting left over the past 10 years. I feel so bad for developers. We've shift left so much that we've thrown so much on their plate. They just wanna do their job, not everybody else's. And so you need to understand their pain and you need to win them over because if you, if you don't have momentum with this group, you're done. So like they're big influencers, they're the ones that bring you in, especially in open source. And so they're the ones at like frontline doing all the heavy lifting. And so you need to sort of appeal to them first before you even get to the group business meeting, before you even get to the new business meeting. Like this is the person you have to win over. So Like getting their attention, good luck. That's why your product has to be quality. And if it makes them better and more efficient, you've got their attention. If it doesn't, you're a complete waste of their time. You're not gonna sell this group anything. So just important. I think the most important when we're talking about this audience, this is a group you have to win over first. You don't win them over, you're not going anywhere. At least that's my opinion and that's my experience. So I know we just, before we go to like key takeaways, Amelia, is there anything else you wanted to cover in that section or, or so we can we close up on action items?

Yeah, we can close up. I think there's just one related thing again on the livestream. Yeah. Back here for the, for those personas you were going through, right? Obviously very technical. Some folks here in the audience will not have been as used to selling, you know, to either technical founders or just technical roles, right? Like the CTOs, the CISOs, that kind of executive suite developers. Engineering, right? Like what, I guess just at a super high level, you kind of talked about each of them and what works. The question we got was like, you know, does, does being creative still work with this more technical audience, right? Because obviously for sales and marketing, it's all about, okay, how creative can you be in your outreach? Like that is what will, how can you add value? Like that is really the two big differentiators if you wanna get into those personas. But for these personas that are more technical, obviously you went into it a bit, but like, Any high-level advice on what works? Like, does be— does being creative still work in these more technical personas that you're selling to?

Yeah. So the answer is yes. Sales is a mixture of art and science. The science, which I think is the majority of the sales cycle, is what gets you to this person. The art side of things is creativity. And so what's never changed— and if you think about the book, I don't know how many people in this audience have read How to Win Friends and Influence People. But like, one thing that's never changed is people love the sound of their own name. And, and you want to always appeal to their nobler side, like motives that excite them. And I think when, when we get down to the persona and we truly get down to the individual, it's all about true interest. And if you're gonna be creative, like, creativity doesn't matter if it doesn't relate. But if creativity is about relating to the person you're trying to reach and engage with and you truly care about them, and you show interest in their background and what they do and what's important to them, that's the only way you're gonna get engagement. So I think no matter the persona and any type of sales cycle, creativity always matters. But to even get the opportunity to be creative, the science of getting there matters most. And once you're in there, that's why we're all, you know, I don't know the type of leadership or people you have, like you, you all work for, But as a leader, you know, I want people to follow a system. I want them to play within the system, but I also want them to sort of do it their own way. You know, we all have our own discipline, we all have our own approach. And so the creativity is where you start to see the differences in ability. And so yes, creativity absolutely matters as long as it's authentic.

Yeah. Um, great question. Let's do your key takeaways and then we'll do the rest of the questions.

Yeah, so, um, key takeaways: keep it simple. We— again, if you're coming from a company that's been around for several years and they have a lot of proof points, um, things have been built out systematically, cool, roll with that. But in the early days, the companies that I've worked for, the, the A, Series A, Series B, seed, like, if you, if you try to boil the ocean, if you don't hyperfocus on what you think your strengths are and you don't just go off the fundamentals. Like I used to be in finance and, and one of the things in finance, they used to say, oh, it's different this time. It's never different. And so focusing on the basics, as far as like, hey, it's, everyone says also it's revenue solves all problems. You don't get revenue without qualified pipeline. And so the thing is, when I'm saying like, when we're talking about this in this audience or whatever audiences, do whatever you need to do to get to qualified pipeline. That's actually the thing that keeps me up at night. When I think about this audience, how to get to them, always think of how do I get to qualified pipeline? Focus, already covered that, but don't boil the ocean, you know, get agreement across the board, you know, iterate, fail forward, keep going. And then for this audience, developers have power. Top-down decision-making won't happen without buy-in. And so if you don't, like, that's the power of open source, that's the power of community, is you have that buy-in, you have that brand. But even when you don't, so for Commodore, we don't have that community. Like, it's getting buy-in from the right people and knowing your personas and then building up. Top-down always matters, but it only matters if you can get to them the right way. And the last thing I wanted to say, open up with this, like, I have a lot of assets. I do have like this Slack channel with these other 60, 50, 60 sales leaders, and we are always helping each other. So if you guys need things like value messaging, you need things on personas, feel free. I think my contact information is going to be provided. But like I said, when I posted this, it's about giving back to the SaaS community. We are a community and, you know, this is our craft. So with that said, I'm all good, Amelia.

Yeah, no, there were a few questions in the chat of how people can get into your Slack, but I don't know if you want to share.

So we do like, we have sort of a process for doing that. So like, Again, if you reach out to me on LinkedIn, I'm happy. Look, I can't promise you that we open it up because we want it to really be focused on a smaller group. But I'm like, if it's the right profile, I'll be honest with you and tell you if it makes sense or not. But just reach out to me.

Yep.

Jason, I know we were— I was thinking about revenue cap the whole time that Jim was talking. I don't know if you want to share a little bit about you know, obviously their— I don't know, just the tidbit on their recent experience with the sales team and maybe get Jim's take on it.

Uh, maybe I won't share that one, but, um, related question, but it is related to that one. Um, Jim, one I debate a lot with API-focused startups I've worked with or invested in or know, um, is, um, just how technical does the sales team need to be? And yeah, with RevenueCat, like Amelia was talking about, we had a huge debate there. They're crushing it. They're on 40% of all mobile devices with subscription. They've found, for example, they're, they're, they're unable to sell to a hyper sophisticated CTO, VP of Eng unless they're close to an engineer. Right. And I remember, I think a long time ago you went, You're sorry, you went to GitHub or GitLab. It's embarrassing that I mix up the Gits, but you went to one of them early, didn't you?

Yeah, I was the first. Well, there were, there were technical account managers when I got to GitHub. I mean, Jeff Jones were the first enterprise reps at GitHub.

And I remember when you did to me, we barely knew each other, but I remember thinking, okay, how, how if you're going and GitHub was pretty well established at the time, we were an early GitHub customer and I was wondering how technical do you need to be for that sale? And I've seen it back and forth, but I've seen a bunch of startups blow up over this issue. I've seen a bunch of CROs say, hey, listen, I crushed it at GitHub, I crushed it here, but I had a whole team of SEs, I had a whole team of solution architects. I just need to be a sales guy and be likable. Others are at the opposite end of the spectrum, which is I'm already using the product, it's already in staging, it's already in production, I'm already part of the community. I need a deeply smart sales rep or I have no value. The sales team provides me no value. What are your— all your learnings from that?

All right. Well, there's, there's an answer I'm passionate about that I think applies to no matter how you look at it. And then there's the broader answer that's a little harder because there's variables that come into play. What I would tell this group, if I was to answer that question for this audience, is you have to be intellectually curious.

Yep.

And it goes back to authenticity. If you don't even take the time to learn the product, to learn why the product matters and the pains it solves for to the audience, then you're not showing true interest in their pain. And so when I'm looking at candidates for any of these companies I've been at or at Commodore, I'm looking for some track record or some style of intellectual curiosity. If you think that you're gonna come in and the SE is just gonna run the deal and you're not gonna play your part, you're probably not the right fit for most of the companies selling to this audience.

Yeah.

So that's my passionate answer. I think it all, it matters to like how technical is the product, the type of depth, like the ecosystem or surface area it covers. Because then it matters like the variable, variables here, like what type of SEs, what type of SAs. And then what am I, what's my role in this sales cycle? And I think where companies can hurt themselves is they get locked in on a certain persona. We gotta like, we have to move fast. And if you're looking for perfect, you need to look for great. You always need to look for great as far as culture. But like, if you're looking for perfect, you don't even know what that is.

Yeah.

And so my thing is it, it matters of like, and as you grow in stages, like there's, there's a white paper, I never remember the CEO's name, but Zura, and he talks about the different stages. He talks about the different stages of, you know, 0 to 1 million, 1 to 10, 10 to, 10 to 100, 100 to a billion. There's different needs and there's different profiles depending on where you are to support your sales cycle. So it's not a great answer, but there's too many variables.

But when you joined, I know it's back in the day, but when you joined GitHub, they're probably north of $100 million in revenue, right? Or approaching it.

No, we were about, uh, 10 or 11.

Oh, only 10 or 11.

I see.

Yeah, it was, it was, it was all, um, almost all, uh, PLG, uh, sales cycle.

And how technical did you have to be back then in the sales cycle talking to developers, I mean, back then when we, at GitHub, when we were acquired by Adobe, I know I'm dating myself, it was super controversial because they didn't allow any repositories in the cloud. So they had to make a super special exception for us. It created lots of drama. And we, my developer, my engineer said we quit. Like they wanted to move us from GitHub to Adobe's. And the logic back then made sense, right? We weren't, we weren't sure we could trust it. But think about how complicated that discussion would be, right? So how, how, how techie did you have to be back then at $10 or $12 million revenue?

I wasn't, I wasn't, I was not technical at all. I jumped over from, from a sales marketing led startups to this was my first.

I remember, that's why I remember thinking about that. How will it go? Yeah.

I mean, and also you have to understand the culture at GitHub at that time was funny. They didn't even want revenue. We had, we were a test. We had to prove that we could sell in a quality way and we wouldn't embarrass the brand.

Yeah, it's a version of this question, right? That, that, that sales isn't actually a negative for the brand, right?

I had to dive in, going back to being intellectually curious. I really wanted this to work. I was excited about the opportunity. I had to learn about the audience personas and, and just before throwing myself out there, I'd cut my teeth on maybe logos and stuff that would not make as much of a splash or waves if I messed up. But like, I had to dive in and learn because we had some support, but not, not that much. We had great engineers that, and, and TAMs are willing to help us. But it was really my, I, I learned to sort of become technical enough where I could hold my own, but I was not technical. I had the attributes or aptitude to want to get there, but I myself at that point, it was absolutely not. I was scared.

Yeah.

That's how, that's, yeah. And what's this curiousness? It's so important, right? If we, Emily, tell me if I'm taking all the time, and I know I was double booked for the beginning of this, but I think this is so— I think this— I agree with this for what it's worth. If they're truly curious, you will get up to speed on the 20 things that matter in your first 60 days, right? But truly, truly, or scared. Scared and curious are actually a really powerful combination to your point, right? What are the signs of that? Do you think— and for— and how, how much work do you think someone in sales in a tougher category or where they have something to learn, how much homework should they do before they start? Maybe these are not related topics, but to me they are. Curiosity. What does curiosity mean for real? How do you know if they're curious enough?

Curiosity means taking time to sort of take it to the first and second levels of like, hey, these are the objections we run into. This is sort of how— so for instance, can they actually do the pitch, but the pitch in a more technical way to the technical audience? Like, and we'll run them through scenarios and make sure if you had to do this on your own, could you add, you know, a certain depth.

Before they start, before they start, they've got to do a pitch.

Oh, well, before they start, it's like if I'm interviewing them and they're trying to say I want to come into this space, like, that's— those are basics. Like, did you do your research? Do you understand sort of the ecosystem? Do you understand or have a feel for our value, sort of our position at our value prop? And then, like, why are you interested in this? Like, show me why this matters to you. Both from a sales approach but also from the audience's perspective. And if they haven't taken the time to truly look at the market and do their research, then it tells me, will they, will they put in the time once they're here?

I'm not sure they will. So how— so, and, and what, um, and, and, and I just think this is so helpful to folks. Of the candidates that you, you've interviewed, right, for what percent of candidates actually have really done that amount of work? Really done enough work at Commodore before where, where by the time they get to you for the interview, you think they're, they've done enough of their homework, they could potentially sell the product. What percent of candidates go that far these days in 2025, 2024?

I would say for me, and it may be because the type of profiles I'm pulling from intentionally on our stage.

Yeah.

I am pulling from a profile that is aspiring enterprise. So I'm pulling from a profile that's been doing the market in a certain area that wanna, and so they are going to, they are going to sort of put their all into it. So I'd say 70% of the profile I pull from when I find someone hasn't done their, their experience. So maybe it's someone that is more tenured, uh, an enterprise rep of 10+ years where they feel like they've got this. Often what I find is they come—

it's just sales.

Yeah. They just come in less prepared and they make, they make less of a, and they go, oh, I got this. I'm like, man, this other person, like, I'm always gonna, I'm always gonna bet on aptitude over tenure, over experience, like, because I think it matters culturally. I want people that want to be here, not people that think they deserve to be here. And so I think that, that does influence, like, the percentage of, of candidates that come in prepared.

Yeah, I do. Um, I feel like now there's so many veterans out there, right? There's so many folks that have done it, right, at so many great companies. I do feel like too many veterans think they can just kind of phone it in. It's the same thing that I did at GitHub. It's the same thing I did, right, at Screen, right? I don't actually have to do much work for— I did it at Datadog or Screen or whatever. I see this all the time. All the time.

I want to be careful about that because I need them. Like right now, like in my first year as a CRO, I think the title CRO at my stage is such a joke. Like I am an everything-o. Like I wear many hats. I'm a first-line leader and that's, that's the primary job I have in my first 2 years is I need to be the first-line leader for CS, for, well, not SE, I definitely wouldn't do that. I need help with that. But like, yeah, with, with the enterprise deals, like, so I need to balance it out with these, these people, high aptitude that are sort of striving to grow in their careers with, with a couple that I can lean on that have the experience. They just have to be, they still, they still have to have the same energy and enthusiasm. Going back to intellectual curiosity that says they want to be part of building this thing together versus thinking, oh, it's just another job. And so I do need those people with experience because I, I sort of lean on them to make us all better. And I, I lean on them to sort of be an example for the rest, but they have to have the right attitude. Got it.

And maybe one other question. Um, and Amelia, you can tell us if we're out of time. Now that you're, now that you're back in the early days now, right? Um, How do— there's this balance in sales. If you're not— if you're not— don't come out of an engineering background and you're selling to engineers, right? And I think actually in any vertical SaaS, there's probably gonna be similar issues, right? In any— in any very specialized area. How do you balance how much time you take from engineering, right?

If you—

if it's early, there's not 20 SAs and SEs and S-this and S-that. You're taking the CTO's time. You're taking the best developer in the company's time, right? And— and you wanna win in sales, you need the help. But I think there, if you care, there's both some guilt around taking too much time, right? And some concern, if I don't take enough, I'll lose the deal. If I take too much, I'm gonna break this relationship and turn into a tax. Maybe I'm overanalyzing it, but how do you think about how much time I get from engineering? Like, is it chips? Is it X hours per week? Have you thought, do you have any metrics or heuristics around this?

It depends on the culture of the company. Yeah, it really does. And, and how much, you know, there's, there's always these dynamics at play of we, we have, you know, G&A and, and revenue, marketing and sales and product and engineering and how we all play well together. And ultimately what are our objectives? Like what do we put as sort of the top 2 or 3 things we want to achieve? That actually matters a lot from dynamics of how much I'm gonna pull from But like in the early days, you know, your first salesperson are your founders and who's gonna do it better than the founders. And if I'm gonna do it the right way, I've gotta learn from them. So I have them in almost all the deals, right?

That's the answer. Almost all the deals in the beginning.

Early, early. Until we start to see pipeline grow, we start to see the number of deals increase and we start to find a motion that you gotta remember, this is their baby. No one cares more about this than they do. Yeah. And so trust, you have to earn that trust. And the best way for me to earn that trust is to pull them early and often to show, hey, we can learn from this and we can do it the right way with our own sort of secret sauce applied. But if you don't build trust with those founders, good luck trying to ever get momentum to sort of build a machine. And so what I would say is like early days, they're, they're my proof points. They know how to do this better than I do. Yeah, but I come with a lot of experience on how to build things with process. And so take their knowledge and then in stages, as you earn that trust and you get a longer leash, then less and less, but you've already now built around what they were, they were running with. So it's, it's not a, it's not a very direct answer because it's a, it's an evolving answer.

No, but it's a good answer. If you're, if you're coming in as, as, as a sales leader in an early stage startup selling to developers and probably to any, I think there's probably, I think a lot of the BDD stuff interesting works in vertical SaaS because if you come into an environmental SaaS company, you probably won't know all the regulations in the environment, et cetera, et cetera, right? You in the bigger deals, you want the founder in every deal or CTO founder in every deal is the simple answer to the question. And be aggressive, like don't hide, like ask for the time and upfront in the interview, say you need it. Say, listen, if you're built, if like a get it and this is common like a GitHub, if you're the first, if you're bolting on a sales team to a PLG or community-led motion, right? So listen, to be honest, this is a great job, but I need, I need, I'm going to need 7 hours a week from you because you got to be in every deal with me, right? Not in every comp, but you got to be in every, every key conversation, right? To start in the beginning, right?

Yeah.

I think it's a stipulation of the job.

Yeah. Someone asked that question earlier in the conversation and not that exact question, but it hinted towards it. And that's the thing of like, what do we really care about? We care about winning. You gotta throw your ego out the door. Yeah. And that, that goes back to being intellectually curious also means being willing to learn and like everyone brings something to the table. Like it's funny, as I've gotten older, I've, I've lost more of my ego. Because I just— all I care about is winning. And whatever gets the deal done, get it done. And like, you live to fight another day, especially when you're sub-$100 million. Like, every quarter matters. And like, that's all that matters. And so live to fight another day and don't let your ego or your lack of curiosity get in the way.

Yeah.

Okay. One last question, because I know we're at time. Two of the best CROs I know, all of whom I used to work with, one of whom I asked repeatedly, I introduced repeatedly to some amazing developer-focused startups. He said, no, I'm not even gonna meet with them ever. I just wanna stick to B2B. Okay. I just want, I don't, I don't know. I don't wanna sell the engineers. I don't wanna sell the developers. I don't wanna sell the CPOs. It's not me. I can't do it. Every time I failed. One of the best, all-time best. Another one who I was catching up with, He'd have forgotten I put him into a developer-facing company that went from 2 to 20 in 2 years. Okay. And I asked, how did you do it? Because you'd never sold it. He's like, I didn't think it was very hard. Now he is curious, right? Is the answer to your question. But so 2 stories, 2 of the best I know, one who no way in the world would ever go work at any of the places you've worked. The other one thought it was no issue, right? Bouncing back and forth between 5 different verticals. Long-winded, why, uh, build up to the question roughly from your gut, what percent of B2B SaaS executives can make it selling to developers and B2D or technical sales? What percent can actually make it and what can't? If you had, if you had to generalize, what percent can make it? That crossover?

Never even thought about that. I think, I think, I think any, like, I think anyone can make it. It's not rocket science, right? It's still the same craft. It's just your ability or your, your desire to wanna, you have to constantly learn. Like I've stayed in this space now for 10 years, but like, I don't, I don't know Kubernetes, right? Like I've, I've been working on things that are—

At least you know you don't know Kubernetes though.

Well, you have to, you have to, and that's just it. Like that's what makes the job fun. Like, yeah, I like going into these different verticals within the same sector.

Yeah.

Because I like sort of the breadth and depth of learning. I mean, it's what makes it exciting, right? All the other challenges are there, but it might as well be fun. You might as well always be learning.

Yeah.

Like, if you're open to that, like, what we're doing, you're going to figure out the support and have the resources to help you. You have to like the audience and you have to like what they're about. Otherwise, it's just not fun.

Yeah.

But then you also have to be willing to learn and put yourself in areas that are super challenging. And like Kubernetes, like the reason I chose Commodore versus like AI products that were out there was I've been seeing Kubernetes been around for 10 years and it's now adopted at scale. All the other products I've been selling over the past 10 years, everyone's saying, hey, we've adopted Kubernetes, but we're struggling. Like, can you help us with your product? And the answer is like, no, we're not touching Kubernetes. And so what I saw also as a salesperson, like, this is where the pain is. And as long as there's pain, I can sell, right? There's a problem to solve. And so for me, you have to be willing to sort of go outside your sort of depth and take chances. And if you're open to that, it's the application of our art. Our craft is the same anywhere. But if you're not willing to do that, you're not going to have fun. I wouldn't do it. I don't know what percentage, though, of people would— that would apply to.

Yeah. Okay, fair enough. Yeah. My, my folks that I know that have spent their lives working at Gong or Salesloft or Outreach or similar great world, world best applications, right? Like sliding into another app, selling another application in the sales or even marketing space. Like they can wing it. They can wing it, right? It's selling more sales tools to more sales reps as a sales rep. And that sounds niche, but so many sales executives come out of the B2B, the classic B2B industry, right? I'm gonna say my life experience is at best 15%. Yeah, at best they can thrive outside of that.

You need someone to take— Paul St. John from GitHub took a chance on me. Yeah. And so that's, that's how I got into this. But like, the other thing I'll tell you, it's hilarious about this is like, I've done those other roles and I know I can relate to that audience in marketing and sales and HR and finance. Like, keep it simple, stupid, you know, don't talk, listen. That never applied when I was selling to those people because I got it. Like, the irony is—

Yeah, you got it, right?

When I switched over to this side, I shut up because I sound so dumb. And like, if I talk— So what the irony is, you listen with this group and you learn versus talking. And so all the sales books, they always told you to do that. These roles forced me to do that because I just was not— I don't have the depth until I do to relate to these people. And so just listening is sort of a key, a key win here. But I know, I know we're over. It's a great question. I haven't been really explicit. My answers are direct, Jason, but like, it's— they're good questions. They're not easy to answer.

It's good. Well, let's wrap on that. I do. I do think if you're, if you're I do think for any founders, any, anyone trying to make these hires, so, and you're gonna take the risk like GitHub took on Jim and others, really make sure they're intellectually curious, right? Really make sure they're asking the right questions during, because you can do sales to anything with even a remote brand if you're intellectually curious, right? You can listen, right? Listening though is not the same as not talk, the same as like checking out during the the sales meeting. So you got— that's the right— I think— I still think it's 15%, but let's combine it with Jim's point, which is you have to be intellectually curious. They have to genu— and they have to have, I think, done enough diligence during the interview process to, to have hacky answers, to ask about the trends in the industry, to, to really ask about the why. Why, why, what's changing? Why would I come to these companies, right? Why would I come to Commodore? Why would I come to Screen? What's changed? What's changed in Kubernetes? What's changed in security? They got to ask the right I think they have to ask the right curious questions or they won't be curious enough to listen to the customers and go help figure out the answers to their problems, right?

Yeah, I agree.

Cool. All right, Amelia, thanks. Jim, thanks for doing this. This will be, this will be great.

Thank you, everybody. Appreciate it.

We'll edit it and publish it and do it more shortly. This was really, really appreciate the time, Jim. It's a great time.

Thank you for the opportunity. Everyone have a great day. Goodbye.

Yeah, thanks everyone. We'll see you next Wednesday.