A summary of Egoless Engineering

The link below goes to Dan McKinley’s talk Egoless Engineering. The content is great but the format makes it hard to share, so here is a written summary of the argument and the takeaways.

McKinley’s core claim is that most organizational dysfunction in engineering comes from how companies divide responsibility. Roles get split into ever-narrower specialties, ownership turns into territory, and the boundaries between teams generate work that nobody wanted. Cooperation is the antidote, and leaders are the ones who make it possible or impossible.

A few examples he uses to make the point:

• A startup needed database specialists, Python developers, and PHP developers to coordinate on every feature. They shipped nothing for two years.
• A mature company kept subdividing roles until it invented a “release manager” position. The role became a bottleneck.
• A company assigned all security remediation to a dedicated security team to reduce context switching for engineers. Developers stopped thinking about security at all, which created more work, not less.

He also gives a positive example. At one company, a designer broke the build. Rather than putting up walls between designers and the deploy pipeline, leadership gave the designer deploy keys. After two years of similar moves, almost everyone contributed to almost everything. Domain experts mentored. They did not gatekeep.

Key takeaways

• How you divide responsibility shapes everything. The choice has immediate effects, and worse second-order effects.
• Poorly factored boundaries create work. Handoffs, queues, and approvals all show up as labor the org pays for.
• Ego and parochialism are the failure modes. As McKinley puts it, the biggest problem with brilliant jerks is not that they are jerks. They are not even brilliant.
• Misery is a bad proxy for results. Mandatory process, ceremony, and busy-ness are not the same as output.
• Domain experts, not domain owners. Specialists multiply their impact by teaching, not by hoarding tickets.
• Expand the in-group on purpose. Bootcamps, hack weeks, and forced cross-functional work build the trust that makes cooperation cheap.
• Articulate anti-elitism out loud. Leaders have to say that no role is more technical or more valuable than another, then act like it.
• Protect organizational slack. Systems run at 100% utilization cannot learn, experiment, or cooperate. Slack is a feature.
• Leaders set the tone. Most leaders never cut feel-bad programs like mandatory review, but they cut feel-good programs like hack weeks first. Notice when you are doing that.
• Cooperation needs permission. People wait to be authorized to be curious or to help across team boundaries. Give the permission explicitly.

Links

• egoless.engineering — Dan McKinley’s original talk.