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.