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

A live Workshop Wednesday session (YouTube) where Jim Hunnewell (Komodor CRO) explains how to sell to developers and DevOps engineers. He emphasizes knowing your ICP and personas, keeping POCs and messaging simple, earning developer buy‑in (bottom‑up) while mapping to business value (top‑down), and hiring salespeople who are intellectually curious and willing to learn technical context. The talk includes practical tooling mentions, hiring heuristics, and a live Q&A about sales team technical depth and founder involvement in early deals.
Chapters
Hello everyone. Welcome to Workshop Wednesday. We are so excited to have you back with us today. I know it's been a few weeks since we've had a Workshop Wednesday. Super excited to have Jim with us here today. He's the CRO at Commodore. So Jim, excited to have you. You are new to this, you've been in the Sastra community, but you're new as a speaker. We'll kick off with just a few icebreakers. First and foremost, I think just tell us a little bit about Commodore and what you do there and your role there as CRO.
Everybody, thank you for joining. It's an awesome opportunity to get to speak with all you today. My job at Commodore is I head up revenue and what Commodore does is we basically help large enterprises solve the problem of managing kubernetes at scale. So like what we would call day two operations versus day zero, day one. But I know it's not about Commodore. I guess a little detail on Commodore's Series B company. When I started, about 40 employees, a little under a hundred right now in less than a year. So we're growing, but we are purely enterprise motion. So no commercial, no SMB, no plg.
I think that's super helpful context essentially, 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 one after canceling 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. Tell us a little bit more about that. What do you like with working for you as a CRO?
Hi. It's a composite of SaaS products and it depends. In collaboration with marketing, we use things like Seamless, 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, 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. I've used Avizo and Clary, but mostly Clarity. So if I go say something that saves me a ton of time once we get big enough to fully utilize it, is forecasting tooling. At Clari Would Clary would probably be my favorite. Awesome.
No, they've been Passport Universe. So that's a 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. Without further ado, let's talk about what it really takes to sell the developers and engineers.
Yeah, so I want to open up with everybody. One thank you for even giving me the time. I believe strongly in the community and specifically the sales community. I even have my own Slack channel with about 60 other CROs heads of sales apps that we always are talking about things like this, enablement comp plans, just ROE rules of engagement. So just to have the opportunity to speak with all of you today and share some knowledge 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 get it before getting into detail, talk about what I've learned working for Series A through C D startups and that's don't boil the ocean. I think when you're sharing knowledge, talking about fundamentals is extremely important. 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 plus 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 oh, what I know is 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 as 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 SAS to the Sasser team. Leave behind different assets that if you want from the presentation you can use. But I'm not gonna 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 asked or given the opportunity to present today and 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. So your product market fit influences a lot of what we're going to discuss and what you take away from it. Selling motion matters and if you're so if you're high velocity commercial mid market versus enterprise, the type of land and expand can be different versus what we're covering today. So again what I present is meant to be at a macro level. However, if you have questions specific to your situation, we're happy to take them if time permits. On the other thing is Commodore is the first company out of the last five that isn't a product led growth motion. This is where purely sales led enterprise inbound, outbound, that matters a lot and we'll get into that. So again, you're selling motion and how you look at these Personas in this audience and where they are is 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. 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 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 if you have to educate people on sort of the existence of the problem before helping them understand how to solve the problem, some of this could sort of the impact of what we're talking about today could vary. 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 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 at an end was Anderson Consulting became Accenture. Part of my job as an analyst was programming. 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 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 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 what matters. So I'd say the thing to 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 going to sell them the silver bullet. They and if you promise them that you are, they're not going to trust you. So there's no BSing 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 running a plan than it is about sort of your artistic ability to sell. So normally we're startups and we're selling, we're a lesser known company, we're selling to enterprises, we're selling to mid market. They want the product, they have a certain desire for the product and like all of our audience, they want low risk, high rewards. So they don't want to take a ton of risk. And what they're buying, they want to know like what you're going to sell to them, you're going to deliver on. But they also want high reward, high outcomes. So you always hear that term, no one ever got fired for buying Microsoft or IBM. Name the huge company. But if we're going to get in there, we need to win them over with trust, with support. And so the buying experience really matters. Keep it as simple as possible with this audience and, and be very direct with your value proposition. And like I already said this, but the don't PS 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 sell them something that is, I don't know, like bulletproof, they're not going to believe you, I would say so as a person selling to this product, know your audience and be hyper focused 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 your listing. They want to build with you. They're builders. No product is perfect. I already covered this. But just knowing your product market fit, knowing how to anchor on is super important. So the developer and DevOps is a component of sort of the engineering. Org. But back in 2011, Marc Andrewson wrote wrote an article in the Wall Street Journal 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 can see this in the 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 Andreessen was right. We saw that software did eat the world and companies generally became or thought of themselves as, as software companies. And 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, what I saw in selling across the globe over the past 10 years was the perspective of how people saw the developers from a cost center to a revenue center. 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? It says they have power, it says they have influence. And 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 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 generally have the power to buy and buy quickly. What I did see was after Covid in 2122, the pendulum swung back a little. And so where they had absolute power and budget, you saw the typical Tops, 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 just finances 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 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. 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 these first couple slides, great. But I wanted to make sure for a broader audience we covered this. And then I want to go to specific Personas you see when selling to engineers in the sales cycle. I'm pretty sure all of you seen these two charts on the right before, but we're talking about our ICP or our, our ideal customer profile. I think it's really important, especially if you're at a younger startup and you're working with founders. Like in my experience I shouldn't paint with 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 caught, they brought in a couple 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 that don't boil the ocean. Yes, we can help everyone, but who can we really help? 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. The other thing I'd say is beware of the left of the chasm down below. So you, your 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 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. 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 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, 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 developing a top target list and testing I generally find for this group when I'm trying to build, I will say 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, we'll boil down that list from okay, there's 50,000 potential companies down to maybe 10,000 based on their tech stack. 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 software's eat in the world. I want to find early adopters of technology. I generally find that if There's a percentage 15% or more depending on the industry or sector of an engineering to employee ratio, I'm looking at company a, they have 2,000 employees, but 500 of those are developers in it. That tells me 25% of that group is focused on building technology that is a really good target. And so I'd say 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. Again, enough of of me preaching there, but I wanted to make sure at least we're talking about icp. You have an approach that works because this is the area 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 gonna hit our numbers and we all get replaced or the company goes under. It's as simple as that. Way too much on this side. But 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, 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 a Fortune 100, Fortune 500 company. The CIO might be more relevant than the CTO, but like BPS, VP of 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 comma, or if we were focusing today and maybe data engineers, those are 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 support teams, there's. This is very vague. I could have added like five more bullets but again, very generic breakdown. Before we get into the Personas, what I'm going to focus on today is the core ones around developer DevOps and really the how these sort of where they play a role in the general sales cycle. There's about 78 Personas I'm going to cover today when selling to engineers and specifically the world today we're talking about is developer DevOps. One area I wanted to start off with was commercial because this is 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 engineering leaders, S and P, startup tech leaders, they don't even have 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 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 all of us, they don't know what they don't know. So they're going to fail forward. So they need something that's going to work that they don't have to worry about that will make an impact. It doesn't have to be perfect, they don't have to worry about too much risk. They're just good. So distractions and complexity. Like if you have a long poc, these people are wearing anywhere from two to five 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 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 when I I was selling specifically to dev for this group. 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. 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. These are the people that are your rock stars. And what will happen is the top down groups, the VP SCP of engineering, the CTOs, CIOs will look to these people for their say. And if you don't win this group over or they're a blocker, you're in trouble. And so they're a technical decision maker. 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, the tech stack and they're trying to find things that make the people around them, the people they support, more effective. So pain it's. 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 it 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 whole concept is transformation and progress. This one's easy. 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, they're like, 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 asp, the landing price goes up. If this, if we don't align to business objectives with our value, this person is not going to improve. 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 bringing the best products that their people can build the best products and ship fast. That's they care about. But my thing is you need to understand, I don't think this matters. Whether it's developers or some other type of Persona or sector, this group, you need to understand what matters to them. Does it align to business value? And if it does, you should be okay. 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 going to become something that sits. They bought it, but no one uses it. So usage metrics and the ROI in those metrics matter. In my world, I only have about two 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 and the Challenger sale or now Gardner like. And this person has always been there. And if you can't check off security, if you can't get through security review, you're probably dead in the water. It depends on again what you're selling and from what does it touch as far as impact? But the security person, often they're not there to be a blocker. They just want to make sure they want to. They see the developers as their customer, they're aligned with the CXO on making sure that things are getting done but like they have to do their job and so they're happy with technology coming in but it better aligned with best practices and standards or you're gonna have a lot of friction in the sales process. So they, they do have this sort of cultural pain point of security seen as an obstacle to innovation. But 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 it to this person no matter what and you might as well find out early on do we do our success criteria from a requirement standpoint meet his or her needs and then their value message is keep development teams safe with NN security but just making sure every step of the process is covered so they can freely work. Development TEAM LEADER ENGINEERING DIRECTOR this is, 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 win them over so we can get to this person. And there, there may be a climber. When you think about the different Challenger Personas, by the way, I'm. I love Force management. If I'm talking about Challenger and Force, I think Challenger 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 trying to grow within your 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 implements are focused on creating a positive working experience for developers that result. I wrote high quality products but as an outcome for them but really just developer happiness, developer productivity. They just want to, they want to build and ship faster the right way and they want to grow with 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 evolve, helping them be productive and also simplifying. Don't 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, 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 engineers, I want to understand first. It's great to say, oh, I'm going to go top down. But something I want to 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 force something on them, they will reject and see CIOs and CTOs have experienced this over the past 10, 20 years because the developer has power. And if you're going to give them some BS rules they have to follow, like they have so many rules restrictions before they sort of ship of what they have to follow. They have so many. We talk about shifting left over the past 10 years. I feel so bad for developers. We've shift left so much that we throw so much on their plate. They just want to 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 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 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 a person you have to win over, 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 going to 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. I know we just. Before we go to like key takeaways, Amelia, is there anything else you wanted to cover in that section 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 live stream. 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 developers, engineering, I guess just at a super high level. You talked about each of them and what works. The question we got was like just being creative still work with this more technical audience. Because obviously for sales and marketing, it's all about, okay, how creative can you be in your outreach? That is, what will, how can you add value? That is really the two big differentiators if you want to 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 work, like does. Does being creative still work in these more technical Personas that you're selling?
Jim?
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 know how many people in this audience have read how to Win Friends and Influence People, but one thing that's never changed is people love the sound of their own name. And you want to always appeal to their nobler side, like motives that excite them. I think 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 going to 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 going to get engagement. So I think no matter their 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, I don't know the type of leadership or people you have like you, you all work for. But as a leader I want people to follow a system, I want them to play within the system, but I also want them to do it their own way. We all have our own discipline, we own approach. And so the creativity is where you start to see the differences in ability. And yes, creativity absolutely matters as long as it's authentic.
Yeah, I'm Greg. Richard. Let's do your key takeaways and then we'll do the rest of the question.
Yeah, so 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, 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 B seed. 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 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, hey, it's, everyone says also it's revenue solves all problems. You don't get revenue without qualified pipeline. And so the thing when I'd say like when we're talking about this and this audience or whatever audiences do whatever you need to do to get the qualified pipeline, that's actually the thing that keeps me up in when I think about this audience, how to get to them. I always think of how do I get the qualified pipeline Focus already covered that. But don't blow the ocean. Get agreement across the board, iterate, fail forward, keep going. And then for this audience, developers have power. Top down decision making won't happen without buying it. So if you don't, 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 opened up this. I have a lot of assets, I do have 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 Sasser community. We are a community and this is our crap. So with that said, I'm all good. Amelia.
Yeah, no, there, there were a few questions in the chat of how people could get into your slack, but I.
Don'T know if you wanted so we have a process for doing that. So again, if you reach out to me on LinkedIn, I'm happy. Like I can't promise you that we open it up because we want it to really be focused on a smaller group. But like if it's a right file, I'll be honest with you and tell you if it makes sense or not, but just reach out to me.
Related Question Jim 1 I debate a lot with API focused startups I've worked with or invested in or know is just how technical does the sales team need to be. And I remember, I think a long time ago you went, you, 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. There were technical account managers when I got to GitHub. Chep Jones were the first enterprise reps.
At, at GitHub and I remember when you did. We barely knew each other but I remember thinking, okay, how if you're going and GitHub was pretty well established at the time. We were an early GitHub customer in the old and I was wondering how technical do you need to be for that sale? Anyhow, 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 val. I. The sales team provides me no value. What, what are your all your learnings from that?
All right, 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. That's a little harder because. Cause 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 and, or a Commodore, I'm looking for some track record or some style of intellectual curiosity. If you think that you're going to come in and the SC is just going to run the deal and you're not going to play your part, you're probably not the right fit for most of the companies selling to this audience. So that's my passionate answer. I think it matters to like, how technical is the product, the type of depth, like the ecosystem or surface area 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, 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 if you're looking for perfect, you don't even know what that is. Yeah, my thing is it matters. 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 stages, he talks about the different stages of 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.
Good answer. But when you join, I know it's back in the day, but when you join GitHub, they're probably north of 100 million in revenue. Right. Approaching it.
No, we're not 10 or 11.
Oh, only 10 or 11. I see.
It was all, almost all PLG self.
And how, and how technical did you have to be back then in the sales cycle, talking to developers 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 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 sure we could trust it. But think about how complicated that discussion would be. So how techie did you have to be back then? 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.
And also you have to understand the culture of GitHub at that time was funny. They didn't even want revenue. We had Miwa 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? Sales isn't actually a negative for the brand.
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 and Personas 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. Cause we had some support, but not that much. We had great engineers that and TAMs that were willing to help us. But it was really. I. I learned to 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 was absolutely not. I was scared.
Yeah, that's.
Yeah.
And what's this curiousness? It's so important, right? If we. Emilia, tell me if I'm taking all the time and I know I was double booked at the beginning of this, but I think this is. I think this, I agree with this. For what it's worth. If they're truly curious, you, you will get up to speed on the 20 things that matter in your first 60 days. But truly or scared and curious are actually a really powerful combination. To your point, what are the signs of that, do you think? And for. And 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 take it to the first and second levels of hey, these are the objections we run into. This is how so for instance, can they actually do the pitch but the pitch in a more technical way to the technical audience? And we'll run them through scenarios and make sure. If you had to do this on your own, could you add a certain.
Depth before they start? Before they start, they've got to do a pitch.
Oh, before they start. It's. If I'm interviewing them and they're trying to say I want to come into this space, like that's. Those are basics. Did you do your research? Do you understand sort of the ecosystem? Do you understand or have a feel for our value, our position, not our value prop. And then like why are you interested in this? 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 put in the time once they're here?
I'm not sure they will. So how and what. And I just think this is so helpful to folks of the candidates that you've interviewed, right? For what percent of candidates actually have really done that amount of work, really done enough work accommodator before or 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 in these days? In 2025, 2024?
I would say for me, and it may be because the type of profiles I'm pulling from intentionally at our stage, I am pulling from a profile that is aspiring enterprise. So I'm pulling from a profile that's been doing market in a certain area that want to. And so they are going to, they are going to put their all into it. So I'd say 70% of the profile I pull from when I find someone hasn't done their experience. So maybe it's someone that is more tenured, an enterprise rep of 10 plus years where they feel like they've got this. Often what I find is they come.
It'S just sales, they just come in.
Less prepared and they make less. And they go, 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 Cause 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 does influence like the percentage of, of candidates that come in for.
Yeah, I do. 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, I do feel like too many veterans think they can just clone it in. It's the same thing that I did at GitHub. It's the same thing I did at Screen. I don't actually have to do much work for, for I did it. It's. I did it at Datadog or Screen or whatever. I see this all the time.
But 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 in everything up. I wear many hats. I'm a first line leader and that's the primary job I have in my first two years is I need to be the first line leader for cs for not sci. I definitely wouldn't do that. I need help with that. But yeah with the enterprise deals. So I need to balance it out with these, this people high aptitude that are striving to grow in their careers with a couple that I can lean on that have the experience. They just have to be. They still have to have the same energy and enthusiasm going back to intellectual curiosity. It 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 lean on them to make us all better and I lean on them to be an example for the rest of the. But they have to have the right attitude.
Got it. And maybe one other question and you can tell us if we're out of time now that you're, now that you're back in the early days now, how do there's this balance in sales if you're, if you're not don't come out of an engineering background and you're selling to engineers. And I think actually in any vertical SaaS there's probably going to be similar issues 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 essays 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 and you want to win in sales, you need the help. But I think that if you care, there's both some guilt around taking too much time and some concern. If I take. If I don't. If I don't take enough, I'll lose the deal. If I take too much, I'm going to 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. Have. Do you have any metrics or heuristics around this?
It's. It depends on the culture of the company.
It really does.
And how much. There's always these dynamics at play of we have G and A and revenue, marketing and sales and product and engineering and how we all play well together. And ultimately, what are our objectives? What do we put as a top two or three things we want to achieve? That actually matters a lot from dynamics of how much I'm going to pull from. But like in the early days, your first salesperson are your founders and who's going to do it better than the founders. And if I'm going to do it the right way, I've got to learn from them. So I have them in almost all the deals. Right.
I would say it's almost all the deals in the beginning, right.
Early until we start to see pipeline grow, we start to see the number of deals increase, and we start to find emotion that you got to remember, this is their baby. No one cares more about this than they do. So trust, you have to earn that trust. And the best way for me to earn that trust is, 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 build a machine. And so what I would say is like, early days, 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, you get a longer leash, then less and less. But you've already now built around what they were running with. So it's not a. It's not a very direct answer because it's a. That's an evolving answer.
No, but it's a good answer if you're coming in as a sales leader. In an earliest stage startup selling to developers and probably to any I think this 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, the environment, et cetera, et cetera. Right. You in the bigger deals, you want the founder in every deal or CTO founder and every deal is the simple answer to the question. And be aggressive, don't hide, ask for the time and upfront in the interview, say you need it. Say listen if you're built, if it get and this is common like @GitHub if you're the fir, if you're at bolting on a sales team to a PLG or community led motion right Say listen to be honest this is a great job but I need, I'm gonna need seven hours a week from you because you gotta be in every deal with me, right not in every comp but you gotta be in every key conversation right. To start in the beginning like the stipulation of the job.
Yeah. Someone asked that question earlier in the conversation and not that exact question but it hits it towards it and that's the thing is what do we really care about? We care about winning. You got to throw your ego out the door and that goes back to being intellectually curious. Also means being willing to learn and everyone brings something to the table. Like it's funny, as I've gotten older 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 you live to fight another day. Especially when you're sub 100 million like every quarter matters and that's all that matters. And so live fight another day and don't let your ego or your lack of curiosity get in the way.
Yeah, okay, one last question. Cause 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, repeated I introduced repeatedly to some amazing developer focused startups. He said no, I'm not even going to meet with them ever. I, I just want to stick to B2B. Okay? I just want, I don't know, I don't want to sell the engineers, I don't want to sell the developers, I don't want to 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 two years. Okay. And I asked how did you do it? Because you'd never sold it. I didn't think it was very hard. Now he is curious. Right? Is the answer your question? But. So two stories. Two 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 five different verticals. Long winded. Why 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 to generalize, what percent can make it? That crossover.
Never even thought about that. I think, I think any, I think anyone can make. It's not rocket science. Right. It's still the same craft. It's just your ability, your. Your desire to want to. You have to constantly learn. Like I've stayed in this space now for 10 years, but I don't know kubernetes. Like I've been working on things that are.
At least you don't know kubernetes though.
You have to. And that's it. Like that's what makes the job fun. I like going into these different verticals within the same sector because like the breadth and depth of learning, it's what makes it exciting. All the other challenges are there, but it might as well be fun. You might as well always be learning.
Yeah.
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.
And 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 vs. 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 have been selling over the past 10 years. Everyone's saying, hey, we've adopted Kubernetes, but we're struggling. Can you help your product? Answer, no, we're not touching kubernetes. And so what I saw also as a salesperson, 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 go outside your sort of depths 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 gonna 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 a gong or salesoft or Outreach or similar great world. Best applications. Right. 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 going to 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, so that's how I got into this. But like the other thing I'll tell you, it's hilarious about this is I've done those other roles and I know I can relate to that audience in marketing and sales and HR and finance. Keep it simple, stupid. Don't talk, listen. That never applied when I was selling to those people because I got it like the irony.
Yeah, you got it right.
When I switched over to this side, I shut up because I sound so dumb and I have. I talk. So what the irony is you listen with this group and you learn versus talking. It's 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 listing is the key win here. But I. I know, I know. We're over. It's a great question. I haven't been really explicit. My answers are direct, Jason. But it's. They're good questions. They're not easy to answer. It's good.
Let's wrap on that. I do think if you're. I do think for any founders, any. Anyone trying to make these hires and you're going to take the risk like, like GitHub took on Jim and others. Really make sure they're intellectually curious. 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 is 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 genuine 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 really ask about the 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 asked 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 great.
Thank you everybody. Appreciate it.
Edit it and publish it and do it more shortly. This would really appreciate the time, Jim. It's a great time.
Thank you for the opportunity, everyone. Have a great day.
Yeah, thanks everyone. We'll see you next Wednesday.










