Engineering Intake

The lightweight front door. Fill out the form, and we respond within a few days with a slot in a standing pilot, a scoping conversation, or an honest redirect.

What this is

This is the intake pilot named in the Engineering Intro to Deployed Teams: a simple way for deployed teams to describe a technical need — the risk, the urgency, and the type of support needed.

The form lives in Airtable. See the decision record for why Airtable instead of Jira. The short version: intake is a vetting and triage process, not an execution backlog. Jira implies the work is already accepted. Airtable does not.

The form does two jobs at once. It routes a single request to the right kind of help. And in aggregate, the answers tell us what to hire for next — every submission is a data point about where deployed teams are actually getting stuck.

What this is not

It is not the 25 Questions. Those are the ninety-minute discovery you run after a request is accepted and an engineer is in the room. This form deliberately stays shallow so it is low-effort to fill out and low-effort to triage.

It is not a commitment. Submitting tells us what you need; it does not promise an engineer by Friday.

What we are screening for

Every accepted request gets run through the four questions from the intro doc. The form exists to give us a first read on each one before anyone spends real time.

Screening question	What the form asks
Is this an engineering gap we can actually move?	What is going on, and what is actually blocking you
Does it unblock more than one team?	Which agency and what breaks if we don’t act
Are we the team best positioned to help?	What kind of help you are looking for
Will the work carry forward without us?	Contact and agency context

The form fields

Contact: Your name and email

Required. Name and email address.

Why we ask: So we know who to follow up with and can keep your submission connected across triage, routing, and any follow-on conversations. Not stored for marketing. Used only for this intake.

Which agency or engagement is this?

Short text.

Why we ask: Requests exist in context. Knowing the agency tells us whether we’ve seen this problem before in this engagement, whether there’s an existing relationship or access constraint, and whether this is one team’s problem or a pattern across several. It also determines who the contact is after the deployed team rotates off.

Any upcoming deadlines or deliverable dates we should know about?

Date picker.

Why we ask: Urgency shapes routing. A deadline that’s two days away is a different triage decision than one that’s next quarter. We don’t want to learn about a hard constraint after we’ve already deprioritized a request. If there is no date, leave it blank — that’s a valid answer, and it doesn’t disqualify the request.

What kind of help are you looking for?

Multi-select. Pick all that apply.

Office hours or a quick consult
A lightweight architecture review — a second opinion, not a sign-off
A technical sounding board — talk a problem through with someone who has seen it before
A reusable question set for an agency or vendor meeting
Engineering documentation or a written position
Not sure — help me figure out what I need

Why we ask: Routes the request to the right standing pilot without inventing a new commitment each time. “Not sure” is a real answer — it usually means the need is still forming, and that’s worth a conversation on its own before anyone digs into the problem.

What’s actually blocking you right now?

Multi-select. Pick all that apply.

Engineering problem
Procurement or contract
Budget
Staffing or ownership
Security or ATO
Not sure

Why we ask: This is the most important field on the form. The recurring failure in deployed work is a perfect engineering recommendation blocked by a procurement, budget, or staffing wall that engineering cannot move. If the honest answer here is procurement or budget, a prototype will not fix it. Naming that early is a redirect, not a rejection — and it saves everyone the time of a full engagement that goes nowhere. This is the Maya filter: it catches the case where the real blocker is institutional, not technical, before an engineer’s month gets spent on a wall they cannot move.

What’s going on, and what would “unblocked” look like?

Free text. One paragraph is enough.

Why we ask: Gives us the problem in your words, and a picture of what success looks like — not a proposed solution. The same thing the 25 Questions listens for in its very first prompt: describe what a good outcome looks like, in plain language, without naming a tool or a vendor. If your answer to this question is “we need Salesforce,” back up one step. What does Salesforce solve? That’s the thing worth writing here.

Anything else we should know that would be helpful?

Free text. Optional.

Why we ask: The form is intentionally short. This field exists so you don’t have to shoehorn important context into a box that doesn’t quite fit. Budget constraints, prior attempts, political sensitivities, a relationship you want us to know about — if it matters, put it here.

File upload. Optional.

Why we ask: A screenshot, a diagram, a scope document, an email thread — sometimes the fastest way to understand a problem is to see what you’re looking at. Don’t overthink it. If you have something relevant, attach it. If not, skip it.

Field-to-screening mapping

Field	What it captures	Screening question it feeds
Agency or engagement	Context and relationship history	Does it unblock more than one team?
Deadline or deliverable date	Urgency and time constraint	Is this an engineering gap we can move?
Kind of help	Type of support needed	Are we best positioned to help?
What’s actually blocking you	Engineering vs. institutional wall	Is this an engineering gap we can actually move?
What’s going on	The problem and the outcome	Is this an engineering gap we can actually move?
Anything else	Context that doesn’t fit elsewhere	All four screening questions
Attachments	Faster problem comprehension	All four screening questions

Nothing here asks for budget category, procurement lane, or production architecture details. Those are discovery questions for an accepted engagement. Asking them at the front door turns a five-minute form into a barrier.

What happens after you submit

We read submissions within a few days and respond with one of three things:

A slot in a standing pilot — office hours, a review, a sounding-board hour
A short scoping conversation to understand it better before routing
An honest redirect when the blocker is not an engineering one

A redirect still comes with a pointer — to procurement, to another team, to the deployed-team contacts who can move it. We don’t close a submission without telling you where we think it belongs.

The answers also accumulate. When a pattern shows up across submissions — the same kind of help, the same kind of blocker, across several engagements — that is the signal for what engineering should staff or document for next. The intake is not just a request queue; it is the clearest picture we have of where the work actually is.

Templates

The intake is a form, but the work around it is email. These are the copy-paste starters: announcing the door, acknowledging a submission, and replying when you triage. Swap anything in [brackets] for your specifics, and replace [form link] and [#channel] with whatever your team already uses. The wording carries the intake’s principles — it stays shallow on purpose, and it never lets a reply become the discovery session this form deliberately isn’t.

Announcing the front door

Send this to deployed teams once the form is live. It tells them where the door is, how little it costs to use, and what it is and isn’t for.

Subject: New: a front door for engineering support — [form link]

Hi all,

If you've got a technical need and weren't sure who to ask, there's now a
front door: a short intake form at [form link].

Nine fields, five minutes. It asks what kind of help you're after, what's
actually blocking you, and what "unblocked" would look like — no architecture
diagram, no scoping doc, no proposal. We read submissions within a few days
and respond with one of three things: a slot in a standing pilot, a short
scoping conversation, or an honest redirect if the blocker isn't an
engineering one.

What it's not: a commitment, a ticket queue, or a place to fully scope your
project. It's the lightweight way to raise your hand. If the answer needs more
than the form holds, that's what the follow-up conversation is for.

Not sure whether your thing fits? Submit it anyway — "not sure what I need"
is a real answer the form is built to take.

[your name]

Notice it sells how little the form asks — nine fields, five minutes — and names what it is not. The front door only works if teams trust it’s cheap to knock; an announcement that oversells turns a five-minute form back into a barrier.

Acknowledgment reply

What a requester gets right after submitting. It confirms receipt and sets the “within a few days, one of three things” expectation so nobody refreshes their inbox.

Subject: Got your intake request — [topic]

Hi [name],

Thanks — your request is in. We read submissions within a few days and will
come back with one of three things: a slot in a standing pilot, a short
scoping conversation, or an honest redirect if the real blocker turns out to
be procurement, budget, or staffing rather than engineering.

A redirect isn't a brush-off — it comes with a pointer to whoever can actually
move it. Either way, you'll hear where we think this belongs. Nothing you need
to do in the meantime.

[your name]

Notice it repeats the three outcomes and frames a redirect as a pointer, not a rejection — exactly what “What happens after you submit” promises. Saying it at acknowledgment means the redirect, if it comes, reads as the honest answer it is rather than a door closing.

Routing reply

When the submission is clear enough to send onward, route it in one message. Name the destination and stop — don’t reopen the problem here.

Subject: Routing your request — [topic]

Hi [name],

Read this, and it's a good fit for [office hours / a lightweight architecture
review / a specific person]. [One line on why that's the right place.]

Next step: [I'll send the office-hours link / I'll set up the review / I'll
intro you to [name]]. Bring what you wrote in the form — no need to re-explain
it to me first.

[your name]

Notice the reply routes and stops — it doesn’t ask the requester to walk through the problem again before being sent on. The form already captured the shallow read; making them re-pitch it to you turns the front door into the discovery session it’s meant to feed, not be.

”Tell us a bit more” reply

When the blocker field is too thin to route, ask for the one missing thing — and only that. Resist the urge to run discovery in the thread.

Subject: One quick thing on your intake request — [topic]

Hi [name],

Want to route this well, and I'm one detail short. [The single missing
thing — e.g., "Is the thing in your way an engineering problem, or is it
waiting on procurement or budget?" / "What would 'unblocked' actually look
like — what could you do then that you can't now?"]

Just that one answer is plenty — a sentence is fine. I'll take it from there;
no need to write the whole thing up.

[your name]

Notice it asks for exactly one missing field and caps the answer at a sentence. The blocker field is the most important read on the form, but chasing it with a five-question email rebuilds the ninety-minute discovery this intake exists to stay shallower than.