Dan McKinley is a software engineer and writer known for Choose Boring Technology, Data Driven Products Now!, and work at Etsy, Stripe and Mailchimp. These lessons examine his published views on production technology, product experiments and engineering teamwork. — Dan McKinley Resume.

Infographic for "Lessons from Dan McKinley".

Part 1: The Philosophy of "Boring" Technology

  1. On Boring Technology: Boring technology is technology whose capabilities and limitations are well understood; knowing its failure modes is a practical advantage. — Choose Boring Technology Talk.
  2. On Quality vs. Boring: Boring does not mean bad. Prefer well-understood tools when they solve the problem, while still rejecting tools that are poor fits. — Choose Boring Technology.
  3. On Proven Systems: McKinley names familiar tools such as MySQL, Postgres, Python, and Memcached as examples of mature technology, not as a universal prescribed stack. — Choose Boring Technology.
  4. On Predictable Failures: A mature tool can make likely failure modes easier to anticipate because more organizations have operated it in production. — Choose Boring Technology.
  5. On The 'Best' Tool Fallacy: The best technology choice for a company can be the tool that is least bad across its full set of problems, not the locally optimal tool for one task. — Choose Boring Technology.
  6. On Living with Tech: Adding a technology is easy; operating it well in production over time is the harder commitment. — Choose Boring Technology Talk.
  7. On Redundancy: When a new technology duplicates an existing one, plan to replace the old tool if the new one proves its worth rather than carrying both indefinitely. — Choose Boring Technology Talk.
  8. On Polyglot Persistence: Giving each team freedom to add its own data store may create global operational toil that outweighs local convenience. — Choose Boring Technology Talk.
  9. On Novelty: Novel technology consumes scarce attention; use it where it helps solve the company’s distinctive problem, rather than everywhere. — Choose Boring Technology.

Part 2: Managing Innovation and Risk

  1. On Innovation Tokens: McKinley’s approximate innovation-token model asks teams to spend a small number of novel choices on what matters most to their mission. — Choose Boring Technology.
  2. On Core Competency: Spend novelty on the core problem your company exists to solve; infrastructure experimentation needs a clear reason and can be core for an infrastructure company. — Choose Boring Technology.
  3. On Unknown Unknowns: With mature tools, teams know more of the failure modes. New tools carry unknown unknowns that can appear only in production. — Choose Boring Technology.
  4. On Local vs. Global Optimization: A local infrastructure choice can impose a cost on the whole organization, so technology additions need a company-wide conversation. — Choose Boring Technology Talk.
  5. On Shiny Object Syndrome: Before adding a new technology, ask whether the existing stack can solve the actual problem; enthusiasm for a tool is not itself a problem statement. — Choose Boring Technology Talk.
  6. On Rewriting Databases: Unless building a database is your business, take care not to spend scarce engineering effort reinventing one. — Choose Boring Technology.
  7. On Risk Distribution: Accept technical novelty where it serves the core mission, while keeping incidental infrastructure as well understood as practical. — Choose Boring Technology.
  8. On Migration Costs: If a new tool replaces an old one, define a migration plan and a fallback if the new tool fails to justify its cost. — Choose Boring Technology Talk.

Part 3: Data-Driven Product Development

  1. On Measurement: Use rough arithmetic to size an opportunity before committing a large team to an appealing product idea. — Data Driven Products Now!.
  2. On Staying Honest: Measure the result of a product release to test whether it actually helped users rather than relying on the team’s confidence. — Design for Continuous Experimentation.
  3. On Vanity Metrics: During strong organic growth, aggregate charts can rise even when a particular feature adds no value; compare outcomes before claiming credit. — Data Driven Products Now!.
  4. On Proving Value: Controlled experiments helped Etsy discover that an apparently helpful search change made that experience worse. — Design for Continuous Experimentation.
  5. On Bad Ideas: Teams need enough honesty and discipline to abandon a costly idea when measured results undermine its original premise. — Design for Continuous Experimentation.
  6. On The Infinite Scroll: At Etsy, an infinite-scroll search test led users to view, click and save fewer items in search, contrary to the team’s expectation. — Design for Continuous Experimentation.
  7. On Baseline Metrics: Size the existing audience and purchase behavior before forecasting a feature’s benefit; a large page audience does not by itself imply large revenue impact. — Data Driven Products Now!.
  8. On Business Value: Evaluate a major idea before building by estimating its audience, plausible effect and business return; this can avoid expensive work on a weak opportunity. — Data Driven Products Now!.
  9. On Data Infrastructure: Before building real-time product analytics, distinguish the genuine decision need from operational monitoring and weigh the new system’s complexity. — Whom the Gods Would Destroy, They First Give Real-time Analytics.

Part 4: Continuous Experimentation and A/B Testing

  1. On Small Changes: Make product changes in smaller steps where possible, and measure the results so that counterintuitive outcomes become visible. — Design for Continuous Experimentation.
  2. On Avoiding Hysteria: Design experiments to avoid premature conclusions from constantly updated product metrics; early apparent gains can disappear with more data. — Whom the Gods Would Destroy, They First Give Real-time Analytics.
  3. On Frequent Deploys: Deploy small changes frequently so code review and production debugging remain tractable. — Ship Small Diffs.
  4. On The A/B Testing Mandate: Etsy used A/B tests to compare releases with controls and learn when a change made search better or worse. — Design for Continuous Experimentation.
  5. On Feature Flags: Etsy’s experimentation tooling supported tests and configuration ramp-ups, allowing the team to measure changes before a broad release. — Design for Continuous Experimentation.
  6. On Negative Results: A negative test can save further investment: Etsy removed infinite scroll from search after measured outcomes fell short. — Design for Continuous Experimentation.
  7. On Statistical Significance: Do not stop an A/B test as soon as an interim result looks significant; timing and user behavior can create false confidence. — Whom the Gods Would Destroy, They First Give Real-time Analytics.
  8. On Gradual Rollouts: Break a large redesign into smaller, measured releases when possible; Etsy’s dropdown removal became a series of bets rather than one irreversible launch. — Design for Continuous Experimentation.

Part 5: Engineering Culture and Management

  1. On Pragmatism: Choose technologies by their total development and operating costs, not by technical novelty alone. — Choose Boring Technology Talk.
  2. On The Etsy Way: McKinley later acknowledged that his public data-driven-product talk portrayed a minority approach at Etsy as “the Etsy Way”; it was an argument for better opportunity sizing, not a description of uniform practice. — The Guerilla’s Guide to Influencing Leadership.
  3. On Egoless Engineering: Engineering teams work better when people abandon territoriality and elitism, stay curious about colleagues’ disciplines and help one another. — Egoless Engineering.
  4. On Blameless Culture: After a designer broke the build, the team widened safe deploy access and invested in monitoring and tests instead of rebuilding role barriers. — Egoless Engineering.
  5. On Autonomy: Teams can have autonomy without letting each group independently add infrastructure whose long-term costs fall on everyone. — Choose Boring Technology Talk.
  6. On Communication: Over-specialized roles and handoff queues can turn feature work into a coordination problem; McKinley favors domain experts who help others rather than rigid domain owners. — Egoless Engineering.
  7. On Leadership: Technology leadership should make proposed stack additions a deliberate cross-team discussion, including whether existing tools suffice and how a new tool would be retired if it fails. — Choose Boring Technology Talk.
  8. On Alignment: Engineers should connect proposed features to plausible user and business impact by doing rough opportunity sizing rather than assuming someone else has done the math. — Data Driven Products Now!.
  9. On Burnout: McKinley argues that misery is a poor proxy for results and that leaders should make room for curiosity, cooperation and slack. — Egoless Engineering.

Part 6: Systems, Architecture, and Scaling

  1. On Caching: Etsy’s activity-feed team used the shared PHP, MySQL and memcached stack rather than add a new dedicated store, allowing site-wide scaling work to support the feature. — Choose Boring Technology Talk.
  2. On Search Architecture: At Etsy, McKinley helped shift search from recency sorting toward relevance; he describes that as a deeply quantitative project important to the business. — Dan McKinley Resume.
  3. On Tooling Consolidation: Adding a second production database brought Etsy duplicated work in logging, monitoring, replication, sharding and backups; such costs can outweigh a tool’s local convenience. — Why MongoDB Never Worked Out at Etsy.

Part 7: Operational Excellence and Failure

  1. On Failure Modes: Well-understood technology offers better-known operational failure modes than a new and less-proven tool. — Choose Boring Technology.
  2. On Monitoring: Monitoring and test suites helped McKinley’s team let more disciplines ship safely, rather than making deployment the exclusive responsibility of one group. — Egoless Engineering.
  3. On Incident Response: When a build-breaking mistake exposed a weak workflow, the team improved its tooling and shared responsibility rather than just excluding the person who made the change. — Egoless Engineering.
  4. On Operational Burden: Adopting a technology means taking responsibility for operating it professionally over time, including the less visible work after installation. — Choose Boring Technology Talk.
  5. On Garbage Collection: A new technology may hide production failure modes, including interactions such as a statistics request inducing a garbage-collection pause. — Choose Boring Technology.
  6. On Tooling Investment: Small production diffs make the likely source of a new failure easier to find and can shorten the time needed to debug it. — Ship Small Diffs.

Part 8: Pragmatism and Business Alignment

  1. On Business Focus: The point of a technology choice is to solve a business problem, not to maximize technical novelty. — Choose Boring Technology Talk.
  2. On Shipping: Shipping code to production reveals whether it actually works with real data and traffic; small frequent releases make that learning safer. — Ship Small Diffs.
  3. On Problem Solving: Start with the business problem, then compare the available technical solutions and their continuing maintenance cost. — Choose Boring Technology Talk.
  4. On Value Creation: Direct scarce engineering novelty toward what is central to the company’s work instead of routinely rebuilding commodity infrastructure. — Choose Boring Technology.
  5. On Opportunity Cost: Every additional production technology carries operating cost and consumes attention that could otherwise go toward solving the business problem. — Choose Boring Technology Talk.