The Builder Anti-Patterns

The builder mindset is easier to understand when you can see its opposites.

Anti-pattern one: ticket obedience. The developer completes tasks without asking whether the work solves the right problem. This feels efficient in the short term and expensive in the long term. The fix is not constant debate. The fix is selective clarification for important or unclear work.

Anti-pattern two: product theater. The team uses product language but still builds predetermined solutions. Documents mention users, hypotheses, and metrics, but decisions do not change based on evidence. The fix is to define kill criteria and review results after release.

Anti-pattern three: AI speed without ownership. The team generates more code but does not improve context, review, testing, or evaluation. Pull requests get larger. Defects become harder to understand. The fix is an AI-Assisted Delivery Protocol and smaller changes.

Anti-pattern four: architecture religion. People argue for tools, patterns, or architectures as identity. Microservices, monoliths, event-driven systems, serverless, typed languages, and frameworks become camps. The fix is to evaluate architecture by changeability, ownership, observability, reversibility, and business stage.

Anti-pattern five: debt whining. Engineers complain about code quality but cannot explain business cost. Leaders ignore the complaints because they sound like preference. The fix is debt triage: classify the debt, show impact, connect it to upcoming work, and recommend a treatment.

Anti-pattern six: dashboard comfort. The team has many metrics but few decisions. Dashboards are reviewed because they exist, not because they guide action. The fix is to start with the decision and remove metrics that do not inform it.

Anti-pattern seven: release heroics. Releases depend on late nights, manual steps, tribal knowledge, and hope. The team celebrates heroism instead of improving the release system. The fix is small batches, automation, rollback paths, and release review.

Anti-pattern eight: incident amnesia. The same failures repeat because incident reviews create weak action items. "Be careful" is not a system improvement. The fix is to change safeguards, observability, ownership, tests, runbooks, or product behavior.

Anti-pattern nine: soft-skill dismissal. Engineers treat communication as secondary to technical work. Then good decisions fail because they are not understood, funded, or remembered. The fix is writing, trade-off framing, ADRs, and follow-through.

Anti-pattern ten: title waiting. Developers wait for promotion before acting with ownership. They do assigned work and hope someone notices potential. The fix is to create proof: clarify one problem, improve one workflow, document one decision, mentor one person, own one outcome.

Anti-pattern eleven: founder bypass. Founders stop using the team for thinking and use them only for implementation because previous conversations felt slow or defensive. The fix is for engineers to bring options, speed paths, and business-aware recommendations. Founders should also share context earlier.

Anti-pattern twelve: process accumulation. The team responds to every failure by adding a new checklist, meeting, or approval. Eventually work slows and people route around the process. The fix is to remove low-value process and keep only practices that improve decisions, quality, or learning.

Anti-pattern thirteen: hidden custom work. The team builds customer-specific exceptions without naming them. Over time the product becomes a patchwork of special cases. The fix is to classify work as product capability, temporary bridge, service work, or custom commitment.

Anti-pattern fourteen: learning without memory. People learn in conversations, but nothing is captured. New team members repeat old mistakes. Decisions are revisited without context. The fix is lightweight decision records, runbooks, and learning memos.

Anti-pattern fifteen: outcome avoidance. The team prefers output because outcome is harder to measure. It celebrates shipped features and avoids asking whether they worked. The fix is to define one success signal before release and review it after.

Anti-patterns are useful because they remove vagueness. A team can ask, "Which of these are we doing?" The answer may be uncomfortable, but it becomes actionable.

Do not try to fix every anti-pattern at once. Pick the one causing the most cost now. If releases are painful, start with the Safe Speed Loop. If features miss value, start with the 5P Lens and the Bet Canvas. If AI usage is messy, start with the AI protocol. If trust with founders is weak, start with the working agreement.

The builder rule is this: name the pattern, then improve the system that produces it.

Key takeaways

• Fifteen anti-patterns, each with a specific fix: from ticket obedience (fix: selective clarification) to dashboard comfort (fix: start with the decision, not the metric).
• Naming a pattern turns a vague complaint into an actionable one: "which of these are we doing?" gets a real answer.
• Don't try to fix all fifteen at once: pick the one costing the most right now and start there.
• Several anti-patterns point back to earlier tools in the book: architecture religion to the changeability lens, debt whining to debt triage, AI speed without ownership to the AI-Assisted Delivery Protocol.
• The underlying rule is the same throughout: fix the system that produces the behavior, not just the behavior itself.