Prioritizing a candidate's skills ('capacity') over their fit with the team ('chemistry') is a mistake. To scale culture successfully, focus on hiring people who will get along with their colleagues. The ability to collaborate and integrate is more critical for long-term success than a perfect resume.

Focusing on individual performance metrics can be counterproductive. As seen in the "super chicken" experiment, top individual performers often succeed by suppressing others. This lowers team collaboration and harms long-term group output, which can be up to 160% more productive than a group of siloed high-achievers.

Originally, 'break things' referred to accepting bugs in code to ship faster. This philosophy has since metastasized into a justification for damaging team culture, breaking user trust, and violating ethical and legal boundaries, with severe real-world consequences.

Similar to technical debt, "narrative debt" accrues when teams celebrate speed and output while neglecting shared understanding. This gap registers as momentum, not risk, making the system fragile while metrics still look healthy.

AI coding tools dramatically accelerate development, but this speed amplifies technical debt creation exponentially. A small team can now generate a massive, fragile codebase with inconsistent patterns and sparse documentation, creating maintenance burdens previously seen only in large, legacy organizations.

To prevent engineers from focusing internally on technical purity (e.g., unnecessary refactoring), leaders must consistently frame all work in terms of its value to the customer. Even tech debt should be justified by its external impact, such as improving security or enabling future features.

Hiring someone with a prestigious background for a role your startup isn't ready for is a common mistake. These hires often need structure that doesn't exist, leading to their underutilization and boredom. It's like using a "jackhammer when all we needed was a sturdy hammer."

The popular tech mantra is incomplete. Moving fast is valuable only when paired with rapid learning from what breaks. Without a structured process for analyzing failures, 'moving fast' devolves into directionless, costly activity that burns out talent and capital without making progress, like a Tasmanian devil.

A project's success equals its technical quality multiplied by team acceptance. Technologists often fail by engineering perfect solutions that nobody buys into or owns. An 80%-correct solution fiercely defended by the team will always outperform a "perfect" one that is ignored.