AI Skill Report Card
Applying Strategic Systems Thinking
Quick Start14 / 15
When facing a significant decision (architecture choice, strategic bet, resource allocation, organizational bottleneck), don't jump to a direct answer. Run it through this sequence:
- Frame as a system — what are the components, interactions, and emergent properties? What happens elsewhere if this element changes?
- Trace consequences to 2nd/3rd order — direct effect → who/what reacts → what that reaction triggers.
- Check for a real constraint — is this decision actually about the bottleneck, or a local optimization that won't move the system?
- Look for a TRIZ-style resolution — can the contradiction ("lighter AND stronger") be resolved instead of compromised?
- Map stakeholders — who gains, who loses, who can block, who can accelerate.
- State the decision across 2-3 future scenarios, not just the base case.
Output a structured recommendation, not just an answer — show the reasoning chain above explicitly.
Recommendation▾
Add a brief 'bad output' example showing a shallow/naive answer contrasted with the systems-thinking approach to reinforce the value differential
Workflow14 / 15
Progress:
- 1. Define the system boundary and key emergent properties at stake
- 2. Map direct effects (1st order)
- 3. Map cascading effects (2nd/3rd order) — on adjacent systems, market, regulation, team
- 4. Identify if a systemic constraint (TOC) is involved — is this the bottleneck or noise?
- 5. If there's a "compromise" trade-off framing (A vs B), apply TRIZ: can contradiction be eliminated rather than balanced?
- 6. Map stakeholders: interests, influence, likely reaction
- 7. Build 2-4 scenarios (optimistic / base / adverse / disruptive) and check the decision's robustness across them
- 8. Check decision for antifragility — does it get stronger under stress/volatility, or just survive?
- 9. Audit own reasoning for cognitive bias (confirmation, anchoring, sunk cost)
- 10. Deliver recommendation with explicit horizon (short-term cost vs long-term position)
Depth calibration
- Quick tactical question → steps 1-3 only, one paragraph each.
- Strategic/architectural decision → full workflow.
- Pure bottleneck/performance question → lead with TOC (step 4), skip scenario planning if irrelevant.
- Engineering "trade-off" phrased as inevitable compromise → lead with TRIZ (step 5).
Recommendation▾
Consider trimming the Best Practices and Common Pitfalls sections slightly, as there's some overlap/redundancy between them that could be consolidated
Examples17 / 20
Example 1: Input: "Should we switch our drone's frame material from aluminum to a cheaper composite to cut cost by 15%?" Output:
- 1st order: cost drops 15%, weight changes ±X%, supplier dependency shifts.
- 2nd order: certification process must be redone (regulatory delay 6-9 months); existing service/repair network isn't trained for composite repair → increases downtime cost for customers; competitors using aluminum can undercut on "proven reliability" messaging.
- Constraint check: is cost actually the bottleneck, or is it sales cycle length? If sales cycle is the real constraint, a 15% cost cut doesn't address it.
- TRIZ framing: the real contradiction is "cheaper AND no recertification delay" — explore phased material substitution (non-structural parts first) to avoid full recert.
- Stakeholders: regulators (slow, risk-averse), existing customers (fear reliability change), sales team (wants lower price now), manufacturing (wants simpler supply chain).
- Scenario check: in a scenario where regulation tightens on UAV material certification in 3 years, early move to composite with proper documentation becomes an advantage, not a cost.
- Recommendation: phased substitution, starting with non-flight-critical components, paired with proactive regulatory engagement — turns a cost play into a long-term certification moat.
Example 2: Input: "Our engineering team keeps missing deadlines no matter how much we hire." Output:
- This is a Theory of Constraints signal, not a capacity problem — adding people without finding the bottleneck often makes throughput worse (coordination overhead).
- Likely candidates for the actual constraint: a single approval gate (e.g., one person signs off on all flight-test releases), a shared test rig, or an unversioned requirements process causing rework loops.
- Diagnostic: map the last 5 missed deadlines — find the common blocking resource/step, not the common missing skill.
- Fix: subordinate everything else to protecting that constraint's throughput (dedicated buffer time, remove it from non-critical-path tasks) before hiring further.
- Avoid the trap: "hire more engineers" is an anchoring bias toward the most visible, not most limiting, resource.
Recommendation▾
Include a short template or output format (e.g., headers like '1st order / 2nd order / Constraint / Recommendation') to make the structured output more consistently replicable
Best Practices
- Always separate 1st-order answer from 2nd/3rd-order consequences explicitly in writing — don't blend them, so the reader can see where speculation starts.
- When a trade-off is presented as binary ("fast vs good", "light vs strong"), default to asking "what would make both true?" before accepting the compromise.
- Build scenarios as decision stress-tests, not predictions — the goal is to find a strategy robust across scenarios, not to pick the "most likely" one.
- Name the stakeholder's actual incentive, not their stated position (e.g., "regulator wants to avoid being blamed for an incident," not "regulator wants safety").
- Make time horizon explicit in every recommendation: what this costs/gains in 3 months vs 3 years.
- When auditing your own analysis, explicitly check for: confirmation bias (did I search for disconfirming data?), anchoring (am I anchored to the first number/plan presented?), sunk cost (am I protecting past investment rather than future value?).
- For antifragility: ask not "how do we prevent this failure" but "how do we structure this so this class of failure makes us better positioned."
- Use mental models from other domains explicitly and name them (e.g., "this is a predator-prey dynamic," "this is a liquidity/solvency distinction") — it sharpens the analogy and makes reasoning auditable.
Common Pitfalls
- Treating a subsystem optimization as a system improvement (classic TOC failure — speeding up a non-bottleneck does nothing).
- Presenting only one scenario/forecast as if it were certain — strategic recommendations should show sensitivity across at least 2-3 futures.
- Accepting an engineering trade-off at face value instead of probing whether it's a true physical contradiction or a design/process limitation that TRIZ-style reframing can dissolve.
- Analyzing stakeholders only by their stated interest, ignoring actual influence/power — leads to over-investing in loud-but-weak stakeholders.
- Confusing "long-term thinking" with "no urgency" — strategic patience still requires decisive near-term action; the skill is sequencing, not delay.
- Letting scenario planning become a forecasting exercise rather than a strategy-robustness exercise — the output should be "what do we do regardless," not "which future will happen."
- Ignoring second-order effects on regulation and ecosystem (common in UAV/defense-adjacent industries) in favor of only market/competitor effects.