Three scenarios across different domains, demonstrating the cognitive protocol in action.
User: "We need to migrate our monolith to microservices. What's the best approach?"
Migrating from a monolith to microservices is a common modernization pattern. Here's a recommended approach:
- Identify service boundaries using Domain-Driven Design (DDD)
- Start with a "strangler fig" pattern — extract services one at a time
- Implement an API gateway for routing
- Set up service discovery and a message queue
- Add monitoring and distributed tracing
- Migrate the database last — start with shared DB, then split
This is a proven approach used by Netflix, Amazon, and many other companies.
Problems: Accepts "migrate to microservices" as a given (retroactive justification). Decomposes into implementation components, not constraints (decomposition theater). Cites authority instead of reasoning (structural mimicry). Never asks whether microservices are the right answer.
The question assumes microservices are the target. Let me audit that.
Your actual constraints are likely: (1) deployment independence — ship features without redeploying everything, (2) scaling specific components under load, (3) team autonomy — multiple teams working without merge conflicts on shared code.
Microservices solve all three but introduce coordination costs: distributed transactions, network latency, operational complexity. Alternative configurations that satisfy the same constraints:
- Modular monolith: deployment independence through feature flags and module boundaries, no network overhead. Satisfies constraint 3, partially satisfies 1-2.
- Hybrid: Extract only the 1-2 components that actually need independent scaling. Keep everything else as a monolith.
Which constraints are actually binding for you? If it's primarily team autonomy (constraint 3), a modular monolith with clear ownership boundaries might solve your problem at 20% of the operational cost. If it's scaling (constraint 2), which specific component is the bottleneck?
Active shifts: Frame audit (Shift 1) — questioned whether "migrate to microservices" is a given or a choice. Constraint decomposition (Shift 2) — broke the need into three independently verifiable constraints. Free rebuild (Shift 3) — proposed configurations the original framing excluded. Branch point (Shift 4) — the answer depends on which constraint is binding, creating a genuine fork.
User: "Should we raise our Series A now or wait until we have more traction?"
This is a classic timing question. Here are factors to consider:
Raise now if: the market is hot, you have strong investor interest, you need capital to hit key milestones, your competitors are raising.
Wait if: you can extend runway, more traction means higher valuation, you want to avoid dilution, the market is cooling.
Generally, the best practice is to raise when you don't need to — from a position of strength. Most YC companies raise within 3-6 months of demo day while momentum is high.
I'd recommend talking to 2-3 trusted advisors in your network to calibrate timing.
Problems: Lists pros and cons without identifying the binding constraint (decomposition theater). Cites "best practice" and YC convention without examining whether it applies here (cargo cult). "Raise from a position of strength" is an uncommitted recommendation that doesn't resolve the decision.
The binding constraint isn't timing — it's the relationship between your burn rate, your learning rate, and the capital required for the next proof point.
Ground truths to check:
- Months of runway remaining: how long before you must raise or die?
- Cost of the next proof point: what specific milestone would materially change your valuation, and what does it cost to get there?
- Learning velocity: are you still discovering what works, or executing on a known playbook?
If you have 8+ months of runway and the next proof point costs 4 months of burn, waiting is not "being patient" — it's buying a higher valuation at the cost of time you can afford. If you have 4 months of runway, raising now isn't optional.
The convention "raise from strength" hides an assumption: that strength is monotonically increasing. If your market is contracting or your growth has plateaued, waiting makes you weaker, not stronger. The deciding question: is your trajectory clearly improving with each passing month? If yes, wait. If flat or uncertain, the option value of capital now outweighs the dilution cost.
Active shifts: Frame audit (Shift 1) — reframed from "timing" to "burn rate vs learning rate vs proof point cost." Verifiable atoms (Shift 2) — decomposed to three measurable quantities. Convention audit (Shift 3) — examined "raise from strength" and identified its hidden assumption. Branch point (Shift 4) — the answer forks on trajectory direction.
User: "I'm thinking about getting an MBA. Is it worth it?"
An MBA can be very valuable depending on your goals. Here's a framework:
Pros: network, credential, structured learning, career switching opportunities, higher salary potential. Cons: opportunity cost (2 years + $150K+), may not be necessary if you're already in tech, some argue the network is overvalued.
It's worth it if: you want to switch from a technical to a business role, you're targeting consulting or finance, you want the brand signal. It's not worth it if: you're already on a good career trajectory, you can learn the skills online, you're in a field that doesn't value the credential.
I'd suggest talking to MBA alumni in your target field to get their perspective.
Problems: Pro/con list without identifying the binding constraint. "Depending on your goals" defers the judgment. Treats MBA as a fixed product to evaluate rather than decomposing what the user actually needs. Ends with "talk to people" — an empty recommendation.
An MBA bundles four things: (1) a credential signal, (2) a peer network, (3) structured business knowledge, (4) a 2-year pause to redirect.
These are separable. The question isn't "is an MBA worth it?" but "which of these four do you actually need, and is the bundle the cheapest way to get them?"
- Credential signal: matters in consulting, finance, and large corporate environments. Doesn't matter in startups, tech, or creative fields. Does your target employer filter on this? Check their actual job postings and LinkedIn profiles of recent hires.
- Network: the real asset, but only if the specific program's alumni are in your target industry. A top-10 MBA network is qualitatively different from a top-50 one. And network is increasingly buildable through other channels (YC, on-deck, Twitter, industry conferences).
- Knowledge: available at near-zero cost online. The MBA packages it conveniently, but $150K+ is a steep convenience fee.
- Career pause: the hidden value most people undercount. If you need permission to stop, think, and redirect, an MBA provides social cover. But a sabbatical does the same for less.
The real question: which of these four is your actual bottleneck? If it's credential, can you get it from a top-10 program? If not, the ROI drops sharply. If it's knowledge, skip the MBA. If it's the pause, there are cheaper options.
Active shifts: Frame audit (Shift 1) — decomposed MBA from a monolithic product into four separable goods. Verifiable atoms (Shift 2) — each component can be independently assessed. Free rebuild (Shift 3) — for each component, identified alternative ways to obtain it. Convention audit — surfaced the hidden value (career pause) that MBA marketing doesn't emphasize and the conventional framing misses.