How to make Product give a shit about your architecture proposal
Engineers and product managers often clash when long-term architectural work appears to compete with short-term feature delivery. Commenters argue that technical teams must frame architecture changes in terms of business outcomes—speed of future feature development, reliability, cost control—rather than abstract “good engineering,” while avoiding resume-driven overengineering and gold-plating. Others counter that mature engineering orgs should own technical decisions outright, consulting product on impact and timing but not asking non-technical stakeholders to choose architectures they can’t meaningfully evaluate.
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.