Frankly Speaking 8/2/22 - Why I buy tools but don't (usually) plan to keep them
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
In some ways, working at a startup is similar to working in VC. You have to learn about a variety of topics quickly, and definitely having some baseline expertise in them helps you learn and grow faster. However, unlike VCs, I actually have to deliver on a product and outcome… haha
To answer many people’s questions, that’s why I have thoughts on various topics because there’s more work to be done than resources, and I’m forced to learn and context-switch very quickly. This is similar to what happened early on in my PhD where breadth is a huge focus.
Anyway, this is related to what I am going to talk about in this newsletter.
LET’S BE FRANK
In this newsletter, I’m going to talk about why I buy certain security tools and why I don’t plan to keep them around most of the time…
I’m going to cover the following topics:
Why companies, especially startups, should buy security tools vs. building them internally
Talk about a specific tool, and why it’s useful (Teleport)
Why I don’t plan to keep it around
When I will start thinking of replacing it
When does it make sense to buy a security tool?
A common problem in most startups is that there are more problems to solve than people and resources. This requires certain employees to fill in the gaps. In order to achieve product and traction goals, strict time prioritization is important. So, leaders and employees have to determine the best use of their time. However, most employees are not experts in the challenges that need to be solved, i.e. it would probably take them many times longer to learn and solve the problem than a moderate expert in the space. Especially, if the problem or issue is not strategic to the company’s core offering, then it seems not a great use of time.
In other words, employees should be spending time figuring out how to use and take advantage of their strengths rather than trying to fix their weaknesses. They should find some other way to fill the gap created by their weakness. Usually, this is by buying a tool.
Specifically for security tools, many companies early on will hire someone with security expertise, but it’s impossible to find someone who is good at all aspects of security. However, this security person will be tasked with doing various tasks and building out various systems.
As many of you might have heard me say, time is a startup’s most valuable asset. The main question is the following: “are there ways to shortcut or accelerate growth?” Buying tools does just that. It outsources a problem to someone else and as result, the product hopefully provides a nice abstraction for the user without having the user worry about all the details of the problem itself.
With that said, here are some criteria I use to consider when to buy a tool:
Is the solution strategic to a company’s core product offering?
How much time will this product save my team and me?
How many employees does this product impact?
Is it key to our security goals?
Does the problem the security tool solves become exponentially worse as we scale?
The first criterion is the most important question in the buy vs. build world. However, the key question before determining buy vs. build is to define product requirements. Without doing that, it’s impossible to make a well-informed judgment on that question. Luckily, most security problems early on in a company’s life are not complicated or require too much customization unless they are directly related to product security. Many security problems early on are usually not strategic. If a problem, is strategic to the company’s core offering, then you should not buy this product and invest in building it because it is delivering additional value to your customers.
The next criteria are determining resource allocation and what prioritization we should give a certain security product, and consequently what order to buy certain products. A commonly underestimated way to think about buying products is opportunity cost. You could hire a few engineers to build this solution, but they also have to maintain it after it’s built. Is this the best use of their time? Could they be building something else that can accelerate growth?
Unless you are a big tech company that has a well-resourced engineering organization, have a need for a customized solution, and/or want to solve a problem that’s strategic to your product, buying is a wiser decision.
Specific example: Access control for dev infrastructure
Internally, we use Teleport at dbt Labs. I can write a whole post on why we chose Teleport over its competitors, and many of the reasons are specific to our organization. However, I won’t elaborate more on this. The idea is to look at a specific example to have a better sense of when to buy products.
Is the solution strategic to a company’s core product offering? Teleport was not inherently strategic to our core product offering. It improves our security posture substantially, but it does not provide additional direct value to customers that could lead to an upsell.
How much time will this product save my team and me? This probably would have taken a team of 2-3 engineers full time for 6 months to build it. It probably would take an engineer to maintain full time going forward. So, the time gained can allow us to focus on other, more strategic security issues.
How many employees does this product impact? This impacts all our developers and others who occasionally access our infrastructure. As a result, this product makes it easier to manage and grant access, so it actually increases development velocity by reducing management overhead.
Is it key to our security goals? Absolutely. My philosophy for security engineering is that we should enable engineers to build secure systems. Any solution that increases development velocity while improving security posture is an obvious win.
Does the problem the security tool solves become exponentially worse as we scale? Yes. As the company hires and onboard more developers, access will only become increasingly complex, so it’s better to have a centralized way to manage access to infrastructure now to better manage the complexity.
Developer infrastructure is a core part of any tech company. It’s important to properly manage access to it. That’s why it’s a core security priority early on. It’s important to establish policies early and maintain them. It’s more effort to clean them up afterward.
Why I don’t plan to keep it around
When I think about buying products, I think of time to value tradeoffs. It’s unreasonable to think any solution will stay around forever. However, it’s important to buy or build a solution that will take the company to the next level of growth. This varies from company to company. In my mind, for every month of implementation time, it should last that many years. For example, it takes 3 months to build and deploy and lasts 2-3 years, that’s great. If it takes 6 months to build and lasts only 2 years. That’s not great. There are exceptions like features core to a product that block sales.
As companies grow, the problem and needs change. Inevitably, companies start to focus on various gaps that were deprioritized. Cost is a major one. Companies also mature and have more specialized needs that a product can’t address. So, many times at this stage, it’s both easier and cheaper to build and maintain their own solution. However, a company needs a stopgap solution to get there!
To clarify, I say I don’t plan to keep it around forever. That’s the plan. Of course, plans always change. Products mature, priorities change, etc. It is possible that a solution is kept around for much longer than intended or even never removed because it becomes such a core part of the security strategy. Part of that also depends on the product’s evolution, but for now, it’s strategic not to depend on a product too heavily.
When I will start thinking of replacing it
Honestly, I’m not sure. I know the criteria for when I will start thinking about it. Cost becomes a concern, and there are sufficient engineering resources to tackle this project. If we hire intentionally or unintentionally engineering expertise around building this product, we will consider it. Basically, our strategy has to change toward a build mentality to start thinking about replacing. However, this doesn’t prevent me from looking at alternate solutions every couple of years, which is a good strategy/policy to follow.
It’s important to establish a strategy around build vs. buy. However, the strategy is not as simple as choosing to buy or choosing to build. There are nuances that need to be figured out to determine what and when to buy or build. Having a clear strategy can substantially change the effectiveness of a security engineering organization!