The hiring ADR: what to capture when you're choosing between candidates — and what to leave out

A new VP of Engineering joins a twenty-person startup. First week, three different senior engineers ask variations of the same question: why is the backend team three people when the frontend is a single contractor? Why isn't there a dedicated infrastructure engineer? Why does the data pipeline responsibility get split across backend engineers instead of living with a data engineer?

The hiring manager who made those calls left six months ago. His Notion page has a list of past open roles and offer status. Nobody wrote down why the team is shaped the way it is. The new VP makes an assumption — the company was optimizing for backend velocity at the expense of frontend polish, probably because the early product was API-heavy — and proceeds on that assumption for three months before discovering the real reason: two frontend specialists had turned down offers because the equity was below market, so the company defaulted to a contractor model by necessity, not by design. The constraint was compensation, not strategy. Three months of frontend investment decisions made on a wrong premise.

This is the hiring version of the new-CTO onboarding problem. The expensive confusions at new-hire onboarding aren't usually technical — they're organizational. Why is the team structured this way? Why did we prioritize this role over that one? What constraint drove this design? These questions have answers. The answers just live in 18 months of hiring deliberations that happened in ChatGPT sessions that nobody exported.

Why hiring decisions don't get documented

Three structural reasons work together to make hiring decisions the least-documented category in most engineering teams.

The first is the privacy reflex. Hiring involves evaluating people. Anything that could be perceived as a written record of person evaluation triggers a legal-risk instinct — even when the record in question is about role design, not candidate assessment. The result is that teams avoid written records of hiring decisions entirely, even the candidate-anonymous parts that carry no legal risk and would be valuable for every future engineer on the team.

The second is the outcome-artifact problem. Technical decisions leave code artifacts — the library choice leaves a dependency, the architectural decision leaves a service boundary, the schema choice leaves a migration file. Hiring decisions leave a person. The person is the artifact. Teams conclude that no additional documentation is needed because the outcome is visible. But the person's presence tells you what was hired, not why this role was prioritized over alternatives, not what constraint drove the role design, not what the team gave up by making this choice rather than a different one.

The third is the deliberation surface. Hiring decisions happen in AI chat, in one-on-ones, and in brief verbal conversations — not in documents. When an engineering manager is wrestling with "should I hire a senior individual contributor or promote an existing mid-level engineer and hire two juniors to replace the gap," they take that question to ChatGPT or a trusted colleague, not to a formal document. By the time the decision is made, there's no record of the reasoning. The decision was made. The person joined. Nobody wrote down why this shape and not that one.

Three types of hiring decisions worth documenting

Not every hiring call needs a decision record. The three categories that do share a common property: a new engineer joining the team six months later would infer something different about the team's priorities, constraints, or capabilities without knowing the reasoning.

Role prioritization decisions

Why did you hire this role now instead of an alternative? Why a frontend specialist over a second backend hire? Why a growth engineer over a customer success manager? Why did you hire engineers before hiring product managers?

Role prioritization decisions encode your product thesis and execution priorities at a particular moment. An engineer who joins twelve months after this decision and sees only the team's current composition will infer those priorities from the current state. If the current state is misleading — if the team looks frontend-heavy because of contractor headcount, not because of strategic prioritization — that engineer will operate on a wrong model of what the company values.

The ADR captures: the moment (what was true about the product, the market, and the team at decision time), the alternatives that were seriously considered (what other roles were under evaluation), the constraint that drove the selection (budget, timeline, a specific gap that was blocking progress), and what was accepted by not hiring the alternatives first (the capability gap that persisted).

These records are particularly valuable at the role-prioritization decision for the founding hire — the first engineer, the first non-engineer, the first manager — because those decisions encode assumptions about the business that will be invisible to everyone who joined later.

Role design decisions

Full-time employee vs. contractor. Senior individual contributor vs. two mid-level engineers. Backend specialist vs. full-stack generalist. Dedicated DevOps vs. distributed infrastructure responsibility. In-house vs. agency for a function.

Role design decisions create the capability profile of the team. They feel like HR details at decision time but become architectural constraints at scale. A decision to hire backend specialists rather than full-stack engineers makes the team faster at backend work and slower at cross-cutting changes. A decision to use a contractor for frontend rather than a full-time hire creates velocity on existing work and fragility on new-direction work. A decision to defer a dedicated DevOps hire and distribute infrastructure responsibility across backend engineers creates flexibility now and a coordination cost later.

These decisions expire in a way that technical decisions don't. The right review trigger for a role design decision is usually a team growth threshold rather than a calendar date: "review this decision if the team reaches twelve engineers" or "review this decision if time-to-production-deploy exceeds 30 minutes." The role design that was correct at eight people is often wrong at twenty, and the wrong model compounds for every month nobody notices the original constraint has dissolved.

Team structure decisions

Who reports to whom. Flat team vs. layered management. Cross-functional product pod vs. functional engineering team. How decision authority is distributed between engineering managers and technical leads. Where the line falls between product and engineering for different decision categories.

Team structure decisions are organizational architecture decisions that outlast the individuals who made them and create constraints for every person who joins after. They're the closest hiring-adjacent category to a traditional ADR: they have clear alternatives, explicit trade-offs, and durable consequences that a new team member would need to understand to operate effectively. An engineer who joins a team without knowing that the cross-functional pod structure was chosen over a functional team specifically because the product team lacked technical knowledge to write specifications will misunderstand why engineering and product work so closely together — and may find the integration intrusive rather than structural.

Team structure decisions are also the category most likely to create cross-team constraints — decisions that affect how multiple teams interact, who owns which surfaces, and what the handoff points are between functions. These are exactly the decisions whose absence is most expensive when a new leader joins and starts making changes based on the current structure rather than the original reasoning.

The privacy constraint: candidate-anonymous by design

A hiring ADR that captures role design and team structure reasoning contains no sensitive personal data. It should never contain:

• Candidate names
• Specific interview feedback about named individuals ("Alex was strong on system design but weak on ownership")
• Salary negotiations for specific people
• Reference check contents
• The specific candidates who were rejected and why they specifically were rejected

What it should contain is the decision about the role, not the decision about the person. The capability gap the role was addressing. The trade-offs in the role design. The constraint that drove the selection. What was accepted by making this choice rather than an alternative. These are organizational facts, not personal assessments. They carry no legal risk and would be recognized as legitimate documentation by any employment attorney.

This candidate-anonymous format has a second benefit beyond privacy: it makes the record more useful. The reason a senior backend engineer over two mid-level engineers is valuable to future team members is the reasoning about capability distribution and mentorship cost, not a comparison between two specific people who may have left the industry entirely. The organizational reasoning is the lasting artifact. The candidate comparison is ephemeral.

What goes in the record, and what stays private

The practical boundary: if the record answers "why is the team structured this way?" it goes in the engineering decision log. If it answers "why was this specific person chosen over another specific person?" it stays in the HR system.

A role prioritization record for a frontend specialist hire:

Context: Product has been API-first for 12 months; backend team has three engineers. Frontend is a single part-time contractor delivering basic UI for internal workflows. We're entering a market-facing phase where the product surface visible to end users will be primary. Three options were evaluated: (1) hire a dedicated frontend specialist FTE, (2) hire a second backend engineer and upskill one of the three for frontend, (3) continue contractor engagement and double contractor hours.

Decision: Hire a dedicated frontend specialist as a full-time employee.

Constraint: Q3 external beta with 200 design-conscious users requires a polished UI that cannot be delivered by upskilled backend engineers on a 90-day timeline; contractor model provides insufficient institutional knowledge for this surface area.

Consequences: Backend-to-frontend ratio becomes 3:1 FTE, which is frontend-weighted for our current product stage. Backend capacity is unchanged. Upskilling path is foreclosed for the next 12 months — the decision to hire a specialist rather than develop internal capability means we don't build frontend competency on the backend team and must hire another frontend specialist if the frontend scope expands significantly. Review trigger: if backend team grows to five engineers before another frontend hire, reassess the ratio.

Nothing in this record names a candidate, references an interview, or creates any legal exposure. It's a record of an organizational decision that any new engineer joining the team needs to understand the team's capability profile and priorities.

The role-prioritization decision: why this hire now

The most commonly undocumented role-prioritization decision is the one made at the fork between two equally plausible hires. The first engineering hire at an early-stage startup. The first manager vs. the next individual contributor. The growth engineer vs. the customer success hire. The data engineer vs. the platform engineer.

These decisions are made once, never revisited (because the role is filled), and shape the team's capability and culture for years. They're almost always made in AI chat or a trusted conversation with a board member or advisor — not in a document. The reasoning at decision time is rigorous. Six months later, nobody can reconstruct it.

The record for a role-prioritization decision should capture three things the current team composition doesn't reveal: what alternatives were seriously under evaluation (not a token list — the two or three roles that were genuine competing priorities), the specific constraint that made this role win (not "we needed backend velocity" but "the Q3 integration deadline required three backend engineers to deliver in parallel"), and what capability gap persisted as a consequence (the thing the team doesn't have that it would have had if a different role had been prioritized).

The last field — the persisting capability gap — is often the most valuable. A new engineer who joins and sees the current team composition infers that the team has the capabilities it has by design. They don't see the gap that was accepted. A team that hired three backend engineers and deferred the DevOps hire for six months built up an implicit infrastructure debt that manifests as "engineering time spent on infrastructure" rather than a visible gap. The decision record that names the accepted gap makes that debt visible rather than invisible.

The role-design decision: full-time vs. contractor, seniority, specialization

Role design decisions are the category most likely to generate the "why is it built this way?" question about team structure rather than about technology. They're also the category most likely to be made under time pressure, which means the deliberation is real but the documentation probability is near zero.

Three role design trade-offs that consistently go undocumented:

Senior vs. two mid-levels. The deliberation has a genuine trade-off: one senior person provides mentorship, faster ramp-up on ambiguous problems, and stronger external credibility; two mid-levels provide more capacity, lower compensation cost per head, and a stronger pipeline for future growth. The constraint that drives the selection (usually: what kind of work is ahead of us, and what does the existing team look like) is specific and temporal. Write it down with a review trigger tied to team growth: "if we hire two more mid-level engineers before we hire another senior, the mentorship math changes."

Specialist vs. generalist. A specialist delivers higher quality on the specific surface and weaker coverage on adjacent ones. A generalist delivers consistent coverage and shallower depth across many surfaces. The decision is usually constraint-driven: early-stage teams with a single critical bottleneck need a specialist; teams with many smaller bottlenecks need a generalist. The constraint changes as the team grows. A record that captures "we hired a frontend specialist because the bottleneck in Q3 was UI quality, not frontend coverage breadth" lets a future manager recognize when the bottleneck has shifted.

Full-time vs. contractor. The reasoning here is almost always about institutional knowledge, benefit cost, and work nature — not about quality. Contractors are right for well-scoped recurring work with clear deliverables and low institutional knowledge requirements. Full-time employees are right for work that requires deep context, changes frequently, or builds toward a future capability. Writing down which of these properties drove the contractor/FTE decision for a specific role lets the team recognize when those properties have changed.

Team structure decisions: the organizational architecture ADR

Org structure decisions are the least obviously ADR-appropriate category, because they feel more like management than engineering. But they share every property of a technical architectural decision: named alternatives existed, a constraint drove the selection, the consequences are durable, and a new team member would behave differently knowing the reasoning.

The decision to organize as cross-functional product pods vs. a functional engineering team is a genuine architectural fork. Pods deliver faster on the product surface they own and slower on cross-cutting infrastructure concerns. Functional teams deliver consistent platform quality and slower on product-specific features. The right model depends on the maturity of the platform, the technical sophistication of the product team, and the nature of the current development phase. All three of those factors change over time.

A new engineer who joins a pod-structured team and has experience with functional teams will infer that pods are the right model here and adapt accordingly. If they don't know that pods were chosen specifically because the product team lacked technical knowledge to write detailed specifications — and that the long-term plan is to develop that specification discipline and transition to more functional ownership — they'll build habits appropriate for a team that plans to remain pod-organized rather than one planning to evolve.

The ADR-vs-RFC question is real for org structure decisions. Decisions that affect multiple teams warrant an RFC first — circulate to affected stakeholders, collect objections, incorporate them, then document the outcome. An org structure decision made unilaterally and then documented after the fact is correctly structured but poorly governed. For decisions that affect only a single team's internal organization, the ADR-first approach is fine.

Review triggers for hiring decisions

Hiring ADRs expire faster than most technical ADRs. The conditions that drove a role design decision at ten people are usually wrong at twenty. Three review trigger patterns work well for hiring records:

Team growth thresholds. "Review this role design decision when the team reaches fifteen engineers." Team size is the single most reliable predictor of when a role design decision has expired. The specialist/generalist balance that was correct at six people is almost always wrong at fifteen. The flat management structure that worked at eight needs rethinking at twelve. Write the number down.

Product stage transitions. "Review this role prioritization when the product moves from internal beta to public launch." "Review this decision when the team acquires its first enterprise customer." Product stage transitions change what capability gaps are expensive and what role design trade-offs are acceptable. A decision that was right during early development is often wrong at growth stage.

Individual departure. "Review this team structure decision when [role title] changes." Some team structures depend on a specific person's strengths. When that person leaves, the structure may not fit the successor. Writing "review if the [Head of Product] role changes hands" as a review trigger on a pod structure decision makes explicit that the structure was partly person-dependent rather than purely design-optimal.

Using AI chat extraction for hiring deliberation

Hiring deliberations in AI chat are structurally explicit and among the highest-confidence extraction targets. Founders and engineering managers frame hiring decisions as decisions from the first message. The sessions look like: "I'm trying to decide between hiring a frontend specialist or upskilling one of the existing backend engineers. Here's the situation: three-person backend team, no dedicated frontend, Q3 deadline for a market-facing product release, $180k budget for this hire." That's the question shape, the named alternatives, and the constraint in the first two sentences.

The deliberation sessions also contain the trade-off language that extraction patterns capture strongly — "the advantage of the specialist is X but the downside is Y" — and often end with explicit user commit phrases: "I'll go with the specialist hire because the timeline doesn't leave room for an upskilling track." These sessions produce high-confidence extraction candidates.

The challenge is finding the right window in a multi-year export. Technical decisions have commit dates. Hiring decisions have offer acceptance dates and start dates, which most teams track in their HR system or in an ATS. The workflow: identify significant hires from your HR records, note the approximate decision date (typically 2–4 weeks before the offer acceptance), export AI chat history from the 6-week window before each significant hire, and run the WhyChose extractor on that window. The deliberation before a structural hire — the first manager, the first specialist, the founding engineer — will surface as a cluster of high-confidence candidates in that window.

One pattern specific to hiring deliberations: founders and engineering managers often run multiple sessions on the same decision across several weeks, as they learn more from the interview process and adjust their thinking. A session from week one of a search ("should we hire a specialist or a generalist?"), a session from week three ("two strong candidates, very different profiles — how do I think about this?"), and a session from week six ("we got an offer back with a counter — here's the situation") all belong to the same hiring decision. The extractor surfaces them as separate candidates. The triage pass connects them into a single decision record with richer reasoning than any single session contains.

The multi-engineer extraction pass is especially valuable for hiring decisions. When two engineering managers, a recruiter, and a CPO are all discussing the same role, they're running parallel AI chat sessions with different framings. Pooling exports across everyone involved in a hiring decision produces a more complete record than any single person's export can.

The "not hiring this role yet" record type

The most valuable and most commonly missing entry in a hiring decision log is the deliberate choice not to hire a role. "We evaluated hiring a DevOps engineer and decided to defer it." "We considered a dedicated data engineer and chose to keep data responsibility distributed across the backend team for 12 more months." "We decided not to hire a Head of Product until we reach product-market fit."

These are "not building this" records applied to hiring. They capture the reasoning behind a capability gap that looks accidental but was intentional. Without them, new engineers and new leaders who join the team see the gap as a neglected priority rather than a deliberate deferral with specific conditions for re-evaluation.

A "not hiring this role yet" record is shorter than a role design ADR. It needs: the role that was evaluated, the constraint that made deferral the right call (budget ceiling, product stage, the specific gap it would address not yet being the binding constraint), and a review trigger (the condition under which the deferral should be revisited). "We evaluated a DevOps hire. Current infrastructure work is not the binding constraint on delivery velocity; the binding constraint is product specification clarity. Review this decision when infrastructure cost exceeds 20% of engineering time." That's a complete record.

Where to start

The most tractable starting point for hiring documentation is the quarterly review pass applied specifically to hiring decisions that happened in the last 12 months. List every significant hire: founding engineers, first manager, first specialist, roles that were contested choices between multiple options. For each one, ask: do we have a record of why this role was prioritized, why the role was designed this way, and what we accepted by making this choice? For any gap, the AI chat extraction pass will typically surface the deliberation.

The second priority is the "not hiring yet" audit: what roles have been evaluated and deferred without a written record? These are often visible as recurring topics in 1:1s ("we should really think about hiring a DevOps person") without a decision record that explains why the deferral was made and under what conditions it should change. Write a short deferral record for each recurring deferred role, with an explicit review trigger. The record converts "we keep talking about this" into "we decided to defer this until condition X" — a much cheaper conversation going forward.

For teams using the same git repository for technical and non-technical ADRs, add a decisions/hiring/ subfolder with a README.md that explains the candidate-anonymous convention — what goes in the folder and what doesn't — so future contributors understand the privacy boundary without having to ask. The standard ADR format works without modification for all three hiring decision categories: the Context section captures the organizational moment, Decision captures the role design choice, Consequences captures what was gained and what was accepted. The decision log template is the right starting point if the team isn't already using a structured ADR format.

The goal is the same as for technical ADRs: when a new leader joins and asks why the team is structured the way it is, the answer shouldn't require finding the person who was there. It should be a folder that tells the story of every significant organizational choice, with the reasoning intact.