Engineering Support

The front door deployed teams knock on, and the artifacts they walk away with — run so neither quietly turns into staffing you never agreed to.

What these are

These are pilots, not permanent commitments. Each one is meant to be low-effort to offer and high-return for the team using it, and each one is something you can stop, reshape, or hand off the day it stops earning its place. None of them is a substitute for embedded engineering work — they are the connective tissue between deployments, the thing a team can reach for in the moment without waiting for a new engineer to be hired and onboarded.

There is one throughline: enablement, not capacity substitution. The job is to upgrade the team you’re helping so it can do the next thing without you — not to become the engineer it never staffed. The day a pilot starts doing a team’s work instead of building the team’s ability to do it, it has stopped being a pilot and started being load you’ll carry until you leave.

Support splits into two kinds of help, and the kind tells you how to run it. The front door — engineering intake — is how a request finds the right help. The inheritance artifacts — reusable question sets and internal documentation — are what outlast the engagement, so the next engineer walks in with the hard parts already mapped. The live formats a request gets routed to — office hours, sounding-board hours, architecture reviews — live in Engineering Meetings.

Pilot	What it is	Your time commitment	Link
Engineering intake	The front door — a short form for a deployed team to describe a technical need	Minutes per request to triage	Engineering intake
Reusable question sets	The questions an experienced engineer would ask, encoded as artifacts	Curation and maintenance time	Question sets
Internal engineering documentation	How engineering operates, published openly so teams can point to it	Writing and publishing time	Internal docs

Notice the time commitment column is the honest cost, not the headline value. Intake costs you minutes and routes everything; the artifacts cost you maintenance time forever but pay down the next engineer’s cost. Read the column as “what you’re signing up to protect” — a pilot you can’t protect the time for is one you shouldn’t offer.

Each pilot page ends with a Templates section — copy-paste launch emails and reusable artifacts — so standing one up is mostly swapping the [brackets] and sending. If you’re starting one of these for the first time, that section is where to go.

How they group

The three pilots aren’t a flat list. They sort into two kinds of help, and the kind tells you how to run it.

Front door

Engineering intake is the one entry point. It’s not help itself — it’s how a request finds the right help. Everything a team might need is something intake can route to, which is why it’s the only thing a team has to know about to reach you. Most of what it routes to is a live format: a slot at office hours, an architecture review, a sounding-board hour.

Inheritance artifacts

Reusable question sets and internal documentation are the ones that outlast any single engagement. This is the inheritance model from the intro: each artifact pays down the cost for the next engineer, so they walk into the next engagement with the hard parts already mapped. A question set you write once gets asked in twenty vendor meetings you’re not in. A doc you write once stops you from re-explaining the same thing for the rest of your tenure. The work that used to take a year of one engineer’s attention becomes capability built across many agencies in the same calendar.

Notice the front door spends your time in the moment, while the artifacts spend it once and collect forever — which is why, when you’re deciding where an hour goes, an hour into an artifact usually beats an hour into a one-off reply.

How you decide what to keep

Run the pilots themselves through the same four questions the intro uses to screen incoming work. The questions aren’t only for requests — they’re how you keep your own menu honest.

Question	How you’d detect a pilot failing it
Is this an engineering gap we can actually move?	The pilot keeps surfacing procurement, budget, or staffing walls it can’t touch — and you keep building things nothing can adopt.
Does it unblock more than one team?	Usage traces back to a single loud engagement; no second team has touched it in two months.
Are we the team best positioned to run it?	Research, design, or another team already does this better, and you’re duplicating their work.
Will it carry forward without us?	The pilot only works while you personally show up; nothing about it would survive your rotation.

Notice every row is testable. You don’t decide whether to keep a pilot on a feeling — you look for the named tell, and a pilot that trips a row is a pilot to kill or reshape, not defend.

Re-ask these at month three and month six, not just at the start. The answers change. An intake that surfaced four teams’ problems in its first month can quietly narrow to one agency’s queue — and the discipline of revisiting the questions is what catches a pilot drifting from enablement into capacity substitution before you’ve spent a quarter on it.

Saying yes to everything is saying yes to doing nothing well. Every pilot you keep alive out of habit is time you’re not spending on the one that’s actually working. Killing a drifting pilot isn’t a failure of the pilot — it’s the whole point of running them as pilots.