Unexpected anti-patterns for engineering leaders
Engineering leadership advice that warns against micromanagement, over-reliance on metrics, and exposing teams to pressure is being reexamined, with many arguing that these “best practices” can backfire when applied dogmatically. Commenters debate how deeply leaders should engage in technical details, whether imperfect metrics help or harm, and how much to shield engineers from business demands, often contrasting large web-focused companies with other domains like embedded systems or robotics. A recurring theme is that context, trust, and real business impact matter more than any single framework, and that cargo-culting management playbooks can lead to disengaged teams and poor outcomes.
Micromanagement vs. Technical Engagement
- Many distinguish “micromanagement” (controlling day-to-day decisions) from leaders staying close to technical details.
- Several argue good leaders understand systems deeply, can challenge assumptions, and sometimes dive into bugs, but without dictating every step or eroding autonomy.
- Others warn that leaning into micromanagement destroys trust, reduces ownership, and trains teams to wait for the manager.
- There’s debate over whether the article misuses the word “micromanagement,” causing confusion about what’s actually being advocated.
Metrics, Value, and Measurement
- Strong thread arguing engineering should be tied to concrete business metrics: per-user costs, infra vs. staff spend, impact of projects on bottom line.
- Some praise “measure something imperfect but useful” to start conversations and refine understanding.
- Others say the real problem isn’t imperfect metrics, but leaders making rigid judgments from bad metrics, rewarding the wrong behaviors and adding entropy.
- DevOps/DORA-style metrics (speed, stability, cost) are cited as useful levers when paired with continuous improvement and real process change.
Reactions to the Article and Its Ideas
- Mixed reception: some call it a thoughtful, nuanced take on leadership tradeoffs; others find it verbose, self-promotional, or “VC puff.”
- A few report seeing these ideas cargo‑culted into “ivory tower” orgs that clash with the business and later get cut.
- Counterpoint: any management framework can be abused; problems often stem from poor managers, not from the ideas themselves.
Org Design, Team Size, and Complexity
- Debate about whether better tools will shrink teams to a few “wizards.” Some think most complexity and demand make this unrealistic.
- Classic “mythical man‑month” and “9 women, 1 baby” analogies are revisited; commenters stress ramp-up time, non-parallelizable work, and pivot costs.
- Clarifying roles, decision rights, and approval processes is seen as crucial to avoid surprise vetoes and diffusion of responsibility.
Culture, Documentation, and Politics
- Several emphasize documenting “why,” not just “what,” especially around major business and technical decisions.
- There is concern about “cult of personality” leadership; some push for consensus-building and strong engineering–business alignment.
- Career-wise, many note that relationship with one’s manager and cultural fit often matter as much as formal process or methodology.