How to make Product give a shit about your architecture proposal
Overengineering vs. “Just Ship It”
- Many see the article’s stance as overengineering for an early-stage product, arguing that “bucket under the leak” solutions are often correct until scale proves otherwise.
- Others counter that deliberately reducing quality can backfire; quality has a cost but so does tech debt and rushed fixes.
- Tension between “resume‑driven architecture” (microservices, pub/sub) and pragmatic, simple designs is a recurring concern.
Product vs. Engineering Responsibilities
- Strong disagreement on whether engineers should “sell” architecture to Product.
- One camp: anything engineers build is part of the product; they must speak in terms of outcomes, costs, and tradeoffs, and help Product prioritize.
- Another camp: asking non‑technical people to make technical decisions is a responsibility failure; engineers should own architecture and just do necessary work.
- Several note dysfunction when Product dictates both what and how fast without understanding technical consequences.
Communication as Sales / Empathy
- A major thread: you can’t make others care about architecture; you must translate it into their interests (feature velocity, reliability, costs, roadmap risks).
- Suggested tactics:
- Frame proposals as solving Product’s pains (slowing delivery, rising infra costs, unreliable features).
- Use simple, business‑oriented narratives, not technical diagrams.
- Provide options (A/B/C with costs and risks) so stakeholders feel ownership, but avoid fake choices that erode trust.
Plumber / Mechanic Analogies and Distrust
- Some view the plumber metaphor as illustrating upselling and fear tactics, mapping to engineers proposing “gold‑plated submarines.”
- Others argue it shows that quality work legitimately costs more, and that many organizations are too willing to accept “buckets under leaks.”
Organizational Dysfunction & Incentives
- Multiple comments emphasize misaligned incentives:
- Engineering optimizes long‑term maintainability; Product optimizes features; corporate optimizes cost.
- Lack of cross‑functional thinking causes each group to maximize its own metric.
- Several propose that mature teams silently budget time for refactoring/architecture, measure outcomes, and avoid mixing technical work items with feature backlogs controlled solely by Product.