1. Library
  2. Arrow Icon
  3. Building a Dev-First Security Unicorn: Fireside with Snyk Founder Guy Podjarny
DEC 15, 2020 - 53 MIN

Building a Dev-First Security Unicorn: Fireside with Snyk Founder Guy Podjarny

  • Celebrity
  • DevSecOps
  • General Management
  • Secure Development
  • Security

In this Speaker Series, Snyk Co-Founder Guy Podjarny joined Heavybit Managing Director Tom Drummond for a fireside chat exploring Snyk’s journey building an open source security unicorn.


In this special Heavybit Speaker Series, Snyk Co-Founder and President Guy Podjarny joined Heavybit Managing Director Tom Drummond for an intimate conversation exploring Snyk’s incredible journey building an open source security unicorn.

Read on to learn about the key moments in Snyk’s history that helped define the DevSecOps category, some of the difficult setbacks the team encountered along the way, and insights that early founders can use to forge their own paths to breakout success.


Tom Drummond: Thanks everyone for joining us this morning. My name is Tom Drummond, I’m the Founder and Managing Director of Heavybit, and we really appreciate you all joining us today. I’m really excited today to be talking to Guy Podjarny, who’s the Co-Founder of Snyk, a developer-first security enterprise software product and platform.

So good to see that so many of these people in the audience are founders and leadership, 60% of you are clearly in some leadership positions at these early stage companies. I would love to start there, Guy. What brought you to founding Snyk and what was the problem that you wanted to solve when you started the company?

Guy Podjarny: Thanks for having me here, Tom. It’s always a pleasure talking to you and to the team here at Heavybit. So, Snyk is my second time around. My first startup was Blaze in the web performance space, which was sold to Akamai. I was CTO there for a bunch of years, and really if you think about Snyk and what drove me, there is maybe the founder bit and the idea itself.

The founder piece or the desire to build has just always been there, I always saw it first internally and then subsequently in actually founding companies and getting them going, to just keep challenging myself and try something else, and create. I’ve never been very good at being comfortable, so there’s definitely a lot of discomfort involved in being a founder, but that didn’t deter me.

After a few great years at Akamai I got the itch to found another startup, and I felt that I learned a ton at Akamai. I’m very grateful for my time there and the opportunities, but I felt it was time for me to start a new business. Having founded what I felt was a great company and had a great outcome at Blaze, but fairly short– I saw something that was a bit more shooting for the skies, trying something pretty big.

My history goes back to the early days of application security, having built the first web app firewall, AppShield, and app security scanner, AppScan. Then basically for about a decade and through two acquisitions, this was Sanctum acquired by Watchfire acquired by IBM, we’ve always wanted to get developers to embrace security, but we couldn’t really– I even built a product called AppScan Developer Edition, and in hindsight I would say that it was a product that was a security and auditor product built into a developer environment, but it didn’t really think about the developer as the user at the time.

It succeeded, this product succeeded financially, but not so much in getting developer adoption. So my primary eureka moment, if you will, was in the 7-8 years that I was in the world of web performance. I was very involved in the first waves of the DevOps movement and the understanding that first, the need for getting developers to embrace security is greater than ever, but also that there’s a methodology now.

There’s a playbook, there are ways to successfully build products the developers will embrace. To do so, you need to build a developer tooling company to tackle security that puts the developer first. Hence that tagline we have about dev-first security, and so that’s what we set out to do in dev-first security. We can talk about this some more, but it permeates everything. That approach affected the go to market and the logo of the company and even the culture internally, and absolutely the product UX and how we build and how we try to solve the problem.

Tom: Why do you think the developers were reluctant to embrace security products, or build better security into their development workflow?

Guy: My view is that first of all, every developer out there, if it was the same effort for them to build secure software or insecure software, they would always choose to build secure software. The ones that are not are really problematic, but they’re very rare. So really, the question isn’t “Why aren’t developers–? Why doesn’t the developer want to tackle security?”

That’s not the reality. But rather, that they don’t want it enough to overcome the friction. I think that’s true for pretty much any problem that you take on. There is how much you want it, how much you care, and then there is how hard it is. You need to figure out whether you increase the caring or whether you drop how hard it is, and that’s really what we tackle.

My view, and I think that’s still true today and there is great opportunities there, is that security was just too hard for developers to do. Because the products that were built were not taking in mind, they are not built focusing on the challenges or the needs of that developer.

So it just resulted in something that required pretty heavy conviction, or somebody to shove it down your throat and require you to do it to adopt it. I think our primary accomplishment at Snyk was to make security as easy as it can be. It’s still work, it’s still an effort, but we try to weave it into the developer’s life. There’s a lot of ways to achieve this.

If I throw a few quick things that I think are actually very applicable in other areas as well, for example, the Git integration. The fact that security audits are really a form of code of collaboration, of code review. You build something and then you want to interact with a team and review it, and for the most part, code review happens in Git pull requests, the key collaboration of reviewing your code. So we built integrations around that surrounding, which required some specific tech and that allowed us to integrate and build that. Probably even more notable is this notion of the automated fixed pull request.

We found a bunch of issues and we found vulnerable open source dependencies, and we figured that a developer’s job– Arguably an auditor’s job ends with finding those issues and then logging them or reporting them back to development, but a developer’s job doesn’t end with finding the issue, it ends with fixing it. So we really put in a lot of effort into completing that circle and actually opening a fixed pull request to the issues that we found.

These are just two of many examples of just thinking about this problem in the sense of, “how would you? What’s the ideal product for you as a developer who wants to build secure software?” But you also want to do a lot of things, so you need it to be within a certain reasonable level of effort.

Product Discovery

Tom: In terms of making it easier, making it simpler for developers to adopt, you mentioned some Git integrations there. But are you mostly relying on your own intuition as founders to figure out the features and pieces that make developers’ lives easier? Or was there a process or system that you had for, measuring even, how easy it was to get your product up and running with a new developer?

Guy: I think it’s always a certain balance, but especially at the beginning you need to have a certain amount of vision. I think where data kicks in is validation– Or, where customer data kicks in is on the tail end after you’ve build it in the validation, both what you’re doing but also of how you’re doing it, which we can dig into in a sec. Then before, in an appreciation of the pain point.

So if I look at Snyk as an example, the space that we chose to start with was open source security and this notion of, “you’re using libraries? They’re vulnerable. You need to find out which libraries you’re using and you need to/want to tackle that.” What we did hear from customers is a validation that they even care about the space, and we learned that developers generally are uncomfortable with dependencies.

So the nerve, you still need to find something the developers are bothered by for them to pick this up, and that was really the vicinity of the area that we’ve had. It was intuition and then validated through customer conversations. The pain point wasn’t security so much as those dependencies, and then tipping that in. Then the thesis of “how do you build it, how do you fix it?” that was always an iteration. So for example, in Snyk’s case the idea of providing a dependency tree, so

Instead of giving you “here are 500 libraries your app depends on,” we instead paint this as a graph or give you precise guidance around, “You’re using A, that uses B, that uses C. C is vulnerable, here’s the minimum change you need to do to A to fix that.” That was intuition, and that was the original path.

But then for instance, what we’ve observed when we built this, we built a CLI only and we built a beta of that CLI, and we had great feedback. Great usage, people would download it and they would run it, they tweeted good things and they gave us good feedback, and they never put it in the build. We said, “The thing to do is to put it in the build.” But they didn’t put it in the build, because it was too much effort to put it in the build.

Similarly for the fix, they got good guidance, but they wanted more. We built the CLI wizard that walks you through fixes, and data showed it was used when you downloaded it, you ran the wizard, which is actually what we guided you to do, and you fixed a bunch of issues, and then you never came back to it again.

Because we didn’t create that continuous relationship, so that was a problem that we learned from data. Then again, intuition or our vision around “how do we fix it?” was to say, “it needs to be easier. Users discover us over the web. Collaboration happens in Git.” It was really only about eight months later that we launched our Git integration, which was one of the better moves that we’ve done, in terms of product.

It’s always some collaboration between those, you’re trying to educate or invent a new way of doing it that is more developer friendly. “I don’t think customers would guide your way into it,” is the whole Henry Ford quote of “Customers would have asked for a faster horse.” But you do need to work with them to understand what is the real pain and how they are acting and why they are acting with the solution that you provide to them?

Category Creation

Tom: There’s a step before getting people to interact with your product or download CLI, and that’s just getting them to pay attention to you. Getting them to come to the website and getting them to go to the open source project. How did you think about that in the early days of the business, when you wanted to introduce essentially a new set of concepts to developers? How did you entice them or get them to come and even take a look?

Guy: I think that’s a very important question, and that is actually one in which we invested proactively a fair bit. I advocate doing it, so we were trying to get developers to care about security and we were advocating open source security at the same time. The two were basic notions that were advancing together, and we’ve done it in two ways. One is the more traditional, just education, and as I mentioned before referring or relating to something that customers care about, which is dependency management.

So we chose an ecosystem which was npm that we started with, and with dependency management, dependency pain was sufficiently discussed. It was understood that it’s an issue, it’s a challenge, but also a place in which consistency of the community was just the right size. It was like Ruby was when Heroku and New Relic came out, it was big enough that there were enterprises building it and a big user community, but small enough that you can make your way to the top in terms of talking to the leaders in this community and becoming an influencer in that community. It was consistent enough in methodologies, and it hasn’t sprawled as much, in terms of those, so we can build things.

One aspect of it was just becoming a part of that community, investing in good education material, getting to relevant conferences like NodeConf and Node Summit, and engaging with leaders in this space. It was more about within that niche that we picked, it wasn’t a tiny niche but still a niche, just being out there publicly speaking and referring to, “how do you address this problem?” Always in a non-preachy fashion, but also always with an eye towards our solution.

The other thing that we’ve done, which is not always available but I think it’s important to try, is being free for open source. Generally, open source projects are a great virality vehicle, but they’re also a great role model. Generally you don’t see really beyond the blog post and all that, you don’t see how most companies develop software, but open source software development happens publicly.

So when you talk about adding or changing development methodologies for that specific slice, if you can be a part of the open source space, you’re doing well for the community because you’re helping these open source projects be secure. But in the process, one is you’re getting direct visibility when an open source project that has 100 watchers on it uses Snyk and we open a fixed pull request to fix a vulnerability, 100 people get an email. These commit statuses show up when somebody reviews those projects, so all of those create a certain natural virality and visibility element.

But then also you’re teaching them a methodology, you’re showing them that this is a means that can be done. Then people would come along and would bring it into their home. So I would say clearly there’s a lot more to it, but those are the two primary means in which we established ourselves in terms of visibility and then following that is just a very seamless, as I talked about, the Git and all that. Next, next, next as easy as possible onboarding process. To get going and then start a continuous process that monitors your applications and talks to you about security in an ongoing basis.

Freemium vs. Open Source

Tom: Being free for open source projects is certainly a huge value to a lot of a lot of users. But what about actually building or developing open source software yourself and giving that back to the community? Is there any part of Snyk that is open source? Or, to what extent do you actually develop in the open and allow people to use software that you’ve written?

Guy: Let me start by talking about freemium and then I’ll go to open source. I think, for developer tools as a whole and really I think for any product-led product, you want to think about whether you want to have that freemium tier of users that use it. When you think about freemium and these are people that would use the product in an ongoing fashion and would never have to pay.

They would never really get to the point in which for a certain set of use cases, those people might eventually pay, but for a certain set of use cases they shouldn’t need to pay. So when you think about defining your freemium, and I have many thoughts about freemium versus free trial, but when you think about freemium it should be defined not technically, but rather from a use case perspective.

Know who, which personas, which audiences should be able to do what with your product for free forever. And then, what is it that you want from them once they’re using it? For instance, do you want visibility or do you want them to convert for other use cases, to paying? Etcetera.

So, Snyk has a very rich freemium user base. We are free for open source. For those users, really our return is that visibility and influence that we talk about. We are free for a low volume usage and private code, where our return is eventually having some of those people talk to a salesperson and consider purchasing for a governance of security. High level, that’s the split right now, freemium is really for smaller teams and building securely if you want to govern. So I know it sounded like I’m ducking the question, but basically, I think open source is a form of freemium. It’s an extreme version of freemium, because it’s a one-way path and it’s also one that doesn’t necessarily afford you as much a conversation.

Open source, I know that for many people it’s a principle. It’s not for me, I think we are involved in the open source community for instance, by it being free for open source.

We are active, sometimes we lead the security working group of many open source foundations, we find hundreds of vulnerabilities– I think it might be even hundreds monthly right now, but many vulnerabilities in the ecosystem. For a good chunk of those, we actually help contribute to the fix or we help collaborate with the maintainers for the fix. But we don’t actually have some big scale open source project. We have open source clients, but not a full open source product that is usable. I think for us, that’s right.

The way that we serve that freemium audience best is through that freemium service, not through some freemium open source. For many reasons, including the fact that we need to maintain a vulnerability database in a constant fashion, and open source is not great at that. For other products, what I would advise is you need to think about whether it’s right for you or not.

For instance, if you’re building something that you expect to get embedded into the Kubernetes and CNCF ecosystem, then there is a certain advantage to shipping something that is open source. If you think databases today, there’s a certain understanding from a data perspective and data sensitivity, there might be a bias to doing open source.

But my view, my philosophy, my advice here would be to not start from open source, but rather start from saying, “do you want freemium or not?” And then “how do you reach this audience? Is open source the right means to satisfy the use case? Is open source the right means of distribution?” And I think oftentimes the answer is “no,” and companies get stuck open sourcing first because it seems like a means in which they would get distribution, but then they get stuck delineating the use cases for which they want to charge and the ones that they want to get for free.

Tom: That’s great, and just to pull on that thread a little bit more, obviously there are elements of your freemium product– Or, there are limitations. If you’re not building open source software there are limitations to using the free version of your product, so how are you making those decisions about both what’s free and what’s not free? Other than perhaps the user and the use case, but, what are the axes or the dimensions that you’re choosing to charge on?

Guy: I think that’s a journey that I would say is still ongoing. At a high level, the way we decide what’s in and what’s out is use-case driven. I’m a bit of a broken record here, but it’s very important. It’s not about a technical limitation, it starts from use case, and for that use case we want customers to be successful.

So what you definitely don’t want, for instance, if we give you the ability to run five tests a month and we say, “the best practice is to put it into the build and we’re looking for modern companies running a lot of tests,” that just doesn’t work. It’s not a freemium, it’s a free trial. It’s a means of trying out the product but you can’t actually successfully use it by putting it in the build, so we define use cases. They don’t have to be fully straightforward but they need to be simple enough to reason with and reason about.

Clearly we are free for open source, and that’s one key element. Then the other is for smaller teams, that high level definition for us is that for smaller teams, smaller development teams that are looking to build continuous security into their product, they should be able to use the product as is. That includes smaller teams in the enterprise, for instance, it’s not just small businesses.

Now tactically, a measure of open source has to be very simple. So the measure that we put in place for the freemium tier is the number of tests. Basically, how many times do you ask, “am I vulnerable?” We bundled in the test that you might run in the CI, but also the test we might run in the background for you on a daily basis to see if a new vulnerability was disclosed and alert you about it. We figured that the number of tests is a very simple test or measure, so it’s very easy to track it and we have visibility in the product to see where you are.

One thing that we have done is we have very soft limits. In this conversation, say you put it in the build and you hit your 200 tests/month monthly limit, do you want us to break the build? A very important decision we’ve made, which I absolutely vouch for, is the answer is no, we shouldn’t stop it from working. It implies the test is soft, and we are in there, “What do you do? Do you not test? You don’t actually provide the security validation?”

So we provide a soft limit, we have the ability to break it, which we absolutely very rarely do, to actually turn that on and say “No. OK, Look. We’ve bugged you a whole bunch of times, you’re over the test limit.” It shouldn’t break, and maybe in the future we would be a bit stricter, but we definitely don’t just right away go off and break the build, because the likely result of that is someone’s going to pull us out of the build. That’s the whole system.

In contrast, in our Git integrations we have the ability to fail, to not run the test and do so visibly without being disruptive to the process. Over there, we do block that test so that interaction around hitting the test limits is different. What we didn’t do, if I add one more bit which is on the pricing front, we had the choice to say “do you want to bill by test?”

We actually decided that we don’t want to bill by test, because test is a very utilitarian measure. When somebody buys Snyk or purchases a license, then we think that our value is best measured by the number or the size of the dev team. Basically, the more developers you have the more app you have, the more value we provide. We measure and we provide developer productivity, we help those developers build secure software, so we charge by the number of contributing developers.

Which is, we think, a better proxy for value but is not as clean from a tracking perspective and all that. So in the pricing, I would say most important thing is aligning to value, to the extent you can in the freemium tier. You really have to have something that is very clear cut, “Are you over the line? Are you under the line?” And then “Don’t be disruptive where you can avoid it.”


Tom: You mentioned at the start of that, it’s been a journey for you. Was there a point at which you said, “All right. Now it’s time to turn on monetization,” or “It’s time to become more enterprise-y.” Or is that something that’s been more of an evolution?

Guy: It’s been a lot of learnings here, but I say the main one is when we started Snyk, we knew we were going to have freemium. The developer count was a little bit more of an evolution, but what we did think is that like many devtools, we will have a free tier and then we’ll have a $20, $50, $100 a month type tier that allows you to start moving up from the free tier to premium. That failed spectacularly. Basically, we built a product and we accumulated thousands and tens of thousands of users, we turn on the GA and we put the pricing, we had a grace period for the free users and we expected the floodgates to open and lo and behold, not even a mere trickle came over.

When we dug in there were many reasons for that, and I think the reality of it really boils down to the fact that we haven’t really fully defined the use case for the purchasing. We defined the free and the paying from the free perspective, but we didn’t really define “what does the buyer need?” So we didn’t have an appreciation that our buyers have slightly different needs, and today I can say, and we learned this over time, that the primary reason people purchase a license for Snyk is for broader governance. So you say “In my business unit, I want to know what’s going on.” The person signing that check tends to be central. Platform or security versus an individual developer that is the person, or a small dev team.

If you have three directors of engineering in your group, it doesn’t really make sense for one of them to govern their open source usage with Snyk and for the other two not to, it’s less natural for them to do so. So we learned that governance unit is probably the one in which a purchase should be done, so what we did is we basically increased the freemium piece of it. We gave a much more generous free tier, so people can stick around for longer. In turn, we basically skipped a tier almost, and jumped straight to the next tier that offers those governance capabilities and started selling in that element, and also satisfying other needs that the buyers had.

In the case of security for instance, developers like depth. No developer could care less that you’re amazing at PHP, they want that. But a security person wants breadth, they want you to cover a security threat across most of their stack. Otherwise, you’re not tackling the security risk.

So satisfying those two was probably one of the biggest challenges we’ve had, and I think good execution got us there, but all of those learnings led us to where we are today. When I say it’s a journey, I would posit that it’s possible that today the industry started five years later, 4-5 years later. I think the notion of a product that offers continuous security before governance may be viable, so it’s possible that now is a good time for us to introduce something that is a slightly smaller price scale that focuses on container security, and we’re considering it.

We’re having those conversations, and that’s why I’m saying it’s a journey, because you need to adapt a little bit as your market adapts to those changes. But it’s not a one size fits all, of what worked with one dev tooling or the other. So I’d say the primary lesson is to think about the user needs, but also when you think about defining your tiers and all that, think about the buyers need to know what would truly, not aspirationally, but make someone purchase, and then plan your tiers accordingly.

Org Evolution

Tom: You mentioned, Guy, that the market evolved. But I’m sure in this transition from being a developer first or an open source first security product into something that’s more governance related, more enterprise focused, I’m sure your organization has changed pretty dramatically as well. Can you just talk for a minute about how, in broad strokes, you feel the organization has evolved over time?

Guy: Maybe I should describe a little bit our growth journey from a numbers perspective, first. Snyk is circa 400 people right now, we were about 250 at the beginning of the year. This year, because of Covid, there was a moment there where we stopped hiring for about a quarter, and then we ramped back up. So we were 250, we’re probably going to be about 450 by the end of the year. The year before that we were 80, so we went from about 84, I think, to 250. The year prior to that we went from 23 to 84. So, 23 to 84 to 250 to 450, and this is with the slowdown that we had this year for a quarter in terms of hiring. It’s fast growth, there’s a reason they call it “Hyper growth,” that’s a lot of people to hire and it requires a lot of changes.

The two that I would highlight are 1) from an org structure perspective, you always have to figure out “Where do you want to specialize?” So when you start off, you have a lot of teams that you want them to be generic. You want them to do many things and you manage different backlogs in different ways, and the easiest to think about is the engineering organization. In engineering, you have one team and they do it all. You might have two teams or something if there’s some specialization, but mostly you have teams that build the whole product.

Over time we started divvying out a team that was focused on enterprise. Basically, we had the core product and then we had specific functionality around enterprise single sign on, some reporting capabilities, things like that. That carved out over time, and that team in turn got split into a governance team and reports versus a scale team that’s more about user management and doing it.

There is actually another split that’s happening right now as those teams specialize, and clearly that’s just one vein and you build those out as we launch more products, there’s specialization for those products. So the one thing that happened, and that you always have to reassess, and we did that reassessment constantly but really heavily every 6 months or so, is to just reassess what’s the right org structure.

“What’s the right means of ownership?” And then try to figure out “How do you fit it into the people?” Versus the other way around, of “What else can the person X do?” I think that doesn’t get you the right element. If you’re a technical founder, you can think of it as architecture. You can’t code your way this way, you need an architecture of your organization and then you need to figure out how people fit into that. If you start from the people right away, then you won’t get to the right result.

The second thing that’s very important and that’s sometimes a bit more hard to stomach is the leadership, and that’s really when you talk about “When is it that you need to balance bringing people from the inside versus getting external talent?” It’s true for specialization, and it’s a little bit easier to stomach it there if you need an SEO expert or you need someone who has proficiency in the tech space. It’s harder a little bit when you think about management, it means you can’t always promote from inside.

Really the ideal, and we’ve done this sometimes better and sometimes worse, is to have a mix of people that you promote from within and that embody the DNA of the company and what has made you successful so far, and give your talent and individuals an opportunity to grow, and from outside especially when you’re growing so quickly. Because it’s impossible to think when you’re growing at the pace that I just described, that everybody would grow their capacity at the same pace.

If you have someone who manages all of a function and in one year that entire function is them, and then the next year it’s them and three people, and then the next year it’s them and 15 people. Not everybody can grow, in fact, very few people can grow to be the right person to hire within a year. Especially when you grow that quickly, people don’t necessarily have as many cycles to just naturally invest in self development.

They need to grow on the job, and it doesn’t mean that they’re not talented individuals. It just means that it’s a very fast pace of growth, so depending on their background sometimes people have stretched down to take that job. For those people, it’s a little bit easier because they grow into that job. For others, it’s not.

So what you need to do, and we’ve done a fair bit and we keep doing, because we keep growing at this rate, is to hire people from outside. That statement is true throughout the company, but it’s especially true in the executive level. There could be multiple directors and you can hire another director, but for an exec it’s almost always effectively a demotion.

You used to run this entire function and now you’re running a subset, and somebody is being brought above you. That’s hard to stomach, but it’s massively necessary. We can talk about one big change we’ve done, which is I stepped down as CEO and brought in a CEO to take my place, and we can talk about that. But I would say when you’re hiring leaders and especially execs, you should make sure that you hire someone who is stretching down to your size.

When you need someone to manage 40 people, if you use that as a measure you don’t want to say, “I want to bring someone who has managed 40 people in the past.” You want someone who has managed 100 people in the past so that they stretch down to your size, they can build it up and in a year’s time they have a little while in which they just need to grow into your surroundings. They don’t need to grow in that aspect of the job because they’re set up to grow.

Tom: How has the split changed over time between engineering, marketing and sales? If you think back where you are, say, at the end of this year versus where you were at the end of last year, versus the year before. How do you think about the split in terms of headcount and investment?

Guy: I think I’ll describe three quick phases. Which is at the beginning, sales is minimal. You’ve got nothing to sell. It’s all about R&D. As a founder, you’re out selling and you might hire an individual in marketing or an individual in sales, and you build those out. But as numbers go, they’re tiny. As far as once you hit that fabled product market fit, basically once you have a product that is demonstrated to be something people need to buy, a big part of what you’re trying to do is to get it in front of people and to get those people to enjoy their tech.

But in the meantime, you’re probably still very early because if you’ve built this correctly, you’ve built the MVP, you’ve built the early product. So you have a lot to grow, and so the sales organization and go-to-market organization, sales, customer success, marketing, they grow to accommodate more and more need.

They basically derive out of the revenue number that you achieve. The reality is, that piece of the business grows very rapidly because the engineering is growing at a more regular pace, if you will. But this is going from nothing to a fair bit, until it ends up being roughly matching the size of the organization.

Alongside that grows the G&A organization. Over time that being able to successfully support a larger revenue stream, a larger organization, and you just need people that are more dedicated to those jobs so they grow. Then in the phase that we’re in today, we’re looking to public benchmarks, and those exist. So you look at companies that are product-led and you try to create a peer group of companies that look a little bit more either like you or ones that you want to look at, and they give you percentages and you need to choose where you are on the continuum.

But there is a certain range that you should expect, especially if you think about in the future going public and you think about “What would the investors expect there?” But also as a healthy barometer of “How do I relate to–?” Because the natural tendency is for engineering to always want to just basically be “No, I want to be 80% R&D.” In most cases, that doesn’t really work that way. So you compare it to the benchmarks and you try to not go below, so you don’t get overly tempted with the revenue targets and all those.

Frankly, engineering is the question. Because G&A has a certain math to it, sales and go to market is a very straightforward math. Many of the heads that you have there, most of the people you have there derive out of the number. You want to sell X ARR, there are so many reps. Every rep carries a certain amount of quota, you expect this much quota attainment, every sales rep needs a certain amount of SEs. Marketing needs to generate pipeline, we need to do those. Customer success can’t support that many customers, so there’s formulas for the majority and for the lion’s share of the of the headcount there. Probably the more creative piece is the engineering side.

Key Hires

Tom: Are there roles or individuals that you hired relatively early in the trajectory of the business or the life of the business that you found had a bigger impact on the trajectory of the business? Was hiring your first VP of Sales a key unlocking moment for you, or were there other key hires? Either in executive function or senior leadership functions that changed, or gave you a bit of an inflection point?

Guy: I think we’ve had quite a few leaders that made a big deal. Although I am a product person and an engineering leader, I had either a VP Engineering or a Head of Product, who subsequently were replaced with the VP Product early on. I think that was a good move, because I had proficiency in the space, I knew what good looks like and I could hire the right person, and I could manage them with a relatively small amount of effort. I could spend my time doing the other things, getting the product out there in the community and such.

Subsequently, I hired a Head of People, probably premature to hire VP people, which I did. It was important for me to say “VP People is a function that is just as equivalent to all the rest, and therefore I called it VP.” I don’t know if it would do precisely that, but I think hiring a head of people and of HR, I think, I’m very happy with that move.

Tom: When was that, just out of–?

Guy: When we were in the 20s, we had some twenty odd people, I think.

Tom: It’s interesting. I think one of the pieces of feedback that I get from a lot of founders is that “We wish we’d hired a Head of People, Head of Talent sooner.” Often we should be encouraging people to do it after their Series A, which can’t happen around 20-25-30 people. It’s amazing how much, one of the key challenges for any large organization or any fast growing organization is hiring, and having someone dedicated to that is just game changing.

Guy: I think hiring is a big deal, but also the talent. Just thinking about how to build the company right, it comes back to that architecture. It’s like saying, “How many engineers do you want to do until you want to have someone who’s majority of time is dedicated to ensuring that the architecture is correct?” I think it’s just important to get it right. Hiring becomes the primary part of their job, and even the hiring processes are important. But also just the methodologies inside, your people are just a group of people working together in a certain market. So, making that work well is very important.

Tom: Was there something that told you needed to hire a Head of Person, or was this some catalyzing effect that you needed to hire them?

Guy: It was actually quite a philosophy for me from the beginning of the company, I kept saying “It’s just as important for me to build the right company as it is to build the right business. It’s important for me to be a place that I’m proud of having founded this company, this group of people, this organization.” And I am, absolutely, about Snyk. It was important from the get go, and so hiring that Head of People was just my decision and nobody got in my way.

Clearly, yes, most of their time at the beginning was more recruiting oriented. You needed to have enough funding, and I think it was after a certain run of funding that I allowed myself to do it. But I knew it was important from the early days, and I’d be remiss if I didn’t also mention our VP Sales. But VP sales, I think for us it was very important to decide if we wanted a VP Sales and we had to decide whether we wanted more of an enterprise VP sales or more of a product-led bottom-up VP Sales, in terms of their original experience.

We hired Ethan Schechter, who has been amazing and comes from the devtooling world. That was a very conscious decision that I’ve spoken about, I probably took a bunch of months to decide and spoke to many candidate VP Sales just to say that we’ve already had a couple of sales people, maybe definitely one at the time. So we knew a bit more about the sales process, but it was very important for me to basically say “If you go enterprise first, it’s hard to go back.”

I felt it was more important for me to anchor the transactional, methodical, product-led growth approach with the ability to do enterprise, which he has. But it was important to ensure that piece is done well, and then subsequently we hired further. He indeed ended up focusing more on that transactional system, and we hired a different Head of Sales who was more enterprise oriented to run the broader function. I think both of those decisions were at the right time.

Top-down vs. Bottom-up

Tom: Stepping back a little bit from the organization and thinking more about your overall investment in developer tooling or developer products versus the enterprise user. How has that changed over time? Because as you mentioned, if you start going into enterprise too early it’s very hard to go back. How much do you invest in content marketing and the outbound efforts for developer-focused usage, versus for larger enterprise use cases?

Guy: It’s really an important question, and it doesn’t have a very simple answer. Because oftentimes the product is intertwined for us. Developers are at the beginning and the end of the curve, so if I have a multimillion dollar customer on one hand, there’s a question of “OK. Are the developers at that organization using Snyk on the free tier on some lower cost tier and then that led to the purchase?”

But also there’s the question of once purchased, developers are at the other end of the curve. That customer will succeed or fail based on whether developers embrace the product. So there’s two angles to it. We are developer focused pretty much across the company, even in such a large customer, because that’s a promise to the customers. Our developer dedication is greater than that of our product-led growth motion, if you will.

Tom: You see it mirrored in a customer success organization.

Guy: Exactly. So we talk about developer adoption, we talk about developer adoption amidst customers who licensed 15,000 developers to use Snyk. We want 15,000 developers to be using Snyk, so how do we help make that happen? But the question is still very valid, also, on the bottom-up motion and the product-led growth. Increasingly, basically what happens there is we have before what we’ve done primarily is it comes back to that specialization.

It started from a single team, doing everything and managing into the backlog. It went on to being teams, so dedicated teams that are focused on the online developer experience and the onboarding and the activation. We’re actually now forming groups, directorships, groups of teams. The same goes in the marketing side, the split was DevRel focuses on the developer audience and direct to developers, while marketing focuses more on the buyer.

We’ve since merged, and we put DevRel as an independent part, a big part, but still a part of the marketing organization. So within the marketing organization now we have that developer approach and product-led growth team, so we have developer relations and developer marketing and our growth, if you will.

Then those peer up with those peers in R&D. What we haven’t done and we’ve considered and it’s a fair model, is to put a single GM that manages the engineering and the marketing and all of that for the product-led growth motion versus not. In my opinion, that is less fitting, at least for us, because we don’t want to distance.

Everything is developer oriented, everything needs to have that blend of product-led growth, including the product lines. So we want dedicated resources because we’re going to make sure it doesn’t get starved in the midst of these big customers, because it is easy to get sucked into investing everything over there.

But you don’t want to distance engineers that work on that or the product people that work on that, the marketers that work on that, you don’t want to distance them from the rest of those organizations.

Tom: It’s not a binary choice, whether you’re enterprise or developer focused. It’s far more of a spectrum–

Guy: It’s just resource isolation, and fundamentally that’s the only two ways that you have means of prioritization. Either you prioritize, you manage your resources either through prioritization, and when you don’t have enough resources to split then that’s what you do. Enough people to work on it, or through resource isolation, through basically putting dedicated people to it.

Over time, as you specialize, this is one of the more important specializations to keep in mind. Because left to its own devices, it’s really hard to ignore these large deals and not naturally rotate in the backlog. Defer just this other, just one more feature that the free online user would care about, but the multimillion dollar customer wouldn’t.

Tom: Do you try and track and measure the end financial ROI of all of your investment in developer product and developer marketing, and the bottom-up piece? Or is there a component that’s still quite EQ driven, say, rather than–?

Guy: No, we increasingly are, and I wish we had been even more, but we are increasingly connecting. You want it to be one full funnel, I would say when a company grows quickly that you never have enough data. There’s a whole million of areas where we are still too intuition driven as compared to what we want, but it’s not because of a decision.

It’s just sheer investment that is needed in a bunch of these places, but we have the logic and the definition of saying “What’s the full customer journey coming through it?” I would be first to say that this is an area that we want to invest more in, and I don’t want to paint a picture here where everything was perfect and we’ve made all the decisions correctly right away.

There’s a lot of warts. This is something where, especially middle of last year, we were tracking but only a portion of it. So we knew from our free registered users, we knew to measure the path to a paying user. Over the last year and a bit, we’ve invested a lot in improving that. I think we have much better understanding of the ties between our community work, our free user base, and all the way to paying customers.

I would still say that we have massive gaps, so some of it you have to take a leap of faith. Especially investments in community, you get an inbound lead. Is that related to your free tier? It probably impacted your brand, so there’s probably a relation there, but you can’t always measure it. But you have to have some data to track because without that, you can’t optimize what you can’t measure. You have to do it.

Final Advice

Tom: Guy, is there anything in particular that you think has been a key formative event in your journey with Snyk that has changed how you thought about building developer products, or has changed your preconceived notions about what it means to build a large enterprise software company or develop a company?

Guy: I think I’ve learned a million things over the journey, so it’s hard to reduce it to really one, but I think probably the one thing I would go back to is this notion of use cases and the user versus buyer. Really deciding what is your true North, and I think what happens in the world of bottom up in general, product-led growth, but anything that has freemium in it, revenue is a second order indicator. Because you need to build a product that needs to get a free audience, a user base using it, and then you need some of them to convert to paying. Versus building a product and right away going to paying. Neither is easy, but you need to acknowledge that if you’re going to that freemium path, you understand why you’re doing it.

You understand what is the measure of success, you have investors that are attuned to that conviction and share it. You need to understand, what’s the true North.

For us, there have been many opportunities to rotate. In fact, those continue to exist. Many opportunities to over rotate towards security, and we stay true to this destination, to this vision and this belief that the only way to solve security and application security in what we call cloud native application security, to build secure software in the world of DevOps and cloud, is for developers to build software securely as they build it.

We keep measuring and monitoring our actions not on a daily basis, but on a holistic basis compared to that true North. If you don’t have that, then you can succeed but you’ll become tactical. You’ll address today’s needs versus tomorrow’s needs, so you need to have some perspective on it. Sit down, write down your use cases, your needs, and make sure that your investors and your team are all aligned with that journey that you’re trying to accomplish.

Tom: I think that’s probably a great place to end it. If people want to hear more about how to build software security, they can listen to you on your own podcast. Is that right?

Guy: Correct. I run a podcast called The Secure Developer, which Heavybit helped me start. In fact, probably without the Heavybit affiliation I don’t know if I would have started it. So really, I owe you a great thanks here for the program and to Ted and for getting it up and running. We talk to security leaders and development leaders about how to build secure software and how to make your organization do that as well.

Tom: That’s great. Where can everyone find it?

Guy: It’s on any of the podcasting platforms, it’s also specifically on DevSecCon, which is our community website.

Tom: Thank you again, so much, for joining us this morning or this evening in London. We really appreciate the time.

Guy: Thanks for having me on.