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
- Founder-Leader Ownership: The project lead must act as a founder, not a manager. They own the vision, the team, and the output entirely.
- 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.
- 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).
- 100% Radical Focus: Every member must be 100% dedicated. Shared resources or part-time contributors create "momentum friction" that kills Thermal projects.
- 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.
- Stage 1: Use prototypes (Figma/UserTesting) to prove demand.
- Stage 2: Use small pilots (e.g., Amazon MTurk) to prove feasibility.
- 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.
1---2name: thermal-team-incubation3description: 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.4---56The "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.78## Core Pillars of a Thermal Team9101. **Founder-Leader Ownership**: The project lead must act as a founder, not a manager. They own the vision, the team, and the output entirely.112. **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.123. **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).134. **100% Radical Focus**: Every member must be 100% dedicated. Shared resources or part-time contributors create "momentum friction" that kills Thermal projects.145. **Process Autonomy**: The team is exempt from standard corporate rituals (OKRs, rigid planning cycles, Jira grooming) in favor of dynamic, milestone-based execution.1516## Implementation Workflow1718### Phase 1: Structural Setup19* **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.20* **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.21* **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").2223### Phase 2: Execution Mechanics24* **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."25* **Iterate Daily**: Meet once a day. Focus on: "What is the biggest problem right now?" and "What is in the way of launching?"26* **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.2728### Phase 3: Proving Survival29* **Iterative Proof Points**: Prove the product at every stage to maintain funding. 30 1. *Stage 1*: Use prototypes (Figma/UserTesting) to prove demand.31 2. *Stage 2*: Use small pilots (e.g., Amazon MTurk) to prove feasibility.32 3. *Stage 3*: Launch a limited public pilot to prove quality.33* **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.3435## Examples3637**Example 1: Launching a radical new AI feature in a legacy company**38* **Context**: A PM wants to add a decentralized moderation tool to a social platform.39* **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.40* **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.4142**Example 2: Rapidly scaling a feature during a crisis**43* **Context**: A sudden global event causes a deluge of misinformation.44* **Thermal Setup**: The team (already small and focused) skips all external meetings. 45* **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.4647## Common Pitfalls4849* **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.50* **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.51* **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.52* **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.
samarv