The engineering new manager onboarding decision record: why the onboarding model you chose determines your manager effectiveness ramp ceiling and your first-90-days failure rate

A 19-person developer tools startup promoted a senior backend engineer to engineering manager after a founding engineer stepped back to focus on architecture. The decision was widely regarded inside the company as the right one: the engineer had institutional knowledge, strong relationships with every engineer on the team, and genuine interest in the management path. The onboarding conversation lasted thirty minutes. The VP of Engineering walked through the compensation change, gave the new manager access to the performance review tool, and said "you know the team and you know how we work — you'll figure out the management stuff quickly, and I'm here if you have questions." The new manager left that conversation with a new title, a new salary band, and no model of what the role required that their prior role had not. They began their first week as a manager by doing what they had always done: writing code, reviewing pull requests, joining architecture discussions, unblocking technical decisions on two active platform migration tracks. The 1-on-1s they scheduled with their four direct reports in week one were conversational and project-focused — catch-ups on what each engineer was working on, blockers to clear, technical questions to discuss. By week six, the 1-on-1s had established a pattern: fifteen-minute discussions of current sprint work, coordinated follow-ups on technical decisions, and then the hour returned to the sprint board. The new manager was working harder than they had as a senior engineer. The management responsibilities were not being neglected deliberately; they were invisible. Career development conversations were not on the agenda because no one had specified what a career development conversation was supposed to cover or how often it was supposed to happen. Feedback delivery outside the context of code review was not happening because the new manager had a mental model of feedback as "tell people when something is wrong," and nothing was visibly wrong. Team health monitoring was not happening because there was no model of what team health monitoring was — no template, no check-in questions, no signals to watch for.

Eighteen months after the promotion, two of the four engineers who had been direct reports at the time of the transition had departed. The first departure, at month seven, cited in the exit interview "no real career development support — I had been waiting for a conversation about what the path to senior engineer looked like for four months and it never happened." The second departure, at month fourteen, cited "feeling stuck — I wasn't sure where my growth was going and I didn't have a strong enough relationship with my manager to raise it directly." The new manager processed both departures with genuine confusion: they had been working harder than they ever had as an individual contributor, had written more code than any other engineer on the team in the prior six months, and had cleared technical blockers faster than anyone. The confusion was structural: they had been given a new role and the same framework. The IC framework optimizes for technical contribution and problem resolution. The management framework optimizes for team capability growth, retention, feedback quality, and organizational health — none of which appear on a sprint board, none of which produce the immediate positive feedback signal of a merged pull request or a resolved architecture question. A senior engineer promoted to manager without an explicit model of how the roles differ will default to the prior framework, and the prior framework will feel productive because it is producing real value — just not the value the management role exists to produce. The VP of Engineering's post-mortem conversation with the new manager after the second departure identified the onboarding gap precisely: "I told you to figure out the management stuff, and you did — you figured out what you could see, and everything that required a different model of the role was invisible to you." The observation was accurate and arrived twenty-one months after it would have mattered.

A 55-person B2B SaaS designed its new manager onboarding program deliberately. The program covered five days of structured orientation: HR systems setup, performance review tool training, compensation philosophy overview, manager handbook reading, the engineering career ladder in detail, and a shadow session where the new manager observed a senior manager's 1-on-1 with one of their direct reports. At the end of the five days, the new manager received a copy of a thirty-day check-in template and was told the program was complete. The program was genuinely better than the ad-hoc versions most comparable companies ran. It covered what it covered well. What it did not cover was the specific team the new manager was inheriting: who the engineers were, what each of them was working toward, what the team's current state was, and what the previous manager had left behind. The previous manager had relocated and their departure had been sudden relative to the transition timeline — two weeks between announcement and last day. There had been no formal handoff. The new manager's first week with the team was exploratory: relationship building, sprint kick-off attendance, getting to know the product context. The engineers on the team were welcoming. No one surfaced anything urgent.

In week six, a senior engineer came to the new manager with a concern. A team member — a mid-level engineer who had joined fourteen months earlier — had been delivering inconsistently for the last four months: some sprints fully delivering, others underdelivering by thirty to forty percent, with the shortfall absorbed by other team members across two consecutive features. The previous manager had had a direct conversation with the team member three months before departing, framing it as a coaching conversation rather than a formal performance concern: "I've noticed the delivery inconsistency; I want to understand what's creating it and help you get back to the output level the team needs." The team member had acknowledged the concern, attributed it to a difficult personal situation, and the two had agreed to reassess in the next sprint cycle. The previous manager had tracked the situation informally — notes in a personal document, not in the performance management system — and had planned to assess whether to formalize it at the next review cycle. When the previous manager departed, those notes departed with them. The new manager, hearing the concern from the senior engineer in week six, had no background on the four-month history, no knowledge of the coaching conversation, no visibility into the informal tracking, and no understanding of whether the team member had been told anything about consequences or timelines. The new manager did what seemed appropriate given the information they had: they had a direct conversation with the team member about the delivery pattern. The team member's response was not receptive. From the team member's perspective, they had had a direct conversation with their manager three months ago, had been told it was a coaching conversation rather than a performance concern, had understood that the situation was being monitored informally, and had expected the assessment to happen at the next review cycle. The new manager's conversation — arriving without any of that context, framed as if the delivery concern were new — felt to the team member like the new manager was acting on information from colleagues rather than from their own observation, which was accurate. The team member said this directly: "you've been my manager for six weeks and weren't here for the last four months — why is this being treated as a formal concern now rather than as a continuation of the conversation I already had?" Connect this to the engineering feedback culture decision record: the feedback timing failure here is not a timing decision made by the new manager but an architectural failure in the onboarding model — the context transfer that would have made a timely, appropriately framed intervention possible was never part of the onboarding design, so the intervention arrived with the timing of the new manager's discovery rather than the timing of the issue's development.

The escalation that followed consumed six weeks of the new manager's first quarter: multiple HR conversations, a documentation review that found the informal tracking was insufficient for the outcome being considered, and a process re-do that required the new manager to restart the performance management clock from week six rather than continuing from where the previous manager's coaching conversation had left off. The team member's perception of the situation — that the new manager had acted on secondhand information, had not respected the context of the prior conversation, and had formalized a concern that had been explicitly characterized as a coaching moment — did not improve over the six weeks and was eventually reflected in the team member's decision to leave rather than accept the outcome of the performance process. The team member's perspective, examined with the benefit of context, was reasonable: the onboarding model had produced a new manager who arrived without the information required to manage the inherited situation appropriately, and the resulting intervention was genuinely uninformed in the ways the team member named. The root failure was not the new manager's judgment — given the information they had in week six, their response was reasonable. The root failure was an onboarding design that treated context transfer as optional rather than foundational.

A 90-person enterprise SaaS had invested in building a structured new manager development program after a difficult year in which three newly promoted managers had left or returned to IC roles within their first twelve months. The program was designed with care: a six-month cohort of four to six new managers per cycle, meeting monthly for four hours, covering management philosophy, giving and receiving feedback, structuring 1-on-1s, running career development conversations, and navigating the hiring process. The program used an experienced external facilitator with a strong track record in management development. At the end of each cohort cycle, skip-levels assessed the cohort graduates against a management effectiveness rubric and consistently rated them higher on interpersonal management dimensions — feedback quality, 1-on-1 consistency, career development engagement — than managers who had joined the engineering organization before the cohort existed. The program was working.

Two years into running the cohort, the VP of Engineering reviewed a quarterly engineering leadership summary that contained a pattern they had not expected: three of the five engineers who had resigned in the most recent quarter were from teams managed by cohort graduates. The cohort graduates were among the highest-rated managers in the organization on the skip-level assessment rubric. The exit interviews from the three departures contained themes the VP read twice: "my manager was great at the people stuff but couldn't protect the team from the scope changes that happened after the product strategy shifted"; "I felt like my manager genuinely cared about my development but had no ability to push back on the timeline the VP of Product was proposing — I ended up working three weekends in a row for a ship date that moved anyway"; "decisions were getting made above my manager and arriving at our team as instructions rather than conversations — I don't think my manager knew how to change that and I got the sense they didn't feel like they could try." The cohort graduates were performing exactly as designed on the dimensions the cohort had trained: they were giving feedback with behavioral anchors, running structured career development conversations, maintaining consistent 1-on-1 cadences. Connect this to the engineering skip-level meeting design decision record: the signal gap here is in the skip-level assessment rubric, not in the cohort program itself — the skip-level rubric had been built from the cohort curriculum, so it measured the dimensions the cohort covered; the organizational navigation dimensions the cohort had not covered were not in the rubric; the cohort graduates looked excellent on every dimension being measured because every measured dimension was a trained dimension; the untrained dimensions had no measurement surface and therefore produced no signal until attrition events made them visible.

The investigation that followed identified the specific organizational navigation gap: cohort graduates knew, in theory, that managing up was part of the management role; they had no scripts, frameworks, or practiced experience for managing up in this specific organizational context — how to bring a scope concern to the VP of Product in a way that was likely to be heard, how to frame a timeline risk in a language the sales-oriented VP of Product would register as important rather than as engineering conservatism, how to protect team context from a reorg announcement that had arrived with three days' advance notice and required the manager to both absorb the organizational anxiety themselves and transmit a stable, contextual version of the change to the team. The gap was structural: managing up requires organizational-specific knowledge that the external facilitator did not have and could not provide. The cohort curriculum had covered the interpersonal dimensions of management using frameworks that were transferable across organizational contexts, and had not covered the organizational navigation dimensions because those require knowledge of this specific company's decision-making norms, senior leadership communication styles, and organizational authority structure. The cohort graduates had internalized the transferable frameworks and had no equivalent framework for the context-specific dimensions. The result was managers who were unusually strong at giving feedback to their direct reports and unusually weak at protecting their teams from organizational decisions made above them — and the external pressure that exposed the weakness was exactly the kind of pressure under which organizational navigation skill matters most and interpersonal management skill is insufficient.

Structural properties set by the engineering new manager onboarding decision

Two structural properties are determined by the founding decisions about role transition model, inherited context transfer, 30/60/90-day framework, support architecture, and organizational navigation curriculum. Both are invisible when the organization is small enough that the promoted engineer's skip-level can provide informal real-time guidance on everything they have not yet been taught, and visible when that informal guidance pathway is unavailable, overburdened, or insufficient for the complexity of what the new manager is navigating.

Property 1: Manager effectiveness ramp ceiling. The manager effectiveness ramp ceiling is the maximum level of managerial effectiveness a new manager can achieve within their first 90 days — the ceiling on how quickly the new manager's management behaviors reach the standard that the organization needs them to sustain. The ceiling is bounded by three factors. First, role model clarity: whether the new manager has an explicit, concrete model of what the management role requires in terms of recurring commitments, conversation structures, and deliverables that are distinct from the senior IC role. A role model that specifies "you are now responsible for quarterly career development conversations for each of your five direct reports; those conversations cover growth goals, active blockers to those goals, and any commitment you are making about what the organization will provide to support them; they happen in addition to your regular 1-on-1s, not as a substitute for them; the output is a written note in the shared HR system accessible to you, the engineer, and your skip-level" is a model the new manager can execute from day one. A role model that says "you'll figure out the management stuff" relies on the new manager to assemble the model from observation and inference, and the parts of the model that require explicit instruction — the parts that are invisible until someone names them — will not be assembled at all. The ramp ceiling for the "figure it out" model is bounded by the observability of management work, which is low: management work is mostly invisible in the way that senior IC work is mostly visible, and the new manager who is watching experienced managers to assemble a model of the role from observation will primarily observe what is observable — 1-on-1s that look like project check-ins, sprint ceremonies that look like coordination meetings — and miss what is not: the career development conversation that happened offline, the skip-level observation that triggered an out-of-cycle manager check-in, the managing-up conversation with the VP of Product that happened before the sprint commitment rather than after. Second, inherited context quality: whether the onboarding provides specific, current knowledge of the team's state that the new manager cannot assemble on their own in the first 90 days. The new manager who arrives without knowing that one team member has been on an informal improvement path for four months will either discover it through an uncomfortable revelation (as in the 55-person company's week-six escalation) or not discover it until the performance review cycle surfaces it with insufficient runway to respond. Context that requires discovery rather than transfer produces a new manager who is operating on an incorrect model of their team's state during the period when their decisions are simultaneously the most consequential — first impressions, relationship establishment, early team norms — and the most uninformed. Third, coverage breadth: whether the onboarding explicitly covers the organizational navigation dimensions of the role. The ramp ceiling for organizational navigation skill is zero in the first 90 days if the onboarding does not cover it, because organizational navigation skill is context-specific and requires explicit instruction about this organization's decision-making norms — it cannot be acquired by observing general management behavior patterns.

Property 2: First-90-days failure rate. The first-90-days failure rate is the probability that a new manager makes a consequential error in the first 90 days that creates a problem requiring six or more months to resolve — the probability of starting the management trajectory with a structural deficit that compounds rather than diminishes. The failure rate is bounded by three factors. First, context transfer completeness: whether the onboarding explicitly transfers the inherited context that the new manager needs to make informed decisions from week one. Incomplete context transfer is the single largest contributor to first-90-days failures because it produces errors that appear to be judgment errors but are actually information errors — the new manager who makes an uninformed performance intervention is not exhibiting poor judgment, they are exhibiting the predictable outcome of operating without the information required to make a judgment at all. The design question is not whether the new manager has good judgment but whether the onboarding architecture provides them the information on which to apply it. Second, time-to-first-structured-feedback: whether the onboarding architecture produces structured feedback on the new manager's actual management behaviors within the first 30 days. A new manager who establishes a management pattern in weeks one through four that is incorrect in ways they cannot self-diagnose — because the pattern is invisible to them by definition (if they could see it was wrong, they would correct it) — will run that pattern for as long as it takes for the signal to accumulate into something visible enough for the skip-level to name. A structured 30-day skip-level review that includes behavioral observation on management quality — "I've heard from two of your direct reports that 1-on-1s have been primarily sprint-focused; I want to check in on whether career development topics have been coming up" — compresses the feedback loop from six months to thirty days and limits the first-90-days failure rate to the errors that emerge between week four and week thirteen, rather than the errors that compound uncorrected for the entire period. Third, explicit failure-mode awareness: whether the onboarding names the most common failure modes for this specific role in this specific context, with enough specificity that the new manager can recognize their own behavior as an instance of a named failure mode before it compounds. The IC-turned-manager technical over-contribution failure mode is invisible to the person living it — they are not deciding to do IC work instead of management work; they are assessing the available activities by their known value framework and finding IC work to be the highest-value activity available, because the management work has no value in the IC framework. A named failure mode — "the most common failure for new managers promoted from senior IC roles is spending more than thirty percent of available time on individual technical contributions in the first ninety days, because the IC framework assesses technical contribution as high-value work and does not assess management work as work at all; if you find yourself writing more code than you did as a senior engineer, that is the failure mode, and the corrective is to audit your calendar for the management commitments that are not on it" — gives the new manager a self-diagnostic tool that operates independently of the skip-level feedback cycle.

The engineering new manager onboarding ADR: five sections

Section 1: Role transition model and role-clarity framework. The role transition model specifies what the onboarding explicitly covers about the transition from senior individual contributor to engineering manager: what the role requires that the prior role did not, what the overlap between the two roles is and where the non-obvious divergence points are, and what the new manager's authority scope is during the first 90 days — specifically, which decisions they own immediately and which they should make in consultation with their skip-level before acting. The most consequential decision in this section is whether to provide an explicit, concrete role model or to rely on the new manager to assemble the model from observation and guidance. The explicit role model should specify, at a minimum: the recurring calendar commitments that are non-negotiable in the first 90 days (weekly 1-on-1s with each direct report, quarterly career development conversation scheduled in week two, 30-day skip-level check-in scheduled in week one); the classes of decisions the new manager owns immediately versus the classes they should escalate or consult on in the first 90 days (compensation conversations: escalate; performance feedback in a 1-on-1: own immediately; initiating a formal performance improvement process: consult first; making a hiring commitment: consult first; making a sprint commitment: own); and the explicit divergence points between senior IC work and management work that are most commonly misunderstood. The divergence points that require explicit instruction are the ones that are invisible to the IC framework: that career development conversations are not bonus work that happens when there is available time but required management deliverables with the same priority status as sprint commitments; that feedback delivery is not a response to visible failure but a proactive cadence responsibility; that team health monitoring is not passive observation but active inquiry requiring specific behavioral observation questions. The authority scope model during the first 90 days should specify not just what the new manager can decide but what they should not decide alone: a new manager who makes a compensation commitment in a skip-level-equivalent conversation without knowing the compensation philosophy's constraints has made an error that creates problems for months regardless of their intent. Connect this to the engineering 1-on-1 cadence decision record: the role model's specification of 1-on-1 commitments should draw directly from the 1-on-1 cadence ADR's conversation structure model — specifically the requirement to use behavioral observation questions for career development topics rather than status questions, and the documentation model that produces persistent notes accessible to both the manager and the engineer; a role model that specifies "weekly 1-on-1s" without specifying the question model and documentation requirement is specifying a calendar commitment rather than a practice, and the new manager will fill the calendar commitment with the conversational pattern they know, which is the senior IC's project-check-in pattern.

Section 2: Inherited context transfer model. The inherited context transfer model specifies what information is transferred from the previous manager or the engineering leader who managed the team during any gap, in what form, and on what timeline relative to the new manager's first week. The most consequential decision in this section is whether context transfer is a required part of the onboarding or an optional best-practice. An optional context transfer model produces the 55-person company's failure pattern: when the previous manager's departure is sudden or when the transition timeline is compressed, the optional context transfer simply does not happen, and the new manager inherits a team whose current state is opaque to them in exactly the dimensions where opacity produces consequential errors. The required context transfer model specifies a structured handoff document that must be completed by the previous manager or the interim manager before the new manager's first week, covering: (1) current performance status for each direct report — with explicit instruction that any engineer who has had a coaching or performance conversation in the last six months must be documented regardless of whether the situation has been formalized; (2) in-progress career development commitments and timelines — specifically any commitment made about promotion timelines, scope changes, or organizational investments that the team member is expecting to be honored; (3) active cross-team dynamics — any ongoing negotiation, unresolved coordination failure, or relationship strain with a peer team or stakeholder that the new manager is inheriting; (4) team members' stated career goals and active growth areas; (5) any commitments made to senior leadership, product, or external stakeholders about deliverables, timelines, or resources; and (6) known team concerns the previous manager was aware of and had not yet addressed. Connect this to the engineering performance management decision record: the inherited context transfer for performance situations is the specific case where incomplete transfer is most consequential and most commonly incomplete; the previous manager's informal tracking — the notes in a personal document, the shared awareness with the team that something is being monitored — does not transfer automatically, and the new manager who discovers a four-month performance situation in week six through a team member complaint has had the inherited context transfer failure converted into a first-90-days failure by an onboarding model that treated context transfer as optional. The timeline model should specify that the handoff document is completed at least three business days before the new manager's first day with the team, and that the new manager and the previous manager or interim leader have a synchronous handoff conversation before the new manager's first 1-on-1 with any direct report.

Section 3: First-30/60/90-days framework. The first-30/60/90-days framework specifies what the new manager is responsible for delivering versus what they are in observation and learning mode for at each milestone, the structured check-in model with the skip-level at each milestone, and the explicit failure-mode awareness training that should be delivered in the first week. The most consequential decision in this section is the 30-day structured skip-level check-in. The check-in is the mechanism that compresses the feedback loop from the performance review cycle to thirty days and limits the first-90-days failure rate to the errors that emerge after the first feedback intervention. The check-in should use behavioral observation questions rather than satisfaction questions — the skip-level asking "how is the new manager doing?" produces a global assessment; the skip-level asking "I want to hear about one 1-on-1 conversation you have had with a direct report in the last two weeks — what was discussed and how did it go?" produces a behavioral observation. The direct reports of the new manager provide the most direct signal on whether the management behaviors are calibrated correctly; the check-in model should include a brief skip-level conversation with one or two of the new manager's direct reports at the 30-day mark, framed as "I want to make sure the team is well-supported in the transition — is there anything about how the team is being managed that I should be aware of?" The 60-day milestone should include a career development conversation audit: has the new manager had a career development conversation with each direct report? If no, why not — is it a calendar failure (not scheduled) or a model failure (not knowing what to discuss)? The 90-day milestone should include a management effectiveness conversation between the new manager and their skip-level that covers the specific dimensions from the role model: 1-on-1 quality, career development progress, feedback delivery, cross-team relationship health, and whether the new manager has had any interaction with the performance management, compensation, or hiring processes that requires a calibration conversation. The explicit failure-mode awareness training should be delivered in the first week as part of the role transition model: naming the IC-turned-manager technical over-contribution failure mode, the feedback avoidance failure mode, the inherited-context blindness failure mode, and the organizational navigation deficit failure mode, with specific behavioral indicators for each so that the new manager can self-diagnose without waiting for external feedback.

Section 4: Support structure and feedback architecture. The support structure model specifies who provides support to the new manager during the onboarding period, in what form, and on what cadence. The most consequential decision in this section is whether the support architecture produces feedback on the new manager's actual management behaviors or feedback on the new manager's understanding of management theory. An assigned manager buddy who meets the new manager for coffee once a month is a support structure that produces social normalization — "other new managers also find the transition hard" — without producing behavioral feedback. A peer skip-level who conducts the 30-day and 60-day check-ins and provides structured feedback on what direct reports are experiencing is a support structure that produces behavioral feedback with enough specificity to correct. The support structure should specify: the new manager's skip-level as the primary accountable support, responsible for the 30-day and 60-day structured check-ins and available for ad-hoc consultation on any decision the new manager is uncertain whether to own alone; a peer manager buddy assigned from the existing manager cohort, paired on organizational context similarity (same skip-level, similar team size, similar engineering domain) rather than just seniority, responsible for informal support and organizational navigation guidance that requires insider knowledge the external cohort facilitator cannot provide; and the HR business partner for the team, available for any performance, compensation, or organizational process question where the new manager is uncertain whether their planned action is within the normal scope of their role. The feedback architecture during the onboarding period should specify a minimum of two structured skip-level observations of management behaviors — not conversations about management, but observations of actual management behaviors: the skip-level attending one 1-on-1 as an observer at 30 days, or reviewing a set of anonymized 1-on-1 notes with the new manager to assess whether the conversation structure and documentation quality meet the standard expected. Connect this to the engineering manager span of control decision record: the skip-level's ability to provide the support architecture described here is bounded by their own span; a skip-level who is managing eight direct managers and onboarding two new managers simultaneously has a structural ceiling on the attention they can bring to each onboarding; the span of control decision and the new manager onboarding support architecture are jointly constrained, and an organization that designs a robust new manager onboarding model without checking whether the skip-level span is compatible with delivering it has designed a program that will degrade under the organizational conditions where new manager volume is highest.

Section 5: Cohort integration and organizational navigation curriculum. The cohort integration model specifies how the new manager's onboarding connects to any peer cohort program, and what the organizational navigation curriculum looks like — specifically, what content covers the organizational navigation dimensions of the role that are context-specific and cannot be addressed by a generic external facilitator. The most consequential decision in this section is whether the organizational navigation curriculum exists at all. Most new manager cohort programs cover the transferable dimensions of management and implicitly assume that the context-specific dimensions will be acquired through observation and experience. The 90-person company's failure pattern demonstrates the cost of that assumption: cohort graduates who had internalized the transferable frameworks were excellent at the dimensions the cohort covered and had no framework for the dimensions the cohort had not covered, and the gap became visible only when organizational pressure made organizational navigation skill necessary. The organizational navigation curriculum should be delivered by organizational insiders — the VP of Engineering, a senior engineering director, or the HR business partner — who have the institutional knowledge to make the curriculum specific rather than generic. The minimum organizational navigation topics for the first cohort cycle are: how to bring a resource or timeline concern to the next level of leadership in a way that is likely to be heard given this organization's decision-making norms (not "how to escalate" in the abstract but the specific conversational framework that works with the specific senior leaders this manager will be navigating); how to protect team context from organizational decisions that arrive as instructions rather than conversations — what options are available to the manager who disagrees with a decision, what the organizational norms are around expressing that disagreement, and what the costs and benefits of the available options are; how to navigate a reorg, a product strategy shift, or a senior leadership change as a manager — specifically, what the manager's role is in translating the organizational signal for their team versus absorbing it, and how to distinguish the decisions the manager can influence from the ones they cannot; and how to make resource trade-off decisions under ambiguity — the manager who must decide whether to absorb a scope expansion or push back on the delivery timeline does not need a general principle about scope management but a specific organizational model of who to have that conversation with, when, and in what form. Connect this to the engineering feedback culture decision record: the organizational navigation curriculum's managing-up component is the complement of the feedback culture's upward feedback model — the feedback culture architecture specifies how the manager delivers behavioral feedback to the skip-level via the skip-level's 1-on-1 with the manager; the managing-up curriculum specifies how the manager initiates resource or timeline or scope conversations with senior leadership proactively, before those conversations are forced by a sprint failure or an attrition event; both channels require explicit instruction and both are typically absent from generic management development programs because they require insider knowledge of how this specific organization's authority structure works and what conversational forms the authority structure responds to. The cohort integration model should specify that cohort sessions happen monthly rather than quarterly — monthly frequency is short enough that a new manager who makes an error in week two can bring it to the cohort in week six rather than week fourteen, and the cohort's normalization function (other new managers also find organizational navigation hard) is most valuable when accessed closest to the error rather than closest to the next formal review cycle. Connect this to the open-source extractor: the reasoning behind new manager onboarding decisions — the VP of Engineering working through what specific organizational navigation topics to include in the next cohort cycle, what the 30-day check-in model should ask for, why the inherited context transfer requirement specifies three business days rather than the first week, what the minimum source threshold is for surfacing a team concern from the 30-day check-in without attributing it to the specific direct report who named it — is conducted in AI chat sessions and rarely documented anywhere; running those sessions through the extractor produces the onboarding decision record that allows the next VP of Engineering or HR partner who inherits the onboarding program to understand not just what the program requires but why each design decision was made, and what would break if any given design decision were changed.

FAQ

Further reading

• Engineering 1-on-1 cadence decision record — the new manager onboarding's role transition model should specify the 1-on-1 cadence commitments that become required from day one; the 1-on-1 cadence ADR specifies the conversation structure model, question framework, and documentation requirements that distinguish a management practice from a calendar commitment; designing the role transition model without drawing directly from the 1-on-1 cadence ADR produces new managers who know they are supposed to run 1-on-1s and fill the cadence with the project-check-in conversational pattern they know rather than the behavioral observation practice the role requires.
• Engineering feedback culture decision record — the new manager onboarding and the feedback culture architecture are jointly responsible for whether the new manager's first feedback deliveries establish a high-quality feedback practice or entrench the avoidance pattern; the onboarding's explicit failure-mode awareness training on feedback avoidance is only effective if the organization's feedback culture specifies the behavioral anchor requirements and timing model that make high-quality feedback deliverable — a new manager who is told that feedback avoidance is a failure mode but has no model of what a well-formed behavioral anchor looks like has been warned without being equipped.
• Engineering skip-level meeting design decision record — the skip-level's 30-day and 60-day structured check-ins during new manager onboarding are a specific application of the skip-level architecture's support function; the skip-level design ADR's conversation structure model — specifically the behavioral observation question framework and the information handling model for manager-specific observations — determines whether the check-in produces actionable signal about the new manager's management behaviors or a global "the transition is going well" assessment; organizations that have not designed their skip-level architecture cannot deliver the onboarding check-in that depends on it.
• Engineering performance management decision record — the inherited context transfer model's most critical component is the transfer of any active performance situation from the previous manager; the performance management ADR's documentation requirements, informal tracking model, and continuity expectations specify what should exist for the new manager to inherit and in what form; an organization whose performance management ADR does not specify documentation requirements for informal coaching conversations will consistently produce the 55-person company's failure pattern: informal tracking that exists in a personal document and transfers to no one.
• Open-source extractor — the reasoning behind new manager onboarding design decisions — what organizational navigation topics to include in the cohort curriculum, how to structure the 30-day check-in so it produces behavioral signal rather than global assessment, what the context transfer requirement should specify and why, what the explicit failure-mode awareness training should name — is reasoning conducted in AI chat sessions and rarely preserved anywhere; the new manager onboarding ADR that captures the reasoning behind the design is the institutional memory that allows the next person who inherits the onboarding program to build on what was learned rather than re-discover at a different cost what the previous iteration of the program learned about what happens when role model clarity is absent, when context transfer is optional, or when organizational navigation curriculum is outsourced to someone who does not know how this organization makes decisions.