Doing Everyone Else's Job

It argues that being able to do everyone else’s job is a practical advantage: stepping into others’ roles teaches how their work fits together, gets needed work done when others won’t, and yields disproportionate rewards and organizational insight. Concrete examples include engineers integrating new hardware support into external toolchains (Intel adding 32-bit CPU support to Microsoft’s compiler) and contributing patches directly because waiting for slow planning cycles won’t get features released. The piece asserts that a tiny fraction of people (<5%) who take on others’ responsibilities keep organizations alive, that most organizations tolerate some level of this informal cross-role work, and that doing so brings direct and indirect benefits - career rewards, deeper knowledge of how the place actually operates, and the satisfaction of preventing avoidable failures.

It warns against two dangerous variants that look attractive to leaders: building in-house rather than buying a suitable product to justify headcount, and letting every department recreate the same service instead of standardizing centrally. These choices arise from approval and reporting incentives rather than outcome optimization, and they cause duplication and poor outcomes. It also notes recent friction - well-intentioned patches being mistrusted because they resemble generic LLM output - and echoes a reviewer’s point that founders who’ve done hires’ jobs hire better, while growth eventually requires managing people whose work one cannot personally perform.