10

Install the 90-Day Operating System

Senior-to-Principal Growth OS

Overview

The complete Growth OS

The Growth OS is this course's synthesized operating system for turning aspiration into capability and honest evidence. It combines a local progression framework, archetype hypothesis, fixed growth conversation, contract, real opportunity, support modes, sponsorship, impact ledger, and calibration.

The system produces learning and evidence, not a guaranteed title. It works only when manager and engineer both act and when the organization supplies real, needed scope.

The minimum viable installation

Start with the smallest complete loop rather than launching a career-program bureaucracy. One engineer-manager pair needs five living artifacts and a recurring calendar commitment.

ArtifactMaximum useful sizeOwner
Local expectation excerptRelevant dimensions onlyManager explains; both interpret
Shared 1:1 pageOne running pageBoth
DiagnosisOne evidence-based statementBoth
90-day contract and opportunity briefOne page each, or combinedBoth
Impact ledgerOne row per meaningful claimEngineer updates; manager reviews

Install these within one week. Do not wait for a perfect company-wide ladder redesign before making one development relationship clearer and fairer.

Week 0: set the conditions

Preparation determines whether the next 90 days are a real capability test or an aspirational side project. The manager first identifies genuine organizational needs and available authority; the engineer brings evidence, aspiration, and sustainable-capacity constraints.

Week-0 actions:

  1. Read the local Senior, Staff, and Principal expectations together.
  2. Choose one reliable strength and one limiting-gap hypothesis from evidence.
  3. Test an archetype fit against organizational need and the engineer's energy.
  4. Write the 90-day contract and six-part opportunity brief.
  5. Remove conflicting capacity and secure access, authority, and support.
  6. Announce the assignment mandate and boundaries to affected people.
  7. Schedule checkpoints and create the impact ledger.

Weekly: run exactly 30 minutes

The weekly standard is exactly 30 minutes with fixed 10/10/10. Status remains asynchronous so live time can surface judgment, feedback, context, growth, and action.

TimeAgendaOperating prompt
0–10Engineer agenda“What concern, decision, relationship, or energy issue needs private attention?”
10–20Manager context and feedback“What does the engineer need to know, and what behavior/effect should be visible?”
20–30Future growth and actions“What did the opportunity teach us, and who will do what by when?”

Both people update the shared page. If deeper performance, compensation, health, or sensitive content arises, schedule a separate conversation rather than consuming the standard segments.

Days 30, 60, and 90: inspect different questions

Checkpoints prevent the same vague career discussion from repeating. Each milestone has a distinct decision purpose.

DayPrimary questionPossible decision
30Is this a fair, relevant test with real authority and sustainable capacity?Repair access, support, boundaries, or assignment
60What capability and outcome pattern is emerging?Continue, narrow, deepen, or change support mode
90What became reliable, what remains uncertain, and what does the organization need next?Continue, redirect, stop, or form a new contract

At every checkpoint, separate four judgments: project outcome, engineer capability, manager/support performance, and opportunity quality. A cancelled strategy does not erase demonstrated judgment; a successful rescue does not prove sustainable leverage.

The manager operating checklist

The manager owns the parts of the system that require organizational power. Delegating these obligations back to the engineer turns development into self-service access for people who already have influence.

  • Maintain clarity about local expectations and role need.
  • Give timely evidence-based feedback and useful organizational context.
  • Allocate consequential opportunities using explicit evidence and interest.
  • Remove workload when adding stretch.
  • Make mandate, authority, and decision boundaries visible.
  • Choose coaching, feedback, mentoring, or sponsorship based on the actual need.
  • Observe relevant work instead of judging only presentations.
  • Keep commitments in the shared page and escalate structural blockers.
  • Represent impact accurately in calibration, including collaborators and uncertainty.
  • State organizational constraints without disguising them as personal gaps.

The engineer operating checklist

The engineer owns active learning, transparent execution, and accurate evidence. Agency does not mean manufacturing scope outside organizational priorities or accepting unsafe work.

  • Bring concerns, decisions, relationships, and desired outcomes to the opening 1:1 segment.
  • Keep routine status asynchronous and decision-ready.
  • Seek evidence on behavior and effect, including dissent.
  • Translate title aspiration into a capability and contribution hypothesis.
  • Negotiate authority, capacity, support, boundaries, and stop conditions.
  • Delegate meaningful ownership and teach context.
  • Ask explicitly for the needed mode: coaching, feedback, mentoring, or sponsorship.
  • Keep a concise impact ledger with accurate shared credit.
  • Surface changed assumptions and opportunity defects early.
  • Treat promotion as a separate organizational decision, never the promised payment for one assignment.

Worked 90-day example

A complete example shows the artifacts reinforcing one another. Elena is a Senior engineer with strong reliability judgment who wants to test Staff-scope multi-team direction.

System partInstallation
NeedFour checkout services have incompatible recovery ownership
DiagnosisStrong incident judgment; limiting hypothesis is early cross-team ownership design
ArchetypeTech Lead pattern for a bounded multi-team operating-model effort
ContractAlign four teams on recovery roles and pilot two services in 90 days
SafetyExisting roadmap item removed; no platform rewrite; director conflict escalates to manager
SupportManager sponsors mandate; Principal peer mentors decision design; feedback after forums
EvidenceRecovery trend, adopted owner model, dissent record, independent response by service leads
Day-90 decisionDirection capability is stronger; adoption durability needs another cycle

Elena is not promised promotion. She leaves with broader capability, credible evidence, a clearer remaining gap, and an organization that now has better recovery ownership.

Failure modes and recovery

Operating systems drift under pressure, so define recovery moves in advance. Repair the smallest broken component while preserving the core loop.

Failure modeRecovery move
1:1 becomes statusMove update to shared async channel; restore fixed 10/10/10 next meeting
Growth segment has no opportunityManager brings two real organizational needs; engineer tests fit
Contract becomes a checklistReturn to one outcome, one capability, and evidence that could change your view
Stretch causes overloadStop or reduce work immediately; remove capacity before restart
Feedback stays vagueRequest situation, behavior, effect, and next experiment
Sponsorship favors familiar peopleReview opportunity log, evidence, interest, access history, and support
Impact ledger becomes activity logDelete entries with no meaningful outcome or capability evidence
Promotion becomes impliedSeparate development evidence from role need, policy, and calibration decision

Do not “make up” missed growth time by expanding the next assignment. Restore cadence and fair conditions first.

Your installation worksheet

This worksheet turns the course into a dated operating plan. Engineer and manager complete it together and review it with a trusted peer if the scope crosses several teams.

By whenActionOwnerEvidence complete
Day 0Identify organizational need and local expectationsManager[ ]
Day 0Bring evidence, aspiration, and capacity constraintsEngineer[ ]
Day 7Agree diagnosis, archetype hypothesis, and contractBoth[ ]
Day 7Secure mandate, access, support, and boundariesManager[ ]
WeeklyRun fixed growth 1:1; update actions and ledgerBoth[ ]
Day 30Audit fairness of opportunity and conditionsBoth[ ]
Day 60Inspect capability and outcome patternBoth[ ]
Day 90Review evidence; continue, redirect, or stopBoth[ ]

Add the actual calendar dates, named people, and links before considering the system installed.

Key takeaways

The Growth OS makes development a joint operating practice rather than an annual conversation. Its discipline comes from a few fixed interfaces and honest separation of learning, evidence, opportunity, and promotion.

  • Install one complete loop with five small living artifacts.
  • Use the local framework and real organizational need as context.
  • Run the standard 1:1 for exactly 30 minutes with fixed 10/10/10; keep status asynchronous.
  • Review opportunity quality at day 30, emerging evidence at day 60, and next-cycle decisions at day 90.
  • Manager owns access, authority, support, and fair representation; engineer owns active learning, execution, and accurate evidence.
  • Repair drift without adding bureaucracy.
  • Growth and strong evidence improve readiness; neither guarantees promotion.

Checklist: launch the next 90 days

This final checklist is the course's completion artifact. The course is finished when a real, safe development loop is operating—not when every sentence has been read.

  • [ ] We named one consequential organizational outcome.
  • [ ] We wrote one evidence-based diagnosis and archetype hypothesis.
  • [ ] We agreed one capability to test.
  • [ ] We created a real assignment with authority, support, capacity, boundaries, and stop conditions.
  • [ ] We scheduled the fixed weekly growth conversation and all three checkpoints.
  • [ ] We created the shared 1:1 page and impact ledger.
  • [ ] We stated manager and engineer obligations with dates.
  • [ ] We told affected stakeholders the mandate and decision boundaries.
  • [ ] We separated development review from promotion promises.
  • [ ] We will record changed context, counterevidence, and shared credit.