The notebook
The room was full of people getting a company ready for a government compliance audit, and I was one of the assessors. A technical lead started walking us through telemetry across their cloud operations, and I lost the thread almost immediately. It sounded like rocket science. I had the compliance framework cold; the technology it was supposed to govern might as well have been narrated in another language.
So I did the only thing available to me. I took detailed notes. Not to fake comprehension in the meeting, but so I would have a syllabus for later. I did not know it at the time, but that notebook was the whole career plan.
The paper years
I got my start on the policy and compliance side of security. My first job out of college put me in London, helping companies classify encrypted technologies for export controls and apply for trade licenses. I had never studied encryption. Nobody asked whether I had; the work was due. So the learning happened on my own time, one concept at a time, until the paperwork in front of me described something I could actually picture.
The loop closed for the first time in a job interview later on, when someone asked me to explain PKI and I could. Assess it, then go learn it, then come back better at both. I did not have words for the pattern yet. I just knew the interview went differently than it would have gone a year earlier.
From prototype to production
Back stateside, I landed as a program manager over a SaaS product, which was my first real exposure to anything cloud. I was responsible for a team of offshore .NET developers and for a supply chain risk assessment application I did not build and could not have built.
That job taught by necessity, which is the fastest teacher there is. I taught myself the difference between agile and waterfall because I could not run a team without knowing it. I learned what a load balancer was for, and why a website certificate has an expiration date, through conversations with our hosting provider that started as logistics and ended as an education. Then I stood in front of trade show crowds and demoed the product live, as the lead.
I was not yet assessing technology and I was certainly not building it. I was accountable for it, which is its own kind of exposed. You cannot hide behind a framework when the demo is live and the questions are real.
Up to then, everything I knew had been a prototype. It worked in controlled conditions, on paper, against questions I got to choose. This was the job that pushed it into production.
Moving toward the gap
Then came audit work, and audit made the gap impossible to ignore. I was assessing technologies I had never operated, writing findings about systems I could not have configured, rendering judgments on work I had never done. Plenty of people in governance, risk, and compliance know this feeling. Almost nobody says it out loud.
What I started doing, without ever calling it a strategy, was moving toward whatever I felt least qualified to judge. Certifications first, then cloud training, not for the frames on the wall but for the vocabulary, so the next technical lead who talked telemetry would be speaking a language I could at least read.
The certifications did more than expected. One of them, a tough cloud cert, carried me into my first role with the word engineer in it, and the title arrived well before the experience did.
The room that rearranged something
I remember sitting in a room full of people with far more technical depth than me, years of it, all of it on-prem. Then the strangest thing happened: I was the one explaining. Cloud computing was new country to them, so I reached for analogies, translating virtualized environments into the on-prem terms they had spent careers mastering, until it started to land.
I had walked in feeling like an imposter, the least qualified person at the table by any resume math, and I walked out understanding that everyone at the table has a gap; mine was just the one I could see. Imposter syndrome is a measurement error. It counts your gaps and nobody else's. The veterans were not frauds for not knowing cloud, and I was not a fraud for knowing it only from study. We were all mid-syllabus on something.
Week one
That cloud track eventually took me into a senior consulting role focused on cloud security, and the work started before the onboarding finished. In my first week, a lead asked me to get to a healthcare client. The team I had been hired to work alongside was overseas on another engagement. So I went alone, ran the assessment, and wrote the report: key findings, what was already working, and what I called opportunities for improvement rather than weaknesses.
That phrasing was not softness. It came straight out of the paper years, where I had learned that a finding lands better when the person receiving it can act on it without first defending themselves. The technical work was new to me. The craft of delivering an assessment was not. The kudos that came back were for the second thing as much as the first.
The other side of the table
Years later I was supporting a large identity and access program, and I owned its compliance and audit work. Which put me across from third-party auditors, and on the opposite side of the table from where this essay started.
They arrived with a checklist. Generic questions, written for systems that were not ours, aimed at a stack they had not been briefed on. So I walked them through it: the systems of record, the data integrations, how single sign-on and multifactor sat next to identity governance and privileged access, which sources were authoritative and which were downstream. Not to dodge anything. To get the questioning pointed at what was actually in scope, so the audit would find real risk instead of paperwork mismatches.
Somewhere in the middle of that, I realized I had become the person who could have helped the version of me from the first scene. The guy taking notes he did not understand had turned into the guy who could explain the stack to the people holding the checklist. Same table. Other chair.
The floor
Then the bigger move: I volunteered into an advanced security operations center. It is the same logic as starting out on a help desk, the classic on-ramp, except the stakes on a SOC floor are live. Tier 1 is a humbling place to stand when your entire incident response experience is certifications. The first time I sat in front of a real alerting dashboard, every credential I held got very quiet.
That is where the real learning happens, in the tiers. Alerts do not care what the framework says. They care whether you can tell signal from noise, at volume, under time, with consequences.
The seat
About a year into SOC shifts, I was asked to train a new joiner on the triage process. I was mid-explanation, walking a new analyst through the same queue that had humbled me, when the distance registered. A year earlier I had never touched an alerting dashboard. Now I was the one teaching the floor.
Nobody granted that seat. It accreted, shift by shift, note by note, out of every gap I had walked toward instead of around.
These days the work is Zero Trust architecture with a focus on securing Agentic AI, which is to say: the newest work I feel underqualified to judge. So the method is running again, in public, right now. I have been building my own threat-model reference for agentic systems against the OWASP AI Exchange (opens in a new tab) body of knowledge, taking hands-on training on attacking LLM applications, and chasing a certification track that did not exist a year ago. Same notebook, new syllabus. At this point, that is the method.
How to learn
Here is the part I would go back and tell myself in that first audit meeting.
In a technical field, the specific facts have a half-life. The console you memorized has been redesigned twice since. The exam objectives you drilled describe a service that has been deprecated, renamed, or absorbed. If what you acquired was a set of answers, you are already expiring. Anyone who has recertified knows this feeling.
What compounds instead is knowing how you learn. Where you go first. How fast you can get from "this sounds like rocket science" to a working mental model. Whether you can sit in a room, not follow it, and take useful notes anyway instead of shutting down. That skill did not show up on any of my certifications, and it is the only thing that has transferred across every role I have described here, from export controls to load balancers to alert triage to Agentic AI.
Notes are the opening move, not the whole game. There is a point in most of those meetings where the more useful thing is to put the pen down, look up, and actually listen. Then ask the question that reveals you are lost. That costs something in the room. It is still faster, because a note preserves your confusion perfectly while a good question dissolves it.
The certifications were never the knowledge. They were scaffolding, put up so I could reach the work, and taken down once the work held its own weight.
For the paper side of the house
If you work in GRC or audit and you carry that quiet feeling, assessing technology you have never touched, I want to name it for you, because naming it was the thing nobody did for me. The gap is real, it is common, and it is not a verdict. It is a syllabus.
You do not need a new title or anyone's permission to start closing it. Take the notes in the meeting you do not understand, then put the pen down and ask the question. Build the lab. Volunteer for the floor, even at the bottom tier, especially at the bottom tier. Assess it, then go learn to do it, then come back better at both.
And do not write off the paper years while you do it. Policy taught me what the controls are for. The floor taught me how they fail. Both sides taught me how to deliver a finding someone can actually use. The most useful seat at any table is the one built from both sides of it.
There has been a motto on this site's front page for a while: builders, not browsers. It turns out it was a career strategy before it was a slogan. There is a second one, trust but verify, and the arc above is just that rule pointed inward. I stopped trusting my own assessments until I could verify them with my own hands.
That habit matters more right now than it ever has. The newest systems do their work at machine speed, and the human's job is direction, review, and the final word. You earn the right to command the machines the same way you earn the right to assess anything: by learning the work yourself.
Humans in Command. Bring a chair you built.
Further reading: the OWASP AI Exchange (opens in a new tab), and Measuring Security, a 2019 piece from the paper years about counting what matters.