Skip to content
Models · syntheses · adaptations

Frameworks

Ideas from 100+ talks in one visual form. Each one-pager takes 30 seconds to read and can be shared with one link.

Topics

01 · Original model

CTO Lifecycle

Startup Coder → Engineering Manager → All-in-one → role split
Leadership
When to use
Use when aligning which CTO profile the company needs at its current growth stage.
CTO lifecycle S-curveOrganization lifecycle →↑ Organizational performanceStartupGrowthMaturityComplexityDeclineStartup Coderbuilds the first productEngineering Managerscales teamsAll-in-one CTOtech · people · businessCIO · CTO · VP Engthe role splitsNo new CTO rolefour decline symptoms

The source model has five organizational stages. The CTO is a Startup Coder at the beginning, an Engineering Manager during growth, and an All-in-one CTO during formalization. As the structure becomes more complex, that role splits into CIO, CTO, and VP Engineering. The talk assigns no new CTO profile to decline.

02 · Original model

Channel → Product → Platform

Three-step evolution of a large fintech
PlatformArchitecture
When to use
Use when product and platform strategies start to conflict because they are in different phases.
Channel to Product to Platform evolution01 · 2006 → 2011Channelmobile bank as an extrachannel02 · 2015Productin-house mobile product03 · 2019 → 2022Platformplatform teams ·modularization · releasetrains · governanceMilestones2006company founded2008internet bank2011mobile bank ·channel2015mobile product2019mobile platform2022what next?

The case timeline starts with the company founding in 2006 and internet banking in 2008. Mobile banking appears as an additional channel in 2011, becomes a product in its own right in 2015, turns into a platform in 2019, and reaches the question of what comes next in 2022.

03 · Adaptation

SE 2.0 → SE 3.0

Code-first → Intent-first engineering
AI-nativeArchitecture
When to use
Use when evaluating a move from AI-assisted code-first work toward intent-first development with AI teammates.
Software Engineering 2.0 to 3.0ASE 2.0 · code-firstBSE 3.0 · intent-firstCode-first workInterfaceIntent-first dialogueImplements with AI assistanceHuman roleRequirements + verificationAssists traditional activitiesAI roleSearches for + implements asolutionAI-assisted practiceStatusVision + challenge roadmap

The position paper describes SE 2.0 as code-first development with AI assistance and SE 3.0 as intent-first, conversation-oriented collaboration between a human and an AI teammate.

04 · Author synthesis

Senior+ Fork

Management track vs IC track
Leadership
When to use
Use when an engineer chooses the next step after Senior and the company designs a dual ladder.
Career fork after Senior EngineerSenior Engineerowns an individual scopeLeadershiptransition / forkManagement trackIllustrative · varies by companyscales impact through peopleand processL1Engineering ManagerL2Engineering DirectorL3VP EngineeringIC trackIllustrative · varies by companycross-team technical leadershiparchitecture · standards · complex problemsL1Staff EngineerL2Principal EngineerL3Distinguished EngineerL4Technical Fellow

After Senior, a career may split into management and IC tracks. In the source diagram, Leadership marks the transition into management rather than a separate grade. The exact steps—Engineering Manager or Director, Staff or Principal—depend on organizational design and do not form a universal ladder.

05 · Adaptation

Fitness Functions Matrix

One characteristic ↔ trade-offs × Triggered ↔ Continual
ArchitectureSRE
When to use
Use when architectural qualities need automated checks instead of team memory.
Architecture fitness functions matrixAUTOMATED SUBSETATOMICone characteristicHOLISTICcombination / trade-offsTRIGGEREDevent / CICONTINUALalways onOne characteristiccoupling · contractsTrade-off checksecurity × latencyOne live signalp99 latency · crash rateSystem trade-offsreliability × costconcern scope × cadence → qualities stay verifiable

An architectural fitness function provides an objective integrity assessment of one or more architectural characteristics. Fitness functions may be automated or manual; this matrix deliberately covers only the automated subset.

06 · Original model

Dream Teamlead AI-native

Individual practice → team system → org culture
LeadershipAI-native
When to use
Use when a teamlead's AI habits need to become a shared team contract.
AI-native Dream Teamlead impact levelsL1Individual practicelocal speed ≠ deliveryAccelerates individual artifactsFrames task and intentVerifies AI outputMaintains deep skillsL2Team systemhuman-agent contractDesigns the human-agent loopSets autonomy by riskVerification in Definition of DoneContext: ADR · runbooks · docsL3Org operating modelplatform + policyGolden paths & platformShared policy & observabilityMetrics & trainingTrust & risk governance

An AI-native teamlead expands impact from individual practice to a team system and then to organizational conditions. The individual layer accelerates artifacts but does not yet guarantee value delivery.

07 · Author synthesis

SRE Maturity

From heroics to SLOs and adaptive learning
SREArchitecture
When to use
Use when you need to assess reliability maturity and choose the next 2-3 practices.
SRE maturity is a reliability systemREACTIVE → ADAPTIVEL1 · ReactiveM · uptimeR · heroicsL · firefightingL2 · ManagedM · service SLIsR · runbooksL · postmortemsL3 · ProactiveM · SLO + error budgetR · automationL · blameless reviewsL4 · ResilientM · user-journey SLOR · self-healingL · game-daysL5 · AdaptiveM · business-aligned SLIR · auto-rollbackL · chaos → changesmeasure → respond → learn

This five-step ladder is an author synthesis of reliability practices rather than a canonical Google SRE model: Reactive → Managed → Proactive → Resilient → Adaptive.

08 · Author synthesis

Engineering Productivity

DORA + DevEx + SPACE — three lenses, one picture
ProductivityLeadership
When to use
Use when engineering productivity needs a metric system rather than a single counter.
Three lenses on engineering productivityDORA + DevEx + SPACEGOAL → SIGNAL → METRICDORADELIVERY OUTCOMESlead time · deploy frequencyfail rate · recoveryreworkDevExEXPERIENCE SIGNALSflow · feedback loopscognitive loadSPACEMULTIDIMENSIONAL CONTEXTsatisfaction · performanceactivity · collaborationefficiency · flowONE ENGINEERING SYSTEMone object · three distinct readingsmetric → target = distorted signal · read all three

DORA, DevEx, and SPACE are complementary lenses rather than interchangeable metric sets or literal overlapping sets. DORA reads delivery through the current five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.

09 · Original model

Agent Stack Map

Three independent decisions → eight reference patterns → a portfolio
AI-nativePlatformArchitecture
When to use
Use when deciding which agent stack to allow and how to end the build-versus-buy argument.
Agent stack reference patterns and an example large-fintech portfolioThree axes, chosen independentlyHarnessloop, context, sandboxModelquality, place of inferenceToolsactions, identity, execution8 REFERENCE PATTERNScurated · not exhaustiveCore#2 own + API#4 vendor + gatewayScale#6 model routerRestricted#1 air-gapped#3 client + localHigh risk#7 plan ↔ executeSandbox#5 full SaaS#8 personal + MCPEXAMPLE TARGET PORTFOLIOLARGE FINTECHSANDBOX: NO WORK DATA OR AUTHORITYNo universal ranking: status is assigned per scenario and data class.

The argument 'our own client on our own model versus a vendor agent over an API' conflates independent decisions. Harness, model and tools are chosen separately: each axis carries its own data path, cost, failure point and vendor lock-in.

10 · Original model

Replayable Episode

Start state → contract → hidden judge → trace → release gate
AI-nativeProductivity
When to use
Use when turning real work into an agent evaluation robust enough to support a release decision.
One episode — a small replayable copy of real work01Frozenstart stateone snapshotfuture hidden02Agentcontracttools + rightstime + budget03Hiddenjudgetests + policystate invariants04Tracesteps + callsno dangerousside effects05Releasegateevidencesame thresholdOne success is not reliabilityPass^ksuccess across a seriesVariancespread of trajectoriesBudgetprice of durable successKeep the set freshStaticholdoutRollinglive setfresh work feeds the next frozen episode

The smallest unit of agent evaluation is not a benchmark question but a replayable episode: a small copy of real work. For code the start state is the commit before the pull request, for an incident the system at T0, for data a snapshot of the data, catalog and lineage.

11 · Original model

Stack Ownership Boundary

Change rate × uniqueness → rent · adapt · own
AI-nativePlatformLeadership
When to use
Use when deciding what to rent in your AI stack, what to adapt, and what to keep owned.
↑ change rateenvironment uniqueness →Rentchanges fast · rarely yoursFrontier modelsCompute capacityGeneric loop /commodity executionAdaptchanges fast · must fit youProvider routingContext packagingTool descriptionsOwndefines the right to actIdentity + policyDomain contractsEpisodes + evidenceBuild gate: an owned harness must be earned1Unique actionenvironment2Sovereignty /strict latencyconstraints3Enoughvolume4Matureevals5Customer-facingagent capability0–1 YESRENTmanaged harness + owned policy2–3 YESADAPTowned seam over a managed harness4–5 YESBUILDstrongest when #5 is also yesA strong platform team is not a business case on its own.

For a technology leader the question is not which logo to pick but where to draw the ownership boundary. Two axes give the answer: how fast a component changes and how unique it is to your environment.

12 · Original model

Architecture Memory Graph

6 nodes · 7 link fields · one change, both directions
ArchitectureAI-native
When to use
Use when checking whether the organization is ready for an architect AI assistant and where the decision chain breaks.
Minimum chain of living architecture memory01Requirementintent02ADRrationale03Componentor model04Code+ config05Qualityattribute06RuntimesignalEvery link carries seven fieldstypeversionrationaleownerevidenceconfidencedate / triggerDiagnostic: walk one change in both directionsone changeboth directionsPASSboth paths replayFAILa link existsonly in memoryOUTPUTmissing linkbacklog

The artifacts usually exist: requirements, ADRs, models, code, SLOs and runtime signals. What is missing is the chain between them — documents sit in six different systems while people provide the continuity.

13 · Original model

The CTO Transition

−30 → 00 → 30 → 90: the transition starts before day one
Leadership
When to use
Use when entering an executive role or hiring a leader and you want the transition milestones up front.
Four linked phases — each rests on the quality of the previous one−30Beforeday onechoose the transitionbefore the rolemarket · techpower · tensionsrole choice00Commitpointexpectations becomea mutual contractoutcomes · authorityresources · constraintssuccess criteriamutual contract30Days1–30listen to fourversions of the companyflows · hypothesesevidence · tensionscompany mapby day 3090Days31–90verify diagnosischange 1–2 systemssystemic betfirst resulttrust · strategyupdated contractby day 90Red flagsRed flags are not a fifth phasethey run through the entire transition

A transition is usually counted from the first working day. For a CTO that is late: by then the company, the task and the people are already chosen. The four phases are linked — weak research weakens the contract, a weak contract hampers diagnosis, and rushed diagnosis leads to the wrong changes.