Doing Everyone Else's Job

A senior engineer argues that taking on tasks outside one’s formal role can be a powerful way to get work done, citing Intel’s early 32‑bit CPU launch as a prime example: Intel engineers added support for the new processor directly into Microsoft’s compiler, effectively doing Microsoft’s job to ensure the CPU’s success. The writer contends that many employees resist “doing someone else’s job,” viewing it as unnecessary charity, yet such cross‑functional effort often proves essential when the intended owners are unwilling or unable to act, especially in organizations where managers fail to enforce accountability.

The piece explains why this approach matters: in many companies a small minority performs the bulk of productive work, while an even smaller elite handles the tasks that others neglect, keeping the organization afloat despite systemic inefficiencies. By stepping in, an individual not only accelerates feature delivery—often by persuading others to merge patches rather than waiting for formal agile planning cycles—but also gains a deeper understanding of the organization’s inner workings, positioning themselves for indirect rewards and recognition. The author warns that relying on others to “just get it done” leads to preventable crises, whereas proactive involvement can avert such failures.

Further, the author highlights two related practices that senior leaders may favor but can backfire. First, companies sometimes choose to build solutions in‑house rather than purchase existing products, either because external spending is easier than hiring or because internal headcount can be expanded without budget approval. Second, departments frequently duplicate services instead of centralizing them, allowing managers to avoid dependence on external teams. Both strategies can inflate headcount and create hidden inefficiencies, underscoring the need for leaders to weigh the true costs of building versus buying and centralizing versus fragmenting services.

⚡ Effects Interpreter