Frankly Speaking 1/12/21 - Convincing Developers to do Security
A biweekly(-ish) newsletter on random thoughts in tech and research. I am an investor at Dell Technologies Capital and a recovering academic. I am interested in security, AI/ML, and cloud.
If you were forwarded this newsletter, you can subscribe here. For more regular updates,
Happy New Year everyone! I can’t believe it’s only been a week into the year. I don’t hope it’s only downhill from here…
Anyway, it seems like I’m going to be WFHing for the near future. It’s hard to network without in-person meetings, but I’ve been using Lunchclub and LinkedIn to try to meet new people. I actually find meetings over Zoom easier to schedule, and I probably will focus on doing Zoom meetings more in the future (at least for the first meeting and/or if travel is required).
How are others meeting new people? Also, if you think there’s someone I should meet, please send them my way.
LET’S BE FRANK
A few months ago, I wrote about why developers don’t care about security, which resulted in a bunch of good discussions, so I wanted to write a follow-up post.
I do believe that developers should care about security, but in practice, they have other priorities, like delivering products. Like with all “shoulds,” we have to deal with the “is,” i.e. the reality of the situation. Don’t get me wrong. I think educating developers about security and trying to get them to understand its true value is an important endeavor. Unfortunately, as a startup, it’s not a capital-efficient way to go to market because you are trying to force a product-GTM or product-market fit. In other words, it’ll take too long to educate the developer market enough to achieve traction before your startup runs out of money. It’s better to let the market develop organically than try to force it to develop.
You might ask, “are all DevSecOps-related startups bound to fail unless there’s strong, initial developer adoption?” That’s a common misconception. You can sell a product to DevOps without doing a bottoms-up sales motion. Of course, bottoms up is viable, but that GTM is not a great fit for most products. So, how do you do it?
It’s simple. Security has to convince/force developers to use the product.
Of course, there are many ways to convince developers, some much harder than others. Security can force developers to use a product, which might result in a higher friction GTM. On the other extreme, there are products like Snyk that have significant bottoms-up adoption. However, there are many products in between. As with many things in life, there’s a lot of value between the two extremes.
How do you get DevOps to buy and/or use security products? Well, you should have a value proposition for them, i.e. DevOps should believe that this product benefits them. Simple right?
What kinds of products will DevOps and security both like? Well… that’s for startups to figure out. An area with potential is the “shift left” movement for security as companies migrate to the cloud and adopt DevOps.
More concretely, security tends to buy products for compliance and risk reduction. It’s no surprise that most CISOs top priorities are vulnerability management, cloud security, and identity and access management. Vulnerability management and IAM have strong compliance components. Similarly, the cloud has many compliance-related issues, but it’s also one of the biggest risks to an organization given the lack of mature security programs around it.
So what does DevOps care about? My partner, Tyler Jewell, has written a great article looking at trends on major products bought by developers in the past 2 decades. He identifies two main drivers: compliance and reduction in cycles. Compliance is pretty straightforward, but the reduction in cycles is commonly misunderstood. It’s not about reducing headcount. It’s about making the current headcount more efficient by reducing the cycles it takes to perform tasks. For example, code repositories reduced the number of cycles it took to iterate and merge code.
It seems like to convince both DevOps and security to buy a product, we need to sell compliance, which is a good sell, but has low revenue multiples. A product that reduces the risk for security and reduces cycles for DevOps would be highly desirable. We see this with Snyk. They reduce the risk of vulnerabilities in open source and code in general, leading to fewer security incidents. They also find these vulnerabilities before the code is run in production, leading to fewer cycles to remediate for both DevOps and security.
There’s a lot of value in selling to DevOps and security. Most importantly, you have the ability to access both budgets. The question is what other products can provide value for both DevOps and security.
I’m spending a lot of my time thinking about this, so I would appreciate any additional thoughts. Please send me a note if you want to chat more!
TWEET OF THE WEEK
Sometimes, it’s best to keep intros simple.
