Skip to content
Documentation

Decision Record: Use Airtable for Engineering Intake

Decision Record: Use Airtable for Engineering Intake

Status

Accepted

Context

MDDS needs a lightweight intake system for engineering requests from deployed teams, agency partners, and internal stakeholders.

The problem is not simply tracking engineering work. The problem is that requests, questions, risks, architecture concerns, and “one-hour problems” are often routed directly through engineering leadership before they have been clearly framed, vetted, or prioritized. Everything lands in the same channel. There is no signal about type, urgency, or whether engineering is even the right team to move it.

We need a front door that helps us:

  • Capture requests consistently across agencies and engagements
  • Understand the type of support being requested before any conversation happens
  • Triage urgency and risk before committing engineering time
  • Identify patterns across teams — not just individual asks
  • Decide whether engineering should take action, redirect, or decline
  • Avoid turning every request into committed delivery work before it has been scoped

The intake system should help engineering make decisions. Jira is for executing them.

Decision

We will use Airtable as the engineering intake system.

We will not use Jira as the initial intake front door.

Jira may still be used later for confirmed engineering delivery work, but only after a request has been reviewed, accepted, prioritized, and assigned.

Why Airtable, not Jira

Airtable is a better fit for intake because it allows requests to be captured, structured, reviewed, and triaged without implying that the work has been accepted.

Using Jira as the front door sends the wrong signal. A Jira issue is interpreted as a backlog item, which implies the request is already approved, prioritized, and ready for engineering execution. That is not what intake is for.

Intake is where we determine whether something is:

  • A quick answer that can be closed the same day
  • A request for a standing pilot — office hours, a review, a sounding board
  • A risk that needs escalation
  • A staffing or capability gap rather than an engineering problem
  • A request that belongs with another team (procurement, product, legal)
  • A future backlog item once it has been scoped
  • A duplicate or a pattern appearing across multiple agencies
  • Something engineering should decline, defer, or redirect

That distinction matters because engineering capacity is limited. The intake system should protect that capacity, not create an uncontrolled backlog.

Operating model

Airtable is the front door. Jira is the execution system.

flowchart LR
    A[Request submitted] --> B[Airtable intake]
    B --> C{Triage decision}
    C -->|Quick answer| D[Respond and document guidance]
    C -->|Needs review| E[Architecture or engineering review]
    C -->|Not engineering work| F[Redirect or decline]
    C -->|Approved delivery work| G[Jira backlog item]
    G --> H[Engineering execution]

Airtable responsibilities

Airtable captures and triages engineering requests before they become committed work.

FieldPurpose
Request titleShort description of the ask
Requesting team or agencyWho needs support
Request typeQuestion, architecture review, incident or ops, vendor or procurement, staffing gap, delivery support
Problem statementWhat problem needs to be solved
UrgencyHow time-sensitive the request is
Risk if ignoredWhat happens if engineering does not engage
Blocker typeWhether the blocker is engineering, procurement, budget, staffing, security, or unknown
Work already attemptedWhat has already been tried
Estimated engineering effort15 minutes, 1 hour, half day, multi-day, or unknown
Recommended next stepTriage recommendation after review
OwnerPerson responsible for the next action
StatusNew, triaging, needs more info, accepted, redirected, declined, converted to Jira

Jira responsibilities

Jira should only be used after a request becomes real engineering delivery work.

A request moves to Jira when:

  • Engineering accepts the work
  • There is a clear owner
  • The next step is implementation
  • The scope is defined enough to track
  • The work needs to be prioritized against other engineering backlog items

Jira is not the place for vague requests, early discovery, or unvetted asks.

Consequences

Positive

  • Requests can be reviewed without implying commitment.
  • Engineering leadership can see patterns across teams and agencies.
  • Intake supports lightweight triage instead of creating immediate backlog pressure.
  • Engineering can protect limited capacity more deliberately.
  • Jira remains cleaner and more focused on actual delivery work.
  • Stakeholders get a clearer process for asking for help.

Tradeoffs

  • Airtable requires discipline to keep statuses and fields current.
  • Some accepted requests may need to be copied or converted into Jira later.
  • Teams may need guidance on when a request is still in intake versus when it has become committed work.
  • Airtable should not become a second unmanaged backlog.

Guardrails

  • Submitting an intake request does not mean engineering has accepted the work.
  • Airtable records should have clear statuses, reviewed on a regular cadence.
  • Only accepted and scoped delivery work should move to Jira.
  • Jira tickets should reference the originating Airtable record when applicable.
  • Intake should be used to identify patterns, not just manage individual asks.
  • Engineering leadership reviews the intake backlog at least bi-weekly for triage and pattern detection.

See also