stevenacoffman/strategy-leadership
Architecture strategy, program governance, complexity diagnosis, and organization design.
Use when architecture and business leadership are disconnected: EA diagrams engineers ignore, tech choices (cloud, database, lock-in, managed vs self-hosted) made without business framing, or CIO cloud commitments engineering can't deliver. Riding the architect elevator.
Use when designing or diagnosing team boundaries or a reorg: individual SLOs are green but the end-to-end experience breaks, incidents cluster at team handoffs, or teams can't name their consumer. Structures teams around consumer journeys, not technology or function.
Invoke when a project or program shows governance mismatch: following the process but the situation keeps deteriorating, escalations don't resolve, or a major event (failure, regulation, vendor collapse) may have shifted its Cynefin domain.
Invoke when a program's projects all report green (on schedule, on budget) but program-level benefits aren't materializing, or when designing governance for a new multi-project program that needs an owner for the interaction layer where outcomes emerge.
Use when classifying a system property, incident, or AI behavior as resultant or emergent (weak or strong) to pick the right response: post-incident contributing factors, non-linear blast radius, whether tests or simulation can predict it, or multi-agent LLM resilience.
Use when evaluating whether a private or enterprise cloud is really a cloud: ticket-based provisioning taking days, access only via corporate VPN or proxy, dedicated rather than pooled resources, or lift-and-shift apps with no auto-scaling or stateless design.
Use when assembling or evaluating a temporary cross-team taskforce for a bounded mission spanning several teams' ownership and too big for one person, such as a compliance rollout (GDPR, EAA), platform-wide observability change, or catalog migration.
Use when cloud is judged by unit prices, fixed budgets, or servers migrated instead of rate of change (consumption over time, delivery throughput, deployment frequency), or when teams resist pay-per-use billing or treat cloud as a one-time project. Economies of speed.
Use when deciding whether to adopt a best practice, methodology, or approach from elsewhere, or diagnosing why an adopted one fails. Replaces best-practice thinking with a four-question fit test of required conditions, then derives a context-specific alternative.
Invoke when a program leader must diagnose why a complex program is hard before choosing a response: many things failing at once and scope, resource, or stakeholder diagnoses aren't actionable, or when sizing up a new complex assignment before setting governance posture.
Invoke when a governing body has formal authority over a complex program but outcomes diverge from plan and it reacts rather than anticipates, suggesting it governs from someone else's representation of reality instead of its own working model of the system.
Invoke after a requisite-variety deficit has been located, to choose the intervention: amplify governance response capacity, attenuate environmental variety, or both. Guards against misusing attenuation to cut governance capacity instead of environmental variety.
Use when designing or reviewing an AI-powered system or agent and deciding what deterministic code versus the LLM controls, especially when behavior is unpredictable or an agentic or vibe-coding approach lets the LLM run a multi-step workflow. Inversion of control: code owns the state machine.
Invoke when deciding which parts of a task or workflow to delegate to AI and which to keep for human judgment, especially when synthesis or formatting is mixed with consequential calls, or AI output quality has been inconsistent in hard-to-explain ways.
Use when vendor lock-in fears drive architecture: rejecting a managed or native cloud service (DynamoDB, Spanner) as cloud-specific, building abstraction layers for portability, or avoid-lock-in principles with no cost model. Weighs switching cost against the cost of avoidance.
Use when designing, reviewing, or debugging a multi-agent LLM system whose errors, hallucinations, or sycophancy compound. Helps choose a reliability pattern (voting, adversarial critique, hierarchical planning, or elimination) beyond what a single LLM call gives.
Use when someone says we're going multicloud without saying which kind, or when portability, abstraction layers, or avoiding native services are justified as a lock-in hedge. Distinguishes five multicloud options and their costs, including accidental multicloud across business units.
Use when writing or reviewing architecture or cloud strategy principles: wishful principles (to deliver value), vendor names or buzzwords inside principles, principles nobody can recite or adopted without debate, or decisions claimed as aligned with no principle cited.
Invoke when a program shows strong project-level reporting but weak benefits realization, or when designing governance for a new program that must go beyond oversight and accountability to govern the interaction layer between projects where outcomes live.
Invoke when a competent team keeps failing despite correct use of standard PM interventions, or at program initiation when stakeholders split between more planning and control versus agility and iteration. Diagnoses the source of project complexity.
Invoke when a management or governance system keeps failing to regulate the complexity it was meant to control, with recurring failures despite apparent oversight, and the question is why it was structurally unable to catch them. Applies Ashby's law of requisite variety.
Invoke when EVM Schedule Variance (SV) is negative, flat, or worsening across reporting periods and is treated as a status number instead of a corrective trigger, or when a PM must diagnose why a program isn't recovering despite visible schedule pressure.
Use when a Staff+ technical leader self-assesses energy across Technology, People, Operations, and Product (T-POP), or onboards to a new leadership role. Catches ivory-tower isolation, snacking, preening, and premature technical fixes for org or product problems.
Use when a cloud migration reports progress as servers or workloads migrated but business stakeholders see no value, the plan is sequenced by technical ease, or value is promised later on a hockey stick. Ties migration to business metrics like availability and deployment frequency.
Use when diagnosing whether adopting a tool, process, or org model is cargo culting: because Google or Netflix does it, wholesale copying, or rituals without results. The VSI framework checks Value dominance, Shallow understanding, and Imitation.