Dan McKinley is a renowned software engineer, speaker, and former principal engineer at Etsy and Mailchimp, best known for championing pragmatic engineering cultures. His foundational philosophies, particularly the concept of "Choose Boring Technology" and his advocacy for continuous experimentation, have shaped how modern engineering organizations manage risk, scale infrastructure, and make data-driven product decisions. The following insights distill his core teachings on building reliable systems, measuring what matters, and aligning technical choices with business reality.

Part 1: The Philosophy of "Boring" Technology

  1. On Boring Technology: "Boring technology in a nutshell is technology that's well understood. We know what it's capable of, and at least as importantly, we also know what it's not capable of." — Source: [mcfunley.com]
  2. On Quality vs. Boring: "Boring should not be conflated with bad. There is technology out there that is both boring and bad. You should not use any of that." — Source: [Choose Boring Technology]
  3. On Proven Systems: "MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring." — Source: [mcfunley.com]
  4. On Predictable Failures: "The most important feature of boring technology is that we know exactly how it fails under load and over time." — Source: [Speaker Deck]
  5. On Community Support: "When you use boring technology, the solutions to your most obscure problems are usually just a web search away." — Source: [mcfunley.com]
  6. On The 'Best' Tool Fallacy: "The 'best' tool is the one that occupies the 'least worst' position for as many of your problems as possible." — Source: [mcfunley.com]
  7. On Living with Tech: "Adding the technology is easy, living with it is hard." — Source: [Boring Technology Club]
  8. On Redundancy: "If you're adding a redundant piece of technology, your goal is to replace something with it." — Source: [Boring Technology Club]
  9. On Polyglot Persistence: "Polyglot persistence is not the kind of freedom we are looking for; it usually just means operating multiple databases poorly." — Source: [Boring Technology Club]
  10. On Novelty: "The amount of novelty you can afford is limited. The amount of technical novelty any organization can afford to maintain is strictly limited." — Source: [mcfunley.com]

Part 2: Managing Innovation and Risk

  1. On Innovation Tokens: "You get about three 'innovation tokens' to spend on new technology for any given project. Spend them wisely." — Source: [mcfunley.com]
  2. On Core Competency: "Your innovation tokens should only be spent on technologies that directly solve your company's core business problems, not on infrastructure." — Source: [mcfunley.com]
  3. On Unknown Unknowns: "When choosing technology, you have both known unknowns and unknown unknowns. An unknown unknown is something like: geez it didn't even occur to us that writing stats would cause GC pauses." — Source: [mcfunley.com]
  4. On Local vs. Global Optimization: "If you're giving individual teams (or gods help you, individuals) free reign to make local decisions about infrastructure, you're hurting yourself globally." — Source: [Boring Technology Club]
  5. On Shiny Object Syndrome: "Engineers are drawn to complex new systems, but adopting them without a severe business need is a failure of technical leadership." — Source: [mcfunley.com]
  6. On Rewriting Databases: "If you choose to write your own database, oh god, you're in trouble." — Source: [Speaker Deck]
  7. On Technical Scarcity: "Treat your system's capacity to absorb new paradigms as a scarce resource, because organizational patience and operational bandwidth always are." — Source: [mcfunley.com]
  8. On Risk Distribution: "Focus your risk taking on the product features that touch the customer, while keeping the backend infrastructure as risk-free as possible." — Source: [Choose Boring Technology]
  9. On Tool Selection: "Before adopting a new tool, ask whether it fundamentally changes the trajectory of the business, or just satisfies a developer's curiosity." — Source: [mcfunley.com]
  10. On Migration Costs: "The cost of moving from an old, boring system to a new, exciting one almost always exceeds the theoretical performance benefits of the new system." — Source: [Choose Boring Technology]

Part 3: Data-Driven Product Development

  1. On Measurement: "Whomst'd've refuses to do arithmetic is doomed to speak nonsense." — Source: [Data Driven Products Now!]
  2. On Staying Honest: "The second reason we measure product releases is so that we stay honest." — Source: [mcfunley.com]
  3. On Vanity Metrics: "Graphing metrics that naturally go up over time, regardless of what you do, is a recipe for false confidence." — Source: [mcfunley.com]
  4. On Proxy Metrics: "It turns out misery is a shitty proxy metric for whether a product is actually succeeding or failing." — Source: [Egoless Engineering]
  5. On Proving Value: "Without controlled experiments, you have absolutely no way of knowing if the feature you just shipped made things better or worse." — Source: [mcfunley.com]
  6. On Bad Ideas: "You must build a culture where finding out your idea was terrible is celebrated as a successful application of data, rather than a personal failure." — Source: [Data Driven Products Now!]
  7. On The Infinite Scroll: "Sometimes best practices like infinite scroll actually tank user engagement; data is the only thing that will tell you when conventional wisdom is wrong." — Source: [mcfunley.com]
  8. On Baseline Metrics: "You cannot improve what you cannot measure, and you cannot measure anything without establishing a reliable, pre-launch baseline." — Source: [Data Driven Products Now!]
  9. On Business Value: "I am become Digg, destroyer of business value. Massive engineering efforts deployed without validation act as destroyers of value." — Source: [Making Big Changes]
  10. On Data Infrastructure: "The cost of collecting and storing data must always be continuously weighed against the actual utility it provides to decision-makers." — Source: [mcfunley.com]

Part 4: Continuous Experimentation and A/B Testing

  1. On Small Changes: "I’m going to call what we do 'continuous experimentation,' for the lack of a better term. We try to make small changes as much as possible, and we measure those changes so that we stay honest." — Source: [mcfunley.com]
  2. On Avoiding Hysteria: "Experiment without provoking mass hysteria." — Source: [mcfunley.com]
  3. On Frequent Deploys: "Frequent Deploys are a Very Good Idea. Conditional probability: can't stop won't stop." — Source: [mcfunley.com]
  4. On Managing Stakeholders: "Design for Continuous Experimentation: Minimizing gazes of disapproval from results-motivated superiors." — Source: [Speaker Deck]
  5. On The A/B Testing Mandate: "At Etsy, we love experiments and A/B testing... we have to use A/B testing to tell if we've made things worse or better." — Source: [mcfunley.com]
  6. On Feature Flags: "Decoupling deployment from feature release via feature flags is non-negotiable for any team that wants to experiment safely." — Source: [mcfunley.com]
  7. On Experiment Velocity: "The speed at which an organization can run and conclude valid experiments is a direct predictor of its long-term market success." — Source: [Data Driven Products Now!]
  8. On Negative Results: "An A/B test that proves a feature decreases revenue is just as valuable as one that increases it; it saves you from maintaining negative-value code." — Source: [mcfunley.com]
  9. On Statistical Significance: "Do not let product managers stop an experiment the minute it looks positive; enforce rigorous statistical significance to avoid false positives." — Source: [mcfunley.com]
  10. On Gradual Rollouts: "Roll out changes to 1%, then 10%, then 50%; big bangs are for fireworks, not for deploying software to users." — Source: [Making Big Changes]

Part 5: Engineering Culture and Management

  1. On Pragmatism: "A healthy engineering culture values pragmatism and operational stability far more than it values technical purity or complexity." — Source: [mcfunley.com]
  2. On The Etsy Way: "The culture we built prioritized continuous deployment and data-driven product development over architectural perfection." — Source: [Egoless Engineering]
  3. On Egoless Engineering: "You must detach your personal ego from the code you write; if the data says the code is bad for users, delete the code." — Source: [mcfunley.com]
  4. On Blameless Culture: "When a system fails, investigate the system, not the person who deployed it; humans are fallible, systems should be resilient." — Source: [mcfunley.com]
  5. On Autonomy: "Team autonomy is crucial, but it must be constrained by a shared, boring infrastructural foundation to prevent operational chaos." — Source: [Choose Boring Technology]
  6. On Hiring: "Hire engineers who are excited about solving business problems, not just those who want to play with the newest framework." — Source: [mcfunley.com]
  7. On Communication: "As an organization grows, the hardest problems transition from being technical in nature to being purely about human communication." — Source: [Service Disorientated Architecture]
  8. On Leadership: "Technical leadership is often about saying 'no' to exciting new tools in order to protect the team's capacity to ship features." — Source: [mcfunley.com]
  9. On Alignment: "Every engineer should understand exactly how their daily work impacts the bottom-line metrics of the company." — Source: [Data Driven Products Now!]
  10. On Burnout: "Operating complex, fragile systems is a primary driver of engineering burnout; choosing boring technology is a form of team self-care." — Source: [mcfunley.com]

Part 6: Systems, Architecture, and Scaling

  1. On Microservices: "Microservices solve organizational scaling problems, not technical ones; if your communication structures are broken, microservices will just make it worse." — Source: [Service Disorientated Architecture]
  2. On Simplicity: "Start with a monolith. You must earn the right to the complexity of a distributed system through massive scale and pain." — Source: [mcfunley.com]
  3. On State: "State is the enemy of scalable systems; keep as much of your architecture stateless as physically possible." — Source: [mcfunley.com]
  4. On Caching: "Memcached is boring and it works; use it relentlessly to protect your database before you attempt to shard." — Source: [mcfunley.com]
  5. On Search Architecture: "Transitioning from recency-based search to relevance-based search requires a fundamental shift in how you process and store data." — Source: [mcfunley.com]
  6. On Data Pipelines: "Replicating massive amounts of on-premise data to cloud analytics requires tools that favor reliability and idempotency over cleverness." — Source: [mcfunley.com]
  7. On Service Boundaries: "Define service boundaries by business domains, not by technical layers; otherwise, every feature requires deploying every service." — Source: [Service Disorientated Architecture]
  8. On Scaling Challenges: "The things that break at 10x scale are never the things you predicted would break when you designed the system." — Source: [mcfunley.com]
  9. On Tooling Consolidation: "Consolidate your stack aggressively; every unique database or language you support is a tax on the entire engineering org." — Source: [Choose Boring Technology]

Part 7: Operational Excellence and Failure

  1. On Failure Modes: "The highest virtue of boring technology is that its failure modes are well documented on Stack Overflow." — Source: [mcfunley.com]
  2. On Monitoring: "If a service isn't monitored and alerted, it doesn't exist; it is just a ticking time bomb waiting to wake you up at 3 AM." — Source: [mcfunley.com]
  3. On Incident Response: "The goal of an incident response is not just to fix the immediate issue, but to ensure that specific failure mode never occurs again." — Source: [mcfunley.com]
  4. On Operational Burden: "Do not adopt a technology unless you are prepared to become an expert in operating it when it breaks under pressure." — Source: [mcfunley.com]
  5. On Garbage Collection: "It is the unknown unknowns—like a minor garbage collection pause suddenly cascading into a site-wide outage—that destroy SLAs." — Source: [mcfunley.com]
  6. On Predictability: "Operational excellence is fundamentally about making the behavior of your systems as predictable and boring as possible." — Source: [mcfunley.com]
  7. On Tooling Investment: "Invest heavily in your deployment and rollback tooling; the faster you can revert a bad change, the more aggressively you can innovate." — Source: [mcfunley.com]
  8. On Database Migrations: "Treat database schema changes with the utmost respect; they are the most common cause of self-inflicted downtime." — Source: [mcfunley.com]

Part 8: Pragmatism and Business Alignment

  1. On Business Focus: "Your job is keeping the company in business, god damn it." — Source: [mcfunley.com]
  2. On Technical Debt: "Some technical debt is highly strategic; it allows you to capture market share today that you can use to pay off the debt tomorrow." — Source: [mcfunley.com]
  3. On Shipping: "Code that has not shipped provides absolutely zero value to the user and zero feedback to the business." — Source: [mcfunley.com]
  4. On Problem Solving: "Fall in love with the business problem, not the technical solution you've devised to solve it." — Source: [Egoless Engineering]
  5. On Value Creation: "Engineering effort should be overwhelmingly directed toward features that create unique competitive advantages, not rebuilding commodity infrastructure." — Source: [Choose Boring Technology]
  6. On Over-Engineering: "Building a system to handle a scale you will not reach for five years is a fantastic way to ensure your company runs out of money in two." — Source: [mcfunley.com]
  7. On Opportunity Cost: "Every hour spent debugging a shiny new database is an hour not spent improving the core product experience for your customers." — Source: [mcfunley.com]
  8. On The Ultimate Goal: "The ultimate goal of software engineering is to deliver continuous, measurable value without burning out the people building it." — Source: [mcfunley.com]