In today’s post I want to compare house architecture design to product engineering organization (org) design.

The Foundation: Mission vs. Muddy Footings

In house architecture, the foundation is everything. If the footing is shallow, uneven, or built on shifting ground, you get cracks, settling, and eventual structural failure.

In org design, the “foundation” is the Mission and Decision Framework.

  • The Muddy Footing (Bad Org Design): The org’s mission is unclear, constantly changing, or differently interpreted by different teams. Teams lack autonomy because the decision-making authority is ambiguous (“Who owns the API contract?”). This is the organizational equivalent of building a beautiful house on a swamp.
  • The Cost: This leads to “decision debt.” Every simple choice requires a meeting chain, creating massive drag. Teams waste time arguing about who is responsible instead of what needs to be built.

The Walls: Information Flow vs. Blocked Ventilation

A well-designed house optimizes for ventilation, light, and utility access. Air should flow, light should reach living spaces, and plumbing/electrical systems should be accessible and well-mapped.

In an organization, the “walls” define information flow and dependencies.

  • The Blocked Vent (Bad Org Design): Teams are walled off in silos (e.g., a “Frontend Team” and a “Backend Team” with zero dedicated interface). Information doesn’t flow naturally; it has to be pushed over the wall via formal documentation or time-consuming meetings. This directly manifests as Conway’s Law in action: the resulting product is clunky because it reflects the clunky communication structure of the teams that built it.
  • The Cost: This is the breeding ground for technical debt. Teams constantly wait on others, leading to “stale information” (requirements that are out-of-date) and friction. When the “pipe bursts” (a bug appears), nobody knows if it’s the front wall or the back wall that failed, making debugging a slow, multi-team nightmare.

The Blueprint: Minimum Viable Structure vs. Over-Engineering

A good architect starts with a minimal blueprint, a plan that satisfies the core function (shelter, safety, utilities) and allows for future expansion (renovation).

In org design, we’re after the Minimum Viable Structure (MVS).

  • The Over-Engineered Mansion (Bad Org Design): The org is designed with too many specialized, interdependent teams from day one (e.g., a separate QA team, DevOps team, and UX research team, each reporting up a different chain). This is the organizational equivalent of building a 10-bedroom mansion for a two-person startup.
  • The Cost: This creates coordination overhead and resource bloat. Every task, no matter how small, requires six handoffs. You’ve introduced high friction before the product has even found its market fit. The “house” becomes inflexible, making the inevitable renovation or rebuild (i.e., adapting to market changes) a near-impossible logistical nightmare.

The Analogy’s Conclusion: Renovation vs. Rebuild

A homeowner only has two options when the foundational flaws of a house become unbearable: renovate (fix the internal walls) or rebuild (tear it down and start over).

The main takeaway:

When your teams suffer from slow decisions, endless dependencies, and high-friction releases, the problem isn’t the lumber (the engineers); it’s the blueprint (the org design). Failing to invest time in a thoughtful, simple, and adaptable org design is like cutting corners on the foundation, it saves money now but guarantees a devastatingly expensive structural failure down the road. Bad org architecture is simply technical debt in human form.

Leave a comment

Trending