Doing Everyone Else's Job
a day ago
- Doing others' jobs helps understand their work and needs, and ensures tasks get done when others won't.
- Example: Intel adding 32-bit CPU support to Microsoft's compiler was self-interested, not charity.
- Managing a manager's team indirectly is fine if done without credit, leveraging those who follow orders or are not punished for independent work.
- Contributing patches is easier than waiting for agile planning cycles, though acceptance may require building trust.
- The 80/20 principle extends: <5% of people do tasks others are supposed to do, but won't, due to legitimate organizational reasons that can doom the whole.
- Such efforts are often rewarded in organizations that are sick enough to need them but healthy enough to appreciate them.
- Avoiding areas outside one's job is a regret; it leads to preventable problems when assuming others' work 'just gets done'.
- Two parallel approaches (build vs. buy, decentralization vs. centralization) are loved by senior people for headcount but can backfire, requiring case-by-case decisions.
- Doing things in-house instead of buying is bad when it's to avoid expenses but grow headcount; buying is bad when external products suck due to standards or ease of spending.
- Decentralizing services avoids dependency on non-reporting units but leads to duplication; centralizing requires managing perceived failures.
- Dan Luu's comment: knowing a job helps hiring well, but the limiting factor is managing people whose jobs you can't do.
- The author agrees with Dan Luu, noting that scaling a team to hundreds or an independent company makes it impossible to do everyone's job, so management skill becomes key.