Case: Designing an Amoeba for a Tech Company

Overview

• What you’ll learn: A complete worked example of amoeba design applied to a 50-person software company — including proposed unit definitions, boundary rationale, and internal pricing design for shared infrastructure services.
• Estimated reading time: 10 minutes

Introduction

The Grand Historian presents a case study: TechCo, a 50-person B2B software company. Annual revenue: ¥500 million. Product: a cloud-based ERP platform. Staff composition: 15 engineers, 8 customer success managers, 6 salespeople, 5 infrastructure/DevOps staff, 10 general and administrative. The CEO has read Inamori. The question is: what does amoeba design look like here?

The traditional org chart shows: Engineering → CPO; Customer Success → CRO; Sales → CRO; Infrastructure → CTO; G&A → COO. Clean reporting lines. Zero insight into value flows or P&L accountability below the company level. The amoeba map will look very different.

Proposed Amoeba Structure

• Amoeba 1 — Sales (6 people): External revenue generator. Revenue = new ARR signed. Costs = salaries + sales tools + travel. Unit time profit = new ARR per salesperson-hour. Internal buyer of: product demos from Product Dev (via internal pricing), technical proposals from Infrastructure. Amoeba leader: VP Sales.
• Amoeba 2 — Customer Success (8 people): External revenue generator (renewal and expansion ARR). Revenue = renewal ARR + expansion ARR retained and grown. Costs = salaries + customer tools. Internal buyer of: infrastructure uptime (via SLA-based internal pricing). Amoeba leader: Head of Customer Success.
• Amoeba 3 — Product Development (15 people): Internal revenue generator — sells product capabilities to Sales (new features as competitive assets) and to Customer Success (product improvements that reduce churn). Internal pricing: negotiated quarterly with Sales and CS on a per-feature or per-sprint basis. Costs = salaries + software licenses + testing infrastructure. Amoeba leader: CPO.
• Amoeba 4 — Infrastructure / DevOps (5 people): Internal revenue generator — sells uptime, reliability, and deployment services to Product Dev, Sales, and CS. Internal pricing: SLA-based monthly charge per active service. Example: ¥200,000/month per amoeba for guaranteed 99.9% uptime and 4-hour incident response. Costs = salaries + cloud infrastructure + tooling. Amoeba leader: Head of DevOps.

G&A Treatment

The 10 G&A staff (finance, HR, legal, executive assistants) are NOT a separate amoeba in this design — they are below minimum viable size for meaningful P&L accountability, and their “revenue” cannot be meaningfully priced internally without creating perverse incentives. Instead, their costs are allocated to the four amoebas by headcount proportion, appearing as a fixed monthly overhead charge on each amoeba’s expense side.

Internal Pricing Design for DevOps

The Infrastructure amoeba charges each internal customer a monthly SLA fee. The fee is negotiated annually and covers: guaranteed uptime percentage, maximum incident response time, number of deployments per month included, and escalation procedure. If Product Dev wants five deployments per month and the standard package includes three, they pay an overage rate. This pricing structure gives Infrastructure a clear revenue metric, gives its customers a clear cost metric, and creates natural pressure on both sides to use infrastructure efficiently.

Key Takeaways

• A 50-person software company can support 4 amoebas — Sales, Customer Success, Product Dev, and Infrastructure.
• G&A below minimum viable size is better treated as allocated overhead than as a separate amoeba.
• Infrastructure services are priced via SLA-based monthly charges — not free, not allocated by accounting convention.
• Every internal pricing relationship should create pressure on both the buyer and the seller to improve efficiency.