Lessons from Kellan Elliott-McCrea

Lessons from Kellan Elliott-McCrea

Kellan Elliott-McCrea served as CTO of Etsy, VP of Engineering at Dropbox, and Architect at Flickr. He helped normalize continuous deployment and blameless post-mortems across the industry. This profile gathers his most practical writing on managing up, handling technical debt, and building engineering cultures based on trust.

Part 1: On Engineering Culture and Organization

1. On Culture as Celebration: "Culture is what you celebrate. Rituals are the tools you use to shape culture." — Source: [kellanem.com]
2. On Modern Software Development: "Modern software development is an operational challenge of creating an environment for shared vision, decent technical decisions, and constant measurable progress." — Source: [kellanem.com]
3. On Code as Craft: "We who cut mere stones must always be envisioning cathedrals." — Source: [Etsy Code as Craft]
4. On Misaligned Teams: "The team isn't working hard enough is never the problem. It is usually a symptom of a lack of clear goals, cascading down to a lack of ownership." — Source: [kellanem.com]
5. On Slow Delivery: "Slow teams are misaligned teams." — Source: [laughingmeme.org]
6. On Push and Pull: "Processes often fail when they are all 'Push' (mandate) and no 'Pull' (demand for the output)." — Source: [kellanem.com]
7. On the First Law of CMS: "You should never build a CMS." — Source: [laughingmeme.org]
8. On the Second Law of CMS: "You will eventually build a CMS." — Source: [laughingmeme.org]
9. On Generative Culture: "A generative culture emphasizes high trust, information sharing, and learning from failure over punishing individuals." — Source: [Etsy Engineering Blog]
10. On Questioning Practices: "Nothing we 'know' about software development should be assumed to be true; most practices are remnants of an era of solo practitioners, whereas modern software is a team sport." — Source: [kellanem.com]

Part 2: On Management and Leadership

1. On the Management Trap: "We promote the most competent engineer and wonder why they aren't great at management." — Source: [InfoQ]
2. On Getting Comfortable Not Knowing: "For many leaders the hardest job they have is getting comfortable with not knowing." — Source: [kellanem.com]
3. On the Omniscience Expectation: "It is natural to feel like you have to understand everything about the area that you lead. And that's a feeling that often cascades down through hierarchies." — Source: [kellanem.com]
4. On Seagull Management: "Leaders often disempower their teams by swooping in to make decisions without full context, instead of maintaining team autonomy." — Source: [kellanem.com]
5. On Leading with Curiosity: "When leading, advocate for leading with curiosity rather than authority." — Source: [First Round Review]
6. On Caring and Detachment: "Leaders must balance deeply caring about the work with maintaining enough detachment to remain objective and avoid burnout." — Source: [First Round Review]
7. On Annual Planning: "Annual planning in tech often fails. Bottom-up processes don't work, and the rule of thumb is simply to do fewer things." — Source: [kellanem.com]
8. On the New Manager Path: "Transitioning from engineer to manager requires an entirely new skill set, notably prioritizing communication and alignment over code." — Source: [kellanem.com]
9. On Building the Team: "In 100% of the engineering teams I talk to they aren't spending enough time on building a team." — Source: [kellanem.com]
10. On Information Cascades: "When leaders act as if they must know everything, it creates an environment where failure to know is penalized, halting learning." — Source: [kellanem.com]

Part 3: On System Architecture and Scaling

1. On Sharded Architectures: "At Flickr, we used a sharded MySQL architecture to handle billions of queries, with each shard holding data for around 400,000 users." — Source: [High Scalability]
2. On Master-Master Replication: "Active-Active Master-Master Ring Replication allowed us to take servers down for upgrades without site downtime." — Source: [High Scalability]
3. On the Trouble with Polling: "Polling sucks. Polling for data updates is inefficient and should be replaced with Push/PubSub models." — Source: [O'Reilly]
4. On Data Federation: "Application logic should manage the complexity of connecting to the correct shards rather than relying on expensive cross-shard joins." — Source: [High Scalability]
5. On Global ID Generation: "Ticket servers using dedicated MySQL instances are an effective way to generate unique, non-colliding IDs across a distributed sharded environment." — Source: [High Scalability]
6. On Data Ownership: "Users should be able to programmatically retrieve every piece of data they upload, which was the driving philosophy behind early APIs and the OAuth standard." — Source: [laughingmeme.org]
7. On the Illusion of Correctness: "Software development is a cycle of learning, not a search for absolute 'correctness.'" — Source: [kellanem.com]
8. On Aspirational Complexity: "Teams often adopt complex architectures, like microservices, long before they actually need them." — Source: [laughingmeme.org]
9. On the Easy Part of Software: "Code has always been the easy part of building software." — Source: [Simon Willison's Weblog]
10. On Shipping and Learning: "If you aren't shipping, you aren't learning." — Source: [Etsy Engineering Blog]

Part 4: On Continuous Deployment and Operations

1. On Blameless Post-Mortems: "Instead of punishing individuals for mistakes, shift the focus to understanding the systemic failures that allowed the mistake to happen." — Source: [Etsy Engineering Blog]
2. On Just Culture: "A Just Culture encourages engineers to be honest about failures to facilitate true organizational learning." — Source: [Etsy Engineering Blog]
3. On Detection over Prevention: "It is impossible to prevent all failures in complex systems; optimize instead for rapid detection and response." — Source: [Etsy Engineering Blog]
4. On Continuous Deployment: "Deploying code to production multiple times a day is a sign of a healthy, learning-oriented engineering culture." — Source: [O'Reilly Velocity]
5. On Config Flags: "Use config flags to decouple code deployment from feature launches, enabling dark launching and safe production testing." — Source: [Etsy Engineering Blog]
6. On Global Optimization: "A culture of learning is built by optimizing for the team—sharing tools and beliefs—rather than isolating individual pockets of brilliance." — Source: [kellanem.com]
7. On the Reality of Technical Debt: "What we call technical debt is often just necessary maintenance work to keep a codebase healthy." — Source: [kellanem.com]
8. On Dependencies Resisting Change: "Being stuck on old versions of libraries or frameworks is a distinct category of technical debt that actively resists upgrading." — Source: [kellanem.com]
9. On All Code as Liability: "To borrow from Peter Norvig: all code is a liability. Intentional shortcuts for speed are rarer than code that simply resists change over time." — Source: [kellanem.com]

Part 5: On Managing Up and Communication

1. On the Myth of the Apolitical Engineer: "Engineers cannot be hyper-rational and avoid politics; collaboration, coordination, and communication are the work." — Source: [InfoQ]
2. On the Nature of Managing Up: "Managing up is fundamentally about making your manager’s job easier so they can better support you." — Source: [InfoQ]
3. On Manager Skill Gaps: "Because the demand for engineering managers outpaces supply, individual contributors often need to manage up to help their managers succeed." — Source: [InfoQ]
4. On Studying Your Manager: "Get curious about your manager’s goals, how they are evaluated, and what they value—whether it is product, business, or operational excellence." — Source: [InfoQ]
5. On Upward Alignment: "Ensure your priorities match your manager's and equip them to speak fluently about your work to their own bosses." — Source: [InfoQ]
6. On Moving Past Status Updates: "Building a relationship with leadership means moving beyond raw status updates to a true partnership based on trust." — Source: [InfoQ]
7. On Communication as a Core Skill: "Communication is hard and people don't prioritize it, but no one says, 'I got a communications degree so I could become a startup founder.'" — Source: [kellanem.com]
8. On Isolation vs. Collaboration: "Technical solutions proposed around the idea of 'I don't want to talk to my coworkers'—like microservices sometimes are—miss the point that you should want to talk to your coworkers." — Source: [Simon Willison's Weblog]
9. On Legibility of Work: "Your work is only as valuable as your ability to make it legible and understandable to the rest of the organization." — Source: [InfoQ]

Part 6: On the Reality of Modern Software Development

1. On the End of Cheap Money: "The decade of low interest rates allowed companies to over-hire and ignore inefficiencies, making the shift in the macroeconomic environment a painful re-evaluation." — Source: [laughingmeme.org]
2. On Rising Standards: "Software is harder to build today because of significantly higher baseline expectations for security, accessibility, and performance." — Source: [laughingmeme.org]
3. On the Explosion of Choices: "The overwhelming number of tools and frameworks available today contributes directly to the complexity and frustration of modern engineering." — Source: [laughingmeme.org]
4. On the Loss of Magic: "The 'magic feeling' of startups, where a small team could quickly disrupt an industry, has become much harder to achieve as systems have grown complex." — Source: [laughingmeme.org]
5. On Rising Talent Costs: "As tech talent has become significantly more expensive, the pressure to deliver flawless enterprise-grade software has proportionately increased." — Source: [laughingmeme.org]
6. On Changing Labor Relations: "There is growing friction between management and engineering teams as the expectations of the work environment fundamentally change." — Source: [laughingmeme.org]
7. On Soul-Sucking Code: "There is a category of code choices that simply 'sucks the will to live,' making the developer experience miserable even if the code functions perfectly." — Source: [kellanem.com]
8. On Operability Choices: "Decisions that make a system difficult to run, monitor, or scale in production are often incorrectly labeled as mere technical debt." — Source: [kellanem.com]
9. On Unnecessary Modularization: "While poor modularization resists change, too much modularization can also create rigid systems that resist adaptation." — Source: [kellanem.com]

Part 7: On Diversity and Team Building

1. On Inclusive Environments: "Better software is written by diverse, kind teams who care about each other." — Source: [First Round Review]
2. On the Brilliant Jerk Archetype: "The industry must challenge the 'brilliant jerk' archetype; building an inclusive culture is a direct path to higher quality engineering." — Source: [First Round Review]
3. On Interviewing: "Interviewing is ~10% of the success of hiring. It's also extremely low information." — Source: [kellanem.com]
4. On the Candidate Experience: "Because interviews are low-information, you should optimize your interviews for a great candidate experience rather than an exhaustive technical audit." — Source: [kellanem.com]
5. On Culture Driving Technology: "Great technology is the byproduct of a great culture. Culture creates certainty in the face of the yawning shapeless void of possible solutions." — Source: [kellanem.com]
6. On the Value of Empathy: "Empathy in engineering is not a soft skill; it is a structural necessity for building resilient, highly available systems." — Source: [First Round Review]
7. On Building Learning Organizations: "When you transform organizational culture, you must prioritize creating an environment where engineers can take risks safely." — Source: [Code for America]
8. On Diversity as a Strategy: "Improving gender diversity in an engineering org requires specific, non-obvious tactics, not just generic goodwill." — Source: [First Round Review]
9. On the Team as the Unit of Delivery: "The individual engineer is no longer the atomic unit of software creation; the team is the fundamental unit of delivery." — Source: [kellanem.com]

Part 8: On Artificial Intelligence and the Future of Coding

1. On the Falling Cost of Code: "As AI tools lower the cost of writing code, it creates entirely new bottlenecks in review processes and architecture." — Source: [laughingmeme.org]
2. On the Skepticism of Code Review: "Most senior engineers and engineering leaders have always been quietly skeptical of the value of code review; it's expensive, and the data on defect detection doesn't justify the cost." — Source: [laughingmeme.org]
3. On AI-Assisted Code Review: "With AI generating more code, traditional human code review may be losing its remaining value and becoming unsustainable." — Source: [laughingmeme.org]
4. On Agentic Coding: "Using agentic coding tools makes it entirely feasible to build and deploy real software from a mobile device while on vacation." — Source: [laughingmeme.org]
5. On Bushy Codebases: "LLMs contribute to 'bushy' codebases—sprawling architectures where maintaining a clear mental model of the code becomes the primary leadership challenge." — Source: [laughingmeme.org]
6. On Adapting Leadership for AI: "Engineering leadership must change its practices in the face of LLMs, shifting focus from code production to system comprehension." — Source: [laughingmeme.org]
7. On the Illusion of AI Understanding: "Just because an AI can generate functional code does not mean the organization understands the systemic implications of that code." — Source: [laughingmeme.org]
8. On the Velocity Shift: "The speed at which AI can produce boilerplate shifts the engineering burden heavily toward validation, testing, and operational readiness." — Source: [laughingmeme.org]
9. On the Future of Engineering Work: "The role of the software engineer is moving away from syntax generation and toward complex system orchestration and alignment." — Source: [laughingmeme.org]