Mental Models for Engineering Leaders

Example:To ensure a successful project, list everything that could kill it (poor communication, lack of tests) and focus on preventing those.

Example:Elon Musk's approach to battery costs: breaking down the cost of raw materials rather than accepting current market prices for battery packs.

Example:Adding a new feature might increase user engagement (1st order) but also increase maintenance burden and technical debt (2nd order).

Example:An architectural diagram is a map; the actual running code and infrastructure are the territory.

Example:Schrödinger's cat or Einstein's imagining riding a beam of light.

Example:If a system fails after a small config change, the change is likely the cause, not a sudden hardware failure.

Example:A colleague missing a deadline is likely overwhelmed, not trying to sabotage your project.

Example:Instead of looking for reasons why your architecture is good, try to find the scenarios where it breaks.

Example:A backend engineer should be cautious when making critical UI/UX decisions without consulting experts.

Example:Deciding whether to invest in a new tool based on the probability of it saving X hours vs the cost of implementation.

Example:Recognizing that changing a database schema affects not just the DB, but APIs, frontend, and reporting tools.

Example:CI/CD pipelines provide a balancing feedback loop by catching errors early.

Example:80% of software bugs are often found in 20% of the code.

Example:Chaos Engineering: intentionally breaking things to make the system more resilient.

Example:Multiple teams over-utilizing a shared staging environment until it becomes unusable for everyone.

Example:Small, consistent improvements in code quality lead to massive productivity gains over years.

Example:Adjusting your confidence in a release as more test results and canary metrics come in.

Example:A week of unusually high server traffic is likely to be followed by a week closer to the average.

Example:A single user's feedback might be an outlier, but 10,000 users' feedback represents the true sentiment.

Example:If developers are measured solely on story points, they may prioritize quantity over quality.

Example:Adopting a technology just because 'everyone else is using it' (Hype Driven Development).

Example:Thinking a specific type of bug is common just because it happened yesterday.

Example:Refusing to switch to a better framework because you've already spent 6 months on the current one.

Example:Spending 2 weeks on a minor UI tweak means you can't spend those 2 weeks on a critical security patch.

Example:Cloud computing destroying the traditional on-premise server market.

Example:A senior dev focusing on architecture while a junior dev handles bug fixes, even if the senior dev is faster at both.

Example:GitHub is valuable because that's where all the open-source projects and developers are.

Example:Skipping unit tests to meet a deadline creates debt that must be paid back later with interest (bugs, slow dev).

Example:Running multiple instances of a service across different availability zones.

Example:Provisioning 50% more server capacity than peak expected load.

Example:Using an ORM instead of writing raw SQL queries.

Example:If we assume that adding 100 developers to a project will make it 100x faster, we ignore the communication overhead which eventually makes progress negative (absurd).

Example:Using these rules in a code review to ensure constructive feedback.

Example:Filtering through 90% of low-quality libraries to find the 10% that are actually reliable.

Example:Ignoring performance bottlenecks in a new feature because the UI looks great.

Example:A/B testing a new feature to see if it actually improves user conversion.

Example:Adding heavy logging to debug a performance issue might change the timing enough that the issue disappears (Heisenbug).

Example:Surveying only active users about a feature, ignoring those who quit because of it.

Example:A single line of code change in a core library causing a cascading failure across an entire microservices architecture.

Example:The 'culture' of a company emerging from the daily interactions of its employees.

Example:Multiple teams over-utilizing a shared staging environment until it becomes unusable for everyone.

Example:A monolith is often fragile; a well-designed microservices architecture with circuit breakers is robust; a system with automated chaos testing is antifragile.

Example:The distribution of heights in a population or response times for a stable API.

Example:The distribution of wealth, city sizes, or the number of links to websites.

Example:Financial market crashes or major security breaches.

Example:A developer having an unusually productive week will likely return to their average productivity the following week.

Example:Ignoring the daily 'hype' or 'doom' in tech news and focusing on long-term value.

Example:The rise of digital photography destroying the film industry.

Example:Choosing to build feature A means you cannot build feature B with the same resources.

Example:Two companies in a price war where both would be better off keeping prices high, but both lower them to avoid losing market share.

Example:A company adapting its business model to survive in a remote-first world.

Example:The constant arms race between security researchers and hackers.

Example:The 'Apple Ecosystem' where hardware, software, and services work together to create value.

Example:A small startup using agility and niche focus to compete with a massive incumbent.

Example:A free tool offered by a company to gain access to a competitor's customer data.

Example:The 2008 financial crisis or the COVID-19 pandemic.

Example:Building a bridge to hold 10x the expected load to ensure it doesn't collapse.

Example:'Surely, the users will love this feature'—this often masks a lack of user research.

Example:'Love is just a four-letter word'—technically true, but misses the profound complexity of the emotion.

Example:Instead of optimizing a legacy system, questioning if the system is even needed anymore.

Example:'Do you want our servers to crash on Black Friday?'—used to emphasize the importance of scalability.

Example:Recording all meetings and making them available to everyone in the company (Ray Dalio's approach).

Example:A junior developer's architectural suggestion being chosen over a senior's because it's objectively better.

Example:When deciding on a DB migration, weighing the lead DBA's opinion more heavily than the product manager's.

Example:Conducting a blameless post-mortem after a major outage to ensure it doesn't happen again.

Example:Predicting user behavior on a website based on their current page.

Example:Ensuring that a load-balancing algorithm will eventually reach a stable state.

Example:Understanding how small preferences for similar neighbors can lead to highly segregated neighborhoods.

Example:How a few early adopters can trigger a massive trend in technology adoption.

Example:Software systems naturally tend toward technical debt and complexity (entropy) unless energy is actively spent to refactor them.

Example:The initial effort required to set up a new CI/CD pipeline or adopt a new team habit.

Example:A great developer tool or a clear documentation site that speeds up the entire team's delivery.

Example:Automating a repetitive task provides massive leverage by freeing up human time for higher-value work.

Example:The difficulty of changing a large organization's culture or a legacy codebase's architecture.

Example:The point where a new internal tool has enough users that it becomes the de facto standard and self-sustaining.

Example:The half-life of technical knowledge in a fast-moving field like frontend development.

Example:In management, the more you measure a specific metric, the more you might unintentionally distort the behavior you're trying to measure (Goodhart's Law).

Example:Structuring engineering organizations into 'tribes' or 'guilds' that don't exceed this size to maintain cohesion.

Example:A tool built for internal debugging that becomes a successful external product (e.g., Slack or PagerDuty).

Example:A startup finding a specific, underserved market segment to dominate before expanding.

Example:The high salaries of specialized AI engineers due to low supply and high demand.

Example:Time is the scarcest resource in a software project; choosing what NOT to build is as important as choosing what to build.

Example:Search engines (Google) or social networks (Facebook) where network effects create a dominant player.

Example:High R&D costs, proprietary data, or strong brand loyalty.

Example:Having a plan to migrate away from a third-party vendor if their service quality drops or prices spike.

Example:A leader spending time 'in the trenches' with developers to understand their daily friction points.

Example:Convincing a team of the value of a new process rather than just mandating it.

Example:Isolating a legacy system with a 'strangler fig' pattern to prevent its complexity from leaking into new services.

Example:Continuously adding 'one more small feature' for a demanding client instead of setting firm boundaries.

Example:Using this to justify the use of normal distribution models in large-scale system monitoring.

Example:Applying rigorous quality controls to a high-stakes financial transaction system.

Example:Spam filters use Bayesian logic to calculate the probability a message is spam based on the words it contains.

Example:A feature appearing to improve conversion in every individual country but showing a decrease when looking at global data due to varying sample sizes.

Example:Being more afraid of losing 10% of users due to a bug than excited about gaining 10% from a new feature.

Example:Running a 1-day spike to see if a technology is viable before committing to a 3-month project.

Example:Removing unused features to reduce the cognitive load and maintenance surface of a product.

Example:Ignoring the fact that a project is 3 months behind schedule and hoping 'it will just work out'.

Example:Hiring a candidate because they 'look and act like a great engineer' rather than based on their actual skills.

Example:Creating a post-hoc explanation for why a marketing campaign failed, even if it was just bad luck.

Example:Saying 'I knew that server would crash' after it happens, even if you didn't raise any concerns beforehand.

Example:Studying only successful startups to learn 'how to succeed' while ignoring the thousands that failed doing the exact same things.

Example:Focusing on 'Important but Not Urgent' tasks (like refactoring) to prevent them from becoming 'Important and Urgent' (like outages).

Example:Instead of 'Improve performance,' set a goal to 'Reduce API latency by 20% within 30 days'.

Example:Choosing a simple, well-understood database over a complex, experimental one for a critical project.

Example:Writing the press release and FAQ for a product before writing a single line of code (Amazon's method).

Example:Promoting a great individual contributor to a manager role where they lack the necessary skills.

Example:Choosing a cloud provider is a one-way door; choosing a library for a small utility is a two-way door.

Example:A high-pressure sales environment combining social proof, authority influence, and scarcity to drive impulsive purchases.

Example:Analyzing how two competing companies might set prices or release features based on each other's likely actions.

Example:A salary negotiation is often seen as zero-sum, but a collaborative project is non-zero-sum.

Example:Implementing a strict bug-count quota that leads developers to hide bugs or stop reporting them.

Example:Building a modular architecture that allows for switching databases or cloud providers later if needed.

Example:The shift from monolithic architectures to microservices or from manual deployments to DevOps.

Example:Instead of making a slow elevator faster, installing mirrors in the lobby to make the wait feel shorter.

Example:A brainstorming session (divergent) followed by a prioritization workshop (convergent).

Example:A founder thoroughly researching why previous attempts at a similar product failed before starting their own.

Example:When a product's growth becomes organic and users are actively recommending it to others.

Example:Better code quality leads to faster delivery, which leads to more user feedback, which leads to better products, and so on.

Example:Surveying only active users about a feature, ignoring those who quit because of it.

Example:Users saying they want a feature because it sounds good, but never actually using it in reality.

Example:Using 'lines of code' as a proxy for 'productivity' (often a poor proxy).

Example:A security tool flagging a legitimate request as an attack (false positive) or missing a real attack (false negative).

Example:Saying 'we are 95% confident that the new feature will improve conversion by 2-5%'.

Example:Removing complex features to make a system more reliable instead of adding more monitoring.

Example:SQL has been around for 50 years, so it's likely to be around for another 50, unlike a new JS framework.

Example:The stock market, the internet, or a large software engineering organization.

Example:A team can be 'fast' at shipping features, but if they are the wrong features, their velocity is zero.

Example:Running multiple instances of a service across different availability zones.

Example:Buying a product in a low-cost market and selling it in a high-cost market.

Example:A small increase in subscription price leading to a massive drop in users (high elasticity).

Example:A developer knowing a codebase is a mess while the manager thinks it's high quality.

Example:A team shipping a feature quickly but leaving technical debt for another team to maintain.

Example:Continuing to use a failing tool just because you spent $10k on the license.

Example:Adopting a technology just because 'everyone else is using it' (Hype Driven Development).

Example:Agreeing with a CTO's technical choice even if you know it's wrong because of their title.

Example:Refusing to admit a project is failing because you publicly championed it.

Example:A team being reluctant to adopt a tool built by another team due to 'Not Invented Here' syndrome.

Example:Thinking a specific type of bug is common just because it happened yesterday.

Example:Apple's management style where every task has one owner.

Example:A hard deadline like a product launch or a conference talk.

Example:A developer seeing a difficult bug as an opportunity to learn rather than a sign of failure.

Example:Skipping unit tests to meet a deadline creates debt that must be paid back later with interest.

Example:Having too many layers of management that slow down decision-making.

Example:Amazon being the first major online bookstore.

Example:Google entering the search market after Altavista and Yahoo.

Example:A sudden global pandemic affecting your supply chain when you only planned for local weather events.

Example:The difficulty of moving all your data from one cloud provider to another.

Example:AWS being able to offer lower prices because they buy hardware in massive quantities.

Example:Optimizing a single team's performance (local) at the expense of the entire company's goals (global).

Example:Building a high-trust environment where developers feel safe to admit mistakes and ask for help.

Example:Hiring 'T-shaped' engineers who have deep expertise in one area but a broad understanding of the entire stack.

Example:A remote-first company needing to move toward low-context (explicit) communication to avoid misunderstandings.

Example:Ensuring developers have psychological safety and clear goals before expecting them to innovate at a high level.

Example:Debugging a production issue by disabling half of the new features to see if the issue persists, then repeating.

Example:Decomposing a massive monolithic application into smaller, independent microservices.

Example:The value of a company's internal Slack or documentation increases exponentially as more employees contribute to it.

Example:Limiting the number of approved technologies in a company to reduce decision fatigue for engineers.

Example:Realizing that users 'hire' a dashboard not to see data, but to feel in control of their infrastructure.

Example:A tech company's core competency might be its unique data processing algorithm, not its UI.

Example:Strategy: Move to the cloud. Tactics: Migrate the user database to RDS this week.

Example:A developer spending time specifically on learning a new language or framework through focused projects.

Example:A senior engineer feeling like they don't belong in their role despite a track record of success.

Example:A junior developer thinking they can rewrite the entire core engine in a weekend.

Example:Ensuring developers have 'no-meeting days' to allow for deep work.

Example:Designing systems with the assumption that every component will eventually fail.

Example:Setting tight but realistic deadlines to prevent a project from dragging on indefinitely.

Example:Deciding to start a new company because you'd regret not trying more than you'd regret failing.

Example:Launching a simple landing page to test interest in a feature before building it.

Example:A leader taking responsibility for a failed release instead of blaming the team.

Example:Encouraging a culture where team members can challenge each other's ideas without it becoming personal.

Example:Focusing on team building as a way to improve long-term productivity and retention.

Example:Telling a team member their performance is below expectations so they have a chance to improve.

Example:A developer considering the long-term maintenance cost of a library they are choosing.

Example:Having a deployment checklist to prevent common mistakes during a release.

Example:Deciding to automate a task because the time saved will pay for the development cost in 3 months.

Example:Releasing a basic version of a tool to get user feedback early.

Example:Moving fast on a minor UI tweak but being extremely cautious with a database migration.

Example:Ensuring that the most critical features are included in the initial release.

Example:Providing a budget for books, courses, and conferences for all employees.

Example:A partnership between two companies that allows both to reach new customers.

Example:Technical debt slowly accumulating until the system becomes impossible to maintain.

Example:Users rarely changing the default settings of an application, making those defaults incredibly powerful.

Example:A team that celebrates 'smart failures' as opportunities to learn and improve their systems.

Example:Explaining a new system architecture to a product manager to see if the core logic holds up.

Example:Identifying when a debate has shifted from facts to 'piling on' emotional arguments.

Example:Planning for three different scenarios: high growth, steady state, and market downturn.

Example:Determining which variable (e.g., server cost vs. user growth) has the biggest impact on a project's budget.

Example:Comparing the cost of building a custom tool vs. the benefit of buying a third-party solution.

Example:Running a load test simulation to see how a system behaves under 10x normal traffic.

Example:Reaching a point in a resource allocation where any further change would hurt one team's productivity.

Example:Calculating the number of possible ways a feature could be configured by a user.

Example:Refactoring code to be more readable while ensuring the underlying logic remains identical.

Example:Recognizing that a sudden spike in errors might just be a random cluster rather than a systemic issue.

Example:Modeling user arrival times at an API using a Poisson process.