Adapted from Ben Horowitz's Good Product Manager / Bad Product Manager, written as a practical accountability tool rather than a philosophy document. If you're the first security leader at a scaling SaaS company, this might help.
Good security leads understand their job is protecting the company — its customers' data, its reputation, its exposure to regulatory and legal liability — in a way that lets the business keep growing. They take ownership of risk, and they translate that ownership into business outcomes: improved close rates because security is handled, customer trust that compounds, regulatory exposure that's managed before it becomes a crisis. They both protect and enable.
Bad security leads measure themselves by vulnerabilities patched, tools deployed, and audit findings closed. They own activity, not outcomes. The business can't tell whether all that work is actually reducing risk or just producing artifacts.
Good security leads can explain their security strategy in two sentences. The strategy answers: what are we protecting, from whom, and what are we choosing not to do yet? Everything on the roadmap traces back to those sentences.
Bad security leads have a roadmap that's actually a to-do list. They can't explain why item 3 matters more than item 7. When asked about strategy, they describe their project plan.
Good security leads know which three things would actually cause serious harm to the business if compromised. They've modeled the realistic paths to those things. Every dollar and hour maps to shortening or blocking those paths.
Bad security leads spread effort across everything equally. They treat a misconfigured S3 bucket and a critical auth bypass with the same process and the same urgency. Their risk register is a spreadsheet, not a model.
Good security leads tell the CTO what not to worry about. They actively deprioritize. "We don't need to invest here yet, and here's why" is one of the highest-trust things they say. It saves budget, proves judgment, and earns the credibility to be heard when something actually matters.
Bad security leads only bring problems. Every conversation is another thing that needs fixing, another tool that needs buying, another risk that needs accepting. They never take anything off the list. Leadership starts tuning them out.
Good security leads build the process once. The first enterprise security review is a scramble. The second should be 60% easier. The tenth should be routine. They build answer libraries, template responses, architecture documentation, and internal runbooks so the next questionnaire doesn't require a fire drill.
Bad security leads treat every security review like the first one. Six months in, the CTO is still getting pulled into calls. A year in, they're still writing and copy pasting questionnaire responses. The company is doing more security work than when it started but moving slower.
Good security leads get on the call with the buyer's security team and handle it. They speak the buyer's language because they understand what enterprise security teams actually evaluate. They make the CTO's life easier by taking this off their plate entirely.
Bad security leads prepare the CTO for the call instead of taking it themselves. Or they get on the call and recite controls from a framework instead of answering the actual question. The buyer's CISO leaves the call less confident, not more.
Good security leads know the difference between passing an audit and having a security program. They use SOC 2 to build the foundation of something real — policies that reflect how the company actually operates, controls that are wired into the architecture, evidence collection that runs itself. The audit is a forcing function, not the finish line, nor real security.
Bad security leads build a compliance program. They write policies to pass the audit and file them. The controls exist on paper. Evidence collection is a quarterly scramble. When a sophisticated buyer looks past the badge, there's nothing behind it.
Good security leads understand their compliance platform. They know what Vanta/Drata/Delve actually monitors, what it doesn't, and where the gaps are. They configure it properly, tune the alerts, and treat it as infrastructure — not as "the security program."
Bad security leads point at the dashboard. Green means good. They haven't mapped what's monitored to what actually matters for their architecture. When someone asks about a control the platform doesn't cover, they're caught off guard.
Good security leads make the secure path the default path. They fix the architecture so the dangerous thing is hard to do, not just prohibited by policy. They work with engineering to make security invisible — SSO and passkeys by default, secrets management baked in, least privilege enforced by the platform, not by a checklist someone reviews quarterly.
Bad security leads write policies and hope people follow them. Their security depends on humans making the right choice every time. When something goes wrong, they blame the person who clicked the link instead of the system that let a click matter.
Good security leads produce two versions of everything. A pen test report has a true executive summary for the board and the buyer, and a technical detail section for the engineering team. A risk assessment has a one-page narrative for the CEO and a prioritized remediation plan for the team. They translate constantly between audiences without losing accuracy in either direction.
Bad security leads produce one document and expect everyone to parse it. The board gets a report full of technical details and risk jargon. Engineering gets a strategic memo they can't act on. Nobody gets what they need.
Good security leads know what their pen test report looks like to the buyer who's going to read it. They scope the test to cover what buyers actually evaluate. They ensure the findings tell a story — what was tested, what was found, what was fixed, what the residual risk posture looks like. The report builds confidence.
Bad security leads scope the pen test to check a box. They don't think about who reads the report after they do. When the buyer's security team reviews it and has questions, the CTO is back on the call.
Good security leads talk to sales. They know which deals are in pipeline, which are in security review, and which are stuck. They understand the revenue impact of their work and can tell the CEO: "We closed the security gap on the Acme deal. That's six figures ARR we helped with." They have a seat at the revenue table.
Bad security leads wait to be asked. Sales finds out about security capabilities by accident. The security review bottleneck is invisible to leadership until someone asks what happened to the lost contract.
Good security leads are honest about what they don't know. They say "I need to research that" instead of guessing. They say "the evidence on that is weak" instead of pretending certainty. They say "that's a real risk but not one we can address at our stage" instead of hiding it. This honesty is what makes leadership trust them when they say something matters.
Bad security leads perform confidence. They overstate risks to justify budget. They understate gaps to avoid hard conversations. They present frameworks as gospel instead of tools. When they're finally wrong about something, their credibility collapses because it was built on performance rather than demonstrated judgment.
Good security leads know their team is small and their time is the bottleneck. They are ruthless about where they spend hours. They automate evidence collection, templatize questionnaire responses, and build self-service security guidance for engineering. Every recurring task they do manually is a failure to systematize.
Bad security leads are busy all the time and proud of it. They wear the workload as a badge. They haven't automated anything because they're too busy doing the thing to build the system that does the thing. They complain about being overwhelmed but can't articulate what they'd do with more time.
Good security leads hire slowly and scope the role honestly. When they need to grow the team, the job description matches the actual job. They'd rather wait for the right person than burn a hire on someone who can't operate independently.
Bad security leads write unicorn job descriptions. They ask for one person to cover appsec, cloud security, compliance, vendor risk, incident response, and architecture review and sixteen specialties at mid-level comp. The role sits open for months and they complain they can't find good people.
Good security leads give the board a concise, honest update. Fifteen minutes, quarterly. Here's our posture. Here's what improved. Here's the one thing I need your awareness on. Here's what we're choosing not to do yet and why. They build confidence through clarity, not volume.
Bad security leads either terrify the board or bore them. They present metrics without context, or they paint everything green until something breaks and the board wonders why they weren't warned. Neither builds the trust needed when they actually need board support for a hard decision.
Good security leads make the company more capable after working with external partners. When a consultant or firm helps with a pen test, a roadmap, or an architecture review, the security lead ensures the team absorbs the knowledge. The next engagement builds on the last one instead of starting from scratch.
Bad security leads outsource and forget. The pen test report goes in a folder. The consultant's recommendations sit in a slide deck. Six months later, the same gaps exist and the next engagement covers the same ground.
Good security leads know when they've outgrown the role, or when the role has outgrown them. They proactively tell the CEO: "At our next stage, you'll need someone with X experience that I don't have. Here's how we plan for that." They build toward their own succession because they care about the program more than the title.
Bad security leads protect the role. They resist bringing in senior help. They avoid conversations about what the function needs at the next stage because those conversations might not include them.
