Conversation 2: On "One Engineer Per Team"

The question you will hear: "Can we staff each product team with just one developer?"

Your stance: One engineer is not a team. It is a single point of failure wearing a process diagram.

It looks efficient on a slide: one engineer, one PM, one designer, minimal dependencies, clear ownership. What it actually produces is fragility. That one person cannot get sick, take vacation, or leave without breaking something. Every architectural decision gets made in isolation. After a year the organization owns a dozen product surfaces and a dozen incompatible ways to handle authentication, logging, and deployment.

Cross-cutting concerns—security, observability, data contracts—become nobody's job because no single pod has the scope or incentive to own them.

How to lead in that room: Counter-propose small, persistent teams of three to five engineers with clear product ownership and shared platform infrastructure underneath. Invest in platform teams that own shared concerns: identity, observability, deployment pipelines, security baselines. Those teams are not overhead to be minimized. They are the infrastructure that makes product teams sustainably fast.

Before	After
One engineer owns each product surface	Three to five engineers share ownership
Knowledge concentrated in individuals	Knowledge distributed through pairing, documentation, rituals
Every team reinvents shared infrastructure	Platform teams provide standardized tools and guardrails
Speed measured by isolated pod output	Speed measured by sustainable delivery across the whole product
Org chart optimized for minimal headcount	Org chart optimized for resilience and knowledge distribution

What to avoid: Saying "that won't work" without proposing an alternative. Referencing Spotify or Amazon without explaining why your context is different. Letting the conversation become about headcount instead of resilience.