Building Effective Engineering Teams and Avoiding Cargo Cult Practices

Introduction of David Goodman and his work

• The QCon London conference will take place from April 7-9, 2025, featuring world-class leaders sharing actionable insights from senior software developers working on real-world projects across multiple domains (22s).
• David Goodman has been working in software for over 20 years, with experience at companies like Disney, where he architected and built systems that are still visible on Disney.com and StarWars.com (42s).
• David has also built big ad servers handling 10 billion requests a day and has started his own consulting company, building engineering teams for founders, including the co-founder of MasterClass (1m3s).
• David's current focus is on taking internal tooling he built to support teams and building a more public-facing SaaS that others can use (1m28s).

Building Engineering Teams

• Building engineering teams involves four main phases: recruiting, vetting, onboarding, and managing, with recruiting being a combination of knowing who to attract and positioning oneself to interest those people (1m48s).
• Vetting is the process of proving that attracted candidates are the right fit, while onboarding involves getting new team members up to speed with the culture and process, and management is the ongoing process of maintaining a successful team (2m41s).
• David has written a book that serves as a survival guide for people who depend on devs to get things done, emphasizing the importance of not simply copying what big companies do, but rather finding what works best for each individual situation (3m45s).

Cargo Culting and the Importance of Critical Thinking

• Founders often copy behaviors without understanding their context, which can be detrimental to their success, and removing these "easy things" can help them think more critically about their goals and build targeted systems (4m19s).
• Cargo culting occurs when organizations adopt practices without understanding their underlying principles, simply because they work for others, which can lead to problems (5m14s).
• Targeted learning from others' experiences is valuable, but copying entire systems without understanding their context can be problematic (5m26s).
• Critical thinking is essential when adopting new practices, and it's crucial to evaluate whether the practice solves a specific problem or is just a "whole cloth" solution (6m9s).

Daily Standups vs. Alternative Approaches

• Daily standups, a common practice in some companies, can be a high-cost solution that may not be necessary for every team, and critical thinking is required to determine whether it's the right solution for a specific problem (6m44s).
• Instead of daily standups, one-on-one meetings or reviews can be more effective in identifying and addressing blockers, especially for junior developers (8m1s).
• It's essential to evaluate the specific needs and problems of a team before adopting a practice, rather than simply copying what others do (7m53s).
• Daily stand-ups can be expensive and may not be the best way for team building, as they often involve developers sharing their to-do lists, which may not foster critical thinking or effective communication among team members (8m27s).
• Founders may keep daily stand-ups as a way for team members to see and interact with each other, but this approach may not be the most effective way to achieve team building and critical thinking (8m46s).
• A more effective approach to team building would be to design activities that are tailored to the specific needs and interests of the team, rather than relying on a one-size-fits-all solution like daily stand-ups (9m1s).
• The idea that a daily stand-up works for every team and is the best way to achieve team building and critical thinking is not supported, and teams should instead focus on finding activities that work best for them (9m33s).
• For example, some teams may find that playing computer games, such as Valerent, is an effective way to foster communication, teamwork, and critical thinking among team members (9m44s).
• The key is to find an approach that works for the specific team, rather than trying to implement a solution that may not be effective for them (10m25s).

Internal Management Platform and AI Integration

• An internal management platform, which can be referred to as an internal software as a service (SaaS) product, can be used to manage various aspects of team management, including tracking developer information and facilitating communication (10m42s).
• This platform can be designed to automate routine tasks, such as sending reminders and tracking progress, and can help to promote autonomy and accountability among team members (11m18s).
• The use of AI and robots can be integrated into this platform to provide a more personalized and interactive experience for team members, and to help facilitate communication and critical thinking (11m37s).

Management Practices and Tools

• Management involves written one-on-one meetings, which some people may find unusual, but this approach allows for tracking themes and ensuring important areas are not neglected, with tools available for managers to keep track of these meetings (12m31s).
• A public tool is being developed to serve as an antidote to daily stand-ups, allowing developers to define sequences, marry them with AI, and have more predictable check-ins to see their plans, identify interruptions, and self-correct (13m21s).

Key Elements of a Good Engineering Culture

• The key elements of a good engineering culture include teamwork, but with individual autonomy and accountability, where developers can communicate freely, and it's clear what everyone's doing, with shared and individual responsibilities (14m7s).
• Teamwork is important, but it's essential to have a team of developers who are individually accountable, autonomous, and can communicate freely, with clear and transparent responsibilities and commitments (14m48s).
• Creating space for this teamwork to happen requires ingredients such as tools that prevent individuals' brains from tricking them, allowing them to conserve energy and protect their egos, and understanding psychological constants (16m15s).
• A good engineering culture should have a predictable workflow, where everyone trusts each other, is accountable, and doesn't default to group psychology or committee mentality, avoiding the tragedy of the commons (15m50s).
• Writing down daily goals and reflecting on whether they were achieved can help identify patterns and self-correct, promoting internal transparency and accountability (16m57s).
• Internal transparency is required at all levels, and it's essential to have transparency on the team about what they're working on to avoid duplicated work and ensure alignment (17m45s).
• Removing daily stand-ups can be challenging, but teams can self-organize and communicate effectively with the right setup, norms, and onboarding process (18m1s).
• Establishing clear norms and behaviors during onboarding, such as communicating when stuck and being transparent, can reinforce accountability and communication within the team (18m31s).

The Myth of the 10x Developer

• The concept of the "10x developer" originated from a 1960s US Air Force study, which found that for specific tasks, the fastest developer with the lowest number of errors performed 10 times faster than the slowest developer, despite being paid the same (19m8s).
• The study's findings may not be directly applicable to today's computing environment, and there are reasons to be cautious about the idea of the "10x developer" based on its origins (20m26s).
• The concept of the "10x developer" is often misunderstood, as studies have shown that the difference in productivity between developers is not as extreme as the term suggests, but rather skewed towards the tail, with the worst developer being significantly worse than the median, and the best being closer to the median (21m4s).
• The idea of a single developer being 10 times more productive than others across all tasks is unrealistic, as developers tend to excel in specific areas and struggle in others (22m11s).
• The study that popularized the "10x developer" concept was based on government developers who were paid the same, which is not representative of the real-world scenario where high-performing developers would likely demand higher pay or leave for better opportunities (22m25s).
• Paying a developer 10 times more than others to get a task done quicker may have advantages, but it would no longer make them a "10x developer" if they are paid differently (23m15s).
• The concept of the "0.1x developer" might be more relevant, as it highlights the importance of addressing the performance gap between the worst and median developers (21m29s).

Conclusion and Contact Information

• David Gutman, the guest, can be found on LinkedIn, and his book will be linked in the show notes for those who want to continue the conversation (23m28s).