I am often wrong
A tech leader’s blog post outlining a six-step, “act with urgency” problem‑solving framework and professed love of being wrong has triggered a broader critique of modern management culture in AI companies. Commenters argue the method is shallow, prescriptive, and ignores power dynamics and burnout risks, tying it to frustrations with buggy AI tooling and a perceived overreliance on agents and process over craftsmanship. A minority defend the framework as a reasonable variant of established decision-making models, but many see it as corporate platitudes that fail to account for individual working styles or genuine psychological safety.
Perceived value of the framework
- Some see the six-step process as a perfectly reasonable, fairly standard problem-solving loop, akin to OODA, PDCA, Polya’s “How to Solve It,” or Amazon-style decision docs.
- Supporters say explicitly documenting how one thinks can reduce confusion about expectations and improve decisions, especially when combined with written rationales.
- A minority find it motivating in “bias for action” environments: understand the situation, then execute decisively.
Critiques of tone, humility, and originality
- Many describe the framework as generic, “middle-school” level, or Silicon Valley platitudes dressed up as insight.
- The title “I am often wrong” is widely read as humblebrag; commenters note a lack of concrete examples of being wrong or of decisions changed in practice.
- Some react negatively to the self-focused framing (“my framework,” “my approach”) and publishing this externally rather than as internal guidance.
Leadership, power dynamics, and feedback culture
- Strong pushback against “requiring” others to follow a personal framework and giving them “feedback” when they don’t.
- Several argue good leadership adapts to individual strengths instead of minting clones; frameworks should be tools, not enforcement mechanisms.
- Others respond that every leader implicitly imposes some process; making it explicit can be helpful.
- There is concern that psychological safety and “honest feedback” are assumed rather than ensured, especially when coming from senior ICs whose feedback still carries heavy weight.
Urgency, prioritization, and problem definition
- “Act with urgency” is heavily criticized as a recipe for burnout, sloppy work, and the feeling that everything is always on fire.
- Defenders interpret it as “once you’ve done the thinking, execute quickly,” or as an antidote to big-company paralysis.
- Multiple commenters say the step order is confused: goal definition appears late, information-gathering precedes clear problem definition, and iteration/experimentation is underemphasized.
Claude Code and product-quality spillover
- A large subthread uses the state of Claude Code as a test case: many describe it as buggy, inconsistent, slow, and oddly implemented (e.g., React/JS choices, terminal-in-sidebar UX).
- GitHub issue volume, long-standing bugs (like missing messages), and auto-closed issues are cited as evidence that the process isn’t delivering quality.
- Others counter that huge user scale and broad surface area explain many issues, and that not all open issues are confirmed bugs.
LLMs, culture, and communication
- Some worry that heavy internal use of agents is “filing people’s voices smooth,” making communication sound like LLM output and weakening human-to-human collaboration.
- Others note that all human thinking is already somewhat “faulty narrator”; LLMs may just make this more visible.