thermal-team-incubation

name: thermal-team-incubation description: A framework for building high-impact, zero-to-one products within large organizations by operating as an autonomous "Thermal" unit. Use this when launching a new initiative that requires high speed, bypassing corporate bureaucracy, or when a project needs to survive multiple leadership changes by proving its own value.

The "Thermal" model is an organizational strategy designed to insulate small, high-stakes teams from the "drag" of large-company bureaucracy. By operating like an internal startup with a "founder-leader" and a direct line to a single senior decision-maker, teams can ship products at 10x the speed of standard corporate cycles.

Core Pillars of a Thermal Team

1. Founder-Leader Ownership: The project lead must act as a founder, not a manager. They own the vision, the team, and the output entirely.
2. Single-Sponsor Decision Making: The team reports to exactly one senior executive (e.g., CEO, CPO, or CTO). This eliminates "middle management" layers and the need for consensus across multiple departments.
3. The "Functional Atom" Staffing: Keep the team as small as possible—ideally one expert per function (1 ML, 1 Backend, 1 Frontend, 1 Designer, 1 Researcher, 1 PM).
4. 100% Radical Focus: Every member must be 100% dedicated. Shared resources or part-time contributors create "momentum friction" that kills Thermal projects.
5. Process Autonomy: The team is exempt from standard corporate rituals (OKRs, rigid planning cycles, Jira grooming) in favor of dynamic, milestone-based execution.

Implementation Workflow

Phase 1: Structural Setup

• Secure the "Sponsor": Identify one executive with the power to say "Yes" to everything. Establish a direct communication line (DM or weekly sync) with zero intermediaries.
• Recruit by Self-Selection: Do not assign people to the team. Pitch the vision and let people "opt-in." This ensures every member is mission-aligned and prepared for a high-intensity environment.
• Define the High-Bar Principle: Establish 2-3 non-negotiable principles early (e.g., "The algorithm must be open-source" or "The product is the voice of the people, not the company").

Phase 2: Execution Mechanics

• Dump Heavyweight Tools: Replace Jira/Asana with a single "Live Document" (e.g., Google Doc or Notion) that tracks everything. If a task is no longer relevant, it falls off the doc naturally instead of requiring "backlog grooming."
• Iterate Daily: Meet once a day. Focus on: "What is the biggest problem right now?" and "What is in the way of launching?"
• Set Milestone-Based Goals: Abandon quarterly OKRs. Set the goal for the next milestone (e.g., "Prove 1,000 users can write a helpful note"). When that is hit, set the next one. This allows the roadmap to change multiple times in a two-week span based on real data.

Phase 3: Proving Survival

• Iterative Proof Points: Prove the product at every stage to maintain funding.
  1. Stage 1: Use prototypes (Figma/UserTesting) to prove demand.
  2. Stage 2: Use small pilots (e.g., Amazon MTurk) to prove feasibility.
  3. Stage 3: Launch a limited public pilot to prove quality.
• Delete the "Cruft": Regularly audit the codebase and features. Deleting code is as important as writing it to keep the maintenance burden low for a small team.

Examples

Example 1: Launching a radical new AI feature in a legacy company

• Context: A PM wants to add a decentralized moderation tool to a social platform.
• Thermal Setup: The PM gets the CTO as a single sponsor. They recruit one ML engineer and one designer who are excited about the tech. They ignore the quarterly planning cycle.
• Execution: They use a Google Doc to track "Experiments for this week." They realize the first algorithm is biased. Because they aren't tied to an OKR to "Launch Version 1," they pivot immediately to a "Bridging Agreement" model and ship a new pilot in 14 days.

Example 2: Rapidly scaling a feature during a crisis

• Context: A sudden global event causes a deluge of misinformation.
• Thermal Setup: The team (already small and focused) skips all external meetings.
• Execution: The lead talks directly to the CEO. They realize they need "Image Matching" immediately. Because the team is "Thermal," they re-route all 5 engineers to this one task and ship the feature in 3 weeks—a task that would usually take 6 months.

Common Pitfalls

• The "Shared Resource" Trap: Allowing an engineer to spend "20% of their time" on another project. This introduces a 1-2 week delay every time you need a decision from them, killing momentum.
• Backlog Grooming Overload: Spending more time managing Jira tickets than talking about the product. If the team is small enough, you should be able to keep the core priorities in your head.
• Assigning vs. Recruiting: If people are "assigned" to a high-intensity Thermal team without opting in, they will burn out or resist the "Hardcore" pace.
• Over-Designing for Scale: Trying to build a system for 100M users before proving 1,000 users find it helpful. Use "Thermal" speed to prove the value first.