Egoless Engineering

I cannot find a video of this presentation. The slides and speaker notes are gold.

A big mistake they made in my view was that they conflated roles with work a little too much. Frontend engineers did all of the frontend work and none of the backend work, and vice versa.

I have seen this. In the worst characterizations it interprets people as interchangable parts instead of unique collaborators with strengths, weakenesses, and room for growth.

One big thing that a lot of people love to do is create new role types. For any new thing a company wants to do, the tendency is to put up a new job description.

Resist this urge. Start doing the new thing. If it ends up taking an inordinate amount of time, hire someone to do the thing.

Once people have subdivided work, they naturally try to arrange people into assembly lines. If you have AI work, hand it over to the AI person. If you have ops work, give it to the ops person.

That’s the kind of thing that feels obvious to leaders, but I think it’s wrong. And sometimes it’s wrong in a mathematically provable way.

Thinking Fast & Slow comes to mind. It feels intuitive, but it never works out quite that way in practice.

The most important bit that we took from that movement was that we should tear down existing barriers between roles. So after about two years of creative destruction pretty much everybody was pitching in on pretty much everything.

Tearing down dividing walls is work of the highest nobility.

the thing we were actually going to do was use our rare and precious organizational power, and the free time that came with it, to lift up other teams and make them more effective.

Seeing your work make the lives of real people better is the most rewarding outcome.

We tried really hard to have domain experts, but never really domain owners.

Ownership is a word that means different things to different people. I like the idea of floating experts serving the team rather than stationary owner controlling their fief.

There were other ways in which we didn’t just wait for the streams to cross themselves. We injected sustaining energy into this system very intentionally.

Good organizing patterns and collaboration don’t just happen. They require the intention of leaders.

None of them would admit this, but I think there’s an industry instinct that misery gets results. I think this is mistaken. Misery is a shitty proxy metric for results.

Misery loves companies. This rebellion against misery as a metric reminds me of the bigger argument within Accelerate (the most high-performing teams are those that are healthy and enjoyable to be on).