Balancing engineering cultures: Debate everything vs. just tell me what to build
Engineering teams often oscillate between “debate everything” cultures that stall on consensus and “just tell me what to build” environments where developers disengage from product thinking. Commenters argue that the real issue is leadership and decision-making: clear ownership of decisions, shared understanding of business goals, and psychologically safe space for input are seen as essential to avoiding paralysis, burnout, and over-management. Many highlight the need for product managers and managers who are technically literate, willing to make and own calls, and able to connect engineers directly to customer problems rather than burying them in process.
Debate-Everything vs. Just-Tell-Me-What-to-Build
- “Debate everything” often stems from uncertainty (lack of experience, unclear goals, low trust) and ego (smart people needing their views validated).
- “Just tell me what to build” can reflect apathy/burnout or inexperience and ambiguity about goals and process.
- Both extremes are seen as symptoms of weak leadership rather than stable cultural end states.
- Debate can be productive when grounded in a shared notion of “good” (simplicity, performance, customer value), but harmful when used to delay, posture, or avoid accountability.
Decision-Making and Leadership
- A recurring failure mode: nobody knows who the actual decision-maker is; consensus-seeking turns into paralysis.
- Many argue for: consult stakeholders, then let a clearly identified, competent person decide and own consequences.
- “Consensus” is reframed by some as “no one vetoes strongly,” not “everyone agrees.”
- Comparisons are made to military or film sets: one commander/director ultimately decides, after input.
- Persistent re-opening of settled decisions is described as uniquely exhausting.
- Data-driven decision-making is praised in high-safety domains, but others warn data can be cherry-picked and not every decision can wait for perfect data.
Role of Product Managers and Managers
- Common complaints: PMs who generate endless meetings, documents, and frameworks but never commit to a direction; or powerful PMs pushing vague grand architectures that go nowhere.
- Positive model: PM as decisive “designated scapegoat” who makes tough calls, absorbs risk, and shields engineers.
- Technical fluency in PMs is highly valued for reducing meetings, making realistic tradeoffs, and speaking with customers.
- Overabundance of managers (“too many chefs”) is seen as a driver of process bloat and stalled execution.
Developer Context, Hiring, and Incentives
- Many emphasize giving engineers deep understanding of customer problems and business metrics, not just tasks.
- Blindly implementing stated “wants” is criticized; engineers are urged to ask “why” and restate needs.
- Some devs explicitly want factory-style work; if hired in bulk, they can shift culture toward indifference to product impact.
- Suggestions range from reorgs and incentives to directly firing clearly misaligned team members; views differ on feasibility and risks.
Psychological Safety, Burnout, and Culture
- Toxic reviews and hostile debates are described as creating work-related “PTSD,” especially around peer review.
- Cultures where engineers are disempowered yet blamed (vague orders, no meaningful input) are linked to severe burnout.
- Psychological safety—respecting experiments, clarifying ownership, allowing dissent without punishment—is seen as central to avoiding both endless debate and passive compliance.