Engineering Philosophy

I treat endpoint engineering as software engineering. These are the principles behind how I build — each one earned on a fleet of ~300,000 Windows endpoints, where the gap between a script and a product is measured in thousands of devices and millions of dollars.

Build products, not scripts

A script solves a problem once, for the person who wrote it. A product solves it for everyone, repeatedly, with the author out of the loop. WHAT started as 30+ scattered PowerShell scripts and became a single documented, versioned framework the support organization still runs — because the goal was never "fix this," it was "make this un-break for the team."

Automate the work out of existence — then measure it

The point of automation isn't a faster ticket queue; it's an empty one. Drift-remediation tooling and proactive Intune configuration profiles cut support-queue volume ~65% by resolving problems before they ever became tickets. If I can't measure the outcome, the work isn't finished.

Self-service scales; manual support doesn't

At ~300,000 endpoints, any process that needs an engineer in the loop is a bottleneck waiting to happen. Kiosk Overseer and Portal Maker turned specialist tasks — hand-authoring Windows Assigned Access XML, building branded device portals — into guided workflows that non-engineers run without me. The best tool I can build is one that makes my involvement unnecessary.

Favor maintainability over cleverness

Clever code is a liability the moment someone else has to change it. I write for the engineer who inherits the tool six months from now — clear over compact, obvious over impressive. Cleverness is a cost the whole team pays later so one person could feel good today.

Documentation is part of engineering, not an afterthought

A tool nobody can operate without me isn't finished — it's a dependency on me. Everything I ship is documented and built to be handed off, which is why diagnostics tools like WinDAS and PULSE are run daily by engineers I've never met. Undocumented work doesn't scale past its author.

Developer experience is a business outcome

The fastest way to raise a team's output is to remove friction from how they work. Standardizing the team's GitHub workflows and building GitHub101 moved an operations-heritage organization onto real version control and peer review — raising the floor for everyone, not just closing one ticket. Enabling other engineers compounds; solving problems solo doesn't.

AI augments engineering; it doesn't replace judgment

I build with AI-assisted development to move faster, but the engineer owns the outcome. Card Forge drafts INVEST-compliant Jira stories with AI and routes every one through a human approval gate — the model proposes, an engineer decides. Responsible AI in engineering means the human stays accountable for what ships.

Measure success in business outcomes, not activity

Lines of code and tickets closed are activity, not impact. The numbers I care about are the ones a director recognizes: ~8,000 devices rescued from an unrecoverable state, an estimated $15.7M–$28M in hardware replacement avoided. Engineering that doesn't move a business number is a hobby.

See these principles in the work

Every project on this site is a product built the way described above — problem, solution, and measurable impact.