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, GRC?" 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 Computer Networking and CIS students wouldn't have to relearn the program's lab environment from scratch. In early 2025, I built IAMulator, an agentic-AI tool that turned plain-English requirements into least-privilege AWS IAM policies. Within two months, it had been used across multiple AWS Professional Services customer engagements and was estimated to help other ProServe consultants cut IAM policy development time by roughly 75%.

Different problems, different technologies, different employers — different decades. Both are mine, but until pretty recently even I couldn't tell you what connected them.

## "Pick a lane"

If you spend any time around security consulting, you hear the same advice, and it's good advice: pick a lane (domain, specialty, etc.). The people who thrive can answer "what do you do?" in a word or two — cloud, AppSec, incident response, threat intel, agentic AI (lately). A lane gets you staffed and referred, and it's what a recruiter's keyword search matches on.

The formal side of the industry works the same way: NIST's NICE framework breaks cybersecurity work into named Work Roles, and the certification bodies map their credentials to the same list.

## How I read my own record

I never had the specific answer. My history reads like scatter: virtualization labs, then managed security for 10 client organizations with 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 — touching all of the above again, plus 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. While I was telling myself I didn't have a lane, I knew I'd accomplished things that proved I had... something. 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 bought that conclusion for a long time.

## The artifacts, side-by-side

What changed my mind was ignoring the job titles and lining up the things I built — worth trying if you can't name your lane.

At AWS, there are many internal security-review processes that every consulting engagement goes through. For one type, 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 — and wrote iSQA, a Python analyzer with hundreds of context-aware patterns that made those calls the way a reviewer would. The backlog cleared in about a week. The tool went on to eliminate 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: roughly a 500% throughput improvement over manual review. Across those reviews we surfaced and mitigated 190 threats and 100 vulnerabilities. Handed off.

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 — and when what changed is the pipeline itself, everything gets rescanned. Validation went from two weeks to about two to four hours, and the change detection alone cut CI costs 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. The alerting I needed didn't exist, so I built it: Splunk dashboards, alerting logic, and ETL pipelines across all three. Proactive threat hunting became practical, and mean time to respond dropped — by about 70%, we estimated.

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, 874 network resources — and built a Streamlit planning tool alongside it, because subnet planning at that scale eats weeks by hand. AWS published the pattern as public Prescriptive Guidance, and the code went to aws-samples.

The ESXi guide was the same move, years earlier: a lab environment each new group had been relearning from scratch, documented once, then handed to whoever came next — including our written admission that the ideal student-permissions scheme never quite stuck.