Infrastructure Gravity & Domain Engineering

The article challenges the common two-level view of engineering work, visible product tasks versus invisible cost-center tasks, by arguing that the invisible work actually splits into two distinct activities. It labels these activities Domain Engineering and Infrastructure Engineering, preserving Product Engineering as the third layer. This three-level model exists regardless of company size and does not necessarily follow the org chart.

In the early stages of a startup, engineers concentrate on feature creation until growing complexity prompts one of them to step away from feature work to tame deployment scripts, databases, or test suites. This person becomes the first infrastructure hire, creating a gravity that pulls additional foundational work inward as the system expands. The infrastructure role is broad, addressing any class of problem across the stack because the individual has helped build everything so far.

When a company later hires someone directly onto the infrastructure team without prior product experience, a fundamental mismatch can arise: the new hire maintains a foundation they do not understand. The article warns that this can lead to fixes that are technically correct but misaligned with the product they support, creating hidden technical debt and reliability issues over time.

Domain Engineering is presented as the layer that fills the gap between product intent and infrastructure. It captures the “unique to this company, shared between features” concepts that are neither surface-level features nor low-level platform work. By giving this layer its own identity, companies can allocate dedicated investment and leadership to manage shared business models, data contracts, or cross-cutting concerns.

The three-level framing influences staffing ratios: junior product teams need more infrastructure support, while senior product engineers can reason about deeper layers and require less. The model may stop working in very small teams where roles inevitably blur, or in organizations that refuse to separate layers, causing the infrastructure gravity to pull product work into foundational tasks and slowing feature delivery.