Doing Everyone Else's Job
TL;DR
Yossi Kreinin argues that doing other people's jobs is what gets things done in most organizations. Examples include integrating your work into their systems, sending patches instead of waiting on their roadmap, and working with a disengaged manager's staff. He says it usually pays off. He separates it from building in parallel, such as in-house rewrites or per-department copies of a shared service. Managers like those because they grow headcount.
The article
- If the people you built something for won't adopt it, integrate it into their system yourself. Intel did this with its first 32-bit CPU, having its own engineers add support to Microsoft's compiler. That was for Intel's benefit, not charity.
- When a manager doesn't manage, you can often work directly with their people. Some of them never learn that the hierarchy only wants them to follow orders. Their managers rarely punish them for it.
- Getting a team to merge your patch is often easier than getting your feature into their quarterly planning. LLM output may have made strangers' patches harder to land. That fades once maintainers know you.
- Kreinin thinks 20% of people do 80% of the work. That work only reaches its goal because fewer than 5% of people do what someone else was supposed to do. Organizations bad enough to need this but healthy enough to notice tend to reward it. Kreinin regrets staying out of areas that seemed boring.
- Kreinin warns against two look-alikes that managers love because they add headcount. One is building in-house instead of buying. The other is every department running its own version of a service that could be central. Both are hard calls that should turn on outcomes, not on which choice is easiest for management.
- In a closing note on founders, Kreinin agrees that having done a job makes it easier to hire for it. But at the scale of hundreds of people, the limiting skill becomes managing people whose job you couldn't do.
Why it matters
Engineers and leads who keep running into teams that won't move should read the original. It is short, dry and funny about planning processes and org politics, and the buy-vs-build and centralization sections carry more nuance than a summary keeps.
The discussion
The thread mostly accepted that someone has to do the work nobody owns. Then it argued over whether that person ever gets credit. Commenters traded stories of under-rewarded glue work, argued over letting neglected things fail, and warned about colleagues using the essay's logic to offload work. Kreinin showed up several times to clarify, including a flat "don't do this for free."
Glue work rarely gets rewarded
The most common reply was that the work the essay praises counts for little at review time, especially in companies past about 1,000 people. Several people described load-bearing colleagues whose careers stalled, and noted that preventing fires is invisible while putting them out earns praise. Kreinin agreed that big companies are worse here, and said to make sure you're rewarded, or else work less or elsewhere. Others warned that whoever touches an orphaned system last ends up owning it forever.
Glue work, keeping things tidy, dealing with that annoyance that everyone else has been able to get away with suffering through (and ignoring), all of this will be worth approximately 0 at performance review time
There are people doing that invisible work in every org. They normally become visible around a week after they quit.
Let it fail, or keep it running?
One camp said that if management won't recognize the work, stop doing it and let the thing break so the cost becomes visible. Others pushed back that failure can take years, that the people responsible leave before it lands, and that a mortgage doesn't wait. One commenter took a middle position and recommended warning management in writing, with numbers. Then work normal hours until an incident proves the point, since heroics hide a staffing problem.
Key mistake I see: Don’t work 80 hours a week to be a hero unless you have a specific strategic goal in mind. You’re actually hurting the company by hiding a resource allocation issue.
It can take years for the damn thing to fail even after the key support stops entirely. In that time you and your colleagues will suffer, and the people responsible will jump ship long before the full impact has been felt
Helpers and the people who exploit them
Going around a manager to work with their staff drew the sharpest objections. One manager said every case they'd seen was a team offloading its own work onto agreeable people, who then fell behind on their real jobs. Kreinin answered that this and teams refusing all outside requests are separate failure modes, and that crediting people is the tell. Others added that saying no is socially harder than pleading ignorance, and big-company permission walls make the approach impractical.
You can tell a "workplace shark" from a more vegetarian workplace animal by whether they credit people for their work.
There's a bit of a weird dynamic that if you could do something that others need help with, saying no can be considered rude, but saying (even if lying) that you don't know how to do it is generally accepted.
Rotations and touring other teams
Several people described institutions that make cross-training formal. Examples were a Japanese employer moving staff every year or two, medical rotations in Czechia, Austria and the US, the military, and Cisco. Fans said it builds resilience and context, and some engineers make a point of sitting with support, sales and product when they join. Critics said it slows the growth of experts and that managers on three-year terms start big projects and leave before they fail.
This is a strategy you apply when you want organizational resilience, but it comes at the cost of efficiency. You can't have both at the same time.
Because management know they will be out in 3 years, they spend as much budget as they can to initiate as big projects as they can and have them on their resume
Is centralization better?
An engineer building a company-wide AI platform objected that one shared service is too generic for everyone and forces users onto its timeline. Kreinin replied that the post never says to always centralize. His point was that management avoids centralizing even when it would be better, and that each case differs.
By forcing everybody to use the same common platform, you are either forcing them to work around the mismatch between the platform and their needs, or your are forcing the platform to provide for everyone's needs.
Consensus
Doing work outside your role is useful and often the only way things get done. But check early whether your employer will reward it, and leave if it won't.
Dissent
A minority called the idea plain unpaid overtime. Some also said colleagues who do everyone's job set impossible expectations for the rest of the team, and should be kept in check.