The engineering team growth decision record: why the IC-to-manager ratio you chose determines your coordination overhead surface and your capability threshold failure mode

A 22-person product SaaS that built a B2B workflow automation platform reached its first engineering hiring moment eighteen months after launch. The technical co-founder, who had been managing the six-person founding team directly, decided to hire the first engineering manager. The decision was made with deliberate intent: the company had grown past the point where one technical leader could maintain individual contributor context on every engineer's work and still drive the product roadmap. The ratio was set explicitly in a hiring document: one engineering manager per eight engineers, with the expectation that each EM would operate as a player-coach — contributing code for roughly thirty percent of their time, managing four to eight direct reports, and owning the team's technical quality standards. The rationale was documented: "we want EMs who can earn trust through code, stay close to the technical work, and mentor engineers through example rather than just through one-on-ones." The thirty-percent contribution expectation was understood by both sides before the first EM accepted the offer.

Over the following twenty-six months, the team grew from twenty-two to sixty-seven engineers. Four additional EMs were hired. Each inherited the 1:8 ratio. Each joined with the player-coach expectation. The first EM had been hired when the platform had twelve distinct integration points with external systems and two product areas owned by a single team. By the end of the twenty-six-month window, the platform had forty-three integration points, six product areas distributed across four teams, and a shared service layer whose changes affected all four teams simultaneously. Cross-team dependency meetings — the recurring syncs that existed to coordinate changes to the shared service layer, align on API contracts between teams, and resolve conflicts between product roadmap priorities — occupied the EMs' calendars in ways that no one had anticipated when the player-coach model was designed.

By month ten of the second EM's tenure, she had stopped contributing code. Her weeks were structured around six recurring coordination meetings involving engineers from other teams, three weekly one-on-ones per direct report, biweekly sprint reviews with product stakeholders, and the asynchronous decision-making overhead of a Slack channel that had become the de-facto coordination mechanism for cross-team technical questions. The thirty-percent contribution expectation remained formally in place — it appeared in her performance review template, which asked her to "describe your technical contributions this quarter." In three consecutive performance reviews, she had written something in that section. The contributions described were real but they were not the work the expectation had been designed to produce: they were code reviews of particularly complex pull requests, architecture review comments on RFCs from her team, and the occasional spike for a technically ambiguous feature. None of them were the hands-on code production that the player-coach model had assumed would happen when the ratio was set.

Three of the four EMs hired against the player-coach expectation left within twenty months of joining. Exit interviews referenced variants of the same gap: they had joined to do a job that the company's current organizational structure did not permit. One said it directly: "The role I'm doing is a full manager role. That's fine — the company needs it. But I was hired for something different and I've spent two years doing the wrong thing." The engineering leadership attributed the attrition to "cultural fit" and "misaligned expectations" without examining what had changed about the role since the ratio was set. The founding session that established the 1:8 ratio and the player-coach model had not specified the coordination demand assumption the model depended on. It had not specified a recalibration trigger. It had not specified the product surface complexity threshold at which the thirty-percent contribution expectation was no longer viable. Without those specifications, there was no mechanism for detecting that the model had grown past its design envelope — only the exit interview data that arrived eighteen months after the mismatch became structurally inevitable.

A 29-person B2B analytics SaaS made an explicit decision about its hiring bar in year two, after two consecutive problematic hires. The first had been a mid-level engineer who produced code that consistently required significant rework during review; the second had been a candidate who had represented themselves as having led a distributed systems project and arrived with less practical experience than the interview had suggested. Both situations were resolved — the first through a performance improvement process, the second through an agreed departure — but both had been expensive and distracting. The engineering leadership concluded that the bar needed to be higher and more consistently applied.

The revised bar was documented in the engineering team's hiring handbook: "We only hire senior engineers. Minimum five years of relevant experience. Strong take-home assessment scores in the top quartile of our historical candidates. Unanimous approval from the interview panel." The bar was effective. Over the following eighteen months, the team grew from eleven to twenty-nine engineers. The quality of the cohort was genuinely high — code review cycles were shorter, production incident rates were lower, and the team's average time-to-resolve for technical problems was faster than it had been with the mixed-seniority composition the founding team had. The hiring bar had produced its intended effect.

At month twenty, the platform reached four thousand daily active users running production-critical analytical workloads. The product was an analytics API — latency, availability, and data freshness were customer-visible characteristics, and three enterprise customers had signed contracts with explicit SLA terms. The database layer was a PostgreSQL cluster that had started as a single instance, been promoted to a primary-replica configuration in year one, and grown to handle approximately twelve thousand queries per minute at peak. The twenty-nine engineers on the team were strong individual contributors. None of them had operated a PostgreSQL cluster at production scale through a performance-degrading workload transition. No one had designed or debugged a distributed caching layer under contention. No one had configured CDN routing for API traffic patterns with heterogeneous response time characteristics across customer segments.

In month twenty-two, the PostgreSQL cluster began exhibiting lock contention during the batch analytical query execution that the platform's largest enterprise customer ran every weekday at 9am. The symptoms were elevated p99 API latency, occasional query timeout errors surfacing in the customer's dashboard, and growing primary CPU utilization during the two-hour window when the batch jobs ran. The team investigated. They examined the slow query log. They reviewed the EXPLAIN ANALYZE output for the affected query classes. They tried connection pool configuration changes. They increased the replica count and shifted read traffic to replicas. None of the interventions resolved the contention pattern. Six weeks later — with forty-seven engineering hours spent across the investigation and remediation attempts — a database performance consultant the company engaged identified the root cause in a four-hour session: a missing partial index on a filtered query that was generating full table scans under the batch load, combined with a VACUUM configuration that was allowing table bloat to accumulate faster than autovacuum could process it. The partial index took forty minutes to create. The VACUUM configuration change took ten minutes. The contention pattern resolved immediately.

The consulting engagement cost fourteen thousand dollars. The forty-seven engineering hours cost more. The enterprise customer had filed two support tickets during the contention window and had been in direct contact with the CTO about the performance issues. The six-week timeline was not the consequence of the team being slow or careless — it was the consequence of the team not having anyone who had seen this specific failure pattern before and knew where to look first. The hiring bar had produced a senior team. It had not produced a team with the capability distribution the platform required to operate at its current scale. The bar had been defined as a seniority proxy, and seniority at one company's problem profile does not translate automatically to the capability gaps that emerge at another company's infrastructure evolution point.

The founding session — the meeting where the hiring bar was raised and documented — had not asked a different question: what capabilities does the team need to maintain across growth? Which specific technical domains are becoming critical to the product's reliable operation as the platform scales? Which domains are underrepresented in the current team's experience profile? Those questions did not have obvious answers at the time the bar was set, because the platform's infrastructure requirements at twenty thousand daily active users were not visible at four thousand. But the trigger for revisiting the capability composition as the product's infrastructure requirements evolved was also not documented. There was no mechanism for detecting the capability gap before it produced a six-week investigation. The consulting engagement and the customer relationship damage were both visible. The founding session gap that made them inevitable was not.

A 35-person product SaaS had an onboarding process that had been designed and refined when the engineering team was twelve engineers. The process was simple and had worked well: a new engineer spent their first two weeks shadowing a senior engineer — attending design reviews, code reviews, incident response, and planning sessions, asking questions in real time about the codebase and the product — and then picked up their first small ticket in week three. The expectation was that they would be producing work at a rate comparable to a fully-ramped engineer by the end of their first sixty days. In the team's first two hiring cohorts — four engineers and then three engineers, spread across two-week staggered start dates — the model delivered roughly as expected. The sixty-day ramp window was accurate, with individual variation of ten to fifteen days in either direction.

In month fourteen, the team ran its third hiring cohort. The company had closed its Series A three months earlier. The commitment to investors had included a headcount growth plan. The third cohort was five engineers hired to start within a two-week window — the largest single cohort the team had attempted. The five engineers were assigned to shadowing pairs with senior engineers who had been on the team for at least twelve months. Two of the five were assigned to senior engineers who were each already mentoring a second engineer from the previous cohort, who was still in their last three weeks of ramp. Three were assigned to senior engineers who were individually committed to delivering high-priority features with deadlines tied to a customer contract milestone.

The senior engineers honored the shadowing commitment. Concretely, this meant scheduling two to three one-hour shadowing sessions per week rather than the four to six hours of co-working time that had characterized the first cohort's experience, where the senior mentors had had more open availability in their calendars. It meant that questions asked outside the scheduled sessions often went unanswered for hours, rather than being answered in real time as they arose during adjacent work. It meant that the informal knowledge transfer — the offhand explanation of why the database schema was structured a particular way, the context about why a specific technical approach had been abandoned two years ago, the reasoning behind a deployment process quirk — happened less frequently, because it happened most naturally when two engineers were working in physical or virtual proximity, and the cohort's shadowing hours were compressed enough that the sustained proximity that enabled that transfer was reduced.

The time-to-productive-contribution — measured from first day to first unassisted ticket closed — for the third cohort was 127 days, averaged across the five engineers. The first cohort had averaged 58 days. The second cohort had averaged 87 days. The engineering leadership reviewed the data after the third cohort completed ramp and attributed the growth to two factors: "a more complex codebase" and "harder initial tickets for this cohort." Both attributions were partially accurate. Neither was the primary cause. The primary cause was that the informal onboarding model had been designed for a mentor availability level that the team's current composition and commitment density could not supply when five engineers arrived simultaneously.

At the 127-day ramp time, the team of 35 engineers had, in practical terms, 27 productive contributors — the eight engineers who had joined in the third cohort or were still completing ramp from the second cohort were not yet producing work at full velocity. The team's sprint velocity had not increased proportionately to the headcount increase. The Series A investor update had forecast a velocity increase from the hiring cohort; the actual velocity was lower than it had been at 25 engineers. The gap was attributed in investor communications to "ramp time" — accurate — and the assumption in those communications was that ramp time would return to normal once the current cohort completed. The underlying problem was structural: the informal model had broken, and it would break again in the fourth cohort unless something changed about the model. The onboarding decision that had been made for a twelve-person team had never been reviewed against the new-hire-to-available-mentor ratio it was now operating under. There was no trigger to review it. There was no documented threshold above which the model was expected to fail. There was no structured alternative waiting to activate when the informal approach exceeded its effective capacity.

Structural properties set by the team growth decision

Three structural properties are determined when a team decides how to set its IC-to-manager ratio, define its hiring bar, and design its onboarding process. None appear explicitly in the founding session that sets the span of control, writes the hiring handbook, or designs the new-hire shadowing program — they are organizational characteristics that emerge from the founding decision's assumptions about the team size, product surface, and mentoring capacity that existed when the decision was made.

Property 1: The IC-to-manager ratio and the coordination overhead surface. An IC-to-manager ratio calibrated against a team with low cross-team dependency density works well when the product is small and the teams are largely self-contained. As the product surface grows, the number of inter-team dependencies grows faster than headcount alone. Each new service that communicates with existing services adds coordination overhead to the managers of both teams. Each new shared infrastructure component adds a coordination meeting to the calendars of all teams that depend on it. The player-coach model — the expectation that an EM will contribute code for a specified fraction of their time — depends on the manager having discretionary time after all coordination obligations are met. That discretionary time budget is not fixed; it shrinks as the coordination demand grows. The ratio that produces adequate discretionary time at ten engineers and two product areas produces zero discretionary time at forty engineers and eight product areas with shared infrastructure owned jointly by three teams. The coordination overhead surface is the product of (number of cross-team dependencies) × (average coordination time per dependency per week). It grows superlinearly with product surface complexity, not linearly with headcount. A founding ratio decision that does not document the coordination overhead assumption it depends on — and a recalibration trigger for when that assumption is violated — will operate past its effective range for as long as it takes for the mismatch to become visible in attrition data, manager burnout, or a team velocity decline that no one can explain by looking at the org chart. The service ownership model decision record determines which team owns which services and which boundaries generate coordination overhead; the team growth ADR determines whether the management structure is designed to absorb that coordination overhead without consuming the contribution budget the model assumes. These two decisions are coupled: a service ownership model that produces high inter-team dependency density requires either a lower IC-to-manager ratio (more managers per engineer, each carrying less coordination overhead) or an explicit retirement of the player-coach contribution expectation. Documenting the coordination model assumption in the founding ADR makes this coupling visible before the attrition data reveals it empirically.

Property 2: The hiring bar and the capability threshold failure mode. A hiring bar defined as a seniority proxy screens for the general capability profile represented in the team at the time the bar is set. It does not screen for the specific capability domains that will become critical as the product's infrastructure evolves. A team that is strong at building features in a familiar technology stack may be collectively inexperienced in operating the infrastructure those features require at scale: database performance tuning under complex query loads, distributed cache coherence under high write concurrency, CDN configuration for heterogeneous API traffic patterns, message broker throughput optimization under sustained load. These capability gaps are invisible as long as the product's infrastructure demands do not exceed the team's collective experience. They become visible abruptly, as production incidents that cost disproportionate investigation time relative to their root cause complexity, as consulting engagements that reveal in hours what the team could not find in weeks, or as SLA breach conversations with enterprise customers. The capability threshold is the moment when a production infrastructure problem arrives that no one on the team has encountered before in a context where they had to solve it without guidance. The time-to-resolve delta between a team with a specialist in the relevant domain and a team without one is frequently measured in hours versus weeks — not because the non-specialists are worse engineers, but because certain infrastructure failure modes have characteristic signatures that are recognizable only with prior exposure to the same failure class. The capability map is the document that makes this threshold visible before it is crossed: for each capability domain that is critical to the product's current or near-term infrastructure requirements, what is the minimum viable team coverage (at least one engineer with deep experience, at least two engineers with working familiarity, specific certifications or production exposure requirements), and what is the trigger for reviewing the map when the product's technical requirements change? The on-call rotation design decision record specifies who handles incidents in each capability domain; a team that cannot diagnose incidents in a specific domain efficiently cannot design an effective rotation for those incidents, because the rotation assumes a minimum capability level that may not exist — connect the capability map to the rotation design to make this dependency visible before an incident reveals the gap operationally.

Property 3: The onboarding effectiveness threshold and the ramp time surface. Informal onboarding — shadow a senior engineer for two weeks, take your first ticket in week three — is effective when the new-to-experienced mentor ratio is low enough that senior engineers have genuine availability to mentor. The ratio threshold is not determined by headcount alone; it is determined by the availability of senior engineers who are not currently delivering against hard commitments. A senior engineer in the middle of a milestone delivery has a mentoring availability of near zero regardless of whether the organization has a 1:8 or a 1:4 ratio. The effective mentoring capacity at any given hiring cohort is the number of senior engineers with protected time — time that has been explicitly removed from delivery commitments for the purpose of mentoring. Informal onboarding assumes this protected time will exist naturally; structured onboarding creates it explicitly by assignment. When the informal assumption is correct — when senior engineers genuinely have discretionary time during the new hire's first four weeks — informal onboarding produces fast and relatively variable ramp times, with the variation explained by individual difference in the new engineer's experience profile. When the informal assumption is incorrect — when senior engineers are simultaneously delivering against commitments and mentoring new engineers — informal onboarding produces slow and increasingly variable ramp times, with the variation explained by the availability lottery: which new engineer got the mentor with more discretionary time. The ramp time surface is the product of (cohort size) × (per-engineer mentoring deficit). It grows when cohorts are large relative to available mentoring capacity and shrinks when capacity is protected. The founding onboarding decision must document the effective new-to-experienced ratio and the transition protocol for switching from informal to structured onboarding when a planned cohort would exceed it — not as a policy for future teams to discover on their own, but as an explicit parameter with a named threshold and a documented alternative that activates automatically when the threshold is crossed. The CI/CD pipeline decision record determines when new engineers can safely deploy independently; structured onboarding connects to the pipeline by defining the milestone at which a ramping engineer progresses from supervised deployments with a buddy to independent deployments — the onboarding milestone structure and the pipeline's deployment authorization model are joint constraints on the time-to-productive-contribution timeline.

What the founding session records and what it omits

The founding team growth session — typically a combination of a hiring planning meeting, a job description drafting session, and a "how will we onboard people" conversation sometime between the first and third hire — records the ratio, the bar, and the process. What it does not record is the context those decisions depend on: the coordination demand that the ratio was calibrated against, the capability distribution that the hiring bar was designed to produce, the mentoring availability that the onboarding model assumed would exist for every cohort.

These omissions are structurally identical to every other founding-session decision in this series: the failure modes are theoretical at founding, when the team is small, the product surface is bounded, the hiring bar is applied in a single-context environment, and the new engineers are joining a team where everyone is available and nothing is on fire. A recalibration trigger for the IC-to-manager ratio is unnecessary when there are two engineers and one manager and the ratio has no meaningful alternative. A capability map is unnecessary when the team is building features against a simple monolith with no specialized infrastructure demands. A structured onboarding protocol is unnecessary when the team hires one engineer at a time and the senior mentor has no competing commitments.

The failure modes develop on different timelines. The coordination overhead surface grows as the product surface and the team grow together — it can arrive at month twenty-four in a fast-growing B2B SaaS and not appear at month thirty-six in a company growing more deliberately, but it arrives reliably when the founding ratio is never recalibrated. The capability threshold failure mode arrives when the product's infrastructure requirements first exceed the team's collective experience profile — which is not a function of team size but of the specific infrastructure evolution the product undergoes. The ramp time surface grows as a function of cohort size relative to mentoring capacity, which compounds each time a large cohort is hired without a structured alternative to informal mentoring being activated.

The team growth ADR closes these gaps not by predicting which failure mode will arrive first, but by documenting the coordination model, the capability map, and the onboarding effectiveness threshold that allow each failure mode to be detected before it produces an attrition wave, a multi-week production investigation, or an investor update that describes headcount growth without corresponding velocity growth. The decisions never written down in the team growth domain are rarely the ratio, the bar, or the process itself — the 1:8 ratio appears in the hiring doc, the seniority requirement appears in the job description, the two-week shadowing protocol appears in the onboarding guide. They are the coordination overhead assumption that determines when the ratio breaks, the capability map that the bar was implicitly trying to produce, and the new-to-experienced ratio threshold that determines when the informal onboarding model becomes an informal ramp-time damage mechanism. The new CTO onboarding problem is acute for team structure specifically: the incoming technical leader finds the IC-to-manager ratio in the engineering handbook, the hiring bar in the job descriptions, and the onboarding protocol in the new hire guide — but cannot determine why the ratio was set at 1:8 rather than 1:6, whether the player-coach contribution expectation has been honored in practice or has silently eroded, whether the hiring bar was designed against a capability map or against a set of high-quality recent hires who happened to be senior, or whether the 127-day average ramp time in the last cohort represents a deviation from a historical baseline or the new normal. The team growth ADR makes those decisions explicit, auditable, and findable before three EMs quit citing role misalignment, before a six-week database investigation reveals a capability gap that a one-page capability map would have flagged eighteen months earlier, and before the Series A investor update attributes lower-than-projected velocity to "ramp time" without a plan for addressing the structural cause. The WhyChose extractor finds the team growth discussions in your AI session history — the conversation where the founding engineer chose the management ratio, set the hiring bar after a difficult termination, or decided how new engineers would be onboarded — and surfaces the commitments made in those sessions, so you can check which of the three organizational model elements were documented and which were left to drift as the team, product surface, and hiring cohort size grew.

The engineering team growth ADR: five sections

Section 1: IC-to-manager ratio specification and coordination model. Specify the IC-to-manager ratio and the coordination demand assumption it is calibrated against. Document what "coordination demand" means concretely: the number of cross-team dependencies the team's work generates, the number of recurring coordination meetings the manager is expected to attend, the number of shared services the team either owns or depends on that require cross-team coordination for changes, and the product surface complexity (number of distinct product areas) that the team owns. If the player-coach model is adopted — an expectation that EMs contribute code for a specified fraction of their time — document the fraction, the types of contributions that satisfy the expectation (production feature code, code review of complex PRs, architectural spikes, or some combination), and the coordination demand ceiling above which the contribution expectation is formally retired rather than silently violated. Specify the recalibration trigger: the conditions under which the ratio is reviewed — after any product surface expansion that increases inter-team dependency count by more than fifty percent, after any quarter in which two or more EMs on the rotation report zero code contributions, after any attrition event where the departing manager cites role-expectation mismatch. Identify the named owner of the recalibration review and the process for retiring the player-coach expectation formally rather than allowing the gap between documented expectation and practiced role to persist invisibly. The incident response playbook decision record connects here: the team topology and manager span directly determine the escalation path available during incidents — a manager with a full coordination calendar cannot function as an effective incident coordinator for their team's issues while simultaneously covering cross-team dependencies.

Section 2: Hiring bar and capability map. Specify the hiring bar and the capability map that the bar is designed to produce. Document the two-level structure: first, the general quality standard (seniority proxy, take-home assessment threshold, interview panel composition and approval requirement); second, the capability map, specifying for each critical capability domain — the infrastructure categories that are essential to the product's current and near-term operation — the minimum viable team coverage (at least one engineer with demonstrated production experience in this domain, at least N engineers with working familiarity, specific onboarding or certification requirements). For each capability domain in the map, document the current team's coverage level honestly: who has the required depth, what the gaps are, and what the plan is for closing each gap (next hire to specifically recruit for this domain, internal development program, consulting arrangement until the hire is made). Specify the review trigger: the conditions under which the capability map is reviewed and updated — after any production incident where investigation time exceeded 24 hours and a capability gap was identified as a contributing factor, after any product evolution that introduces new infrastructure domains (switching from SQL to NoSQL, adopting a message broker, deploying to a new cloud region with distinct compliance requirements), after any major enterprise contract signing that introduces new SLA domains the team has not previously operated against. Specify who owns the capability map review and how the review output translates into a hiring prioritization change for the next open engineering requisition.

Section 3: Onboarding effectiveness threshold and structured transition protocol. Specify the onboarding model and the effective new-to-experienced ratio it depends on. Document the informal onboarding protocol: the number of weeks of shadowing, the shadowing format (structured sessions versus open-door co-working), the milestone at which the new engineer takes their first ticket, and the expected time-to-productive-contribution at the protocol's target operating conditions. Document the target operating conditions explicitly: the ratio of new engineers to available senior mentors is at most N:1, where "available" is defined as a senior engineer who has no hard delivery commitment during the new hire's first four weeks. Specify the structured onboarding protocol that activates when a planned hiring cohort would exceed the effective ratio: the buddy assignment process with protected time (the buddy is removed from delivery commitments for the first four weeks of the new hire's tenure, with feature work redistributed rather than expected to continue in parallel), the written knowledge transfer checklist, the week-2, week-4, week-8, and week-12 milestone structure with specific observable deliverables, and the maximum cohort size that can be onboarded simultaneously under the structured protocol given the team's current senior engineer count. Specify the review trigger: after any cohort where the average time-to-productive-contribution exceeded the protocol target by more than thirty percent, conduct a structured review of the mentor availability and cohort size versus the effective ratio documented in this ADR. Also specify the pipeline connection: the milestone at which a ramping engineer progresses from supervised deployments — requiring explicit approval from their buddy before each deployment — to independent deployments, defined in terms of the week-N milestone structure rather than left to informal judgment.

Section 4: Growth trigger documentation and team composition review cadence. Specify the triggers that cause the entire team growth ADR to be reviewed — not just individual sections, but the whole organizational model, to check whether the ratio, the capability map, and the onboarding model are still calibrated against the team and product that currently exist rather than the team and product that existed when the ADR was last updated. Growth triggers are distinct from section-specific recalibration triggers: they fire when the organizational complexity crosses a discontinuous threshold, not when a specific metric exceeds a boundary. Document the growth triggers explicitly: team size crossing fifty engineers (the point at which most informal coordination mechanisms require replacement with structured equivalents), product surface doubling (the point at which the coordination model calibrated against the current surface becomes unreliable for the new surface), a geographic split (the first hire in a timezone that does not overlap with the core team for more than four hours per day), a new product line (distinct from adding features to the existing product — a separate product with its own engineering requirements, customer base, and infrastructure needs). For each trigger, specify the review scope (which sections of the ADR are affected) and the timeline for completing the review (before the team operates under the new organizational reality, not after the first failure mode becomes visible). Document who is responsible for recognizing when a trigger has fired — the CTO or VP of Engineering is the default, but the recognition mechanism must be explicit, because growth triggers are not surfaced by any dashboard or alert and are missed most often when the leadership team is focused on delivery rather than organizational model validity.

Section 5: Team capability audit and ongoing composition review. Specify the capability audit process that keeps the capability map current as the team evolves through attrition, internal growth, and successive hiring cohorts. The audit has three components. First, the departure review: when any engineer leaves the team, review the capability map against the remaining team's composition and identify which capability domains lost coverage, what the minimum viable coverage threshold is for each affected domain, and whether the impact is immediate (the departing engineer is the sole holder of a critical capability), deferred (coverage remains above minimum but below the target threshold), or negligible (sufficient coverage remains). Second, the growth review: when an engineering hire is made, document how the new engineer's capability profile changes the team's coverage map and which gaps were closed or partially closed. Over time, the sequence of departure reviews and growth reviews produces a running audit trail of the team's capability composition that is visible to the next technical leader rather than requiring reconstruction from memory. Third, the periodic audit: every six months, review the capability map against the product's current infrastructure requirements — not the requirements that existed when the map was last written, but the requirements that exist now — and identify which domains have grown more critical since the last review and whether the team's coverage has kept pace. Connect the periodic audit to the hiring plan for the following six months so that capability gaps identified in the audit produce concrete hiring prioritization changes rather than observations that are filed and not acted on. The decisions never written down in the capability domain include not just the initial map but the accumulation of departure reviews and growth reviews that, taken together, tell the story of how the team's capability composition has changed over time and why specific hiring decisions were made in the sequence they were made. That accumulation is the context that the incoming technical leader would need to evaluate the current team's capability against the product's next infrastructure challenge — and it is precisely the context that disappears when it lives only in the memory of the people who made the decisions.

FAQ