I turn “could AI help us with this?” into something that actually works.
Nineteen years across education and enterprise IT, now focused on turning operational problems into practical, well governed AI solutions. I work the whole cycle: understand what a team actually needs, write the brief, then build, test, document and support the result myself. Claude, ChatGPT and Microsoft Copilot are daily working tools, and I am just as comfortable saying when AI is not the answer.
The best answer I ever gave to “could AI help us with this?” was no. An automated alert had stopped firing and the obvious move was smarter logic. Measuring it first showed the job was scanning five days of data while the analysis behind it assumed sixty. Nothing was wrong with the logic. It was one configuration value.
So what do you actually do?
I sit with the people who have the problem, work out what they actually need, and build the thing that solves it. Sometimes that is generative AI doing real work every day. Sometimes it is a script, a process change, or one line of config. Knowing which is which is most of the job, and it is why the things I ship tend to still be running a year later. Everything I build reports on itself, so I hear about it the moment it stops earning its place.
Scheduled agents handling work that used to be manual: receipt intake, expense reconciliation, inventory, reporting. Each one is specified before it is built, tested with the person who will use it, and documented so it can be handed over rather than only understood by me.
The most useful thing I bring is a willingness to say no. Plenty of problems that arrive labelled as AI problems are a config value, a broken assumption, or a process nobody has written down. Diagnosing that first is cheaper for everyone and builds the trust you need for the cases where AI genuinely is the answer.
Least privilege and read-only service accounts by default, strict separation between organisations, no credentials in source control, and a clear line about what data is allowed near which tool. Written down, not assumed.
I once shipped a release where every automated check passed and the application opened completely broken. The check that should have caught it had a blind spot. I now validate a safety check against a known bad input before I trust it, because a green tick you have never tested is decoration, not assurance. The same question applies to AI output: not does this look right, but how would I know if it were wrong.
Anthropic Claude, OpenAI ChatGPT, Microsoft Copilot. Prompt engineering, evaluation and testing, safe adoption and usage policy.
Requirements gathering, solution briefs, workflow design, user testing, documentation, training and adoption support.
Python, PowerShell, bash, REST APIs and integrations, scheduled jobs, telemetry and self-monitoring.
Microsoft 365, Entra ID, Exchange Online, SharePoint, Active Directory, Graph API, data governance and security.
Jamf (Mac, iPad, iPhone), fleet deployment at 1,000+ scale, imaging, asset and lifecycle management.
Server maintenance, LAN/WAN, Zoom Rooms, digital signage, automated AV fault detection.