Scaling and Managing Your GTM Team w/ Vertex Ventures, Okta, Hasura, VMware
- General Management
In this session, Vertex Ventures Partner Sandeep Bhadra asks Betty Junod, Jake Randall, and Rajoshi Ghosh, about their experiences designing modern go-to-market organizations at VMware, Okta, Hasura, and Docker.
Product-led growth doesn’t absolve technical founders from designing a sophisticated go-to-market strategy. In this session, Vertex Ventures Partner Sandeep Bhadra asks Betty Junod, Jake Randall, and Rajoshi Ghosh, about their experiences designing modern go-to-market organizations at VMware, Okta, Hasura, and Docker.
Sandeep Bhadra: Super excited here to be hosting this panel along with the Heavybit team, and of course, with a stellar group of folks who have one thing in common, which is that they have seen the journey from no revenue to one, and then more over the course of a rapidly accelerating revenue curve in startup.
But more specifically, in startups which are started by technical founders, and which oftentimes sell to a technical audience. And so that is why the Heavybit community is very relevant, and it is also very relevant for what we do at Vertex Ventures, where a bunch of our investments are in enterprise infrastructure software, and data infrastructure software, and security, and the like.
So with that in mind, why don't I just kick things off with a quick round of intros? My name is Sandeep. I'm a partner at Vertex Ventures. We've been around in the US for about six years, and we focus on Seed and Series A investments in early stage software companies. About 50% of our investment dollars and time is spent in infrastructure software and tools, and we've collaborated with the Heavybit folks in the past on companies, and we're excited to be doing this panel together.
I'm joined here by Betty Junod, Rajoshi Ghosh, and Jake Randall. Betty, I'll actually pass the baton to each of the speakers to introduce themselves. They'll do a much better job of it than I do.
Betty Junod: I'm Betty Junod. I'm currently the Senior Director of Multi-Cloud Solutions at VMware. So I've recently gone back to megacorp, and it's also interesting as a company, as we're reinventing ourselves for a multi-cloud world, which is different from where we came from.
But along the startup spectrum, I was at Docker running product marketing for about four and a half years from 100 people to 500. So that's an interesting journey. And then after that, I went to Solo.io, joining shortly after a Series A.I was the first marketing hire, and then I left right after B to go to VMware.
Sandeep: Wonderful. And so Betty, you would say that you're more a product marketer in terms of your perspective and the role in this conversation?
Betty: Yeah. So I spent probably the last 10 years focusing on product marketing, but throughout my career, I've actually spent time across all the various marketing functions. Granted some of that programs knowledge is old at this point--
Sandeep: That evolved.
Betty: Yeah, the most recent is all in product marketing, and at Solo being the only hire in marketing at that time, I pretty much did a little bit of everything.
Sandeep: Wonderful. Rajoshi, over to you.
Rajoshi Ghosh: I'm Rajoshi. I'm the COO and co-founder at Hasura. We are in the data access space. So when you're building applications, data can be across multiple places. Hasura comes there, lets you connect to different data sources, and gives you an API out of the box. We are an open source startup. We started about three years ago.
We just crossed 100 people, I think, last week. And we're distributed across five continents, many time zones. And yeah, I spend a majority of my time looking over the community and marketing functions at Hasura. Prior to Hasura, I did run a technology consulting firm for a few years. And prior to that, I was actually in genomics, and biodiesel, and bioinformatics, and very different things. That's where I come from.
Sandeep: Wonderful. How about you, Jake.
Jake Randall: I've been at Okta for 10 years now. So I started at Okta when we were 30 people and had no revenue. And now we're close to 5,000 people, and I was just looking, actually, so I don't get in trouble with our HR people or legal, but I think we did 57% growth last quarter, and we're projecting 1.2 billion this year in revenue. So it's been quite the journey.
I ran a lot of things early-on. Everything from legal, even though I was not a lawyer, but mostly really partnered and responsible for our go-to-market strategy and operations and getting where we got to. Also ran enterprise sales for a bit, and now, I run our CIAM [Customer Identity Access Management] business, which is one of our two main product lines at Okta, and comprises about a third or 40% of our business.
Sandeep: And so just as I asked Betty, her perspective is perhaps more product marketing, and with Rajoshi, it's more community and demand, and Jake, would you say that your experience is perhaps more in field operations and--
Jake: Yeah, field operations sales.
Sandeep: Lovely. I would say that the perspectives that each of the panelist brings is not just from their different companies and their different journeys, but also from the fact that they have different perspectives on the go-to-market functions within a large organization. And so the way we've structured this panel is that there's basically three sections.
First, we'll talk about how to build excellent go-to-market organizations, and then we'll talk about how to set the right goals and metrics, and recruit and retain people. And then we'll talk a little bit about how to bring alignment among the various functions within the go-to-market teams to actually make a company successful.
GTM for PLG Companies
So with that, why don't I set the stage, which is that we see a lot of startups, and each of you panelists also advise and work with a lot of startups outside of your existing companies. And everybody wants to do developer-led sales and product-led growth, or whatever the acronym du jour is. And the big question is, if you build a great product, you tweet about it or get it on Hacker News, and then you make money, isn't that how this actually works?
I mean, what do you all do? Why is it even important to do what do you do? I mean, that's the meat of the conversation here. So given the technical decisions are made by developers, what role do you play? Especially for folks who are starting out with their first company, I know that we have members in the audience who want to build and scale public companies and open source. If all of this is self-service, why do you need a sales and marketing team?
Jake: I just do webinars and joke around all day [inaudible 00:07:38].
Sandeep: That's what I'm doing.
Betty: Yeah, we just send a few tweets, and it's all done. Right? So anyone can do that now.
Rajoshi: Tweet to IPO.
Betty: Yeah, tweet to IPO. There we go. We could do that as a service even. New company idea right there. But I'd love to kick off by answering that question just from a marketing perspective. Oftentimes, I know that there is a little bit of a challenge in thinking like, "Hey, it's a very technical product, it's a developer-led motion. So we don't need marketing. Marketers don't understand." I want to put that to rest because with marketing, especially from a product marketing perspective, it's about taking,
"how does this thing work? How is it designed? And then helping turn that into messages and content and things that can then be consumed by a broad audience."
I think what often happens is the people who build it know it intimately. So they talk about it in one way with the known context. But then for someone who's never touched it before or tried it, so much of that context isn't there.
And marketing is a broad term. It could be writing stuff on the website, how the demos are architected, how you're explaining what it does, and what is the ideal use case or the first user experience you want them to have in the first 10 minutes?
That is really where I think, especially folks like product marketing can bring a lot of value. Because what we want to do is ultimately help scale the vision and message, and what the founder is building, into something that really sounds authentic from anybody at the company and is easily understood by someone who's never seen your product before.
Sandeep: Yeah, that makes sense.
Jake: Okay. I can maybe try a sales perspective also on it. Quick context, when I started at Okta 10 years ago, product-led growth wasn't really a thing yet. I mean, cloud was barely a thing, to be honest. And over the last year, I spent a lot of time on our acquisition of Auth0, which was a developer-led motion but Okta was a traditional top-down enterprise sales motion. We're just going to bludgeon you until you buy something from us. Whereas Auth0 was more of this PLG standpoint.
What we found by putting it together is that, and this is where we're all headed with this, but you need both.
I think of PLG as a great new-- we call them product qualified leads. So there's attrition, the MQL is a whole new channel of how you can think about getting people into your funnel and thinking about you.
But at some point, you want your customers to think about your business or your product in a critical way, where they want to be able to talk to someone. They want to be able to call in, they want to know that if you're going to go to production and be spending millions of dollars with you, and then if you go down, their service goes down, that there's someone. It's not just there's some forum.
And I think that that is still "people can tweet about things and get interest." It's still people business. It's just there's a tweak. But I think at some point, you still want to be able to connect, and you still want people to feel confident. And trust is a big part of any sale, and that's ultimately where your sales team comes in, if you do your job correctly.
The Importance of Marketing and Sales
Sandeep: Rajoshi, you have an open source community, which is a different sort of product qualified lead because somebody could literally download stuff off of GitHub or off of npm, and then start using the product. So how does marketing or sales work in this context?
Rajoshi: I think you could have a great product, but without distribution, there's only that handful of people that are going to hear about it. And I think that's the piece. Distribution is marketing and a lot of times when you speak about marketing, especially to developer audiences, or to technical founders, the definition of marketing can get confusing, but it's really that distribution aspect. So I think the first part of it is when you launch, you go up on Hacker News, GitHub. We went through that journey, and that's great for the initial eyeballs.
But you're going to have to learn from that, and you're going to have multiple product launches throughout your journey in a company. And so to be able to do that, you have to become data-driven, and you learn from how you're doing things well, so that you're able to strategize and prioritize better. Because in the beginning, there's one product and a tiny set of things that you're talking about. But as you grow, actually, there's a lot. So to be able to strategize and prioritize keeps getting much harder.
And the sales process, what we've learned and what we've seen is that you need sales if there's complexity either in the product or in the organization structure. Developers could adopt your product and developers could use it.
But for that to actually make its way into an organization, and for you to make that sale, you have to navigate.
Especially with first time founders or technical founders, people might not have seen that, that navigating that organization structure can take a really long time and a lot of following up and perseverance, which you might not have experienced before. And so having that sales team, or having a sales mindset is going to be very important to navigate that.
Jake: I love that point. Just to echo it, I think there's this element of "helping people buy." Where your average developer, this might be a generalization, but they can put something on their credit card or do something light and easy. But at some points, they aren't thinking about how to get a million dollar PO cut.
And so how do you help them with that process? How do you help them build a business case? How do you ultimately really get your product ingrained in a complex organization? That's where I think a great sales team that understands that motion, it's critical that they're thinking in terms of "helping."
Betty: I want to give an example from Docker. At Docker, it was a tremendous amount of our developer pool because it was so easy to just download, use, and get going. And many developers paid for the five dollars a month to get the private repo. Not a big deal, right? But what we found is, and this is really important for founders of developer tools, is that developers are building apps, but ultimately, those apps need to run in production.
And production systems then, it's no longer that laptop, it's no longer that $5. If you're a developer, and you happen to work in a bank, you have all these other things from a compliance standpoint, and security checks and all that stuff, and that's owned by a completely different team. They have all these different SLAs and all these things they have to do for their cloud environments, their data centers. We're talking server storage, networking, a whole bunch of other jazz, gateways that the developer, honestly, they don't have to care about, right, because their scope is to build the business logic.
If you want the adoptions bottoms-up, but then to make it a sale that's sticky, ultimately, it needs to run in a production environment. That's the part that marketing and sales can do, is how do you then navigate the rest of that sale to make sure that it lands there? And that's usually where you can get some big dollars.
Jake: When we sold the big banks with the technical win, I've had nine-month negotiations with legal. They're like, "Hey, we want this. We're ready to go. This is going to do all these great things for our business," and it's going to take nine months before they actually sign something because of all the SecOps and all they have to go through, and that's something that you can't solve with a tweet.
Sandeep: Moving from a developer's experimental project to actually pushing something into production is something that a solo developer doesn't decide by themselves. So they might swipe a credit card and get started with Docker or Okta, or certainly from Auth0. But then, when it transitions to production, then there's a business context around it. There's a team that depends on it. And so all of a sudden, the decision maker is no longer an individual, but it's an organization, and they're multiple people who are different stakeholders in the decision making process.
And so I heard two points from you. One is the process, the sales piece, which is how to navigate all these people, and security, and compliance, and departmental issues, and finding out who the decision maker is. And then there's also the messaging, which is "the messaging that resonates with the developer is probably not the same messaging that resonates with the director of SecOps, which is not the same messaging that resonates with the VP Eng who might be the ultimate decision maker."
Going from 0 to 1
So it'd be great, for instance, if you could take perhaps your first customer or second customer, one of the first 10 customers in any of your journeys from zero to one, to talk about how you learned and navigated that as an organization. Before, there was a seasoned sales playbook, before there was a seasoned marketing playbook. It would be great to hear examples and anecdotes, because I think that it's hard to generalize, but people can learn from the anecdotes.
Rajoshi: One of our early customers did come from a tweet. Somebody had tweeted.
Sandeep: There you go.
Rajoshi: But that was a startup so it was a quick way. But I think in terms of the larger organizations, it was an insurance company that we started off with, and we already had an open source product. There was no signup process. So people had already downloaded it, installed, started playing around with Hasura. And the technical win was there. And that being one of our earliest enterprise users, we thought, "That's it, the job is done." But that involved-- I think the whole process from when we first spoke to them to closing the sale would have been 9 to maybe even 12 months.
My co-founder got another customer from an in-person meeting with a CTO, who is not even directly involved in this product line or this business unit, just because it was a startup. You could be socializing with some folks. Then suddenly, way into the journey when they had already started using the product, there was suddenly a question about the competitive environment and how we compare to some of the other players. And then we had to run a whole bunch of benchmarks and come up with that.
So there were lots of things that just came at us, which weren't always a logical sort of step.
Sandeep: Linear path.
Rajoshi: Yes, linear path. Because the technical win and all of that was done. So it took a really long time, and people kept getting thrown at us from different departments and different functions, and we just had a lot of conversations. The one thing that we knew is we had a technical champion through all of this.
And this was before we had a sales leader or anyone, it was just the founding team, and so we made sure that our technical champion was always happy.
We made sure that there was somebody always looking at our technical champion while we were doing all of these other things. And then finally, the deal did close, and then that nurture process and that education process happened. That became our fastest expanding deal, and that expanded to multiple teams, and then they're one of our largest customers today. So it started off with that community technical win, but it was a very long navigation process through the org.
Jake: I'm trying to remember what was happening 10 years ago. I think one thing I just want to highlight is this point: where a sales team comes into play is, that trust that you're just hearing about.
Early-on, what you're selling is the founders and their vision. And that's something that you have to, whether it's your founders or sales team, that is an in-person conversation or a Zoom conversation.
I think that's a really important point to tie it into the prior conversation we were having. The other thing I'll say, thinking through, and I have all sorts of funny examples, or anecdotes, is that flexibility. One of the other buzzwords throughout PLG is First Principles Thinking. You just need people that are going to go figure things out and navigate early-on, You don't by definition have product-market fit at that point so you need folks that thrive in a non-structured environment.
Right now, Okta is at $1B per year, and growing at 50+ percent. We're highly structured. There's boxes being checked, and there's Is being dotted, Ts being crossed. Early-on, it was like, "I don't know, just go have a conversation and figure out how we can help them. And if we can help them, then get our founders involved, so that they can trust Okta and feel good about things."
I have memories of one of our first larger deals, and they're like, "Well, we need a security addendum. How do we know what you're going to do? How are you going to encrypt our data? How are you going to do this? Give us SOC 2." So we're up at 3:00 AM writing a security addendum from scratch. "Here you go, put it in the back of the MSA." You go through all sorts of crazy stuff like that to make it work.
But it all comes down to trust, and making people believe that vision.
Messaging to the User vs Buyer
Sandeep: So does the messaging have to be different for different people because the value prop that you're selling for developers is very different to the value prop of whoever it is that is one of those many stakeholders in this complex decision making? How have you seen it?
How have you seen technical founders navigate the fact that they have to change the messaging, and that talking about the awesome features of all the high throughput of whatever database is not going to cut it, basically, with some decision maker who has perhaps other concerns and is thinking about it in a different way?
Betty: I literally just wrote a blog post for Heavybit on messaging to users versus buyers. Is it different? It is a little bit, but I will say they're connected. Because at the end of the day, especially now, because the world has changed a little bit, but if you said 10 years ago, "are people really caring about developers? Can they recruit them? Are they happy in their jobs? Are they productive?" I'd say maybe not as much as they do today.
With the whole-- I hate this buzzword-- digital transformation, every company's a software company. They do care. CIOs, CTOs do care about having tool sets that make their developers super happy to work there, they feel like they're working on exciting things, bleeding edge stuff, et cetera. So they care about that. But how they care about that really comes down to things like simplicity, speed, those types of things.
At the end of the day, the messaging is,
how do you make a person's life better in the time that they spend logged in at work? Because these are all oftentimes tools that change their day to day workflow.
So going back to that use case. What is the canonical first use case that you want to go out to market with? It may change over time, like Rajoshi was saying. But there's that first thing, and that's the vision behind why you built the thing.
So if you map that out, you can say, "Sandeep, this is how I'm going to change your life with this. This usually takes you an entire day, but I've got it done, so that if you set it once, it's just a click of a button every single time now, or just one command." And then if you look at a development team, why does the manager care if that happens? Because how often does this workflow happen?
And then if you look at all the way up to, let's say, an executive. If you have thousands of developers in your organization, and this thing in the workflow is something you have to do all the time, what is the impact on that for your time to market, your delivery? How much faster can you go to market and start making money, because that's effectively what these apps are going to do. And are there other side benefits to other teams, because this workflow is fixed?
Jake: I was going to say, just to give a tactical example, because I think this is a super interesting topic, we will often land with developers, and the developer will say, "Hey, I have X, Y, Z thing that I'm being asked to code or whatever, and this makes it easier for me to do it." And then at some point, in the case of my product line at Okta, we have to go sell to the CTO or CPO.
We have awesome ROI tools we've developed over the years now, and one of the things that we'll actually "sell" is essentially this point that these developers are a hard hire. And so by doing this, you don't need to hire more developers. For developers, it's about making their life easier. And for the check signer, it's about not needing to hire more of these people.
You could almost argue you're trying to put the developer out of their job. Not actually true, to be clear. We would never say that, nor is it actually the case. But that dichotomy of thinking about selling to those people, it's a really interesting point around that messaging changing.
Rajoshi: I think what I wanted to add is in that zero to one phase, the founding team is heavily involved. The single use case that Betty was talking about is super important, because that also heavily ties into the developer experience. Our use case was "Instant API on Postgres." Super specific but that was really helpful because developers knew exactly what they were getting, and it was that single use case.
But as we navigated the org and spoke to different people, I think in the early days, that's where the vision actually works. There's a visual. There is a vision behind that product. You talk about that vision to the developer, they're not going to care too much. They're like, "Give me the product, let it work. Give me an example, let the documentation be good."You may have the best vision but if your docs are bad, I'm not going to touch your product. That's the developer. And so that's important.
But you do have a vision. In that early phase, that trust and that vision is that piece with product marketing that gets you from zero to one, but then being able to ensure that that can scale up is that 1 to n. When you're really trying to build playbooks off this and make it something that can scale, people can come in and deliver that message and whatnot.
Betty: Yeah. The vision is the big promise. And then that use case we talk about is, "and here's step one towards that."
Sandeep: There's a wedge so that somebody becomes your champion in the first place, because they've got a burning problem to solve, and the wedge solved that problem. And then for the larger decision maker who's trying to decide, "Hey, do I partner with this company? Is this a critical strategic piece of my infrastructure going forward?" That's when you're having a platform conversation, and you're tying the roadmap, and selling the vision, and all of the other pieces apart from what you just have today.
You're selling more than what's in the truck, you're also selling what's coming into the truck, next year and the year after.
Jake: Again, this is where a good sales team can be really critical. The developer's trying to solve X, Y, Z. But the sales team goes and figures out, "Well, what else is going on in this? Or what else are your problems? Oh, I can help you with that." Depending on where you are in your journey it becomes bigger deals if you're later on, or if you're earlier on, it becomes "here's new product lines we could start thinking about. Here's the ways we could start positioning our business."
Building Your First GTM Team
Sandeep: Awesome. So now we know why go-to-market teams need to exist for dev tools companies to succeed on scale. So for technical founders, what does the first skeleton go-to-market team look like? Or who should the first go-to-market team hire be, somebody in community, somebody in sales, somebody in marketing, and at what level? It might be hard to generalize, but you each work with a bunch of companies other than your own as well. And so I would love to hear perspective on how that first team gets built.
Betty: From a marketing perspective, when I talk to a lot of founders, they're like, "Should we go with a product marketing person first? Should I go with a growth marketing person first?" And this is a personal opinion, but I always think that you go with someone who can do messaging and content first, because you have to know what you want to say before pushing it out on all the different channels.
I've gone back and forth over whether this is really a product marketing person. Because product marketing people tend to be a little more broadly scoped. They've had a variety of different marketing experiences or they've collaborated with other marketing functions, so they understand them to be able to direct, let's say, a contractor or an agency. I waffle between that, and sometimes the DevRel type person.
I think that's where it depends on your product, and it depends on what your 6 to 12 month goals are, because you want to align the hire to that. Because if you want to make a splash in market, do things like press releases, I'd say more product marketing. If you want to focus on pure adoption and maybe not so lead-centric, and you just want people using and trying, then I'd say much more DevRel, because they're going to work on the actual developer experience part with the product team, and can also do content.
Sandeep: To get the first champions excited about your first wedge, what should the characteristic of the first sales hire be like?
Jake: First of all, I'll say I think Betty's answer was perfect. So I'm glad you changed the question. I think the first sales hire, I maybe already mentioned this, but it's that kind of first principles thinking type. If you do follow Betty's advice, and you hire a great messaging product marketer, or whatever that ends up looking like, even the best one won't get it perfect. It won't be right and so you need that salesperson who is a bit more technical.
You're not going to have SEs and everything probably so you have to be tactful. You have to be able to talk the talk a bit, and then you've got to be able to navigate. I think there's this phrase called audible-ready. Someone who can just get in there, and when something weird gets thrown at them, they're like, "All right, cool. Let's go over here then." Whereas then over time, you end up saying, "No, no, no, there's enablement and you just follow this playbook."
Sandeep: Got it.
Jake: So yeah, I think if they're a bit more technical and first-principles thinking, they're not going to be stuck in their ways.
Rajoshi: Yeah, I completely agree. Because I think the early phase leaders, there's a lot of figuring out that's happening during this time. You're kind of figuring out the pitch. You're figuring out pricing. You may want logos, you may want to heavily discount things to get a loan. There's lots of things that are being navigated in that phase. And so I think that first-principles thinking to be able to not be very rigid on anything is very important, because if you are, then you might not discover the best path forward.
Jake: I agree with that. Yeah. It's a market development. You're doing a lot of, I'll call it education cycles, versus sales cycles early-on that hopefully will turn into a sales cycle. There's also philosophies, which I think are really critical, because if you as the founder, or whoever is administrating that, are too rigid on that side of it, you also can run into all sorts of issues there. Because you don't know yet. You don't know how to sample those, you don't know whether you should focus on logos or something else.
Jake: So just make people happy like, "Hey, you're doing a good job. You hit the totally arbitrary quota we set for you. But you know what you're doing, so you're going to get paid." And don't get too stuck in those ways too.
Sandeep: I think that's really good advice.
Betty: Yeah, that's a great one.
Sandeep: Because everybody knows that, "so much quota is required for a sales head who's this expensive."
Jake: I know at Okta, we ran the numbers. If you lose an enterprise rep, it ends up costing you both ramp for the new rep plus opportunity cost. It's over a million dollars. : So don't be foolish. Focus on the long term goals, and get people feeling like they're part of it, and that you have their back.
Betty: You're just trying to figure it out. So be flexible especially if you're going into a new market. Which is what I found at Solo, because service mesh is so new. What was great is our founder said in the beginning, "I want for the first year, X number in production." Some might be paid enterprise customer, some might be open source, but we're going to learn so much. So let's just make that happen.
Jake: I had a conversation with a company that I advise, and they're trying to get one of their first deals through procurement. It's a six-figure deal, and I said, "Who cares? Give it to them for free for the first year. Do you really care?" At the end of the day, if you get a bunch of companies that are using your product, and they're like, "Yeah, we'll pay you in year two," someone like Sandeep will write you a check if you run out of cash.
Don't worry so much about monetizing everything. Show success. There's a lot of things there that you can start talking about.
10 years ago, they were thinking about quota setting, which is now a very small fraction of our product. Initially, we went to market thinking we could get $20 per user per month. But now it's like $1 per user per month. Whatever quotas we thought someone should be able to carry 10 years ago, we're definitely not. So if you're thinking they could sell it for 20 bucks, and we're selling it for $1, you should rethink.
Scaling Your GTM Team
Sandeep: So how do you think then, about going from that one person in sales or marketing and scaling? And what is the right time at which a founder decides that, "You know what, what I have today with my first sales person is working out well. Now, it's time to scale the organization." Do you have rough MRR metrics or ARR metrics? I'm just thinking about when should founders think about scaling this go-to-market function?
Jake: I'll take a crack at it. I think there's a lot of focus on demand that you should look at, and not marketing.
Jake: Back in 2011 or 2012 we figured out that, and this was a really hard conversation with our reps because they're reaction was, "Oh, you're cutting my territory. How can I generate more quota?" Well, the reality is, focus drives a lot of execution and drives results. And so we figuring out that by actually cutting territories, that meant that our reps could have better conversations, have more focus, and in turn, drive more demand and more sales.
I bring that up because that, for me, is a demand conversation, but it's not a marketing conversation. It's not a lead conversation. It's "how do you make sure that you're getting into the right conversation and work a bit harder, and close more deals? How do you make sure you're getting into those accounts? How do you make sure you're having the conversations that you need to have drive your business forward?"
Sandeep: That's right.
Rajoshi: I just wanted to add on to what Jake said, because that's very in line with how I was thinking about it. Early-on, when you have lower MRR, you focus more on that community function of creating/generating that demand. And once that's there, that's when you start staffing up your sales team. So maybe not exact numbers, but just as a first, community and leads marketing, whichever way you want to go, whether you're top-down, bottom-up. And then when there is enough of that is when we move towards sales.
Managing Your GTM Team
Sandeep: Let's now talk about how you manage folks within the sales and marketing team, and how you learn to set the right goals and metrics for these individuals? Can you talk a little bit about how you have onboarded new hires onto your team? Or have you seen it done at a company where you were early-on? What are some challenges that you faced, and what breakthroughs or realizations did you have that made you successful at onboarding somebody in a function?
Betty: What's interesting is sometimes at startups, it's like you're a lean team. You're going so fast. Everyone's doing everything that you don't always document stuff. I could say that's probably just something that none of us, we don't do well, in general.
Jake: You're telling me you never document stuff?
Rajoshi: It wasn't just me?
Betty: I will say though, I think the biggest thing that I did for my own scalability at Docker was to actually build a simple document even, just a Google Doc. Because otherwise, people were trying to figure out who to go to for what, and it's not even just an org chart. When everyone's wearing multiple hats, how do I figure out this thing that I'm supposed to learn about and then do some marketing on?
Don't expect them to do anything the first week, but instead in your first week, curate the list of videos and talks they need to watch, the demos. Don't just say, "Go watch our YouTube channel," but curate it. And then have them read very specific things. It can be blog posts, press releases. If you've already done messaging, yay, go read it, and then sit in on it.
If there is a sales call, whether it be founder-led, or if there is a salesperson, go sit in on a customer meeting, right? Go sit in on some of those, and then actually have some very clear actions for them. When we do our 1:1s, bring me your list of questions. What are some things that didn't seem right to you? You read the messaging doc, so give me your opinion on it. How does it answer these things for you?
So if you make it almost like a research project for them that first week, and then making it very engaging as a manager to them, I think that's the thing. It may seem simple, but especially for marketing people, because you need to ingest inputs from all these people to then author something new, I think that's an important exercise.
Jake:: One thing I'll say is, I think as you start to scale up your team, frontline sales managers, I think that's one of the hardest jobs there is, to be honest. Anyone who's been a frontline sales manager, kudos to you, because you're smack in the middle of it all. You got reps you've got to enable, you've got management hammering you on what your commit is for the quarter. You're not getting what you think you need from PMMs. No offense, Betty, I'm just joking.
Betty: Healthy tension, Jake. Healthy tension.
Jake: Yeah, healthy tension. I think I would say that as you're scaling up, really make sure that you're thinking about what you want those frontline sales managers to do, and what their responsibilities will be. And it's almost more of a cultural hire in that regard than a tactical. What culture do you want that manager setting, and how do they think about their responsibilities to onboard?
They're not going to have a formal sales enablement team. So it's about those managers taking you under their wing, shadowing calls in that kind of ad hoc enablement, which is what Betty was saying, that it becomes really critical. But they're going to have to own that to understand that, versus thinking that's someone else's problem.
Rajoshi: I think something that we found really helpful to tell folks, especially when you're in that phase where things are not probably as well-documented as they should be, is to pull. I don't know if scale is the right word, but to just get people to pull. If sales doesn't feel like they have a deck that they're happy with, encourage them to pull from folks. And I think that's something that's very important, and has had a lot of positive effects that we've noticed. It's the best way to manage a lot of chaos at an early stage company.
Sandeep: So raise your hand and say, "Hey, I need help here?" This kind of goes into what Jake was talking about culture as well.
Sandeep: The sales manager doesn't have all the enablement tools, doesn't have the right marketing materials from PMM. They don't have everything. They've got to create something, and they need to know how they're going to ask and be resourceful. And I guess that's where being a first principles thinker helps as well.
We win together, so don't lose alone.
Betty: I like that.
Jake: If you can embody that early-on, that's really helpful. It's a team sport. Everyone should be selling. We would get engineers on calls if we needed to. Everyone had to be out there and comfortable doing that early-on.
Dealing with Bad Fits
Sandeep: So I'm going to ask a tricky question, which came from the audience and I really like it, which is, when would you fire a frontline sales manager or a director? At what point do you as a manager of the sales manager start thinking about, "Hey, this is not working out?"
Jake: One thing I'll say, the culture is such a critical thing, more than anything early-on. If you still feel like they're not the kind of cultural person that you want, you need to nip that bud quick. Because I think that a lot of Okta's early success was driven by the culture that our early sales leadership set. And if that had been different, I'm not sure we would have ended up where we got to. So I focus a lot on that, because if people believe and people love their manager, I firmly believe people don't leave jobs or companies, they leave managers.
Early-on as sales manager, what's more important than hitting quota is, are they coming to you with not just the problems, but proposed solutions? If you have a lot of folks early-on like, "Well, I'm not getting the messaging that I need." Okay, well, what do you think we should be saying? So people that are going to try to drive things, that come with solutions they're the ones who are going to hit those arbitrary quotas.
Betty: And I'd say, Jake, that's something that's across the board for every function.
Jake: Right, in every stage of your company.
Betty: Yeah. Because even for marketing, it's like, "Well, we're not doing this, we're not doing that." I'm like, "Well, but tell me more about what should we be doing? What do you see? Did you see something awesome that one of our competitors did and said, 'You know what, that's a great idea? We should do something like that, but I want to add this flair to it'." or whatever. Those are the people that are going to be the ones that can help scale you forward too, because they're going to be creating more opportunity.
Jake: We'll never fire you for trying something and failing. But we will fire you for not trying and failing. That was a terrible idea, but at least you tried making it work. That's fine.
Rajoshi: And you have an idea.
Alignment Across Functions
Sandeep: Exactly. So this is actually a good segue into thinking about alignment. A lot of this is-- I better use the word-- constructive tension, which defines this sort of bottom-up developer-led journey today, at least in modern sales and marketing teams.
You have the big deal enterprise salesperson, whose job by definition is transactional in the sense that they have to get this transaction over the finish line within this deadline to meet the company's objectives. And at the very opposite end, the relationship and the developer love and the DevRel. Marketing is somewhere in the middle. So you can almost think of this funnel where there's a lot of DevRel love, which translates into more concrete messaging and needs, and which ultimately translates into a transaction.
The most common question that we hear across our DevRel-focused companies is, "Hey, when should we mine the community for prospects and leads, and how pushy should we be with leads to make them into sales to meet the quota?"
It feels like that is a natural tension in this category of companies. I'm curious how you have thought about using metrics, or data, or other things to resolve the tension as to when is somebody ready to be approached by marketing? And when is somebody ready to be approached by sales, and actually convert it into a transaction?
Betty: I was going to say that I think it's a little different now than when in the early days over at Docker, there was open source, and community stays that way, and then we have this enterprising that's separate. But part of this also goes back to product design. What is the break between what's free, what's open source, and then what's paid? Do you just have a free tier, or do you have some free features and some paid features?
Because then the path you talked about, community to leads to top-down sale, I don't think it's linear. Basically, all motions can be happening at the same time, because you're likely talking to different people. You can get the developers to be interested and playing with it, but then passively present them the opportunity to, let's say, join the Slack channel, ask questions there or give feedback.
And for that, you want to measure different types of metrics, number of people that start signing up, and the amount of engagement. You may want to look at it from how many people from the community are actually filing issues or making even simple things like corrections to your docs? So those are important engagement metrics.
Then if you have a passive "contact us for help," or "sign up to do the trial of the paid product," that's a pathway. Because it's more top-down, you can do more of the traditional demand gen type things, or ABM and if they answer a lead form, you can be as pushy as you want, because they raised their hand for someone to call them.
Rajoshi: One thing that's worked well for us is just having that funnel, even if it's a very rudimentary. What does your funnel look like roughly? It's not always linear, but there is a process. When does somebody join the community? When are they trying it out? When are they evaluating that? Having a rough idea of the funnel with all of the different ways in which they link, it's a nice way to align everybody, not just sales and marketing, but product, engineering, to know how are people discovering your product.
It's a conversation to make sure that, especially if you're a developer-first company, even if sales is reaching out to you at some point, it's a very educational, helpful kind of message. We're very careful about how we word our emails to developers in a way that we're saying, "Hey, if you need help, if you want to raise your hand, we're giving you this opportunity." And you define certain boundaries.
For instance, for us, we have our community newsletter. And in the community newsletter, you have things like webinars, and your typical demand generation events are part of that. So if you opt in to one of those, you're sort of switching over from community to the marketing funnel, you're raising your hand.
Sandeep: Got it. You raised your hand.
Rajoshi: Until you raise your hand, you don't get any kind of marketing emails. And then from marketing to sales, it's how do you reach out? What is the thought process? You want to reach out by saying, "Hey, would you like to speak to an engineer to help you solve X, Y, Z problem?" Which doesn't sound very salesy, but that might be the first touch point if it's a large enterprise. You don't want to do that for every company, so defining those boundaries and also having clear messaging for different categories of companies and types of folks you're reaching out to help keep this pretty clean.
1 to n
Sandeep: So we talked about alignment across sales and marketing and community. We talked about some of the types of early roles, first principle thinkers, et cetera, et cetera. How do you think about up leveling the leadership teams at these companies? How do you encourage folks that have been part of the journey to say, "Hey, look we need to bring on more horsepower. Zero to one is not the same as going 10 to 200.
What is the perspective of somebody who sits in that role, to think about, "Hey, this is my contribution so far?" And I feel like founders oftentimes hesitate on this issue, because it is a very emotional and sort of personal decision. Have you seen best ways to face that question?
Jake: Being clear as to what you think the company needs to take it to the next level, and having that conversation with whoever's in the seat today is important. And I would argue, assuming they're doing everything well, you should give them a chance.
Sandeep: There's no expectation.
Jake: I think what's hard about that is, often what you need, maybe it's not that you're not making quota. It's that we need someone that's thinking about these things, or pushing us in this way. It's more qualitative. But I think starting by having the conversation, "this is what we're looking for," give them a shot. Hopefully, you haven't waited so long that it's a do or die situation. "Hey, we'd like to see more of this. Let's talk about this." And if not, we want you to be involved in the hire to make sure you're comfortable.
Communication is both easiest and hardest thing in a lot of situations.
Betty: When you're going from Seed to A or in the early phases of A, oftentimes, you see a director level being a first hire. As they go to the next stage, do you level them up? Or do you bring in someone who's been at a much larger organization? Like Jake was saying, they know to think about all these other things, further out on the roadmap, and they can backwards map that for the organization.
I think that's really common, because sometimes to have someone super high level too early on is not good because there's a lot of just 'getting it done' that you want. 100% agree that you should give the person a chance. It also depends on if you're bringing in a director level hire, is it someone who's been a director for a while, are they at a point where they're thinking about leveling up any more?
Sandeep: Thinking about the curve.
Betty: Yeah, or they're a new director, so then they need time to grow. But if you see the potential and you see that they're proactively bringing you solutions and ideas, you see that there's sparks of that, I think it's up to the founder to also then lean in with the board and get them mentors. The board has access to other executives, ones who've taken companies public.
I think one of the things that happens is because, "Oh, we're scrappy, we're doing this," and everyone's going for it that you forget that it is still very much the job to, if you like these people and they have the potential, you have to cultivate them.
Sandeep: That's right.
Betty: And if you can't, you have other folks in the network who can help them out.
Sandeep: That's right. It sounds like then it's about the career trajectory of the individual tied to the trajectory of the company.
Sandeep: If you feel like this individual is growing as fast or faster then the company, then there is opportunity to have them grow alongside. And if, on the other hand, you feel like they've reached a limit where you want somebody with experience... I probably could help any of your companies with probably the first five actual sales. But there is no way that I would know how to do what Jake does, which is manage managers of salespeople. It's just that my career hasn't afforded me the experience to do that.
On the flip side, right, as you think about scaling the organization, you're also just thinking about fundraising milestones, and you're building the product and building the company as you go along. Can you talk a little bit about, what you have done in the zero to one journey? How have you communicated the overall company goals and broken it down to folks in sales, or folks in marketing, or folks in community in a way that the broader company mission is digestible and is translatable to folks within your sort of functions?
Jake: For me, have OKRs. If you've ever worked with anyone from Salesforce, you'll know they talk about their V2MOM [Vision, Values, Methods, Obstacles, and Measures] structure all the time. I say that jokingly, because it's great, and Okta has a version of that. But it's not just about having quantitative OKRs because everyone knows that you got to generate this much pipeline, or you got to sell this many things, or you got to ship this product, or go through it. But how do you set out a cross-functional vision that is compelling, that gets people fired up?
Where you feel like you have this common thing that you can all go drive that, and everyone understands what they're doing to support it. And it's not just to go hit the sales targets, but something bigger. It's something that is like that rallying cry, and I think that's what good leadership is in a nutshell, is finding that larger topic that's going to motivate people, and make them see the purpose in their day-to-day work, so it's not just a job. We all know how they work at startups, for better or worse, it's a lot more than a job.
Sandeep: Yeah. Anybody else would like to weigh in on that?
Betty: At a company level, there's a vision and goals. And then you may have a big goal you want to reach, whether you get to a point of saying, "We want to 3X the community, or we now have a number of customer targets." When you have those goals, I think for the functional leaders, it's really important to translate that back. I've had this before where it's like, "Hey, we have this revenue target now" when we're later stage at some of those startups.
But you know what, now we have a marketing associate who's doing something. Maybe they're supporting the community, all the community meetups and such, and they're trying to figure out what is this 100 million dollar target mean for managing meetups? So in that sense, it's like I think the thing for the leader is to then break that down. "Let's look at things to show that we've moved the needle in this way."
But you can be ambiguous on the exact 'how', because that's where you leave the room for the people on your team to then say, "Here's my ideas on how I can get there, and how I will show success here." Give them that safe space to try.
Sandeep: Awesome. I don't know where those 75 minutes went but it flew by. This has been an awesome panel, and so great to hear you share your perspective.