My Lane Is a Method

If you can answer that with specificity and confidence — great. That's valuable and I'm happy for you. But this post probably isn't for you.

If you can't, keep reading. You're not alone.

For a long time, my answer was a generic "Cybersecurity." Then the follow-up: "Nice — which domain do you have the most experience in? Risk management, network security, IAM?" My answer? "Yes."

In late 2015, while employed in a work-study role, I co-authored a 51-page VMware ESXi reference guide so the next group of networking and cybersecurity students wouldn't have to relearn the program's lab environment from scratch. In early 2025, I built IAMulator, an agentic-AI tool I published internally for my fellow AWS Professional Services (ProServe) consultants: you paste in an IAM policy and it audits it, or you describe what you need in plain English and it writes the least-privilege policy, with its justification, its assumptions, and any questions it still has attached.

Different problems, different technologies, different employers — nearly ten years apart. Both solutions were built by me, but for a long time I assumed conflicting "lanes" of things I'd built didn't belong on the same résumé, or in the same job application.

## "Pick a lane"

If you're early in your career in the cybersecurity field, you're certain to hear this advice: pick a lane (domain, specialty, etc.). Don't get me wrong, it's good advice if you have a clear career trajectory. People who thrive are often able to answer "what's your lane?" in a word or two — AppSec, networking, incident response, threat intel, threat hunting, GRC. Having a "lane" supplies your résumé with exactly what a recruiter's keyword search will match on.

The lane idea is formalized, too. NIST's NICE framework breaks cybersecurity work into named Work Roles, and the major certification bodies map their credentials to that list.

## How I read my own record

I never had the specific answer. My history doesn't line up neatly: virtualization labs; then managed security at KIOSK Information Systems for 10 client organizations and 10k+ endpoints, many of them unattended kiosks (effectively IoT); then network security and detection engineering at Zayo, a fiber provider; then cloud security consulting at AWS, which touched all of the above again and added GenAI/LLM and agentic-AI security. Whenever I tried to answer the "what's your focus?" question honestly, my answer ran long. For years I chalked that up to too much breadth and not enough depth.

The record was fine, though. I'd built things that worked and were still in use after I left. The industry hands you a list of subject-matter lanes, you look for yours, and if it isn't there you conclude you don't have one. I believed that for years.

## The artifacts, side-by-side

What changed my mind was ignoring the job titles and lining up the things I built. If you can't name your lane, try it: list what you actually made (tools, docs, pipelines, whatever people kept using after you left) and ignore what the job was called at the time. Then look for the move that repeats. Mine are below.

At AWS, every consulting engagement goes through internal security reviews. For one type, the engagement security questionnaire, reviews were piling up faster than the small Engagement Security team could clear them. The backlog was more than a year deep. I reverse-engineered what reviewers were actually deciding: which answers flagged real gaps, and which were acceptable in context. Then I wrote iSQA, a Python analyzer with hundreds of context-aware patterns that made those calls the way a reviewer would.

Most of the work came after the first version ran. Pattern-matching a questionnaire mostly produces false alarms, so the patterns had to learn the things a reviewer knows without thinking: a conditional question that doesn't apply, AWS-internal infrastructure that's acceptable by definition, instructional text that isn't an answer at all. The backlog cleared in about a week. The tool went on to save an estimated 3,000 review hours a year, and I handed it off.

On a telecom engagement, nine development teams were generating raw scanner output faster than anyone could consolidate it. I wrote ASHparser to do the consolidating: it turns the Automated Security Helper's output into one developer-readable report instead of a pile of them. The developers using it estimated it made that work about five times faster than working from the raw output. Across 18 security reviews of those teams' deliverables, we found and fixed roughly 190 threats and 100 vulnerabilities.

A financial-services platform's security validation took two weeks per release, mostly because the CI pipeline ran every scanner against everything and died whenever any single tool failed. I rebuilt it as 15+ independent scanner jobs that run against only what changed. The one exception is deliberate: when what changed is the pipeline itself, everything gets rescanned, because the change most likely to hide a mistake is the one I just made to the checker. Validation went from two weeks to about two to four hours, and the change detection cut CI costs by an estimated 40–60%. That one's written up elsewhere on this site.

At Zayo, answering many security questions meant pulling logs from the firewalls, email security, and the EDR separately. There was no alerting across the three, so I built it: Splunk dashboards, alerting logic, and ETL pipelines. Proactive threat hunting became practical, and mean time to respond dropped by an estimated 70%.

When an enterprise customer needed IP address management across six AWS Regions and there was no existing pattern to copy, I automated it end-to-end in Terraform, 67 hierarchical pools, and built a Streamlit planning tool alongside it, because subnet planning at that scale takes weeks by hand. AWS published the pattern as public Prescriptive Guidance, and the code went to aws-samples.

The 2015 ESXi guide was the same shape. Each new group had been relearning the lab environment from scratch, so we documented it once and handed it to whoever came next. We also wrote down, in the guide, that the two-role vSphere permissions scheme we wanted (one role on each student's own VMs, a read-only group role on everything above them) never quite stuck between logins.

In early 2025, consultants were hand-writing least-privilege IAM policies from customer requirements, which is slow and easy to get subtly wrong. IAMulator has two modes: turn a plain-English requirement into a least-privilege policy, or take an existing policy and find the excess permissions, including policies the first mode just wrote. It runs inside AWS's internal guardrails for GenAI use. Within two months it had been used on at least seven ProServe customer engagements, and the consultants using it estimated it cut IAM policy development time by roughly 75%.