AgentSkillsCN

thermal-team-incubation

在大型组织中,以自主运营的“热核”单元为依托,打造高影响力、从零到一的产品。当需要快速推进新举措、绕过繁琐的公司官僚流程,或当某个项目需要历经多次领导更迭却仍能持续创造价值时,可运用这一框架,让项目在组织中脱颖而出、稳步前行。

SKILL.md
--- frontmatter
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.