Clear Priorities: Scheduling Is Itself Strategy

Clear Priorities: Scheduling Is Itself Strategy Creating scarcity is a classic internet-startup tactic: invitation-only access and queues follow this logic. FDE scheduling takes a different form but rests on a similar principle: “Team capacity is always smaller than market demand; the sequence in which projects begin is itself a strategic tool.” First recognize the hard constraints. A qualified deployment squad—one business professional who understands operations and communicates on site, plus two or three technical staff—can usually deliver no more than two projects at high quality simultaneously. A customer success manager (CSM) can support 8–12 customers at once, while an FDE can be deeply embedded with only 1–3. A deployment for one customer often lasts 30–60 days and requires engineers on site daily. OpenAI initially had only two FDE engineers; Sierra measures deployments in months; Harvey needs 6–9 months to implement at a single law firm. High-caliber delivery capacity is inherently scarce. Capacity scarcity is a fact. What we can manage is a set of rules for delivering scarce resources: a profitability threshold and three scheduling principles. The profitability threshold is a minimum contract size. A US$10,000 order cannot support an FDE earning US$200,000 a year. In this model, a contract only becomes viable above US$100,000. Every scheduling strategy must rest on that economic floor. Companies must calculate carefully against their own business and costs. First, schedule by strategic value, not contract size. The decision matrix has two dimensions: the customer’s lighthouse value—its strength as an industry signal—and learning value, meaning reusable capabilities the work can build. Customers strong on both dimensions may deserve priority and extra resources. Palantir’s early free pilots, costing millions of dollars, followed this reasoning. A large contract weak on both dimensions is more dangerous: substantial revenue may lock up an elite team for six months to a year. Second, turn waiting into a product. Do not waste the period before the team arrives. Give customers a data-preparation checklist to shorten implementation; provide business staff with preparatory guidance, identifying key decision-makers early; and conduct lightweight remote diagnostics to maintain engagement and flag risks. Well-managed waiting can shorten on-site delivery by one-third. Waiting then becomes part of delivery quality rather than a negative experience. Third, never promise concurrency beyond capacity. Quality depends on sustained, deep engagement. Each project requires familiarity with the customer’s business context; switching projects requires learning that background anew, creating substantial switching costs. Better to tell customers that availability extends into next quarter, making scarce capacity a selling point, than exhaust the team across multiple projects. Strong demand makes extra projects tempting, but the damage from overloaded, failed delivery far exceeds the loss of one forgone order. #ForwardDeployedEngineeringFDE ---- Robin: “I have suggested before that, rather than eagerly accept a large, long-term order worth tens of millions or hundreds of millions, try splitting it into many smaller, shorter projects that can be delivered and validated quickly. Customers and teams may not clearly understand a vague long-term order. Large amounts tend to extend delivery, and longer delivery creates more variables: customers develop new ideas, technology keeps changing, and the size of the commitment raises expectations. The project may remain unfinished and even expose you to contractual damages.”