That sentence feels slightly strange to write because, looking at the things I have worked on over the last few years, there has never really been a single plan in the first place.
I tend to get involved in whatever I find technically interesting. I have worked on procedural systems, AI experiments, GPU computing, RF observation, benchmarks, games and developer tools. Usually I start because there is a problem I want to understand, a system I want to take apart, or an idea that seems worth testing.
Now, somehow, the next environment I am about to enter is cybersecurity.
It is not a field I would describe as my main area of expertise, and I still do not know exactly what I will be working on. I know the context, but not yet the shape of the problem that will eventually become mine.
That uncertainty is probably the most interesting part.
Most of my recent work has been self-directed. Even when the technical problem is difficult, I usually control a large part of the environment around it. I can inspect the code, change the architecture, redefine an experiment, discard an assumption and start again.
Working inside an existing organization and an unfamiliar domain is different. The systems and constraints already exist. People have knowledge that I do not have, and some of that knowledge may never have been written down anywhere.
So my first task will not be to arrive with answers. It will be to understand what is actually there.
That sounds obvious, but AI makes it easier than ever to create the appearance of understanding something very quickly. You can enter an unfamiliar field, learn the terminology, generate an architecture and sound reasonably informed within a very short time.
That is useful, but it also creates a trap: the faster you can obtain plausible answers, the easier it becomes to forget which parts you actually understand.
I want to pay attention to that distinction.
I want to know what I have observed directly, what comes from domain experts, what is documented, what I am inferring and what an AI system is filling in for me. In several of my projects, separating evidence from assumptions has become almost as important as the implementation itself. I am curious to see whether that discipline transfers to day-to-day work.
There is another reason I want to document this experience.
I have always been much closer to a generalist than a specialist. I like moving between fields, opening systems I do not understand yet and learning enough to start doing something useful with them.
Cybersecurity gives me a different test.
How much of the way I work actually transfers when the domain is not mine?
Can experience with software architecture, debugging, AI agents, infrastructure, data and experimentation compensate for missing domain knowledge at the beginning? Which skills transfer immediately, and which ones turn out to matter much less than I expect?
There is also the opposite question: at what point does being a generalist stop helping?
Some fields contain years of accumulated specialist knowledge that cannot simply be reconstructed from first principles every time. Cybersecurity certainly has plenty of that.
The interesting part for me will be finding the boundary between the two.
I do not want to pretend that knowing how to learn quickly is equivalent to already knowing a domain. At the same time, entering from the outside may make some different questions easier to ask.
I simply do not know yet which effect will dominate.
And that is why I wanted to write this before starting rather than afterwards.
Technical articles are usually written once the uncertainty has disappeared. We explain what happened with the benefit of hindsight, and the path inevitably looks cleaner than it really was.
Right now I do not have that advantage.
I do not know what the first problem will be. I do not know which parts of my existing experience will matter. I do not know how much cybersecurity knowledge I will need before I can contribute meaningfully.
This is the baseline.
In a few months I should be able to come back to it and compare these assumptions with what actually happened.
Maybe being a generalist will make the transition easier than expected. Maybe some parts of the domain will resist that approach completely.
Most likely, it will be a mixture of both.
Either way, this time I get to run the experiment outside my own laboratory.
Top comments (0)