New: The startup CTO's field guide to running security
Read the guide
Two engineering personalities shape security outcomes on lean teams: perfectionists who spiral and cynics who disengage. Here's how to manage both.
By Tim Olshansky, Co-Founder, Fencer
At my last startup, security landed on me by default: we had no CISO and therefore no one else to own it. The work itself was manageable; the harder part was moving it through a team where half the engineers were running a quiet calculation that it could wait.
What I found, running security at multiple companies, is that the same two personality types show up every time: the cynic who genuinely believes the risk doesn't justify the sprint capacity yet, and the perfectionist who cares deeply but gets stuck when the scope of what needs fixing feels too large to tackle. Getting work done with both of them means understanding what each one actually needs, because the approaches are completely different.
They're not reckless. They're running a calculation: "No one is going to hack us yet. We're too small. We're not on anyone's radar. If I spend 20% of this sprint on CVE triage, I'm taking 20% away from the features that might actually keep us alive."
At the early stages, that reasoning isn't entirely wrong. The threat model for a 15-person startup is genuinely different from a 500-person company; the cynic is doing informal risk triage.
The "we're too small" argument has a successor now. The cynic today might not even bother with that framing; they have a more convincing one: our code was written by Claude, we're using AI-powered security tooling, we're on managed infrastructure, and it's handled. That reasoning is completely and utterly false, but it feels true because the stack is so abstract and the tools are so confident-seeming that there's nothing obviously wrong to look at.
The problem with both forms of the argument is the same: the reasoning stays static while the threat model changes. At 80 people, inside a major customer's vendor questionnaire, "no one cares about us" stops being true, and "the platform handles it" was never true.
Every security finding is an indictment, a signal about who they are as an engineer rather than just a ticket to resolve. The moment a scanner flags something they wrote, the internal monologue starts. How did I miss that? What does this say about me?
This is the same instinct that makes them useful everywhere else in the job. They catch edge cases before they ship, push back on shortcuts, and hold high standards for the work. Security is just another surface for that instinct to operate on. When a finding lands, it becomes an attack on their identity and they spiral, which is not a character flaw.
They'll do the security work without grumbling or questioning whether it's worth doing. But the spiral is what stands between "we made progress" and "we fixed nothing because we were waiting until we could fix everything correctly."
The cynic and the perfectionist each offer something useful if you know what to do with them.
The perfectionist's superpower is follow-through. Give them focused scope, a clear priority, a definition of "done for now," and they'll deliver. They're not going to ask whether this ticket is worth the sprint capacity; they're going to close it because leaving it open bothers them. At every company I've been at, the security backlog moved when someone felt personal ownership of the work, and those people were almost always the perfectionists.
The cynic's superpower is ROI calibration. "Is this worth our time?" is a useful question during planning, less useful during remediation. If you can't make a clear case to the cynic for why this issue belongs in the sprint, maybe it doesn't. The cynic, deployed correctly, keeps you from over-investing in low-impact work.
The failure mode is when both go unmanaged: an unmanaged perfectionist fixates on the large issue they can't fix and freezes, while an unmanaged cynic applies "we're not a target" reasoning past the point where it's still true. The other thing to watch for is over-relying on your perfectionists to carry all the security work. If the only people who genuinely care are the two or three whose professional identity is bound up in it, that's a setup for burnout. Give them scope that's achievable and make sure they see wins close. If you can bring one more person into genuine ownership of the work, even a former cynic who got converted by an actual incident, you spread that weight more sustainably.
The challenge isn't usually doing the security work; it's getting agreement that it needs to happen now. The cynic thinks the risk is overblown; the perfectionist thinks the backlog is a crisis. Both are looking at the same underlying data and coming to opposite conclusions, which means prioritization stalls.
The thing that consistently cut through both types, at my last startup and at companies before it, was a pen test.
For the cynic, a pen test finding lands differently than a scanner flag or a CVE severity rating: someone actually got in. The "no one cares about us" reasoning collapses. I've never had pushback on fixing a critical finding from an actual pen test, not once, across multiple companies. The cynic goes quiet because there's nothing to argue with.
For the perfectionist, a pen test works differently, forcing prioritization. The finding is there, it's been confirmed exploitable, and it needs to go to the top of the list. That gives the perfectionist permission to put down the comprehensive security overhaul they've been planning and just fix the specific thing that got exploited. It removes the ambiguity that causes the spiral.
Both types need external structure to work well, and a pen test is one of the more reliable sources: it gives the cynic evidence they can't argue away and the perfectionist a clear mandate to execute against.
What I kept coming back to, at every company I've been at, is a principle that sounds obvious until you watch how many teams fail to follow it: do something small.
For the perfectionist who's frozen waiting to fix the big issue, fix a small one now and don't let the large, unaddressed gap prevent progress elsewhere. Ten small fixes compound, build a pattern, and change what normal looks like for the team. If other people on the team see you making small changes quickly and easily, they'll start making them too.
For the cynic who's disengaged because the backlog feels infinite, show them a small win. Don't ask them to care about 200 scanner findings; ask them to care about one specific, demonstrably exploitable thing with a clear fix. The cynic's resistance is often less about security in principle and more about the sense that the work is infinite and unrewarded.
I've seen the same failure mode at every company: someone is fixated on the large hole in their security posture, the thing that would take a month of engineering time to fix correctly, and it becomes the reason nothing else gets addressed. If you have 20 minutes to make something incrementally more secure, do it and don't let the big thing you can't fix right now stop you from fixing the small things you can.
Security that compounds usually looks mundane while it's working. The place to start, for perfectionists who are frozen, cynics who are disengaged, and CTOs carrying all of it, is almost always smaller than it seems.
If you're trying to build that kind of security habit on a lean team, the Fencer Startup Security Field Guide is a practical starting point, sequenced for teams without dedicated security headcount.
