The Strategic Value of Doing Other People's Work

I believe there is immense utility in being capable of performing tasks that technically belong to others. Not only does this grant you a deep understanding of their workflows and requirements, but it becomes an essential survival skill when critical work remains undone because the responsible party refuses to act.

The "Integration" Mindset

If you develop a new tool or feature and the intended users are too indifferent to adopt it, the solution is simple: integrate it into their system yourself.

A classic historical example of this is Intel. When they launched their first 32-bit CPU, they didn't just wait for the ecosystem to catch up; they had their own engineers write the support code directly into Microsoft’s compiler.

Perspectives on "Corporate Charity"

Many professionals view working on another team's system as an unnecessary act of kindness or "charity" that shouldn't happen in a professional setting. However, this is a misunderstanding of the incentive structure:

---

Navigating the Organizational Labyrinth

When dealing with ineffective leadership, you can often bypass the "manager" layer entirely. If a manager is a vacuum of productivity, you can still achieve results by working directly with their subordinates. The key is to do this without claiming their title or stealing the credit.

While many employees have learned to be proactive strictly obedient—ignoring the "fire" around them as long as they follow orders—there are always "slow learners" who haven't yet succumbed to this apathy. These are the people you can actually get things done with.

Bypassing the Scaled Agile Trap

If you need a specific feature in a tool, don't try to get it on the official roadmap. The Scaled Agile process is often a bureaucratic shield:

• "The plan is finalized for this quarter."
• "We have high velocity because of our rigid planning."
• "We can discuss this in three months for the following quarter."

Instead, simply write the code and submit a patch. While the rise of LLM-generated code means your high-quality patches might initially look like random_ai_output.py, building a personal reputation for quality will eventually clear that hurdle.

---

The Mathematics of Organizational Survival

I subscribe to a modified version of the Pareto Principle. While the 80/20 rule is common, the real engine of a company is even smaller:

$\text{Total Success} = (20\% \text{ of people doing } 80\% \text{ of work}) \times (5\% \text{ of people filling the gaps})$

That 5% consists of individuals who do the work that "someone else" was supposed to do. In the eyes of the organization, the reasons why the original owner didn't do the work are "perfectly legitimate," yet the sum of those legitimate excuses is usually a death sentence for the company.

The Rewards:

1. Direct: In organizations that are broken enough to need this but healthy enough to value it, you will be highly rewarded.
2. Indirect: You gain a unique, systemic understanding of how the organization actually functions.

Personal Note: I regret the times I avoided "boring" areas of the business because they felt outside my scope. By the time those areas became "interesting" (i.e., they were crashing and burning), it was often too late to fix them.

---

Distinguishing Value from Redundancy

Not all "extra" work is beneficial. There are two common traps that senior leadership loves because they increase headcount, but which actually degrade the product.

1. The Build vs. Buy Dilemma

Some companies over-rely on external vendors because they find spending money easier than hiring. Others do the opposite: they build everything in-house because it's easier to get a new hire approved than a software license.

• Buy: Standardized, but potentially mediocre or expensive.
• Build: Tailored, but creates a massive maintenance burden.

Determining the right path requires a deep dive into your own team's deficiencies versus the vendor's flaws.

2. Centralization vs. Fragmentation

Instead of one central service, every department builds its own version.

• Department Managers love this because they don't have to depend on people they don't control.
• Upper Management loves this because they don't have to investigate why a centralized service is failing.

---

The Founder's Perspective

A successful second-time founder once mentioned that the ability to do the job yourself is the ultimate hiring hack.

def hire_employee(founder_experience, candidate_skill):
    if founder_experience == "has_done_the_job":
        return "High quality hire (can spot nuance)"
    else:
        return "Average hire (relies on resume keywords)"

If you have personally performed the role you are hiring for, you can judge a candidate's competence with far greater precision. This is why founders who scale a company from zero are often so effective—they've already done everyone else's job.