I've been doing IT for over a decade. Started as an intern in 2012 configuring Cisco phones, spent years on helpdesk and deskside roles at places like Michelin and Prisma Health, and for the last five years I've been a sysadmin at a law firm in Greenville, SC. Two-person IT team, just me and the CTO. About 85 users across three offices. Real production environment, real stakes, and somehow a Splunk cert and an Azure Fundamentals badge later, I find myself at the part of my career where I have to decide what comes next.

What comes next, I've decided, is most likely solutions engineering at an AI company. Or a legal tech company. Or a Microsoft partner. Somewhere in that neighborhood. And the reason I'm writing this post, the reason I'm starting this blog at all, is that I'm giving myself about a year to make that jump, and I want a public record of how it goes.

Here's the part that I think makes my setup unusual, and worth writing about. Most people teaching themselves AI right now are doing it from tutorials, side projects, and Hugging Face spaces. That's fine. It's how I learned a lot of things too. But I happen to be sitting inside a small IT shop where I share domain admin, lead the Intune and MDM rollout, own the PAM deployment, scope the password manager project, and have actual budget approval to experiment with AI tooling. My boss is supportive, the environment is small enough that I can ship things end-to-end, and the firm benefits from anything I build. That's not a bootcamp. That's a lab. And for the next year, I'm going to use it like one.

Where I'm starting from

A quick word on where I'm starting from, technically. CS degree, A+, Security+, the Splunk Certified Cybersecurity Defense Analyst cert, and AZ-900 as of this past March. Ten-plus years of hands-on work across helpdesk, deskside, AD migrations (I was on the Prisma Health team that moved 25,000+ users into a single domain back in 2020), Windows imaging, Intune/Autopilot, Cisco networking, and the general "you're the person who figures it out" role that small IT shops require. What I don't have, yet, is real Python. I can read it, I can modify it with AI assistance, but I can't sit down and architect a clean script from scratch. That's one of the things this year is for.

Why solutions engineering

So why solutions engineering? Honestly, because the job description reads like a list of things I already do, just in a different setting.

Solutions engineers translate. They sit between a product and a customer and figure out how to make the two fit. That's most of what I've done for ten years. Translating between systems and the people who use them, between vendors and end users, between what leadership wants and what's actually possible with the budget and the stack in front of me. Law firm IT is an especially good training ground for this because attorneys are not a forgiving audience. They bill in six-minute increments. They don't have patience for "let me Google that." You learn pretty quickly how to be calm, specific, and useful, or you don't last.

The other piece is that I genuinely like the demo side of the work. I like figuring out how to show someone a piece of software in a way that makes the value click for them. I've spent years doing the unofficial version of this: training users on new document management systems, walking partners through Office 365 changes, getting non-technical people comfortable with tools they didn't ask for. The formal version of that, with better software and a sales team behind it, sounds like a job I'd be good at and would enjoy.

The roles I'm targeting are Solutions Engineer, Sales Engineer, Forward Deployed Engineer, Customer Engineer, and AI Implementation Engineer. The companies are AI labs and AI-first startups, Microsoft and Microsoft partners, and legal tech (Harvey, Litera, iManage, NetDocuments, CoCounsel, and the rest of that ecosystem). I'm being specific about this on purpose. If a recruiter from one of those companies ends up reading this post a year from now, I'd rather they know exactly where they fit in the picture than have to guess.

The plan

I gave myself roughly a year of runway, with serious applications starting in spring 2027. That sounds like a lot of time. It isn't. I have a full-time job, a family, and a budget of about 13 to 18 hours a week for study, building, and writing. The plan has to fit inside that, or it doesn't work.

Here's the rough shape of it.

Now through late July 2026, fundamentals. I'm taking AI-103 (the Azure AI Engineer Associate path) at General Assembly and sitting the exam in late July. I'm also working through boot.dev's Python track on the side, roughly six to seven hours a week. The goal isn't to become a Python developer by August. It's to get fluent enough that I can read, modify, and reason about AI code without leaning on AI assistance for every line. I've been halfway through the AI-103 MSLearn path already, but I skipped the hands-on exercises the first time through. I'm restarting and doing them properly this round. Lesson learned: skipping the lab work to "save time" costs more time than it saves.

August through October 2026, project #1. An AI-powered offboarding runbook generator, built against Microsoft Graph API and Azure OpenAI. The problem is real and lives in my current environment: every time a user leaves the firm, there's a checklist of accounts, licenses, group memberships, mailbox forwards, and access reviews that has to happen, and the checklist drifts from reality faster than anyone can update it. A tool that pulls live state from Graph and generates a per-user offboarding plan is genuinely useful, scoped small enough to finish, and demoable in a way that maps directly to what an SE would build for a customer.

November 2026, AB-410 and a Power Platform project. AB-410 (Intelligent Applications Builder) is replacing the retiring PL-200, and a Copilot Studio / Power Platform mini-project pairs naturally with it. This is the cert that opens doors at Microsoft partners specifically.

December 2026 through February 2027, project #2. An internal RAG knowledge bot, built against the firm's documentation. RAG is the workhorse pattern of modern AI implementation, and being able to talk through one I actually built (chunking strategy, embedding choices, retrieval evaluation, the works) is probably the single most useful demo I can have in an SE interview loop.

February through April 2027, project #3 and a self-coded fundamentals project. Something agentic for project #3. I'm not committing to the exact shape yet, because the agentic landscape is moving too fast to plan that far ahead. Paired with a smaller, fully self-coded project to make the point that I can build things without AI assistance when the situation calls for it.

Spring 2027, start applying.

If a project slips by a month, it slips. I'd rather ship something solid than something on schedule.

Why in public

A year of self-study is easy to claim on a resume and almost impossible to verify. That's the problem this blog is meant to solve.

Everything I'm doing, the certs, the projects, the Python practice, is going to be logged publicly as it happens. The code lives on GitHub, with commits five or more days a week. The learning notes live in a public repo. The retrospectives, the project ship posts, and the inevitable "here's what I got wrong" posts will live here on dev.to. By the time I'm applying in spring 2027, a hiring manager won't have to take my word for any of it. They'll be able to scroll back through a year of dated commits and posts and see exactly how I work, how I think, and how I handle the parts that don't go well.

I'm also going to be transparent about something that I think more people in this position should be transparent about: I use AI assistance constantly. A lot of the code in these projects will be vibe-coded with Claude or Copilot in the loop. Some of it won't be. I'll be explicit in each project's README about which is which, because I think pretending otherwise would be both dishonest and increasingly easy to see through. The interesting question in 2026 isn't "did you write every line yourself." It's "do you understand what's there well enough to debug it, extend it, and explain it." That's the bar I'm holding myself to.

What's next

Next post goes up sometime within the next week.

If any of this resonates, or if you've made a similar jump and have advice I should hear, my GitHub is GitHub and I'm on LinkedIn at Linkedin. I'd genuinely like to hear from you.

Onward.