Read the opening of chapter 1
The opening of chapter 1, exactly as printed.
Chapter 1: The Fork at Eight Years: IC, Management, or CISO
Around year eight, something changes that nobody puts on a calendar. You stop getting promoted for being good at the job you already have. The skills that got you from Tier 1 through senior analyst — fast triage, clean forensics, a nose for the alert that actually matters — stop being the thing that moves you forward. What moves you forward now is a choice, and the dangerous part is that you can drift past it without ever making it. Take the first management opening that comes open because it's flattering to be asked. Stay heads-down on the tooling because it's comfortable and the org keeps giving you raises for it. Either one can happen to you instead of being decided by you, and five years later you're in a role you didn't pick, wondering why it doesn't fit.
There are three real paths past this point, not two. Most career content collapses the choice into "stay technical or go into management," as if management were the only door out of the IC track. It isn't. The three paths are staying a deep technical individual contributor, moving into people and operations management, and aiming specifically at the CISO seat. That third one is not simply "management, but longer." It's a different job with a different skill floor, and conflating it with a Security Manager promotion is how competent people end up two rungs up a ladder that was never going to get them where they wanted to go.
The technical individual-contributor track past senior analyst is a legitimate destination, not a failure to get promoted. Principal Security Engineer, Distinguished Engineer, staff-level threat hunter, detection engineering lead: these titles exist because organizations that actually understand security know that a room full of managers with no one left doing the deepest technical work produces mediocre security. The mistake at this stage isn't choosing to stay technical. It's staying a generalist while doing it.
Keep readingShow less
Generalist depth stopped compounding somewhere around year five. What compounds now is a specialization, and the specific lane you pick is itself the strategic decision, not a consolation prize for skipping management. Cloud security, penetration testing, vulnerability management, and digital forensics are the four lanes that show up again and again as the ones senior analysts actually convert into accelerated advancement. The mechanism is straightforward: a generalist senior analyst competes against every other generalist senior analyst for the same generalist-senior-analyst roles, while a genuine cloud security specialist with three years of IAM-and-workload-protection depth competes in a much smaller pool for roles that pay a premium precisely because that pool is small.
The GRC world makes this fork explicit in a way worth studying even if GRC isn't your lane, because the same split exists inside every specialization whether the job titles admit it or not. GRC analysts write reports; they document control status, they run audits, and their output scales linearly with headcount, so twice the compliance scope needs twice the analysts. GRC engineers build the automation that validates those controls continuously: policy-as-code, scripted configuration checks, pipelines that catch drift in real time instead of at the next quarterly audit. Their output scales with the automation they've built, not with hours worked. That's the actual reason GRC engineers get pulled into architecture conversations while GRC analysts plateau at the same title for years. One role's leverage grows with the org; the other's doesn't. The same split exists in threat hunting, where the analyst running known playbooks against known TTPs sits on one side and the analyst writing new detection logic that becomes the playbook sits on the other. It exists in vulnerability management, between the analyst triaging the scanner's output and the one tuning what the scanner catches and automating the remediation routing. It exists in forensics, between case work and the tooling that makes case work faster for everyone after you. If you're choosing the IC path, don't just ask which domain. Ask which side of the automation line in that domain, because that's the line that decides whether you're still doing this exact job in five years or running the team that does it.
The AI era has opened a second fork inside the IC track that didn't exist three years ago, and it's worth naming precisely because it's easy to conflate the two halves. One specialization is using AI to run security better: deep fluency with autonomous investigation agents, natural-language query interfaces over SIEM data, and the judgment to know when an AI-generated incident summary is trustworthy enough to act on and when it needs a second look. The other is securing AI systems themselves: understanding how models get poisoned or evaded, what a defensive-distillation pipeline actually buys you, how adversarial training changes a model's decision boundary. These sound adjacent. They aren't, and the gap between them is wider than most people choosing at year eight assume.
The first track is an extension of the SOC command you already have. Your existing instincts about false positives, alert fatigue, and where automation quietly gets things wrong transfer almost directly; you're learning a new interface onto a familiar problem. The second track is a career restart disguised as a lateral move, and it's worth being honest with yourself about what "ramping up" concretely means before you commit to it. You need enough MLOps fluency to read a training pipeline and understand where a poisoning attack could actually insert itself: which stage ingests untrusted data, where validation happens, what a retraining cadence looks like in production. You need enough working statistics to understand what a differential-privacy budget is trading away, not as a definition you can recite but as a tradeoff you can reason about when a data science team wants to loosen it for better model accuracy. You need to be comfortable evaluating an evasion attack against a specific model architecture versus a poisoning attack against its training data, because the defensive playbook for each is different: adversarial training and input detection blunt evasion at inference time, while data validation pipelines and provenance controls are what actually stop poisoning, and conflating the two in front of an ML team will cost you credibility fast. None of this is a weekend of reading. It's realistically a year or more of deliberate, structured exposure, likely including hands-on work in a framework like PyTorch or TensorFlow that has nothing to do with any SIEM you've ever used. Picking this path at year eight is a genuine career bet on where the discipline is heading, not a light upskill, and it should be made because you've done the diagnostic work above, not because a job posting mentioned "AI security" and it sounded current.
