From acquisition to full conviction

What turned me on to reach out to you was your recent raise… And often, businesses use raises as a mechanism for marketing, but also in a way a position of gratitude, to some degree… What do you think about that? It seems like every time you raise - which I’ve only seen a couple of them, but any time you have that kind of news or that kind of thing to share, you often as a founder get a chance to look back at what you’ve done. What is that like for you?

Yeah, I think a part of it is definitely kind of an acknowledgment of success. To an extent, in startups you kind of move from raise to raise for a while, as you build it up… And there’s definitely that moment of just taking stock, and saying “Okay, I have this smart external entity here, who is willing to literally put money, betting on my future growth”, and that’s quite compelling. I like that.

There’s a similar type signal that I’ve always really liked, which is when customers expand with you. I think that’s another one, where you’re just like “Hey, did I just tell a good story, and sell you something that sounded compelling?” But then when they get to the point where not only do they wanna renew, continue using your service, but they actually want to do more business with you… So I think a raise is a little bit like that.

[04:01] I think the other more significant aspect of a raise is that every time you raise money, you’re kind of doubling down on going long… Because you get to a moment – at a high-level, you can claim that fundraising and exiting (selling the company) are kind of a similar transaction. They’re very different for the founder, but you’re selling shares, whether you’re selling a portion of them or the entirety. And so every time you raise money, you’re committing to doing all you can to return a multiple on that money to the investors. So you’re kind of going long, and every one of these journeys is exciting, but as you know, in startups every piece of the journey is its own adventure, and it’s oftentimes very unlike the piece of the journey that preceded it.

So to me, definitely the last two raises, which were kind of big - big in number of dollars raised, big in valuation - they were more about that. You sort of say from the get-go - or I did, and I believed it, but I had to commit to it again, concretely…

To own it, yeah. What’s that like?

…that this is not about a short-term [unintelligible 00:05:11.15], it’s about a real, long-term, sustainable company.

Did you have to do any sort of soul-searching during this commitment? Like, “Do I really believe in Snyk? Do I really believe in what we’re doing? Do I really believe –” Because it seems like everything you’ve done in your career has led you to do what you’re doing now, which is sort of the way it is for most careers, but more so for yours. You’ve been security-minded forever, basically…

Yeah, yeah.

So you’re in the perfect place.

I never really had any lack of conviction about Snyk and its journey being the right thing for long-term approaches. Snyk is about dev-first security, and it’s built on a core thesis. We can dig into that over the show… But it’s built on that core thesis that developers have to embrace security now more than ever, as kind of DevOps happens and teams need to be more autonomous… That’s kind of a core “Dev-first security has to happen”, and that the way to get developers to embrace security is to build a developer tooling company, not a security company, in terms of what it looks, what it talks, what it walks like… Because you have to build tools that developers would actually want to embrace. And I think those two promises have only – my conviction in them has only strengthened. So I don’t think I had any soul-searching on that.

I think what does always happen when you go from round to round is that you have to commit around the independence. So the journey I think I was committed to and I don’t think I’ve ever veered away from it. The commitment to doing that journey with you in the leader seats, versus under the umbrella of a larger company - I think that’s the true thing that you have to just kind of recommit to every time you do a fundraise… Because we were in a good place, where the company was growing very quickly. We’ve turned down multiple acquisition offers. And I think when that happens - again, it’s this commitment that not only do you think and continue to believe that this is the trajectory the market is going down, but also that on a personal level you’re still there; you have the energy, the drive, the desire to continue the very demanding – very fulfilling, but very demanding startup journey, and do the next stage of growth.

1:Yeah, because you don’t have to just be good at what you do, you have to be good at being the leader. I was gonna say “what you do” again, to double-enunciate that, but – you have to be good at leading, and sometimes you’re really good at a particular skillset. And maybe you’ve been a good leader, and you have good leadership qualities, but you may not be the best leader to lead it to the next – is that what you’re saying? …when each time you do that round change - are you the person that should be at the top still yet?

Well, I think there’s two things that I’m saying. One is it’s just the conviction on – like, regardless of your role or what your role you play, it’s just that it’s almost the next phase in risk management - do you want to bet, quite literally, financially, that these shares that you have here in the company will continue to grow? …versus take what you’ve got off the table… And also, alongside that, be willing to put in the sweat and tears that is involved in that. And it’s not to say that you don’t work hard post-acquisitions, but it’s different; it’s a little bit more existential when it’s your own. So that’s one aspect of it.

[08:25] And yeah, definitely there’s that other aspect, which is you don’t know what would be needed off you. I personally have brought on a new CEO onto the company, Peter, who - it’s probably a story in its own right that we can cover… But you know, it was my initiative, and it was an acknowledgment of both what I can do best, what the company needed, and what I want to do, that drove me to do this. So there’s that bit of specifically the role, in my case kind of replacing myself as CEO… But also just the company; we’re now a company of about 300 people, and we’ve grown very quickly, and you have to run the company differently when you’re 300 people, versus when you are 80 people, which we were just like a year and a half ago, or 20 people that we were a year prior to that. So you have to want it. And you know, some people totally legitimately don’t want that. They don’t want to lead a company that is more than 50 people, when they can’t name everybody… And I think that’s entirely legitimate, but that’s the decision that you have to decide - do I want to stop here? I got it very far; I’ll be an employee. I’ll see how long it takes me within the acquiring company, and then figure it out… Or do I wanna continue down this journey, and build something big?

I had the luxury of this not being my first rodeo. I spent about a decade in AppSec, and through three acquisitions of Sanctum - they got acquired by Watchfire and they got acquired by IBM. Then they founded a web performance company and got acquired by Akamai, and I was CTO there for a bunch of years… So I think that the first stretch kind of taught me a little bit about acquisitions and what does it mean to be acquired and being in those companies; that sort of second journey put me in a pretty good financial state and allowed me to also learn how to be an exec in a big – the chief technology officer of a 700-million-dollar-a-year business, C-scale… So by the time I arrived at Snyk, I was – you know, it’s never been about the money, but it was even more so about… Like, it wasn’t just about proving that I can once, it was around building something that matters, something that is big, that kind of makes a dent in the Universe. So I think my conviction was there all the time, and yet it still needed to be reaffirmed every time that there was a big financial transaction that takes place.

You definitely have to recheck yourself - retrospective, recheck yourself, whatever that might be; everybody’s version of that is different, because life changes… It’s not just about businesses, it’s about your family too, in a lot of cases. You’re not just leading a company, you’re leading an opportunity for your family, so you have to manage the risk level for yourself personally, how you feel about things, going day to day, to do what you do, and how does that impact your family, and then how does that impact your future in that business, and what it might do. It’s an interesting perspective.

Yeah.

You mentioned your acquisition processes over the years… I do wanna talk about Peter McKay at some point, so let’s earmark that, but I wanna go back to some of the learnings you had from Blaze to Akamai. You’d mentioned that was the one that put you in a better financial situation; I’m assuming that may have even helped you do Snyk originally… I can only assume, but it made it a little easier to do it that way, right?

Yeah…

But what did you learn from that process? It sounds like you’ve thwarted off a couple acquisition opportunities over the last couple of years, however long… But having gone through an acquisition process and being acquired, what did you learn that you didn’t like about that process? Or what did you like? What did you learn from that, that made you feel the way you feel today about Snyk and its potential acquisition, or lack thereof, if there’s none for you?

[11:59] I think Blaze was an amazing ride. If you don’t mind, I’ll actually go a little bit further back…

Please do, yeah.

It’s a learning exercise. So I was in this Israeli company called Sanctum. It lived over the bubble; it was one of the pioneers of the application security space, building the first web app firewall app shield, and the first web app security scan , AppScan. And Sanctum raised a lot of money shortly before the bubble burst, and that allowed it to get out the other side… And it had great technology, but it didn’t have the best go-to-market execution. Also, there was a need to rewrite… You know, as the technology of the web evolves and application security was growing, it was a constant chase to – you know, JavaScript wasn’t on pages when that started… So by the time Watchfire came along to acquire it - Watchfire was a company that audited websites for other types of problems, not security problems; it found spelling mistakes, it found broken links of websites, in big scale. And you know, some of you might disagree with me, but I think the tech was not as deep as Sanctum’s, but the go-to-market was excellent; and the tech was scalable. It was around breadth. So Watchfire acquired Sanctum a little bit before Sanctum ran out of money, in a slightly more elaborate private-to-private transaction… And I moved from Israel to Canada in the process.

And for me, the next 2-3 years were very seminal in my learnings. First, I moved, I relocated - a big life experience, seeing something that is different, which I loved, and I think I learned a lot from. Second is I got much closer – Israel is a great technology hub, but oftentimes when you’re there, you’re a little bit shielded from the go-to-market. But by moving there, I got much closer; I got on more sales calls, I got on more customer conversations.

I actually did a stint as a tech sales person, and then I took a product role; I went out of development, into product. So I learned a lot about the outside, and I learned to appreciate what a good go-to-market looks like. AppScan’s sales first quarter after the acquisition were the best ever for AppScan; this is the first quarter into Watchfire, after the acquisition of Sanctum… And it was just because the sales leader there just kind of figured out and immediately saw the way it should be sold over the phone, with a certain process, very quickly.

So to me, I think that’s my first takeaway, which is appreciate go-to-market, learn the interaction, appreciate sales, as I was a part of the org for about six months, and then kind of learned that product. And then when IBM acquired Watchfire, I guess I’m gonna say that there’s a bunch of things I learned what I don’t’ like about an acquisition. The acquisition itself was good, it was great; we moved into good surroundings, and IBM is very methodical with their blue-washing process on how do they gradually merge companies into it… But then it taught me a lot of things that I didn’t like to do post-acquisition.

I’d say my two primary learnings were - you know, one is we got acquired into Rational; this is a security company. We got acquired into Rational as a part; it’s the same journey that I’m on, this sort of developer journey to build security into development tools… And one of the key challenges, which we did some right and some wrong, were really around “How do we merge this security sale within the dev environment?” So I feel like I learned a lot there about the challenges in those scenarios, which I think helped me with Snyk later on.

Yeah.

The other thing I learned is the importance of some technical things, like banding. When you get acquired by a company that is a large company, it’s really important to negotiate the bands, the tiers that the different team members would be on… Because it’s really hard to change them inside; there’s a lot more fluidity to it in the moment of acquisition around where do people rank, and it’s hard to move up the ranks later on, in the ten bands, or whatever it is that IBM or large companies have.

And I guess kind of an appreciation - and again, some was done right and some was done wrong - of how important it is to shield an acquisition. To have that acquisition be protected from the beast, from the acquiring company at the beginning… But then also, similarly, it’s really important to not make the steps be too big. You have to gradually, but you have to merge it, and you can’t remain a sidelight.

[16:06] So I ramble a little bit, but that was a very educational exercise for me. I wasn’t a founder in that journey, but I had enough of a role in the diligence of both of those acquisitions, and even acquire a company inside of IBM.

Well, the key thing I hear there that you’re saying though is that despite not being a founder in that scenario, you were able to leverage that learning to when the day came for you to be, to have that skillset. I think that’s an interesting path, and something for those who are not quite there yet, listening to this, can keep in mind - what you’re learning today may not be… You may not be in a founder, CEO or a leadership role, but that doesn’t mean you’re not learning leadership qualities… And to not discount what you’re doing today.

Yeah, absolutely. And I think to an extent it’s like – you know, you get what you put into it.

Yeah.

I kind of joke that I don’t have a first gear and a fifth gear. I don’t really know how to go at speed, so I dive deep in… But I definitely use those opportunities, with the relocations/acquisitions to learn, to try new things. I like – I think it’s a Marc Andreessen statement that says “Replace career planning with strategic opportunity taking”, which I feel is a good guidance. Just find those opportunities, learn from them… And it means that post-acquisition you don’t need to find your corner and get comfortable, but rather look at the opportunities that we now have for growth and for learning, and see what you can make out of them.

You’d mentioned the banding - I’m not sure how deep you wanna go on that point, but I’m interested in the negotiation process, because the best time to negotiate or set terms is during the deal-making; that would make sense. When you talk about banding, can you go into that a bit more, in terms of how that set the teams up for success?

I’m even gonna talk about this a little bit in the context of the Akamai acquisition of Blaze. At a high level, what happens is big companies - every company; we do this now at Snyk as well - increasing (once again) to a certain size, you start tiering the employees in terms of seniority. You want to do this because the market operates this way, and that allows you to get salary benchmarks across different companies of a certain size…

So if you’re a smaller company, you might have five tiers; you might have a junior person, and you kind of progress up to your top-tier individual contributor, you might have individual contributor and manager tiers, and they would somewhat overlap… But you tier somehow. Now, because it’s different people, different roles, different salaries, very different, each of these tiers does have typically a fairly broad salary range, and other sort of compensation bits… But there are other pieces that are attached to it. And moving from tier to tier is a bigger deal than getting your salary adjusted within the tier.

Larger companies - there’s a magic number of ten, if you look at IBM, and I think Google is like that… Generally, there’s these ten tiers. Tech roles are oftentimes – the minimum is like a four, and maybe one and two are the temp receptionist or janitorial roles, things that are a little bit outside the technology operation of the company… But then within those ten tiers – and then you have executives, and executives is a little bit of a different tier.

So when a big company buys a small company, you have these things - you have VPs, you have directors… A VP in a company of 20 is very different than a VP in a company of 20,000. It’s not the same type seniority that you expect in the scope of responsibility. So there’s a matching exercise that happens during the acquisition, of deciding “Okay, this person who’s a VP here, or is a director here - what are they? What is their real seniority?” And there’s a paycheck element to it, and I think that got a lot of focus in early conversations… But there’s also an importance around your career trajectory, in terms of like that banding is very important.

[19:59] So if I was to try to condense this, so the guidance is, in the moment of acquisition, that’s not the most important thing. You’re trying to figure out “Would your team have a good home? What’s the responsibility of the team over time in the acquiring company? Would you be successful, would people be happy?” And of course, there’s the financial terms of the deal itself… So this bit, of like when you look at the team, what tier they’re in, like your comp - you think about the different people’s comp… But the tiers are generally not as discussed. But it’s just to say that the individuals, if you put them in a band, when they’re kind of at the top end of that salary range, and they round it down, then it’s harder for them – once they’re inside the company, it’s harder for them to get bumped up to that next tier, that maybe it might have been earlier on.

Gotcha.

So it sounds small, but it’s just like a bit that was actually a topic of conversation in that IBM acquisition after… Because a lot of things were done right. Again, I don’t wanna nitpick, I’m just sort of talking about this as an area of learning. When I went on to found – I left IBM and I co-founded Blaze with Mike Weider, who was the founder of Watchfire and my boss in IBM… He joined it a little bit as a late co-founder; I started before… So the two of us sort of started Blaze.

First of all, on a personal note, which might be interesting to people - my son was born in October. I took parental leave – I was living in Canada at the time so you can take up to almost a year as a father, parental leave; you didn’t get paid much, but you could kind of fall back to your job after. So instead of resigning, I took parental leave in January, and I was kind of feeling out what is it that I wanna do, with kind of the assumption that I would found a startup. But I had a three-month-old at home, I was kind of closing off in my bedroom, kind of geeking out, trying to build all sorts of pieces of software, just trying to learn spaces… And then I eventually landed on “Okay, I want to do this performance optimization piece”, and I think by May or June I resigned. I left IBM and I kind of properly started Blaze. Blaze was a shorter journey. It was like 20 months from a corporation to – yeah, even less than 20 months from incorporation to acquisition, it was a team and technology acquistion.

It was pretty fast.

We had some initial market traction, but not really; no revenue to speak of. And then we got acquired by Akamai. And if I was to distill a little bit of learnings here… There’s a whole bunch; a lot of things I would have done the same, or differently, and I guess I got the chance to do some of them the same or differently with Snyk… But I think there were a few – I’m not sure where to start on these. There were a few key learnings from motion we did to get started.

We started marketing before we had the product. So we had the product that made the websites faster, and we had a video on the page explaining that we make websites faster, and how we move things around inside the app, frontend optimization; we coined the term frontend optimization. And what we did is we did a video that explains it, and we said if you wanna see your website being fast or not, plug your URL here, and your email, and we’ll show your before and after video.

Wow.

We had an automated system that would run it through our – very kind of duct-taped together, but… The core tech was good, but the surrounding was kind of still duct-taped together. It came out with a video that showed a before and after, which was very emotive, a very emotional response, to say “Yeah, I want that fast website, not my slow website.”

Right… [laughs] Who picks slower, right?

And sent it to people. And that was probably 3-4 months before they could actually start implementing these things on their own sites…

Wow…

And it got us some leadgen. That was good, it got good traction… The other thing we did is we did – mobile performance was hot at the time; it still is, but at the time you couldn’t really measure your mobile performance site, so we outsourced a little agent that would run on mobile apps… I actually bought an IKEA cabinet and some photo frames, and I bought a bunch of mobile devices, and they would sit in that sort of IKEA cabinet, connected to a server that we wrote, based on WebPageTest which is an open source software…

[24:07] Anyways, we measured – we opened a service called MobiTest that would measure your website and give you a bunch of visuals and data on a real mobile device. And we did an Android versus iPhone bake-off, and Android came out ahead. The thing made top tech news for like three days. It was a whole experience around it. I think Wired titles were like “Sorry, Steve.” Steve Jobs was still alive at the time. “Android smokes iPhone”, on these tests… It was a lot of iPhone fan boys coming along and pushing against the study…

Getting upset… [laughs]

Yeah, we had like three days of – somewhere between shame and glory, depending on your perspective… But it definitely kind of helped get us on the map. So I think that understanding your market presence early was definitely something we took into Snyk, even if we did things that are very different.

And then subsequently is an understanding of the importance of biz dev and partnerships. So we built Blaze to accelerate websites, but we weren’t delivering the websites. We partnered with the CDNs and the ADCs (application delivery controllers, so load balancers and the like), and we really designed the system to be integration-friendly, and integrated with a whole pile of them, given how early we were in the market… And I guess over there, and that to me is like maybe the tip - we talked before about going long versus going short, and I think it’s a decision that’s important. I think with Blaze we saw an important technology evolution, and we didn’t really see a big company.

Right, yeah.

So we partnered, we worked well with them, it helped locally to get better integrations and get some customers, but it really helped when it came time to the acquisition, because we had a lot of interested parties, because we filled a good hole at the time in the somewhat commoditizing world of performance optimization.

Did you ever hear the term “This is a product, not a company”? Is that kind of how you felt about Blaze, like it’s a product, not a company? Is that what you mean by that?

I don’t know if that’s the right term… Maybe. Maybe it’s a product, not a company. It was just limited in scope. We had thoughts about how can we transform websites for a variety of other reasons, like accessibility, maybe even visually and such, but we didn’t have true conviction. We could have gone longer, but really, we felt – and this was at the very beginning. It was probably a realization about a year in, that if you’re honest and that technology really should sit alongside the entities that provide network-level acceleration and delivery of the website.

Which means you would have to build that kind of company…

So either we could compete – precisely. And there are examples - there were CDNs… There was a CDN called Instart Logic, which to my perception - and again, they might portray it differently - they basically were founded around the same time as Blaze. They built a CDN that had frontend optimization built into it. By the time they came out of stealth, because it takes a long time to build a CDN, all the big CDNs have already built or acquired some frontend optimization capabilities, and that differentiation was no longer a differentiation that held… So we chose the core feature, the capability of the product, but it wasn’t so much a company.

I ramble a bit, but I think that’s my history. The acquisition itself - I think there was a lot to love there, we really picked. We had the advantage of being able to pick the right home for the team, where we thought both the team and the product should live… And the team is thriving; the vast majority of the team is still at Akamai. The branch in Ottawa, Canada has grown to own a lot more. They’re executing really well, so they’ve grown in the responsibilities they’ve taken out in terms of products in Akamai. They’ve built other new products… And I think based on the learnings from before, we’ve built the right level of integration and isolation. The location helped; it was a separate location, so it was a little bit at arm’s length from the rest of Akamai, which allowed more independence and to preserve some startup methodology and agility and spunk… But then we also made sure that we’re integrated well and connected people.

[28:18] I took the CTO role, so my role very quickly was broader than just the acquisition that we’ve made… And I think we – you know, not all by intent; sometimes we got lucky, but I think that we struck the right balance of that integration versus independence in that acquisition.

You mentioned you moved into the CTO role, which gives you a chance to sort of look wider at Akamai, and potentially even be a good lookout for the team that you’re sort of launching within, I suppose… It seems like a proper term there. What was your stint after that? Were you happily at Akamai for a while? How long did you stay there before Snyk came to be?

Yeah, so I stayed at Akamai for 3,5 years. It was a great journey. I really learned a ton, whether it’s building business cases inside the company… There are amazing people at Akamai, so I definitely learned a lot from people and built a network. I think it’s important when you get acquired to invest the time in helping others. As CTO at Akamai, I could help more, to founders and entrepreneurs in other companies around to connect them with relevant customers, in a mutually beneficial – a customer of Akamai oftentimes wants to hear about a cool, performant startup that’s around… And you have to stay clean, in terms of like I had no financial interest in any of these things… But just being helpful and connecting. And I think that type of networking and reach really helped me later… And it also taught me, once again; I learned a lot.

To me, at this point, and some time after the Akamai acquisition, I started doing angel investing… And again, I have kind of a good phrasing from a friend, which is that when you’re a founder, you learn in serial, and when you’re an investor, you learn in parallel. You see different companies, you see how they work, whether you’re helping those just ad-hoc, helping those companies, or whether you’re an angel investor… And so I learned a lot from all those companies, and that helped me understand what I want to do better… And eventually, I moved with Akamai to London, UK after about a year and a half – no, more like two and a half years, I moved to London. Then I kind of got the itch, and at some point I felt like – I went to do it. I was gonna take a year off in between, and…

And that didn’t happen?

…that didn’t happen. When I decided to – it was probably about a six-month process from the point in time I decided to resign and when I was fully out, because I also had a long notice period… And when I decided to resign, I said I’m gonna take a year off, somewhere sort of mid-way I sort of said “Well, maybe six months would be enough”, and then I eventually left Akamai on July 1st and incorporated on July 7th.

Okay, so a week… If. Maybe six days.

[laughs] And I was mostly off that summer. I got the itch, and I got stuck on the idea.

Let’s pause there… What’s the point of taking off then? How do you – when you take off… Like, you did it before Blaze, right? You were on paternity leave, which is similar to taking off, but you were using that as a position of figuring out your next direction. When you do these kinds of exercises - or lack thereof, in this case - what is your intention with the time? Is it to recharge with family, is it to chip off at your bucket list? Not so much to ge morbid like that, but maybe things you wanna do in your life; what’s the point of the time to take off?

It’s a really good question. I think my primary goal was not to jump into the first thing that you see. There are a lot of great ideas, and there are a lot of great people that you can partner with, and when you’re in one mindset - for instance, you’re an executive in a large company - then it’s very refreshing and nice to see an exciting new company, to start opening that thought of saying “Hey, can I join that, or can I found that? Get enamored with an idea and found it.” And I think what you want to force yourself is not to jump on the first idea that you see, or the team that you get excited by…

[32:08] So to me, when I thought about the break, part of it was “Yeah, can I rest on my laurels a bit? Can I recharge?” But in practice, I think for me that six-month period – I had about a four-month notice period. So from the time it was announced to the team, to the time I was out, I probably had about 3-4 months… From the time I decided to leave, I was already thinking about things. I have already been engaged with a whole bunch of startups, to be fresh in that space… And so for me, I think that period of time already kind of happened in parallel to that departure from Akamai, even without the intent. I’ve seen enough and I’ve learned enough.

I don’t believe so much in regretting the time that you’ve invested. Both in the company and in my personal life I believe in big vision, small steps. You want to aim somewhere, and that somewhere needs to be worthy of accomplishing; it doesn’t have to be a life ambition, it can be temporary, but you want to have some goals that you’re working towards… But then again, you need to have the strategic opportunity-taking.

And what you don’t want to do is to do steps that you really regret. So you either win or you learn. You make a step, and if it’s learning something that you didn’t care to learn, then could you have avoided doing that in the first place? So I take that stance with family life as well; while I work hard, I don’t sacrifice my family life in favor of the startup.

For instance, now it’s Snyk, and since the beginning of Snyk, with all the massive intensity that Snyk has, I have a block in my calendar from 6:30 to 9 PM, and I make sure that I’m home to have dinner with my kids. So I have breakfast and dinner with my kids.

I do have some travel which I can’t avoid, and that sometimes gets a bit heavy, but I try to do it. And look, oftentimes at 9 PM I’m back at the computer and I’m having calls with the West Coast from London… But that’s okay for me. That’s a balance that I strike. I’ve always been good at taking time off; even when I’m at the midst of it, I would take time off. I try to truly disconnect on the weekends…

So I work really hard, but I have lines that I try to be very diligent about, to not cross. I don’t want to be in a place in which I’ve, just for a few years, sacrificed family for – now, there are balances; these things are ranges, they’re not black and white… But anyways, all that said, I don’t think I needed a lot more. If I could just take my foot off the gas a little bit in Akamai in the last few months, that was really all I needed for recharging. And then not press it all the way on the gas when I started Snyk. That was kind of all I needed for recharging.

When it comes to family, as you mentioned there, the way I’d see what you’re describing for me is I can make a choice for a season. So if I’m gonna – not so much sacrifice my family, to be so brash like that, but if I’m gonna trade off some of the time, I have to give myself a time period. I could do it for three months, or through this push in particular; once we get through this, I’ve gotta give that time back to my family. And I might even have that conversation with my wife prior to it and say “Listen, for the next three months things are gonna be a little bit different.”

The point is just I do it as a season, knowing the beginning and the end. And if I’m gonna do it, it’s gonna be for a very purposeful reason, and not just for the sake of sacrificing my life, my wife, my family for something that in the end, for your life – later on your life, once Snyk is done, or this is all through, the thing that really matters is… What? Your family, right?

[35:50] Yup. I think that’s a great way to put it, to talk about a season. And I also think you have to think about the aspects that are in your control. When you’re in a downturn - you know, like where we are right now, there’s a certain amount of investment I need to do when you look at the Coronavirus crisis, that I have to invest in the company. We’re in a good place and we’re in good shape, as compared to many other companies… But if you get drawn and you need to invest there, that’s a part of the responsibility. Similarly, if unfortunately there’s some sort of medical case or some other sort of crisis at home that you have to deal with, then the company has to do it.

So there’s definitely elements that are outside of your reach, and you have to make sure that you jump off and do what you need to. And I think when you do these presses, then yeah, they have to be time-bound. I guess that’s the thing about the startup. A startup is not a short journey; it’s not a season. A conference season is a season; you’re gonna fly around a lot in September and October, and a little bit of November, and hopefully in December and January/February you get to be home more, because there’s less conferences around… That’s okay, that’s a seasonal decision. But I think a startup is – you should anticipate a multi-year journey, and that’s too long to say “Hey, I’ll put personal life aside for that period of time.” I think I rambled a bit… All of this is pre-Snyk, so I do think that you learned a lot in all of these different stages. There’s always something bigger to do, which in my case was Snyk.

Well, the opposite of a sales acronym, ABC, I like to do ABL - Always Be Learning. Always Be Learning is my key. I can see personally for me, and similarly I can see it for you - my entire journey, everything I’ve learned… This isn’t about my story, but I’ll give you a short snippet… I had been in some sort of sales role early in my career; when I was 18 I worked at a call center. This was back when making those things – I’m 41, so making those calls at a call center as a telemarketer was a thing you did way back when… And then I went into a sales role.

But there’s so many things I’ve done over my career that I can see that have layered on Always Be Learning, to get me to where I’m at today… And then not only get me here, but enable me to be the best me in the position I am to do what I’m doing. And it’s just interesting that people don’t always see today as their learning day to do tomorrow better, or to do tomorrow the way they want… To sort of take stock of the fact that where you’re at today is for a reason, and what you’re learning today is for a reason… Whether it’s an acquisition that went wrong, or an acquisition that went good, or whatever the case might be, to take that knowledge in and to just use it for the future forward.

Sometimes people get caught up in the what-if and the future and they kind of forget to take stock of today and what they’ve done. It seems like you’ve done a very wise maneuver through your career to sort of understand your position today, where you’re trying to eventually go… I’m sure way back when you didn’t maybe see yourself as a founder, or maybe you did, but the point was that you were the whole time leveraging these opportunities and these scenarios to learn, so that today as a founder at Snyk you can do what you’re doing.

Yeah, absolutely. You have to use the opportunity you have right now. If you’re not growing, you’re falling back. Also, it’s just about – you only have so much time on this planet, so you want to take advantage of it.

Well, let’s talk about sales. When organizations (I guess) decide to become adopted by a large user base, or provide an on-ramp, so to speak, for new users, there’s often “Let’s give it away for free. We get mass adoption. Everyone will use it because there’s no barrier”, and you’ve got two different models that sort of fit in there, which is freemium, which we could talk about, and there’s the free trial model, which sort of enables both of those things, but there’s just different ways you could slice it. What’s your experience on this front?

I’m actually quite passionate about the freemium vs. free trial type model… So what I feel is that people conflate them. Snyk is a freemium model. And what does that mean? I’ll extrapolate beyond Snyk for us… Which is we actually serve a use case for users that would never pay us. And we serve that use case really well for a long period of time… Again, until they basically don’t qualify for that use case.

For us, for instance, we support individual developers who want to secure their applications, as well as small teams, within our freemium tier. And there’s no buts, there’s no exceptions. We also support open source users. That’s maybe even the first profile, or people protecting open source platforms… And those users should be - we do all we can - to make them really happy with the product, independent of whatever purchasing ability. There’s a use case there about an individual developer, about an open source developer, about a small team, where the product should within the free tier truly deliver success. And in general, I think in freemium that’s what you need. You need to define a use case that you will support for an extended period of time, or forever, presumably, that people would run.

[44:00] Free trial is really about a chance to explore the capabilities of your product. And what people do is they call it freemium because they think of free trial as something that is only limited by time. So they say “Well, no, if it’s not a time-limited thing, it’s not a trial.” But in practice, they don’t solve any use case… So they for instance – say you have a collaboration tool, and you allow collaboration for up to five users as something that’s within your free tier. But your product really only brings true value - you know, the product that you’ve designed is really around large group collaboration. And collaboration amidst five people – let’s assume for a second it was like a Slack style system… Well, the value is fairly dubious. It’s not really that significant. When you’re five people, you don’t really care about that much assisted collaboration between the five of you. I mean, you can communicate pretty well.

So you find yourself not really solving a problem, and in earnest, you don’t actually want people that are five-person teams to use it. What you want is you want the 100-person team or the 1,000-person team to start with five people. But for those people, you never started, you never solved an actual use case, an actual problem that they’ve had. And so this type of mistake typically happens when people think about freemium last. What they basically do is they say “Well, I’ll build a –” let’s say in our case I will build a security solution, I will price it by the number of developers building the application, and therefore now how do I keep people? I’ll give people something for free, but I will keep it from encroaching on my commercial; I want to keep enough value in my premium tier, so that there’s enough people that would move over to upgrade.

And so they start from that, and they reduce it back down. Or they now say “Okay, I will only allow up to five developers.” If I was to do that, and I would say “Well, it’s only teams of up to five developers”, then basically none of those is probably going to be that significant kind of a customer. If it’s organizations with no more than five developers, that’s not really the profile that I’m trying to reach.

So what you really want to do is you want to understand for a given user what is the use case that you are solving for them. You start with the users you want to reach, the people that you want to reach in the first place. Developers as a whole, and then developers within enterprises. Then you wanna say “Well, what’s the problem that you want to solve for them?” Let’s say you have a team over there, or you have an individual developer there - what is the problem that they want to solve? Well, they want to find out if there are vulnerabilities in their code. And now you build a solution that helps them address that, helps them find those problems and be very comfortable with the fact that they will never pay you.

And then as you expand it, when you think about like “Okay, another use case for us is developers in open source”, like an open source project developer. Well, what is the use case that I solve for that user? I help them integrate into their open source project an ability to identify and fix known vulnerabilities… And I want to do that indefinitely. What I want those two developers to do is very different. The developer in the enterprise - what I want to do is I want to make them successful, but then I want them to help introduce to other team members, I want to inform them about my commercial capabilities, I want them to engage sales when appropriate, so that they would go off to the purchase.

The open source developers - what do I want them to do? Well, above and beyond, again, like the first case, being successful and loving the solution, what I want them to do is tell the world. I want them to help the world know that open source security matters, and that Snyk is a good way to address this… So if they publicly talk about me or about Snyk, and if they help educate their peers, then that provides that value… And I shouldn’t bother them around purchasing. I can also consider saying “Well, if I think that this person might work at a job, work on also non-open source projects, maybe I want to have them consider using Snyk in that surrounding.”

[48:34] So these are all very Snyk-specific examples, but I think that the key distinction here is when you have a solution and you think about how do you bring it to market, there’s this aspiration that it’ll be a freemium-led go-to-market; so you want to get these masses of people using your product, and you want some portion of them naturally growing to buy your product. And what often happens is you will unleash a freemium product and then nobody would use it, or the products would not really get adopted. To avoid that problem, or if you see that that’s happening, you have to stop and think “Who are the people that this freemium product works for? What are the use cases that I’m truly solving for them, and what is it that I want them – that I as a business (a little bit more cynically) want to get out of them?”

And you know what - if you can’t figure those out, that’s entirely legit. You don’t have to have a freemium model. If you don’t have those solutions, if the minimum use of your product is one that really should be commercial, then it should be a free trial. But then you should adjust your methodologies, adjust your expectations that what you’re really doing is you’re offering them a free trial, and you should convey it accordingly to them, to say “This is a trial of our capabilities”, so they don’t have the misconception that your product is limited in the way that you’ve provided it.

I like the distinction between freemium and then having a paid tier with a free trial… Because in most cases, in any sales opportunity, period, you have “Okay, we’re done doing whatever we deliver. What is success?” And that’s use case. “What is successful use of software? What is successful use of this service? What is successful execution of whatever we plan to do?” If you give them a free trial, if they require that, then that gives you something to optimize towards, which is “Hey, here’s a sliver of success in a free trial.” This makes you feel comfortable, gives you trust, gives you feedback to sell others on, so that you can move into this premium tier that’s paid. However, if you’ve got a freemium model, I like the idea that you sort of maybe even have to some degree both, as necessary. For sure, freemium, if that makes sense for your business, especially as your organization has been able to align that around a use case that sort of helps the world.

There’s a lot of developers out there who need to focus on security around open source, their software etc. and so this freemium model allows you to do that, and the benefit you get as Snyk is to enable them to tell the world, because they’ve had success with it. And it’s a band of people that will generally, as you said before, never pay; or not be in a payment scenario. Can you extrapolate on that side of things, how you know that they’re a worthwhile user and you can solve problems for them, however they’re never gonna really be a position to pay you?

[51:45] Yeah, for sure. I think a freemium user is a legitimate entity in the funnel. It’s okay that they also advance to pay. The key distinction is basically, if we were to standardize the definition of what success is - a free trial’s success is understanding your product’s capability and their applicability to the organization. So that’s really what a trial tries to do. While a freemium model - that person might indeed purchase, but in a freemium model… Like for me at Snyk, for instance, we have countless of examples of either…

You know, for instance in one of the biggest media companies we had an open source user; an avid open source user loved the product, used the product, heard that their organization is reconsidering their open source security tooling or open source governance tooling, and introduced us into the company with a very warm recommendation, which eventually helped us go on and win the deal and then grow with that customer substantially.

Another example actually within a financial organization is that we had a team that was more frontend-minded, that really liked our technology, and used the free tier. It was a small team, and the volume that we provided with our command line interface in the free tier that we had was sufficient for them to actually centrally find vulnerabilities and components that were submitted to them. And then they said “Okay, we want to standardize this and we want to build this up inside the organization. We want to build it into the pipelines, we want to grow it to many more developers.” Both of those cases were freemium users. Both could have continued. In fact, the open source user has continued using it in a way that doesn’t pay. But over a long period of time we made them successful. We didn’t just try to push them down the funnel, because their use case didn’t fit the funnel, but they were the right individuals to go towards the organization. But we had to understand the use cases that we are trying to solve for, for us to be able to help them be successful. So I think it’s really about that definition of success, and its time horizon.

Fundamentally, I think the easy question is “Who do you expect to use your free tier of your product, and what for, and for how long?” And if the answer to the “How long?” is “Very briefly”, or just as they evaluate, or if the “Who do you expect to use it?” is just not someone you care about in your funnel, like it’s just not realistic for you to do it, then that’s an indicator of a problem. Then you have to think about “Okay, so what is the tie between the freemium element–” And sometimes you don’t need to give as much.

And by the way, an extreme version of this is open source-based software. People should ask the same question when they say “Should I open source my software?” Because open source to an extent is an extreme version of freemium. It’s a freemium that you cannot back out of. So we have to think “Who is it that would actually use my open source software, and for what use case, and then for what use case would they use the premium?” You have to ask the same questions, of walking them down that funnel.

Where do you begin then? How do you extrapolate that against, say, tiering your product? Do you begin with identifying what might fit into freemium, and then everything else is divvied up into tiers? I guess maybe specific to you, how did you define your tiers with Snyk?

I think the distinction of freemium – so it depends on where you are. If you are an open source-based solution, then that’s a very big decision. It’s a one-way door to sort of go open source… Pretty much. So you have to really think long and hard to do it. And it’s not that flexible. If you’re a service, it’s a little bit more flexible. You can make something and then not make it free, or change what you get for free. It is more significant than changing your premium tiers. Generally, changing your premium tiers is something that is really not a big deal, as long as you don’t go back and try to milk old customers for more money; or if you do that reasonably, then generally you can change your pricing, and you probably will change your pricing many times.

[56:24] But for free tier, if you manage to build any sort of community around it, you have to be much more careful about changing what’s included. It’s always easy to add, but it’s hard to reduce.

So I would say you actually probably should spend more time thinking about your free versus commercial, than the way you split up your commercial… And this at the very beginning, when you introduce the free.

And then within the free, it boils down to the questions that I talked about. I don’t have as crisp a framework for this, but it’s to say “Who is going to use your free tier? For what use cases? For how long?” and then “What do I want this user to do? What do I want this user to do to sort of help my business?” If you just define – if you sit down and you write that down, then I think it would make things fairly clear, pretty quickly.

From here, you either got the right answers, like either you’ve got a very clear answer - you know, for Snyk, we started and the focus was developers. Developers get to use the product for success; it’s really when it gets to large teams and when it gets to engaging with a security audience that you go to commercial. Then you just run with it.

If you don’t have the right answer, you have to either continue experimenting on what your free tier should include, so that you can find the right use case that you can support amidst this relevant user base… Or if the user base was the problem, you need to go off and say “Okay, so this is the relevant user base here. Maybe I want security people to start this right away… What is the use case that I can offer them?” And if you can’t answer those questions, maybe freemium isn’t for you. Maybe it is about free trial, and you can still have a great inbound, bottom-up, content-oriented – you can still have a great community-fueled product without it being freemium. It doesn’t have to be the same. But don’t fool yourself, I guess, on those fronts.

There’s a couple key points I wanna touch on, but I do wanna move into your story of Snyk and what’s going on there… Dev tooling, security-first, developer-first security - all these things that are really important in today’s world… But kind of layer in for me - you mentioned helping earlier; how important helping helped you later on… Maybe dovetail that into Snyk, what you’ve done there. Because you’d mentioned when you were at Akamai you were helping others… That’s a very – you often hear “If you wanna get ahead, help somebody.” How has that worked for you?

Yes, for sure. To me, a lot of it came back to the community. Some of the help with Akamai was to help the odd founder and connect them with relevant customers… But a lot of my investment at the time was helping the performance and ops communities. I was very much a part of the Velocity Conference, the DevOps movement in the early days, and helping from an Akamai perspective bring Akamai into that mix, but then also help that community thrive… And when it comes to Snyk, that’s really probably one of the key tailwinds that we had, the key pushed that we got that really helped us take off in the first place.

[59:56] So Snyk was founded in this combination - for me, a combination of my two journeys. So it was on one hand the application security background, the constant desire to get developers to embrace security, and on the other side this first-row view, if not actual on-stage participation in the change of DevOps, and the performance and ops industries were the first ones to be disrupted… Sort of seeing what it means to build solutions that are really dev-oriented, what’s important to this community and how to work with it.

So I built a company from the get-go with not just a technology perspective, but a community perspective. It was the idea that if you want to build a solution that really is compelling for developers, that the developers actually want to embrace, it’s not just about building a developer tool, it’s about building a developer tool in a company. And as that company, it implies first of all the culture of the company is one that is open, that is transparent, that the way we communicate outside is it does what it says on the tin.

We talked about builder and breaker, and we had these long conversations about “How can we be a builder, not a breaker?” For instance, to give a very specific example just to show how deep it went - the color scheme of the website. We talked about how I tell you about vulnerabilities in your application, and some of them are very severe… So overall, our color scheme and our thesis was very much like “It needs to be warm, not a fear-mongerer.” We help you build quality software, that includes being secure, and we’re sort of a part of that builder community… But when I tell you that you have high-severity vulnerability, I kind of want you to appreciate the urgency and doing something about it. So we talked about the color scheme, and we got to this Magenta, sort of mid-way understanding of what the right color scheme is.

So every tidbit about how do we work - we’re free for open source, we give a lot to the community, we participate in these open source foundations… So a lot of it actually got embedded into the company of being one that works hand-in-hand with the outside world, with the developer community. We shipped a really minimalist product. I would say a pretty crappy initial product about a month in - really, it was about a month or two old - as beta, nobody was paying for it. We launched it at Velocity Amsterdam, and we iterated with the community, and that’s still how we work - we ship things; we don’t think we know better. We ship it out and we work with the customers, and we do it all the way from large, seven-figure, big financial or technology institutions, we work with them, we learn from them, our engineers talk to them directly and interact with them… And we do it as part of that community, our freemium users; we haven’t tiered support, or anything like that. We still answer all the support calls very rapidly. We’re trying to be very transparent with what we’re building.

So if I go back a little bit to the founding of it, I think that notion of brand – not brand, but rather almost the karma of people helping out, it really helped get the DevOps community to take that leap of faith, to say “Yeah, we know we haven’t liked security tools before, but we kind of trust Guy…” I also brought some great people to join me also from that community, that had some brand and some notoriety and some reach within the developer world. I added great people - two co-founders from Israel, Danny and Asaf, who were both great people, that helped embed the culture, but also brought in even deeper security expertise than what I had, and helped build the branch in Israel, because we had in Tel Aviv and London a kind of shared, two-headed monster approach from the beginning; we sort of split it into two. And that really helped get us off the ground, to build out the product and crack the code on “How do we build a security tool developers will embrace?” Revenue took a couple years more, but we managed to really break through to developers, which was the most important challenge.

[01:04:05.19] Especially as you lead with this developer-first security dev sec ops - you often hear just DevOps, and you’ve gotta put security in the middle there… And what we often find is developers – security is, to some degree, an afterthought; it’s like performance, making it work etc, and the security of it to some degree comes after it’s build, and an afterthought, in a lot of cases. And what you’ve been doing in these last several years has really been around bringing security into the mix… And you mentioned tooling in not a security company being sort of the position you took as – I’m not really sure how to frame it, but just the fact that you were focused on the tooling part of it and developers, rather than just simply being a security company. You don’t fix the fixes, you find them, and enable others to fix them, and help that kind of thing. So talk about that position, like why tooling was the way in… I guess why developers needed to have security baked into their processes, and how you do that with tooling.

Yeah, and I think it’s more about the developer – it’s maybe more the word “developer” in the developer tooling, than just the tooling. So the key difference is practically all security solutions out there are built for auditors; they’re built for security people, which makes sense, because they’re also the ones buying them. And then we want the developers to use them as well.

Then what happened was that as an industry we built auditor tools and we integrated them into a developer environment. And lo and behold, they didn’t work well for developers, because developers are not auditors. They don’t have the same needs, the same surrounding responsibilities, the same pre-existing expertise… So the primary change that we did was that we said “Okay, developer-first. If I’m a developer, what do I need?” And it led us to all sorts of substantial changes in how we devised the solution. And the tools were the ways to make it accessible.

For example, in the world of known vulnerabilities, the norm is to tell you “Hey, this application uses 500 libraries. These 5 are vulnerable. Go fish. Go figure out how these five came in.” Well, in practice as a developer you don’t use 500 libraries, you use 15. And those 15 brought in these hundred, and those hundred brought in those 500. So as a developer, what I really wanna know is which of my 15 brought in a vulnerability, and how does it come along? I want an application context. So that was something that we learned, and we built, and we built what is fairly unique; now, it’s becoming a little bit more standard, which is present the vulnerabilities in an application tree/dependency tree context. Or like our Git integration - where do developers discover tools? Well, developers want to try it out, and generally, the place where a code review happens is on Git, is in these pull requests that get opened up; you want to review it. So that’s where we want to interject, that’s where we want to introduce a problem.

Where they’re hanging out at.

Exactly. So we built an integration into GitHub, and that was really hard. We had to build the technology to take source code that wasn’t built, and the dependency system hasn’t kicked in yet, and approximate - build out the dependency graph without building the app, which every dependency ecosystem is its own unique snowflake, and it’s really hard… And you can sort of argue – like, it was very compelling to say “No, just run it in the command line interface, as we had before, and you ask the dependency system which libraries are here”, but that didn’t provide the developer user experience. The developer user experience was “I want to integrate all my source code when I do code review. I also want you to only tell me about problems that I introduced with these code changes. I don’t really care at the moment about other problems that might already exist in my system. I want to know if my code changes introduced the new problem”, which amazingly is not something solutions do, because an auditor doesn’t care. An auditor cares about the overall state of the application. And of course, I’m generalizing here.

[01:07:54.16] So all of these are just a few of many, many examples of “Think about it through the developer’s eyes.” And I think all of those approaches, whether it’s discovery, or where do we integrate, and the core technologies, how do we present results - those were very different. And the tools is what makes it easy. Every single developer in the world, if it was the same effort to build something that is insecure and something that is secure, they would choose to build something that is secure. The problem is it’s not the same effort. It’s really hard.

So what we need to do is we need to make it easier – like, if there’s a line of how much you care and a line of how hard it is, the line of how hard it is to be lower than the line of how much you care. So we’re gonna inch along how much you care. We’re gonna educate, we can learn security breaches, and all that; we all care about security more and more every day… But we really dropped the line of how hard it is, and I think that was the key to getting this to users, and that’s where tools kick in. We had to embed the simplification, we had to embed the grunt work, embed the security expertise into the tool to make something that used to be hard, easy and compelling for dev.

Yeah.

Everything we do… Like, we went into container security - same approach; what is different as a developer? What do I need from a container security solution? And if I just throw one example, it’s like it’s a separation from the base image to the Docker file. From a security perspective, if there’s an image, there are vulnerabilities there. But as a developer, night and day, if the vulnerability was introduced with my code, if you will, in my Docker file, when I installed a bunch of things on it, versus it’s the base image that I pulled down.

So a lot of these things – and then the last example I just can’t not mention, it is the automated fixing. Maybe the biggest difference between a developer and an auditor is that an auditor’s job is to find problems, and a developer’s job is to fix them.

So if I build a developer tool that just finds problems, developers are not gonna like me too much. So what we’ve built is we’ve built a tool that actually finds those problems, figures out how to fix them and package that up as a pull request and opens that up to your repository.

Well, thank you.

Then you want that. Then you get that reaction, of saying “Why would I do that, if the tool can do it for me?”

That’s right.

Anyways, I get excited a little bit when I talk about it, but I think there’s a lot of passion because this needs to happen, and it needs to happen across the industry, to really think about developers’ needs versus the security mandate and expect developers to fall in line.

Right. I think a lot that comes with a mind change to developers, right? For a while it had just been just DevOps, and as of recently, and part of a lot of the movement you’ve done and the work you’ve been doing in community, as you mentioned of your journey, has been around changing minds. I heard you mention on a podcast recently, you said this term “shift left”, and I think about changing the minds. How do you get developers to embrace security? That’s the thing.

So you can built a great tool, and it can do all these amazing things, but if developers don’t consider it - well, then how do you help developers shift left?

Yeah, exactly. I actually like to say that shift left is really important. It’s this notion of moving testing, and the security activities earlier in the cycle… But I like to think that the big change is not shift left, but it’s top to bottom. It’s this notion of shifting security from being central, and centrally mandated and controlled, to being a bottom-up movement. We expect developers, application teams, DevOps teams, to make decisions and to be autonomous, so that they can very quickly learn what they need to do, build a solution, ship that to market, learn from it, iterate again and again. The tighter the loop, the better the business results are. We expect them to build secure software, and yet we don’t trust them to make security decisions. So there’s a dissonance here, there’s a problem.

Security has to take the lens – like, developers have to change, they have to embrace a bunch of these things, and the tools need to simplify it, but actually, security needs to change very substantially as well. They need to change from being ones that succeed by doing, by being the expert that understands both application and security and is able to combine the two, being a superhero, to succeeding by helping developers build secure software, or make secure decisions… Kind of like ops did when they went from more IT operations where they’re operating the systems, to more of an SRE/DevOps orientation where you equip the developers so that they can build operable software, and then operate it themselves. So I think the change has to happen.

[01:12:23.07] Well, yeah, developer-first security is an interesting concept and interesting thing; obviously, you’ve built a ginormous business around it… You reached unicorn status. You haven’t even said that yet, Guy. I mean, you started from the bottom and now you’re here. It’s crazy that this last round – I don’t know if it was the last round or the round before that where you’d said “We’ve reached unicorn status”, which is great… But as part of this community focus of Snyk too you’d mentioned not just building a tooling company, but building a company for the community that can really embrace a lot of the things you’d mentioned… A recent acquisition from you was the DevSecCon, which is a conference… Obviously, things with Covid-19 have changed some things, so I’m curious what your perspective is there on, I suppose, communities meeting online or not… But this aspect of “How do you make security not only a developer concern but a community concern?” Is that what you’re doing with DevSecCon, and what you’re doing with the podcast you run, and everything else?

Yeah, as part of our commitment to the community, or a part of the need for the community to go through this transition as they did in DevOps is around giving the community places where they can share knowledge. Security is really quite terrible in sharing practices. There’s this sort of natural tendency by many to just hold all the information to yourself and not share, be very secretive. And that’s very counter to how DevOps works. DevOps is around collaboration. We learn from one another, we communicate, we trust.

So early on, we tried to just sort of educate and share practices, and then subsequently I started the podcast “The Secure Developer”, and then we built DevSecOps, which we called The Security Developer Community at first, and then we renamed to DevSecOps And then the last big event was DevSecCon, which we acquired… All of them are really on that same mental of giving the community a stage, companies giving individuals that have important learnings to share about how do they change, how do they mobilize their organizations to embrace this new approach to security - give them a stage to share that. And this is happening across different areas. It happens when you talk about cloud-native companies like Auth0, or Segment, or companies that are more cloud-native and were born in the cloud and born with that mindset… And have them share how they did it to companies like – I had Roland Cloutier, who was the CSO of ADP, and he’s now the CSO of TikTok, talk about how does he shift, which was a pretty massive undertaking… Kind of shift an existing beast of security organization to this newer mentality, which is a process that’s still undergoing… And how they work.

And in DevSecCon, a lot of it is just around literally, physically coming together. Now, of course, Covid-19 will change that and we’re making it virtual to the extent we need at the moment entirely, but it’s around physically meeting. A lot of times what happens – and again, it’s all learnings from DevOps; we’re replaying the playbook, versus reinventing it… It’s around just knowing there’s a person on the other side, and understanding what they’re doing.

So in DevSecCon we bring developers and security people - and operators are also in there - to give talks that are all security-related, but they come from both angles. So suddenly you’re a developer, and you sit and you hear a security person talk about risk, and talk about how do they manage it. And suddenly, you’re a security person and you sit there and you hear about Agile and Scrum processes.

[01:15:53.09] So all of them are really a joint investment, and it’s a commitment for us to the community. And from a business perspective, we believe that the faster the world reaches these conclusions, the faster the practices get formed, the better it is for our business, because that’s the thesis on which we built the company and its offerings.

It’s an interesting world we’re in right now, that’s for sure… And the changes in just the developers and organizations - there’s a lot of organizations that are being impacted, like airlines and just different sectors of business that are just severely being hit by just change; downturn in economy, from no one flying etc… But in many cases you see a lot of cuts in those businesses, and cybersecurity (to some degree) or security taking a back seat. What is your perspective of security in this world now, and how organizations need to approach it?

Yeah, I think security continues to be super-important. Unfortunately, history teaches us that at a time when there is a lot of vulnerability, attackers kick in. So they use this vulnerability we’re seeing – all sorts of phishing scams right now that are related to Covid-19. We’ve seen in past crises, like in 2008, 2001 - we’ve seen an increase in online attacker growth… So we don’t know exactly what will happen here, but we can guess that attackers are only going to accelerate, versus go down… Unfortunately, also some people that are on the cusp also revert to more criminal activities when the market doesn’t give them a lot of great, legitimate work to perform.

So it’s very important that companies continue to invest in that security. you also as a company don’t want to go from a financial crisis to a crisis caused by a breach. You want to do it. So it’s hard… Balancing budgets is hard.

From Synk’s perspective, what we did is we actually tried to help out by giving Snyk usage for free. We’ve actually made an offer of six months free of Snyk usage to companies in the distressed industries, and to small/medium businesses as well, trying to help people… You know, at the moment it’s hard to get – if you’re in an airline, it’s hard to pay anything; you’re not really sure what’s gonna happen tomorrow… But the security people still want to keep the company secure, the developers still want to do that… So we are sort of opening up.

Thanks to the last rounds, we have enough in the bank to be able to withstand this period and allow these parts of the community and our customers as well to keep secure, stay secure as they brave through these really challenging times. We also issued these cheat sheets of ten best practices for secure development while working from home…

Ha-ha! Nice.

…from what we’re doing, and running a little webinar on that topic as well, with [01:18:36.28] and a security lead from Envision… Just again, to share practices about what should you change. A lot of it is about developer empowerment… You know, this is a time that you can’t scrutinize, you can’t slow people down, so how do you change to have the developers know what to do. It’s around focusing on security hygiene, and also some specific security threats and opportunities, like two-factor authentication and Zero Trust Network. This notion of your home surrounding is not gonna be as secure as your corporate surrounding, and what can you do about it.

Actually, this is a great time to start a bug bounty program, because – again, unfortunately, but still kind of turn lemons into lemonade… But there’s more people at home, with the right skills, who might be interested in making a few bucks, helping you find security flaws in your system.

Yeah.

It’s a good time to do that. So we try to give back… I think people have to – if you ignore security right now, again, you’re just gonna wake up from one crisis to another.

I like what you said there, “security hygiene.” I never really considered it as hygiene. Like you wash your hands… You want to enable certain things on your home router, because so many people are operating on Wi-Fi… I hear “Oh, the Wi-Fi is terrible in this area of the house, so I have to go to this area of the house”, and maybe their Wi-Fi is insecure, they’ve got packet sniffing, and all these things… I can only imagine. So I wanna make sure you give me that link to those ten best practices, that cheat sheet.

Absolutely, yeah.

[01:20:03.00] We’ll link that up, for sure. Let’s take a left turn back to I guess the future of Snyk. It was about – I wanna say last year, last July I think… You’d mentioned Peter McKay earlier as humbly giving up your role as CEO and what that process was. You’d mentioned people over your history too, and Peter played a key role in a lot of what you did, too. So it wasn’t just like you picked a random CEO and like “Oh, there you go.” This is a very interesting way of leveraging all of your history and great people in your history. Can you share the story of you and Peter, and maybe even pull in some of this stuff around the need to eject yourself from the CEO role and give it to somebody that can help you lead the company in the direction you wanna go, and allow you to focus on things you can do really well.

Yeah, for sure. So Peter and I go way back. Peter was the CEO of Watchfire; so if I mentioned before Sanctum, Watchfire and IBM, Peter was the CEO of Watchfire when they acquired Sanctum. So we met for the first time there, and we were in touch and doing a bunch of things together over the course of the next five years… And then I’ve always kind of learned a lot from him, and I’ve never been shy, so I would kind of go up to him and ask questions, and I consulted him when I considered going to tech sales for a while, as I mentioned before… So I’ve always kind of learned a lot from him.

When I left IBM and I founded Blaze, Peter came on my board. He at that time – we probably got a little bit tighter, to just sort of talk through problems. And Peter is a very accomplished individual. He comes from a finance and then sales background, and then sort of really big CEO backgrounds. He’s been the CEO of about five companies by now, three exits, he was the GM Americas for VMware, so he ran VMware America’s business, which I think was like a 3-4 billion dollar a year revenue line…

Wow.

So it’s definitely sort of a big business, but also ran Watchfire, and ran series B companies. And he and I think nothing alike. We come at the same problem from massively different angles, but we share the same values, and over the course of the years we’ve learned to see that… And it makes our conversations really valuable. Because when we talk about a problem - you know, I would raise a problem and I would think about different attributes of it. Peter is likely to think about that problem from a totally different angle. But if we both reach the same conclusion, then the likelihood of that conclusion to be right is pretty high.

I really kind of got exposed to that during Blaze, with him on my board, and it was really great conversations. I had Mike Weider, my co-founder at Blaze was super-smart and taught me a ton, and he and I had great conversations as well; we were just a little bit closer. Peter was further removed in terms of how we thought.

So when I started Snyk, Peter was always involved; at that point he was a friend. We’d do some investments together where we benefit as well from the fact that we both think very differently… So again, if we both conclude it’s a good company to invest in, it’s more likely to be right… And I brought him on as an independent board member early on. It was great that he could do it, and he didn’t have a lot of time, but because of our history, he took the leap of faith, and because he was excited about the business… And because of our familiarity, we could get a lot of value even when he didn’t have enough time. It was really great having him on the board, and he was already contributing to Snyk’s trajectory and already excited by it…

So when he ended his tenure at Veeam, which was the company where he was CEO, which I think he grew from like 400 million to about a billion dollars in revenue in like 2,5 years… And when he ended his tenure there, if I go back to that strategic opportunity-taking, I saw a widow.

[01:23:49.13] At the time - to switch from Peter to me - this is the beginning of 2019, but really a few months after, so April/May of 2019… Snyk has been going through this massive growth spurt. At the beginning of 2018 we were 23 people; at the beginning of 2019 we were 84 people, so it was almost 4x the company during that period. We 7x-ed revenue. It went from tech only to like I have to figure out a lot of these businesses. We did a fundraising round in that period, and a substantial – subsequently we did two more, but still, it was a real valuation…

A lot of money, yeah.

And what I found was that all of my time – I have an amazing team; I think our team at Snyk is… I’ve never worked with such a capable team, and I’ve never been the founder that held everything on his shoulders. I think I was fortunate enough to bring great people on board, and they helped make the company a success, and I would fill in different gaps… And still, during that year, if I look at April 2019 to the year before, the vast majority of my time was spent internally. It was just scaling the business, finding more good people to work this way, adjusting the processes, helping the sales deals… And what I wasn’t doing is what I think is my best competency, which is I wasn’t being a visionary. I wasn’t being out in the community to speak and write. I wasn’t engaging with customers enough.

I literally was tracking how many customer calls I have every week, and I went from my desirable several every week, to like none. Sometimes I would have three weeks without. So I was just stretched too thin, and I couldn’t let go of that, because I needed that to happen. And in parallel, I saw this opportunity with Peter, so we started talking about this. My board was very supportive. They basically said “Look, everything’s going well, you don’t have to do this. You don’t have to make any change. It’s going really well. But we also see the appeal in Peter. So if you’re both on board and you’re excited by it, we’ll roll with it.”

So we talked about it, and in July we kind of announced it to the company, and subsequently to the world, and then he officially joined in late August, beginning of September… And look, I think it’s one of the best decisions I’ve made. First, because of Peter. I just got the benefit of this amazing individual who came on board. It was very helpful when we continued to grow, because the company went from 84 people to 250 people in that year… But it also is helping even now, with the crisis, Peter having gone through…

A lot of wisdom.

…the 2000 crisis, and the 2008 crisis… It really helps to just work together. So he and I in a much more intense fashion collaborate and bring those two very different perspectives into the company… Which I think makes our general decision right.

There’s specific expertise he has around scaling our go-to-market. He came in and he made a comment at some point that the R&D organization was far more mature than the go-to-market organization… And to an extent it’s natural, because the company was growing so fast, but also to an extent it’s my lack of knowledge. I didn’t know how to grow a good market organization. I’m a techie, I’m a product visionary, I’m a community guy. So we got all of those, and then on my front, it helped me regain what I started slightly losing around the personal life, because I was trying to do all of those and it was just too much. Both the CEO, and still do the product visionary. And in practice, I wasn’t doing the product, the strategy, so it helped me basically get back to that, which I think is what Snyk needed from me, and needs from me most.

[01:27:17.29] So yeah, I think you always have to swallow a bit of an ego pill when you do this. There’s always adjustments around finding the conversations that you can increasingly not be a part of… Like not just not be the ones leading them, but not be in the conversation; that’s legit, because it’s the only way you make time… And what I had the luxury of, which isn’t available to everybody, is the fact that I had this deep trust and known relationship with Peter. That continues on, and I think I would make the same decision in a heartbeat. Even without that, I would encourage founders to just assess at any time… And I think maybe the key statement that stuck in my mind is “Just because something is good doesn’t mean it can’t be better.” So you don’t have to be in a failure state to make a change like the one I did. It can be in a success state, because there is an even bigger success, and even better situation to be at. You can always improve.

Very wise words, Guy. I’m glad you shared this story, because I think you have a lot of people who have a hard time replacing themselves, to some degree… And luckily, a CEO hunt can be very hard, and very taxing on an organization, and especially if you’re a failure state. Not so much like failure as a CEO you, but if you’re in a bad state and you need a new CEO to move back in and find margin into your life, whether it’s work life, whether it’s whatever, having the history you’ve had with Peter was such an awesome thing.

Maybe it plays a role back into your helping to help earlier on in your career, and having that mindset, because Peter was there, available, trusted, capable, already involved, you already had a lot of personal financial involvings in terms of investments, and angel funding etc. So I’m glad you shared that story, because it really shows the perspective of what it takes to appreciate that transition from getting some of your margin back. It sounded like you were really stretched thin, and what happens when you’re stretched thin is you have no margin. And when you have no margin, what happens? You have no maneuverability. You’re very near to a panic state, potentially, if it got too stretched… And I’m glad you shared that story though.

Guy, thank you so much for sharing your story. I’m sure we could talk further and longer, but man, you’ve got some cool stuff happening. Snyk is doing amazing. 84 last year, to 300 this year, you’re growing… This is a perfect time for being security-minded, and I’m so glad you shared your story today. Thank you.

Thanks for having me, happy to share… And I guess we’ve been talking about sharing learnings and hoping people can learn from them, and then do better.

Yeah. Thanks, Guy.