Teaching, upskilling, and adoption

The thing people keep recommending me for isn't any of the software in this portfolio. It's teaching, and specifically upskilling other engineers so they get measurably more effective.

That has become steadily more true across my career, to the point where it is now the through-line rather than a side effect. I did not set out to be the person who runs the curriculum. It kept happening, and eventually I noticed it was the part with the largest blast radius.

It is also the best-evidenced claim on this site, and not because I wrote it down. Twenty of the twenty-nine recommendations on my LinkedIn profile describe teaching, mentoring, or force multiplication. They span 2008 to 2025, and they come from the two people who managed me directly, engineers I was senior to, a client, colleagues on other teams and at other companies, and one senior data engineer I had never worked with at all, who I met in a LinkedIn comment thread and who wrote a recommendation about being mentored anyway. Nobody coordinated that.

The recognition is for adoption, not output

This is the distinction that took me a while to see clearly.

The Wall Street Journal piece and the GitHub Universe keynote were not about how fast I write code. They were about an engineering organization changing how it worked: 900+ repositories, an entire developer population moved onto Copilot, and a public case study about how it went. GitHub put a number on the result in its own marketing: developers writing Terraform config 50% faster.

You don't get that outcome by being the best engineer in the building. You get it by making several hundred other people better, and by removing the reasons they'd rather not change.

The record

Where	What
Coyote Logistics	Co-founded the DevOps Curriculum and mentored 30+ engineers through modernization and into Microsoft certifications. Not a lunch-and-learn: a curriculum, with an outcome you can verify against a certification registry.
Coyote Logistics	Drove Copilot adoption across a 900-repo org alongside the GitHub migration. Adoption, not procurement: the tool was the easy part.
Next Generation Logistics	Took over after the sole developer of 20 years passed away: nine customers, multiple .NET versions, zero documentation. Got 3.5 developers from 12 to 42 work items per sprint in six weeks, at a 95% PR success rate. The AI mattered, but the job was making a team competent in a codebase nobody alive understood.
Polaris Solutions	Interim development manager for 18 months over 23 people (development and QA) on a point-of-sale platform.
Metafora	Built the AI-agent developer toolchain (code index, hooks, devcontainer) so that agents start from the same context a new hire would get. It is onboarding infrastructure that happens to point at machines.
Community	Frequent speaker at .NET user groups, architecture panels, and Microsoft-sponsored events, including QUEST QAI 2016 and Dev Up 2016.

It's in the products, too

This is the part I only noticed while writing the portfolio down. Every project here does the same underlying thing: it makes something invisible legible, so somebody else can act on it. None of them are for me.

Helix exists because three people ask "is it done?" and mean three different things: the engineer means written, the PM means in front of users, QA means proven. A single percentage answers one and misleads the other two, so Helix reports all three and refuses to average them. It also mines four years of history backwards, so a team that has never heard of it can start today rather than "next project."

INTERLOCK puts the roles directly in the interface: the Conductor decides whether an amber override goes through and signs it; the Engineer drives the consist through the dark deploy; the Yard worker unblocks the blocked ones. Then it ships a dev control panel that lets you drive the failure modes on purpose: knock CI red, take the flag control plane down, reject the next migration, hold the main line busy. It's a flight simulator for releases. You learn the unhappy paths before production teaches them to you.

Cloud Topology Toolkit turns a four-thousand-line terraform plan into a picture a reviewer can actually approve, and draws the hops Azure performs but never declares as dashed, "not in plan." It would be easier to draw a confident solid line. That would also teach people something false.

Runnin' Mules! has a four-step first-time-player tutorial built from the splash art, because a game nobody can figure out in twenty seconds is a game nobody plays.

The principle underneath

My fourth rule for working with agents is make the system say when it doesn't know. null means unmeasured, 0 means measured, and the answer is zero, and those two must never render the same way.

I wrote that down as an engineering rule. It's really a teaching rule. The fastest way to make somebody worse at their job is to hand them a number that is confidently wrong, and most delivery tooling is confident precisely because it has stopped checking. A system that admits its own gaps teaches the person using it where to look. One that papers over them trains learned helplessness.

That's the same reason I keep the AI-attribution methodology attached to the AI-attribution number, and the same reason INTERLOCK's readiness verdicts show their evidence inline instead of asking you to trust a rollup.

What I want to do with it

Pick up an engineering organization that is somewhere between skeptical and overwhelmed about AI, and leave it measurably faster, with the tooling, the guardrails, the curriculum, and the evidence to keep going after I'm not there.

I still build. I build to prove points.