February 13, 2026
16 min
Even the most data-driven founders still make critical decisions based on vibes, gut feeling, and unchallenged assumptions. Here is how to replace intuition with systems that measure and manage real risk.
Pio Greeff
Founder & Lead Developer
Deep dive article
Even the most data-driven founders make decisions based on vibes, gut feelings, and unchallenged assumptions. Here's why - and how to build systems that don't care about your intuition.
Pio Greeff Founder & Lead Developer
Security / Strategy - February 13, 2026 - 16 min
It's Friday the 13th. Somewhere right now, a founder who preaches "data-driven decision-making" just knocked on wood before pushing to production.
We laugh at superstition. Black cats. Broken mirrors. The number 13.
But strip away the folklore and superstition is just pattern recognition gone wrong - the human brain assigning causation where none exists, then building rituals around the illusion of control.
Sound familiar? It should.
Because the same cognitive machinery that makes people avoid the 13th floor is the same machinery that makes operators ship based on vibes, overinvest in shiny tools, underinvest in boring controls, and avoid uncomfortable but necessary changes until the blast radius forces their hand.
The superstition isn't the problem. The unexamined thinking underneath it is.
Superstition persists because it's evolutionarily cheap. Your ancestors who assumed the rustling in the bush was a predator - even when it was just the wind - survived more often than the ones who waited for evidence. False positives kept you alive. False negatives got you eaten.
That's the asymmetry that wired our brains for irrational caution in some areas and irrational confidence in others. Psychologists call this error management theory: when the cost of being wrong is asymmetric, your brain defaults to the cheaper mistake.
The problem? In modern operational environments, the cost asymmetry has flipped - and our instincts haven't caught up.
Being irrationally cautious about a deployment date because Mercury is in retrograde? Harmless. Being irrationally confident that your cloud provider won't have a region-wide outage because it hasn't happened yet? That's where companies die.
The brain doesn't distinguish between these. It uses the same heuristics for both. And those heuristics have names.
Every founder I've worked with says they make decisions based on data. Very few of them actually do. Here's the lineup of biases that quietly run most product and security decisions - and no amount of Notion dashboards will fix them.
The classic. Every breach happens to someone else. Every outage is someone else's architecture. Every compliance failure is someone else's audit.
Until it isn't.
The median time to identify a data breach in 2024 was 194 days. Not because detection tools don't exist - but because teams genuinely believe they aren't a target. The infrastructure is "good enough." The logs are "probably fine." The access controls are "on the roadmap."
Optimism bias doesn't look like recklessness. It looks like prioritization. And that's what makes it dangerous.
You just survived a DDoS attack. So now every engineering conversation is about DDoS mitigation. Meanwhile, your IAM policies haven't been reviewed in 18 months and three former contractors still have production access.
Availability bias means we overweight recent, vivid events and underweight slow-burning, invisible risks. The breach that made the news gets budget. The misconfigured S3 bucket that's been leaking data for six months? Nobody's thinking about it because nobody's seen it yet.
If you're wondering how frameworks help counterbalance this kind of reactive thinking, I've written about the compliance roadmap that connects ISO 27001, SOC 2, and GDPR - it's specifically designed to surface the risks your availability bias wants to ignore.
You spent $80,000 on a SIEM platform that your team hates. The dashboards don't match your environment. The alert fatigue is crushing. But you've already invested so much time, money, and political capital that switching feels impossible.
So you keep paying. You keep suffering. You keep telling yourself it'll get better after the next update.
This isn't a technology problem. It's a psychology problem. And it applies equally to vendor relationships, architectural decisions, and that legacy authentication system you've been meaning to replace since 2022. The real cost isn't what you've already spent - it's what you could have built with the TCO framework that accounts for hidden costs.
Your board heard "99.9% uptime" during the vendor pitch. That number now lives rent-free in every executive's head, regardless of what the SLA actually guarantees, what the penalty clauses say, or what the real-world performance data shows.
Anchoring means the first piece of information disproportionately shapes every subsequent judgment. The first cost estimate. The first risk assessment. The first compliance gap analysis. Whatever number lands first becomes the gravitational center - and everything else orbits around it.
Perhaps the most lethal of all. Normalcy bias is the tendency to interpret warning signs as consistent with normal conditions. The alerts are probably false positives. The unusual login pattern is probably a developer working late. The vendor's vague response to your security questionnaire probably means they're just busy.
It's the operational equivalent of standing in rising floodwater and telling yourself it'll stop soon because it always has before.
Here's where the superstition metaphor gets teeth.
People who are superstitious about Friday the 13th are irrationally overweighting the probability of bad luck on one specific day. But the operators who refuse to plan for low-probability, high-impact events are irrationally underweighting real, measurable risk.
Both are failures of calibration. But only one of them can destroy your company.
The average cost of a data breach hit $4.88 million in 2024. For companies under 500 employees, a breach can be existential - not because of the fine, but because of the customer exodus, the legal exposure, and the operational paralysis that follows.
Yet most early-stage companies treat security as a Series B problem. "We'll invest in that when we scale." "We don't have anything worth stealing yet." "Our developers are careful."
These aren't risk assessments. They're incantations. They're the operational equivalent of throwing salt over your shoulder and hoping for the best.
I've covered why website security is a legal liability, not just a marketing asset - and that conversation applies to every surface area in your stack, not just the front door.
Single points of failure are the operational version of walking under a ladder - except the ladder is load-bearing and it's holding up your revenue.
If your entire application depends on one database instance in one availability zone managed by one person who's also on vacation, you don't have an architecture. You have a prayer.
The uncomfortable truth is that redundancy is boring. Multi-region failover is expensive. Chaos engineering takes time nobody wants to allocate. So teams ship the happy path and hope the unhappy path never shows up.
It always shows up. And when it does, startup speed without architectural resilience isn't velocity - it's acceleration toward a wall.
Vendor lock-in is the sunk cost fallacy scaled to the infrastructure level. By the time you realize the dependency is toxic, the migration cost is so high that staying feels rational - even when the vendor's pricing model, reliability, or security posture is deteriorating.
I've watched companies burn months of engineering time migrating away from platforms they should have evaluated more critically on day one. Not because the warning signs weren't there, but because the switching cost was always "too high for this quarter."
That's not a strategy. That's normalcy bias with a procurement budget. If you want a case study in how vendor dependency plays out in practice, the Antigravity rate-limit debacle is a masterclass in platform capture.
Here's the thing about cognitive bias: you can't think your way out of it. That's the whole point. Biases operate below the level of conscious reasoning. You can't just "decide to be more objective." You need systems that enforce objectivity whether you feel like it or not.
This is where operations becomes engineering.
Every recurring decision should have a framework. Vendor evaluation? Weighted scoring matrix. Incident severity? Predefined classification criteria. Feature prioritization? Impact-effort with actual data, not conference room vibes.
The framework doesn't need to be perfect. It needs to be consistent. Consistency is what strips cognitive bias out of the equation. Not completely - we're still human - but enough to prevent the worst outcomes.
The boring controls are the ones that save you. Automated access reviews. Forced MFA. Mandatory code review gates. Scheduled credential rotation. Log aggregation that actually gets monitored.
Nobody wakes up excited about these. That's exactly why they need to be automated. If a control depends on someone remembering to do it, it's not a control - it's a suggestion. This is the same principle behind bank-grade authentication: the standard should be the floor, not the ceiling.
Dashboards are not feedback loops. A dashboard is a thing you look at when something's already broken. A feedback loop is a system that forces information to the people who need it before the situation becomes critical.
That means automated alerting with defined thresholds. Regular risk reviews with real data, not recycled slide decks. Post-incident reviews that actually change process, not just document what happened.
If your feedback loop requires someone to voluntarily check a dashboard, it's not a loop. It's a dead end. And if your data infrastructure isn't mature enough to feed those loops, you may be living the AI readiness illusion without knowing it.
The most powerful tool against irrational risk isn't better technology. It's structured pessimism.
A pre-mortem inverts the planning process. Instead of asking "how will this succeed?" you start from "this has already failed - why?"
It's devastatingly effective because it gives people permission to voice concerns they'd normally suppress. Nobody wants to be the person who kills momentum by raising objections during a planning meeting. But in a pre-mortem, identifying failure modes is the assignment.
Research from Wharton, Cornell, and the University of Colorado found that prospective hindsight increases the ability to correctly identify reasons for future outcomes by 30%. That's not a marginal improvement. That's a structural advantage.
Run one before every major deployment. Every vendor selection. Every architectural decision. The twenty minutes it costs you will save months of cleanup.
A control framework - whether it's SOC 2, ISO 27001, NIST CSF, or something purpose-built - is the structural antidote to magical thinking. It replaces "I think we're secure" with "here's the evidence that we've implemented, tested, and validated these specific safeguards."
Frameworks don't eliminate risk. Nothing does. But they transform unmeasured, unmanaged risk into measured, managed risk. They turn vibes into evidence. Assumptions into audits. Hope into process.
That's not bureaucracy. That's engineering applied to uncertainty. I've mapped the full landscape - including what's actually new in 2026 - in the global compliance landscape guide.
The best operators don't just plan for known failure modes. They build systems that degrade gracefully when confronted with failures nobody anticipated.
That means circuit breakers in your service architecture. That means runbooks for scenarios you've never encountered. That means regular tabletop exercises where you simulate the disaster and discover - in a controlled environment - all the assumptions that would have killed you in production.
Resilience isn't about preventing failure. It's about ensuring failure doesn't cascade into catastrophe. And with AI systems increasingly embedded in critical workflows, the governance question is no longer optional - it's the defining standard of the next decade.
Here's what it comes down to.
Superstition is unmeasured risk dressed up as mystery.
A rabbit's foot in your pocket doesn't reduce your attack surface. Avoiding deployments on Friday doesn't improve your rollback process. Knocking on wood doesn't replace a disaster recovery plan.
But building systems that measure risk, enforce controls, and create resilience regardless of what day it is? That's not superstition. That's operational discipline.
The irony of Friday the 13th is that the people most afraid of "bad luck" are usually the least prepared for real adversity. They've invested their energy in rituals instead of systems. In feelings instead of frameworks. In comfort instead of capability.
Don't be that operator.
Measure the risk. Build the control. Test the assumption. Run the pre-mortem. Automate the boring thing nobody wants to own.
And the next time someone tells you they "have a good feeling" about a deployment, a vendor, or a security posture - ask them to show you the evidence.
Because in operations, the scariest thing isn't Friday the 13th.
It's the risk nobody bothered to measure.
Building operational systems that replace gut feelings with governance? That's exactly what CISO Blueprint is designed for - translating "we should probably secure that" into clear controls, frameworks, and execution.
Found this useful?
Share it with your network
