In June 2025 I published my Strategic AI Career Roadmap (2025-2028+).
I am not going to rewrite that post. It should stay where it is, because it records what I knew at the time.
AI looked like a jungle then. Endless concepts, courses, models, frameworks, job roles, and no clear taxonomy. I needed a map before I could move with confidence, so I built one.
Looking at that roadmap now, I am actually surprised by how well most of it worked.
The foundations were right. The sequence was mostly right. The decision to first build AI literacy, then add the business perspective from Berkeley, and then specialize around Red Hat AI turned out to be a very good one.
More importantly, I look at where I was when I wrote it and where I am now, and I am impressed by how much changed. I entered that jungle barely knowing how to classify what I was looking at. Today I work with AI platforms, customers, engineering teams, product management, new product capabilities, real deployments, and the problems that appear when all of this meets production.
The roadmap helped me become somebody very different inside this world.
Where it became less accurate was exactly where I would expect it to: the further into the future I tried to see, the more the roadmap became educated guessing rather than a plan based on evidence.
Now I have more evidence.
So this is V2.
The Information I Did Not Have in 2025
When I wrote the first roadmap, I was trying to answer a question I could not yet answer:
Where exactly do I want to sit in AI?
At that point the safest answer was breadth. Learn the foundations. Understand ML. Understand deep learning. Add mathematics and statistics. Refresh Python. Go deeper later, perhaps as far as the MIT Statistics and Data Science MicroMasters.
That was reasonable because I did not yet know which parts would matter most.
The following months changed that.
In 77 Days Later I was still building the mental map. I had gone from almost no taxonomy to a reasonably coherent model of ML, neural networks, transformers, LLMs, RAG, evaluation, and the wider AI landscape.
Then Berkeley Haas added another lens. As I wrote in From Self-Study to Executive Lens, it did not teach me “more AI” as much as it changed how I evaluated AI: value, constraints, feasibility, adoption, operating model, and business outcomes.
Early 2026 shifted the center again. I went deep into OpenShift AI, passed EX267, and deliberately moved from studying the product to touching it. In OCP AI: Field Notes After EX267 I wrote that the next phase had to be hands-on: deploy things, break them, fix them, read documentation against logs, and write code on purpose.
Then the work itself accelerated that transition.
Customer engagements, close cooperation with engineering and product management, working across multiple teams, presenting new OpenShift AI capabilities, and solving real problems gave me something no roadmap could give me in advance: a much clearer idea of the kind of AI specialist I want to become.
I feel strong in this space now.
Not finished. Not remotely finished.
But no longer wandering around trying to identify where the ground is.
I Do Not Want to Build Foundation Models
This is the biggest simplification.
I want to understand AI deeply. I want to understand what models do, where they fail, how inference works, how models are served and optimized, how RAG, agents, evaluations and guardrails work, and what happens when the application reaches production.
But I do not currently want to become a researcher building foundation models.
I want to use AI to build systems that solve problems.
That changes the critical path.
The original roadmap put mathematics, statistics, ML and deeper data science on the road toward greater specialization. Those subjects are still valuable. I still respect them. Some of them are probably more durable than half the product features I learn at work, which was exactly the tension I described in What Stays, What Goes.
But valuable does not mean highest priority.
Time is the constraint.
Right now another year of preparation would cost me something more important: a year of building.
AI as Electricity
There is an analogy here that I owe, at least partly, to Kai-Fu Lee.
When I was carefully working through AI Superpowers, his framing of technological revolutions stayed with me. I kept thinking about electricity in particular.
The invention itself mattered enormously. But so did the long period after it, when people started discovering what electricity could actually do. New products. New processes. New companies. Existing industries rebuilt around a new capability.
I still think that is one of the better comparisons for AI.
I am not trying to build the generator.
I want to understand the electricity extremely well, then become good at seeing where it can create value and how to engineer that value into something real.
That requires technical depth, but it also requires a business lens.
The question cannot only be:
What interesting thing can I build with AI?
It also has to be:
What problem is worth solving, and does AI actually make the solution better?
That is a different way of looking at the same technology.
The Next Six Months: Close the Gaps and Shift to Building
The next phase runs roughly from now until April 2027.
It is not six months of preparation followed by building.
It is the transition period in which I close the remaining gaps while steadily changing the ratio from learning about systems to building and operating them.
By the end of this phase, I want hands-on work to dominate this development track.
1. GitHub as Workshop and Scoreboard
I know that visible progress works very well on me.
James Clear’s paper clip strategy in Atomic Habits is a simple example of the mechanism: make progress visible, and every completed repetition provides a small reinforcement. I already use a similar idea with lists and whiteboards. Crossing something out works on me disproportionately well.
I want to use the same mechanism for building.
The plan is to start using GitHub Projects alongside the code I create. I have not used it seriously yet, so I am deliberately not designing some elaborate workflow before I understand the tool.
For now the idea is enough:
GitHub should become both the workshop where I build and the scoreboard where I can see that I am moving.
Projects, issues, experiments, ideas, completed work.
A growing visible history of execution.
If the tool fits me the way I expect it to, that matters.
2. Build Things That Are Allowed to Fail
This part is important because I have done it before.
Years ago I built worldofmma.pl.
Nothing important came from it as a business. But I learned an enormous amount because I had to create something real rather than complete isolated exercises.
I want that mechanism again.
The difference is that this time I do not want to look only through the technical lens.
A project can still fail commercially and be worth building. It can teach me architecture, coding, cloud, deployment, AI integration, observability, or how users behave.
But I also want to start asking questions I largely ignored back then:
Does anybody actually need this?
What problem am I solving?
How painful is that problem?
What is the value of removing it?
Can I test the assumption before building too much?
The goal is not to find the perfect idea before writing code.
The goal is to get into repeated loops of building, testing, learning, and correcting.
3. Add Real Cloud Competence
Most of my strongest platform experience has been built around on-premises environments, OpenShift, and Kubernetes.
That remains valuable, but it is no longer enough.
Customers increasingly use cloud environments alongside their own infrastructure. Cloud platforms are also moving aggressively toward AI and ML workloads. And sometimes I simply need an environment where I can build or test something that is impractical in a constrained internal lab.
I want cloud to become another environment I can use naturally rather than something I conceptually understand from the outside.
I have already studied Google Cloud more than once, so I am going back to it and this time I want to finish the job.
The current target is Google Cloud Associate Cloud Engineer.
The certificate gives the learning a structure, but the actual objective is practical competence: being able to use a cloud platform comfortably when the problem calls for it.
4. Connect More Dots Around MLOps and GenAIOps
AI501 in Belgrade was particularly useful because it connected many things I had previously understood separately.
The course approached the stack from the application code perspective. During one week we worked continuously on a solution involving LLMs, RAG, MCP, an agent using OGX, evaluations, guardrails and MaaS, while also quantizing models and fine-tuning with LoRA.
Git, Argo CD, test and production environments, Tekton and Kubeflow Pipelines tied the pieces together.
That complete workflow was the important part.
It exposed several smaller gaps too. Helm, PromQL and Grafana deserve more deliberate hands-on work. Tekton and Argo CD need less. I understand their role much better now, so a focused lab, some repetition and a few flashcards should be enough to make that knowledge durable.
I also want to close the MLOps side through AI500.
There is a useful opportunity here beyond doing another course individually. I want to see if I can organize AI500 and AI501 environments for a small group of other AI TAMs so that people can work through the material self-paced.
I am not planning to become the instructor.
The useful model is much simpler: get the environments working, coordinate the initiative, pair people where useful, and create enough mutual backup that when somebody is learning and gets stuck, another person is not starting from zero.
That gives me another pass through the material, strengthens MLOps where I need it, and makes the investment useful beyond one person.
The next course I also want to complete is AI510 - Serving Models at Scale with Red Hat AI Enterprise.
Its focus on model serving at enterprise scale, including vLLM, KServe, NVIDIA NIM, distributed inference with llm-d, Kueue and production monitoring, is directly aligned with the layer I want to understand more deeply.
5. Close Technical Gaps Without Turning Them Into New Careers
I have a short list of things that need work.
Helm is one of them. I avoided it for too long. It survived the test of time and it is everywhere, so I want enough practical experience that charts stop being something I merely read.
PromQL and Grafana are another. These need active use, not more passive reading.
Tekton and Argo CD are different. The conceptual gaps are much smaller now. I want to do focused labs, turn the important mental models into a few flashcards, and move on.
This distinction matters.
Not every knowledge gap deserves a six-week learning program.
Some need depth.
Some need one good afternoon.
6. Think About Business Earlier
Berkeley Haas made me much more sensitive to the business side of AI.
Before that, my natural instinct was heavily technical: what is interesting, how does it work, what can I build with it?
I still need that instinct.
But it needs a counterweight.
I have to get better at asking whether the problem deserves solving at all, where the value is, who benefits, who pays, what changes operationally, and whether AI is actually the right lever.
That is why The Personal MBA and The Mom Test are useful to me now.
The Personal MBA is helping me organize how I think about value creation and business systems.
The Mom Test attacks a different weakness: how to learn whether a problem is real without asking people questions that merely invite them to praise my idea.
This is not a separate “business phase” after technical mastery.
It has to run in parallel with building, because it should influence what I choose to build in the first place.
7. AI_devs as a Broader Engineering Lens
I also want to join the next AI_devs cohort.
Partly this is straightforward: more practical work should deepen my understanding of how modern AI applications are actually built.
But there is a second reason that matters professionally.
The users of AI platforms are increasingly developers, AI/ML engineers, data scientists and data engineers. As a TAM, understanding only product features is not enough. I need to understand what these people are building, what problems they hit, why they choose particular architectures, and what sits below the platform surface.
I want to go lower in the stack of their problems.
A practical development cohort is also useful for a simpler reason: it expands the horizon. Different people, different approaches, different assumptions, different ways of solving the same class of problem.
I do not want AI_devs to become the starting line, though.
I want to be building before it starts.
What Leaves the Critical Path
This is the part I remove with some pain.
For now, the deeper mathematics and data science track moves out of the active roadmap. That includes the MIT MicroMasters idea.
I still like it.
I still think mathematics and statistics compound in a way that short-lived product knowledge often does not.
I still hope I come back to it.
But I do not have unlimited time, and right now I do not want to spend that time preparing to build models when the role I increasingly see for myself is elsewhere.
This is not a judgment that mathematics is unnecessary.
It is a decision that it is not on my critical path right now.
If the work later exposes a real need for deeper probability, statistics, optimization or model development, I can return with a much better reason than “it seems like something an AI expert should know.”
For now, I need to build.
What Success Looks Like by April 2027
Success is not a longer list of completed courses.
I want to have done the things described above: strengthen cloud competence, close the specific technical gaps, deepen MLOps and GenAIOps, work through AI510, create useful learning infrastructure around AI500/AI501, broaden the development perspective through AI_devs if the cohort timing fits, and keep sharpening the business lens.
But the bigger test is the ratio.
I want dirty hands.
By the end of this phase, I want roughly 80% of my development effort to be hands-on: code, deployments, experiments, debugging, infrastructure, applications, evaluation, observing what works and correcting what does not.
Learning remains part of the system.
It just stops being the dominant output.
Updated Strategy Stages
The first roadmap tried to see several years into the future.
This time I want the near-term stage to be explicit and the next one to remain honestly unknown.
[ 2025 ]
|
v
+-----------------------------------------------------------+
| STAGE 0: AI Foundations |
| |
| AI literacy, taxonomy, books, courses, mental models |
| Status: completed |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| STAGE 1: Business and Strategic Context |
| |
| Berkeley Haas, value, feasibility, adoption, strategy |
| Status: completed |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| STAGE 2: Red Hat AI Specialization |
| |
| OpenShift AI, AI TAM work, customer engagements, |
| engineering and product collaboration, enterprise AI |
| Status: established and continuing |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| STAGE 3: Close Gaps -> Build |
| Oct 2026 - Apr 2027 |
| |
| - GitHub Projects as workshop and progress system |
| - Continuous hands-on projects and prototypes |
| - Google Cloud + Associate Cloud Engineer |
| - AI500 / MLOps |
| - AI501 environments and peer learning for AI TAMs |
| - AI510 / enterprise model serving |
| - Helm |
| - PromQL + Grafana |
| - Tekton + Argo CD focused labs |
| - AI_devs if cohort timing aligns |
| - Personal MBA + The Mom Test + business thinking |
| |
| Target: hands-on work becomes the dominant mode |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| STAGE 4: TBA |
| |
| Direction chosen from what Stage 3 teaches me. |
| Build more. Follow evidence. Reassess the next mission. |
+-----------------------------------------------------------+After April 2027: Clear Direction, Flexible Timing
I am not promising that every item above will fit neatly into six calendar months.
The goals are ambitious. I hope I have the energy to execute them at the pace I want. Some parts may take longer.
That does not bother me.
What matters is that the direction finally feels unusually clear.
I have a strategy, and the individual tasks now fit inside it rather than competing for attention as disconnected interesting things.
I wrote before about the relationship between the soldier and the commander.
The soldier was never my problem. Give him a mission he believes in and he will work.
The difficult part is giving him the right orders.
Right now, the commander has a plan that makes sense to me.
That clarity matters because when I genuinely understand why I am doing something, execution becomes much easier.
Stage 4 can wait.
First I want to execute Stage 3 hard enough that the next decision is based on evidence rather than imagination.
The Roadmap Changed Because It Worked
I do not look back at the first roadmap and think it was wrong.
Quite the opposite.
A surprisingly large part of it was right.
It gave structure to the period when AI looked like a jungle. It pushed me through foundations, business context and specialization. Those stages created the knowledge and experience that now allow me to make a more precise decision.
The weak part was simply distance.
Stage 0 was concrete because I was standing next to it.
Stage 4 was mostly a guess because I was trying to see years through fog.
Now I have moved far enough that part of the fog is gone.
The strategy has become clearer:
understand AI deeply, build with it, connect it to real problems, strengthen the engineering layers around it, and judge the work by the value it can create.
That is enough direction for the next stage.
Then I will look at the evidence and decide what comes next.