The engineering reorg decision record: why the reorg model you chose determines your change absorption rate and your coordination reset cost

A 22-person developer tools startup had been organized into three functional teams for its first three years: a frontend team of five, a backend team of eight, and an infrastructure team of four, with two data engineers and a mobile engineer reporting directly to the CTO. The structure had worked well through the startup's early stage. In its fourth year, as the product grew to cover three distinct surfaces — a web application, a CLI tool, and a REST API consumed by enterprise integrations — the CTO began receiving feedback from team leads that feature delivery was consistently slower than it should be. The frontend and backend leads each described the same friction independently: every new feature required a three-way specification negotiation between frontend, backend, and infrastructure before implementation could begin, followed by a sequential handoff — frontend waiting for backend to complete its piece, backend waiting for infrastructure to review the deployment requirements — that added two to three weeks to each feature's end-to-end timeline regardless of the feature's complexity.

The CTO diagnosed the problem as structural: the functional team boundaries were imposing coordination overhead on the tightly coupled work of feature delivery. He proposed a reorganization into two cross-functional product teams, each owning one of the primary product surfaces, with the infrastructure team becoming a shared platform function. The proposal was well-received by the frontend and backend leads, who agreed the current structure was creating friction. The reorg was designed over two weeks, announced to the company, and implemented over a four-week transition during which engineers moved to their new teams, agreed on new sprint rituals, and updated their repository ownership.

Six months after the reorg, the CTO reviewed the delivery timelines for the eight features that had been completed in the post-reorg period. The average end-to-end timeline had improved by four days — from 19.2 days to 15.3 days. But the improvement was not distributed uniformly: the four features that had been delivered in the first three months averaged 17.8 days, barely different from the pre-reorg baseline. The four features delivered in months four through six averaged 12.8 days, a substantial improvement. When the CTO traced the month-four inflection, he found it did not correspond to the reorg itself. It corresponded to a process change the new product team leads had implemented in month three: a shared feature specification template that required backend, frontend, and infrastructure acceptance criteria to be finalized in the same document before any implementation began, eliminating the sequential specification negotiation by making it a parallel synchronous activity rather than a series of bilateral conversations. The CTO's retrospective finding was uncomfortable: the four-day delivery improvement that materialized in months four through six was produced by the new specification template, not by the new team structure. The previous structure could have adopted the same template without a reorg. The reorg had imposed six months of coordination reset cost — the time for fifteen engineers to rebuild working relationships across new team boundaries, reestablish on-call ownership, and reconstruct the tacit familiarity with each other's implementation patterns — in exchange for a structural change whose contribution to the delivery improvement was not separable from the process change that followed it and might have been zero.

A 46-person B2B SaaS had been organized by function for its first four years: a backend team of eighteen, a frontend team of eleven, a platform team of seven, a data team of five, and a QA function of three, with each function led by a senior engineer or engineering manager reporting to the VP of Engineering. The VP who had built the structure departed after a Series B fundraise, and a new VP of Engineering joined with a mandate from the board to increase delivery velocity. The new VP's assessment in her first sixty days: the functional structure was producing exactly the coordination overhead the research literature on functional versus product-aligned structures predicted — long handoffs between functions, features requiring three or four sprint cycles to cross from specification to production, and a delivery cadence that the sales team described as unpredictable.

The new VP proposed a reorganization into three product-aligned stream teams, each owning a primary customer segment's product surface, with the platform team preserved as a shared enabling function and the QA function embedded one person per stream team. The rationale was well-articulated: product-aligned teams would collocate the engineers whose work was most tightly coupled, reducing handoff latency from inter-team coordination to intra-team communication. The transition plan was thorough — two months of parallel structure during which new team identities were established before functional team identities were dissolved, explicit working agreements for how the stream teams would coordinate with the platform function, and a knowledge transfer schedule for ensuring that each stream team contained at least one engineer with deep familiarity with the system areas the team would own. The board approved the reorg, the VP presented it to the company with confidence, and the four-month transition began.

Nine months after the reorg completed, the VP's delivery velocity metric had improved: the median feature cycle time had dropped from 28 days to 19 days, a 32% improvement that she presented to the board as evidence that the structural hypothesis had been confirmed. The board was satisfied. The VP of Engineering who had been in the role for fourteen months accepted this result as success.

What the delivery velocity metric did not capture: in the seven months following the reorg, three of the company's eight senior engineers had given notice and departed. All three had been members of the backend function. In exit interviews, all three gave variations of the same explanation. The functional team had been their professional home — the environment in which they received technical feedback from engineers with comparable depth and domain knowledge, shared context on system-wide architectural trade-offs, and developed their technical judgment through peer review with people who could evaluate their choices at a level of specificity that product managers and junior engineers could not. The product-aligned teams had distributed them across three different stream teams, each of which contained two or three mid-level engineers and one junior engineer in addition to the senior engineer who had joined from the backend function. The senior engineers were no longer each other's colleagues; they were each other's occasional cross-team coordination contacts. The peer network that had been their reason for staying had been eliminated by the reorg's logic. The VP's measurement model had captured the coordination improvement the new structure produced and had not captured the departure risk it created, because the departure risk was concentrated in a dimension — the value of the functional peer network to senior engineers' professional development and retention — that did not appear in the delivery velocity metric the reorg had been designed to improve. Replacing three senior engineers required seven months of sourcing, produced eighteen months of ramp time across the three replacements, and cost the company an estimated $340,000 in recruiting fees and productivity loss. The structural benefit of the reorg — a 32% improvement in median feature cycle time — was real. The total cost of the reorg, including the coordination reset cost and the departure-driven replacement cost, was higher than the VP's model had projected by a factor of roughly two.

A 71-person enterprise SaaS had undergone four significant reorganizations in five years. The first was a functional-to-product reorganization in year two, designed to reduce handoff latency as the team scaled past thirty engineers. The second was a correction back toward functional grouping in year three, after two of the product-aligned teams had developed incompatible infrastructure patterns without a functional authority to maintain consistency. The third was a hybrid model in year four, combining cross-functional delivery teams with functional guilds that maintained standards without formal authority. The fourth was a consolidation in year five, simplifying the hybrid model after two teams complained that the guild obligations were adding coordination overhead that cancelled out the delivery velocity the delivery team structure was meant to produce.

Each reorganization had been thoughtfully designed by the engineering leader who sponsored it. Each had a coherent rationale. Each had addressed a real coordination friction that the previous structure had produced. Each announcement email had begun with a diagnosis of what the current structure was failing to achieve and a hypothesis about what the new structure would enable. None had referenced the decisions that had produced the structure being replaced, and none had engaged with the fact that the new structure bore a structural resemblance — in at least one case, a near-identical resemblance — to a structure the company had already tried and moved away from.

In year six, a new VP of Engineering joined after the previous VP's departure. In his first month he asked each engineering lead to explain the current team structure and why it was organized the way it was. The answers clustered around two categories: recent history — the fourth reorg's rationale, which most people remembered because it had happened eighteen months earlier — and institutional legend — generalized statements like "we tried functional structures and they didn't work" and "product-aligned teams are what the research says to do." Nobody could answer precisely why the third reorg's hybrid model had been abandoned. Nobody could articulate what specific failure the second reorg's return to functional grouping had been trying to address. The founding CTO who had designed the first reorg had left two years earlier and had not documented the reasoning in any artifact that had survived his departure. Four reorganizations had produced four sets of working agreements, four sets of on-call configurations, and four sets of team identities — and had left behind a collective institutional knowledge of the organization's structural reasoning that was, in practice, eighteen months deep. The new VP described the condition as structural amnesia: the org retained the current structure in full fidelity and had lost the reasoning that had produced it almost entirely. Each previous VP had designed the new structure from their best judgment about what would work, without access to the evidence about what the previous structures had actually achieved — the delivery velocity before and after each reorg, the coordination overhead in the new structure versus the old one, and the departure events that each structural change had contributed to. The result was an organization that had spent five years cycling through structural experiments and accumulating the costs of each transition without accumulating the institutional knowledge that would allow the current experiment to be calibrated against the ones that had preceded it.

Structural properties set by the engineering reorg decision

Two structural properties are determined by the founding decisions about reorg triggers, structural hypotheses, transition scaffolding, and measurement models. Both are invisible when the engineering organization is small enough that a structural change can be absorbed informally and the productivity dip is short enough to be treated as transition noise; both become visible when the org is large enough that a reorg takes months for teams to find their working rhythm, when the coordination reset cost exceeds the coordination improvement the new structure produces, and when the org has reorged often enough that the institutional knowledge of why previous structures were chosen has been replaced by structural amnesia.

Property 1: Change absorption rate. The change absorption rate is the speed at which the organization recovers its pre-reorg productive throughput after a structural change — bounded by three factors. First, structural hypothesis clarity: whether the reorg was designed around a specific, falsifiable hypothesis about which bottleneck the new structure would eliminate, or whether it was designed around a general intuition that the new structure would produce better coordination. The first story illustrates the consequence of a hypothesis that was plausible but not falsifiable against the available evidence: the CTO correctly identified coordination overhead as the delivery bottleneck but did not test whether the overhead was inherent to the functional boundary or was instead produced by the sequential specification process that sat on top of that boundary. A specific hypothesis — 'collocating frontend and backend ownership on the same team will reduce the specification handoff that currently adds 2.4 weeks to each feature cycle' — would have produced a testable prediction that could be separated from the process change that actually drove the improvement. Without a specific hypothesis, the reorg absorbed six months of coordination reset cost and produced an improvement whose structural contribution remained ambiguous throughout. Connect this to the engineering org design decision record: the org design decision specifies the team boundary model and the enabling function structure; the reorg decision specifies when those boundaries warrant reconsideration and what evidence would confirm or disconfirm that the new boundaries produce the improvement the change was designed to achieve. An org design without a reorg validation model will eventually produce a reorg without a structural hypothesis, because the absence of a validation framework means no evidence has been accumulated to constrain what changes are warranted. Second, transition scaffolding model: whether the reorg design included an explicit transition plan for the period when the new boundaries exist but the working relationships across them have not yet formed — working agreements for the new team rituals, a knowledge transfer protocol for the domain knowledge that will now sit across a new team boundary, and explicit coordination norms for the teams whose working relationships will change most significantly. A reorg that is designed as a structural event — change the org chart, announce the new teams, expect the working relationships to follow — will absorb throughput for longer than one that explicitly funds the working relationship reconstruction activities the new structure requires. Third, coordination pattern inventory: whether the reorg design started from a map of the current coordination patterns the org relied on and designed the new structure to preserve the load-bearing ones, or whether it designed the structure from first principles and allowed the coordination patterns to reconstitute themselves under the new constraints. A reorg that eliminates an ambient, load-bearing coordination pattern — a cross-team peer review ritual, an informal escalation path, a shared oncall channel that provided situational awareness about system-wide issues — will spend its recovery period rediscovering what the missing pattern was providing. Connect this to the engineering knowledge management decision record: the knowledge management decision specifies how system knowledge is captured and transferred; the reorg decision creates the most significant knowledge transfer event in the engineering organization's lifecycle, and its change absorption rate is largely determined by whether the knowledge management system is robust enough to survive the team boundary change or whether key knowledge walks out with the engineers who move to new teams and leave their previous system areas behind.

Property 2: Coordination reset cost. The coordination reset cost is the accumulated organizational cost of rebuilding the team mental models, working trust, and informal coordination infrastructure that a structural change disrupts — bounded by three factors. First, boundary change depth: how many of the existing working relationships each engineer's reorg crosses. A reorg that moves the formal org chart but preserves the working group composition — moving reporting lines while keeping team adjacencies intact — has a coordination reset cost that is primarily administrative. A reorg that disperses a tight working group across new product teams — as the second story's functional-to-product reorg did — requires each engineer to rebuild the working trust, communication shorthand, and mutual predictability that the functional team had accumulated. The second story's departure pattern is the boundary change depth consequence at its most costly: the three senior engineers whose departure produced $340,000 in replacement cost were not making a rational calculation about the new org chart; they were responding to the loss of a working relationship environment that had taken years to build and that the reorg had eliminated as a byproduct of its structural logic. A reorg design that inventories the working relationships with the highest value-to-replacement-cost ratio — typically the peer relationships of the most senior engineers — and designs the new structure to preserve those relationships, even at the expense of the structural elegance the org design would otherwise achieve, will produce a lower coordination reset cost than one that optimizes for structural purity without accounting for departure risk. Connect this to the engineering headcount planning decision record: the headcount planning model specifies the sourcing and ramp timeline for replacement hires; the reorg decision creates the most predictable source of senior-engineer departure risk in the organization's lifecycle, and the replacement cost of that departure risk should be explicitly modeled against the structural benefit the reorg is designed to produce before the reorg is approved. Second, tacit knowledge surface: how much of the team's productive capacity resided in tacit knowledge that was held within the existing team boundary and will need to be reconstructed, transferred, or rediscovered under the new structure. A team with dense explicit documentation — decision records, runbooks, system design documents — has a lower coordination reset cost than one whose operating knowledge is primarily oral, because the documentation survives the boundary change while the oral knowledge walks out with the engineer who leaves or is dispersed to a team that no longer has contact with the original context. Connect this to the engineering team growth decision record: the team growth model specifies how the organization adds engineers and how knowledge is transferred across generations of team composition; the reorg decision is a forced team composition change at scale, and its coordination reset cost is largely determined by whether the knowledge transfer infrastructure that the team growth model built is robust enough to handle a boundary change that was not planned as part of the growth trajectory. Third, departure risk concentration: whether the proposed reorg creates conditions that are specifically adverse for a concentrated subset of engineers. The second story's departure pattern was concentrated because the dissolution of the functional peer network was specifically adverse for the senior engineers who had relied on that network for technical growth — a risk that did not appear in the delivery velocity metric and was not part of the VP's reorg model. A reorg that creates departure risk in a concentrated population — the senior engineers whose peer network dissolves, the on-call engineers whose system ownership is redistributed without adequate knowledge transfer, the engineers whose functional identity was central to their professional development trajectory — will produce a higher coordination reset cost than one that designs explicitly for retention of the highest-departure-risk population, even if the structural logic of the latter is less clean. Connect this to the engineering performance management decision record: the performance management model specifies how the organization develops and retains engineers; the reorg decision creates the highest-risk window for departure of engineers who are performing well but whose conditions for continued growth have been disrupted by the structural change, and the performance management model should include an explicit reorg retention protocol — targeted 1:1s, accelerated development commitments, and explicit acknowledgment of what the structural change has cost the affected engineers — to reduce the departure probability during the transition window.

The engineering reorg ADR: five sections

Section 1: Reorg trigger model. The reorg trigger model specifies the conditions under which a structural change becomes warranted rather than merely considered, and the diagnostic process for confirming that those conditions exist. Two categories of trigger evidence should be required before a reorg is initiated. Structural evidence: the coordination friction can be traced specifically to the current boundary model — to the fact that the engineers whose work is most tightly coupled are organizationally separated in a way that requires them to coordinate across a high-latency inter-team boundary rather than within a low-latency intra-team boundary — rather than to working agreements, decision rights, or communication channels that could be changed without moving the boundary. Structural evidence requires a coordination map: an inventory of the actual coordination patterns the org relies on, the latency of each pattern (how long does it take to resolve a decision that requires input from engineers on both sides of this boundary?), and the frequency of each pattern (how often per sprint does this boundary require coordination?). High-latency, high-frequency coordination patterns across a specific boundary constitute structural evidence; high-latency, high-frequency patterns that do not cluster at a specific boundary are process evidence. Duration evidence: the coordination friction has persisted for at least two full sprint cycles despite at least one attempt to address it through process changes — new working agreements, revised decision rights, or explicit coordination rituals — that did not produce meaningful improvement. Duration evidence prevents reactive reorgs triggered by temporary friction spikes (a difficult feature delivery, an unusual cross-team dependency, a brief period of unusual team stress) from being misdiagnosed as structural problems. The trigger model should also specify what the reorg is explicitly not a solution for: performance problems in specific engineers (which the performance management model addresses), interpersonal conflict (which the management chain addresses), and product strategy changes (which require a product strategy decision, not a structural one, because a structural change designed to execute a product strategy that changes again six months later produces a reorg whose coordination reset cost was incurred without a durable benefit). An org that waits for both structural evidence and duration evidence before initiating a reorg will initiate fewer reorgs and will produce higher-quality hypotheses for the ones it does initiate.

Section 2: Structural hypothesis model. The structural hypothesis model specifies the precise prediction the proposed reorg is designed to test: which coordination bottleneck the new structure will eliminate, how that elimination will be measured, and what the prediction horizon is for the measurement. The hypothesis should be stated in the form of a falsifiable prediction — 'moving the authentication and authorization service from the platform team's ownership to the identity stream team's ownership will reduce the median cycle time for identity-related feature requests from the current 18.4 days to under 11 days within two quarters of the transition, because the primary bottleneck is the inter-team specification negotiation between the identity engineers who implement the features and the platform engineers who own the infrastructure those features depend on' — rather than a general expectation — 'product-aligned teams will deliver features faster because engineers will be working on related problems.' A falsifiable prediction produces three advantages. It constrains the reorg design: the structural change should be the minimal change required to test the hypothesis, not the maximally restructured org that a clean-slate design would produce. Reorgs that are designed to test a specific hypothesis tend to be smaller in scope than reorgs designed to fix the org chart, and smaller-scope reorgs have lower coordination reset costs. It enables early detection of failure: if the predicted metric has not moved in the expected direction six weeks after the transition, the reorg design has failed to produce the predicted effect and should be investigated before the full coordination reset cost has been incurred. Correcting a reorg that is not working eight weeks in is substantially cheaper than discovering the same failure at eight months. It accumulates the institutional knowledge that prevents structural amnesia: the hypothesis, the prediction, and the measurement outcome together constitute the structural decision record that allows the next engineering leader to understand not only what the current structure is but why it was chosen and what conditions would warrant revisiting it. Connect this to the third story's amnesia pattern: structural amnesia is the direct consequence of a reorg culture that operates on intuition rather than hypotheses, because intuition leaves no institutional artifact that survives leadership transitions.

Section 3: Change absorption model. The change absorption model specifies how the organization will sustain throughput during the transition window and what the recovery timeline prediction is for the new teams to reach the working rhythm the pre-reorg teams had achieved. Three components. Transition scaffolding: the explicit set of activities that will be funded during the transition window to accelerate the working relationship reconstruction the new structure requires. At minimum: a structured knowledge transfer protocol for each team boundary change that involves engineers moving away from systems they have deep familiarity with, specifying what knowledge needs to transfer, to whom, in what format, and within what timeline; a new team kickoff process for each new team composition that explicitly surfaces the working agreements that the team members are importing from their previous teams and produces a shared set of norms for the new team rather than allowing incompatible norms to coexist implicitly; and a cross-team coordination specification for the highest-frequency coordination patterns between the new teams, naming the mechanism (shared channel, weekly sync, async document, explicit decision authority) for each pattern rather than allowing the pattern to find its own form during the transition. Working rhythm prediction: an explicit estimate of how long each new team will take to reach the working rhythm the pre-reorg teams had, based on the depth of the boundary changes each team member is experiencing. The prediction should distinguish between the administrative ramp — new reporting lines, new tooling, new sprint rituals — which typically resolves in four to six weeks, and the relationship ramp — the tacit communication shorthand, predictive awareness of teammates' working patterns, and mutual calibration on decision quality standards — which typically requires four to eight months for a team that has not previously worked together in this configuration. Delivery commitment buffer: an explicit reduction in the delivery commitments the new teams are held to during the transition window, sized to the working rhythm prediction and communicated to stakeholders before the reorg is announced rather than after the first missed sprint commitment reveals that the transition cost was underestimated. A delivery commitment buffer that is communicated in advance is a demonstration of organizational honesty; a delivery miss that was predictable and not communicated is a demonstration of organizational optimism that erodes trust in the engineering team's ability to forecast its own capacity. Connect this to the engineering org design decision record: the org design decision specifies the steady-state team model; the change absorption model specifies what the transition from the previous steady state to the new one will cost and how the organization will fund that cost.

Section 4: Coordination reset model. The coordination reset model specifies the explicit estimate of the coordination reset cost — the total organizational cost of rebuilding the team mental models, working trust, and informal coordination infrastructure that the structural change disrupts — disaggregated into its components so that the cost estimate is auditable and the post-reorg measurement can confirm or revise it. Three cost components. Productivity disruption cost: the estimated below-baseline throughput during the transition window, calculated as the estimated productivity percentage by phase (administrative disruption at 15–25% below baseline for months one and two; knowledge reconstruction at 10–15% below baseline for months three through five; stabilization at 0–8% below baseline for months six through eight), multiplied by the number of engineers affected by the most significant boundary changes in each phase, multiplied by the fully-loaded cost per engineer per month. The productivity disruption estimate should be bounded by the working rhythm prediction from the change absorption model. Departure risk cost: an explicit identification of the engineers in the proposed structure whose conditions for continued growth and retention are most adversely affected by the boundary changes — typically the senior engineers whose functional peer network will dissolve, the on-call engineers whose system ownership will be redistributed, and the engineers whose team identity is most tightly bound to the functional structure being changed — and an estimate of the probability that one or more of those engineers will depart during the transition window, multiplied by the replacement cost. The replacement cost should be sourced from the headcount planning model: the sourcing duration, recruiting fee, and ramp time for a senior engineer in the relevant role category. An explicit departure risk estimate prevents the second story's outcome, where the departure cost appeared as a surprise after the reorg was announced rather than as a known risk that the reorg design had been optimized to reduce. Structural debt cost: an estimate of the technical coordination debt the new structure will create — the increased cross-team dependencies, the new shared ownership arrangements, the split system areas that will require explicit coordination protocols rather than informal intra-team communication — and the engineering investment required to make the new structure's coordination overhead manageable rather than accumulating. The structural debt cost is typically the most underestimated component of the coordination reset cost, because it appears gradually as the new teams begin to work together and discover the coordination patterns the new boundary has made more expensive rather than less. The total coordination reset cost estimate should be presented alongside the structural benefit estimate before the reorg is approved, so that the decision-maker is explicitly choosing a structural change whose projected benefit exceeds its projected cost rather than approving the structural change for its theoretical merit and discovering the cost empirically.

Section 5: Reorg health model and structural decision record. The reorg health model specifies how the outcome of the reorg will be measured against its structural hypothesis, and what conditions trigger a reassessment rather than a second reorg. Three measurement dimensions. Hypothesis validation: whether the specific metric named in the structural hypothesis has moved in the predicted direction within the prediction horizon. If the metric has moved as predicted and the coordination reset cost was within the modeled range, the structural hypothesis is confirmed and the decision record should capture the confirmation, including the conditions under which the new structure was predicted to remain effective and the scale points at which it would warrant reconsideration. If the metric has not moved as predicted, the hypothesis is disconfirmed and the decision record should capture whether the disconfirmation was caused by an incorrect structural diagnosis (the bottleneck was elsewhere), an insufficient transition (the working relationship reconstruction was not funded adequately), or an exogenous event (a product strategy change or a major departure that was not part of the reorg model). A disconfirmed hypothesis should produce a structured post-mortem before any subsequent structural change is considered, because a reorg designed to fix a disconfirmed hypothesis will replicate the structural diagnosis error that produced the first disconfirmation. Coordination overhead measurement: whether the specific high-latency, high-frequency coordination patterns that constituted the structural evidence for the reorg have been eliminated or reduced in the new structure. The measurement should include both the patterns the reorg was designed to address and the new patterns the reorg has created, because a successful reorg eliminates the specific friction it was designed to address but should not create equivalent or greater friction elsewhere in the structure. New friction patterns that reach the structural evidence threshold — high-latency, high-frequency, persisting across two sprint cycles despite process changes — should trigger the reorg trigger model's diagnostic process rather than an automatic new structural change, because new friction patterns are as likely to have process causes as structural ones. Structural decision record: an append-only log entry capturing the reorg's trigger evidence, structural hypothesis, coordination reset cost estimate, actual coordination reset cost, hypothesis validation outcome, and the conditions under which the structure is predicted to remain effective. The log entry should be stored in the version-controlled engineering documentation repository and should be explicitly referenced in the onboarding materials for new engineering leaders, so that the structural history the org has accumulated is part of the institutional knowledge each new leader inherits rather than part of the oral legend that fades as the people who were present move on. Connect this to the engineering knowledge management decision record: the structural decision record is the application of the knowledge management model to the organization's structural history, and the knowledge management system should include the structural decision log as a first-class artifact alongside the technical decision records, ADRs, and post-mortems it was designed to preserve. The structural amnesia pattern the third story documents is not caused by organizational forgetting — it is caused by organizational knowledge management that treats technical decisions as worth preserving and structural decisions as context that lives in the heads of the leaders who made them, available to the organization for exactly as long as those leaders remain.

FAQ

Further reading

• Engineering org design decision record — the org design decision specifies the team boundary model and the enabling function structure; the reorg decision specifies when those boundaries warrant reconsideration, and the structural hypothesis model the reorg decision record requires depends on the org design decision record's documentation of why the current boundaries were drawn — without that documentation, the reorg trigger diagnosis cannot distinguish between a boundary that has become structurally obsolete and a boundary that was always correct and is producing friction because of how it is operated.
• Engineering headcount planning decision record — the headcount planning model specifies the sourcing and ramp timeline for replacement hires; the reorg decision creates the most predictable source of senior-engineer departure risk in the organization's lifecycle, and the departure risk cost component of the coordination reset model should be calculated using the headcount planning model's hiring lag estimates for the specific role categories whose departure probability is highest in the proposed structure.
• Engineering team growth decision record — the team growth model specifies how the organization adds engineers and how knowledge is transferred across generations of team composition; the reorg decision is a forced team composition change at scale, and its coordination reset cost is largely determined by whether the knowledge transfer infrastructure the growth model built is robust enough to survive a boundary change that was not planned as part of the growth trajectory.
• Engineering knowledge management decision record — the knowledge management decision specifies how system knowledge is captured and transferred; the reorg decision creates the most significant knowledge transfer event in the engineering organization's lifecycle, and the structural decision record the reorg health model requires is an application of the knowledge management model to the organization's structural history — an organization whose knowledge management system does not include structural decisions as first-class artifacts will produce structural amnesia regardless of how carefully each individual reorg is designed.
• Engineering performance management decision record — the performance management model specifies how the organization develops and retains engineers; the reorg decision creates the highest-risk window for departure of engineers who are performing well but whose conditions for continued growth have been disrupted by the structural change, and the performance management model should include a reorg retention protocol — targeted development commitments and explicit acknowledgment of transition cost — to reduce departure probability during the most vulnerable phase of the coordination reconstruction window.
• Open-source extractor — the reasoning behind engineering reorg decisions — why the structural hypothesis was formed as it was, what departure risk the reorg design was optimized to avoid, what coordination reset cost was projected and on what basis, and what validation mechanism was chosen to confirm whether the structural hypothesis was correct — is reasoning conducted in AI chat sessions that does not survive into the org chart, the announcement email, or the transition plan that the reorg produces; running those sessions through the extractor produces the reorg decision record that allows the next engineering leader to inherit the structural hypothesis and its outcome rather than only the org chart and the institutional legend that surrounds it.