The First Security Hire Rule of Thumb

Need someone to brainstorm with about hiring for security? I’m always happy to grab a virtual coffee. Reach out!

When should you hire that crucial first security person?¹ There is a lot of fabulous, deeply considered advice out there.

Michael Graham has one of my favorites: “How Early-Stage Startups Can Enlist The Right Amount of Security As They Grow.”

I appreciate it because he is brave enough to offer concrete, quantitative guidance:

“Onboard your first, full-time security hire between 30-100 employees”

However, a headcount-based metric doesn’t easily convey the nuance of this decision. It also loses the color on how to translate the benchmark to your specific organization.

Graham is also the author of the fabulous Rockstar shopping is inherently unsafe - a treatise on the failure models of “we really need to hire somebody to handle all this security stuff.”
Once you’re ready to hire, go give it a read!

Ryan McGeehan (dba. Magoo) has some qualitative guidelines:

• “Hire a team, not a person.” if you only think you need one person, maybe you can still mitigate the fundamentals without them
• “Task management is a reliable value across the workplaces cultures.” reduce friction and empower structured task tracking to get the most value
• “There are clear partners across the company.” if you don’t have partners like IT in place, security will fall backwards into ownership. Is that what you want?
• “Budget is available to support a security employee.” kicking off the program will come with some OpEx
• “Self-organization has begun around security responsibilities.” some ad-hoc work should happen well before you hire for security

A rule of thumb

I’m trying something new, stick around to the end to see a visual summary of this post!

I’ve come up with a Rule of Thumb, based on my conversations with founders and first security hires. This advice is best fit for companies that know security will be important and eventually need dedicated staffing, but don’t know when to actually make that hire.

Here it is:
You should hire your first security person when security is an unavoidable distraction from scaling your business.

Straightforward, right? Here’s why I think this sets you up for the first hire having value and impact. The rule ensures:

Security work is already happening: if security work is not happening, and begins to crop up, the best thing to do is to empower the engineering team to own it. This ensures security is aligned with broader engineering priorities and embedded in the culture as a core aspect of good engineering. You can’t expect the first hire to remake culture, only nudge it. If you wait for a security hire to do security work, and only have security work done by them, you’re creating an accountability problem. This can start an imbalance that will limit scaling your engineering long term.

Security work is already meaningful: hiring for security is hard (and expensive!). In a startup, your time is constrained. For it to be worthwhile, security should be an acute priority impacting the executive level. You should be in a place where a Founder or CTO is spending meaningful time on security. This ensures security is strategic enough to bring in dedicated expertise. If security pain can be relieved through delegating to the existing team, you should start there.

The rule is flexible enough to manage the rich confluence of factors: it’s hard to write a formula for the first security hire. Outsized drivers include industry and customer expectations of security maturity, complex security considerations in your architecture or technologies (i.e cryptography as a core of product), regulation, security as a GTM differentiator, a heavy burden on customer security due diligence, or targeted attacker activity.

The rule avoids relying on loosely correlated metrics: Graham’s rule is just one example of using a loosely correlated metric. Other posts might lean on industry profile (“FinTech should have a security lead in the founding team”), compliance goals (“Hire for Security right after you get SOC2”), ARR (“Once you break $1M ARR, think about a security hire”), or fundraising (“Post Series B, hire security”). However, all of these would only look at one of the many factors in this decision. Plus, the metrics are not sufficiently tied to security requirements. For each, there is an easy counter-example.

Ready to go out and interview, or just accepted such a job yourself? I’m always happy to grab a virtual coffee. Check out 10 Things Your First Security Hire Shouldn’t Do to get off on the right foot!

Be careful, the rule is not “hire when you’re overwhelmed.” This is generally true with first hires, but in security especially because:

• Hiring can be slow. There are many profiles of security candidates, and few who might match your preferred background in a first hire. The security market at the senior-most IC levels tends to be competitive, and resilient to the macro market.
• Debt rapidly accumulates. If you wait too long, your security hire may face a Sisyphean uphill battle against architectural and engineering security debt, and be unable to make proactive strategic investments.
• “Overwhelmed” is a less compelling pitch. Your candidates likely want to see a challenge, but a surmountable one with a long and impactful path forward. It’s rarer to find this sort of unicorn candidate who also enjoys starting from behind. This is especially true with the liability and stress of ownership of risk in a business.

Here’s some examples of emerging work that, if substantial, might be a sign to bring in expertise:

• Dumb Security Questionnaires: if your sales cycle involves a lot of security due diligence, your customers are signaling their preference for you to invest in security. You shouldn’t hire someone to rote answer these questionnaires, but rather to ensure you don’t make risky or counterproductive commitments while unblocking sales velocity.
• Regulation, Compliance, and Audits: not only can hiring a security person help get these done, it can also ensure you’re not mistakenly taking on scope or controls that don’t suit your business. For inspiration, see Fly.io’s “What We Didn’t Let SOC2 Make Us Do.”
• Lack of expertise slows engineering: due to your domain, architecture, or scale, you’ll find bottlenecks on accepting risk and security tradeoffs. Similarly, short term security practices are well established, but formulating a long term roadmap can be time consuming nad requires expertise. You can defray hiring by using contract security expertise.
• Attacks (i.e DDOS), vulnerabilities, CVEs, and the threat landscape: if you’re regularly disrupted by security incidents, a security hire might insulate the broader organization while also increasing resiliency. Signals might be an initial Penetration Test or CSPM demo lighting up like a christmas tree, regular fire drills to fix first- and third-party vulnerabilities, or loosing sleep over known threats.

I’ll leave you with some antipatterns to avoid:

• FUD driven hires: If you’re worried about security, don’t know what to do, and think hiring will make you feel better - take a breath. Find an expert in your network to give you some perspective on whether your fear is tied to actual risk or not. Consider what of the aforementioned elements are present in your business.
• Hiring without a profile: There are so many different kinds of security person. Nail down your desired profile before looking to hire. Do you want a hands-on, independent contributor Security Engineer who codes? Do you want a cloud infrastructure security expert? Do you want someone who has run large teams? Do you want someone who is a repeat-CISO? Do you want someone coming out of Governance, Risk, and Compliance?
• Fiefdom hires: Don’t hire someone who’s strongest driver and competency is team building. These can be a fabulous accelerant for your security program, but I’d recommend you wait until later to bring them in. Make sure whoever you hire is ready to take the time in Player mode before moving to Player-Coach.
• Hiring a sin-eater: Bad engineering teams will welcome reasons to ignore a debt. Make sure you’re hiring someone who will make positive changes for your business from a security lense. Hire someone who will take security responsibilities, but understand that security risk is still a business-wide domain. Your first security hire should apply their expertise and a full-time focus to the many facets of security, but they shouldn’t just be a place to bury your security concerns and offload security from the rest of the company.

Thank you to Ryan McGeehan (Magoo) and Michael Graham, who both provided thoughtful feedback on initial drafts of this blog post.