Big tech companies don’t need heroes

Major technology companies operate via systems. What that means is that key outcomes – up to and including the overall success or failure of the business – are driven by a complex network of processes and incentives. These systems are beyond the control of any particular person. Like the components of a large codebase, they have been collected and co-evolved over time, rather than being designed from scratch.

Some of these processes and incentives are ‘readable’, such as OKRs or promotion criteria. Others are ‘unreadable’, such as the backchannel conversations that usually precede a formal consensus on decisions^{. But anyway, it is these processes and incentives that determine what happens, and not individual acts of heroism.}

How heroes are forged in big tech companies

This state of affairs is not efficient in producing good software. At large technology companies it often seems as if good software has been produced accidentallyas a byproduct of individual humans responding to their stimuli. However, that is exactly as it should be. A shared belief in the mission can lead a small group of people to prioritize good software over their individual benefit for a while. But thousands of engineers won’t be able to do that for decades. Past a certain scale point^{companies must rely on the power of their systems.}

Individual engineers often react with horror to this fact. After all, she want to produce high-quality software. Why is everyone around them just cynical? ^{focused on their own career? Additionally, many software engineers entered the industry because they were forced internally to make systems more efficient. For these people, there is a deep-seated discomfort working in an inefficient company. So they are willing to do it whatever it takes to solve the local inefficiencies of their system.}

Of course, making your team more effective doesn’t always require heroics. Fixing inefficiencies in some way – improving processes, writing tests, cleaning up old code – is just part of the job and will ensure that engineers are rewarded and promoted, just like any other kind of engineering work. But there is a limit. After a certain point, if you work on efficiency-related things instead of your actual projects, you will be punished and not rewarded. Crossing that line requires someone who is willing to sacrifice their own career development in the name of good engineering. In other words, it requires one hero.

Big tech companies don’t benefit from heroes

You can sacrifice your promotions and bonuses to keep a small corner of the company humming along for a while. However, as I mentioned above, the overall trajectory of the company is almost never determined by one person. It doesn’t really matter how efficiently you created a corner Google Wave team if the entire product was doomed. And even poorly managed software teams can often win, as long as they focus on a niche that the company wants to support (think about the quality of the most profitable enterprise software).

Moreover, Heroism makes it difficult to achieve real change. If a company is set up to reward bad work and punish good work, surely a hero must rise up to do good work and be punished will only protect the company from the consequences of its own systems. It is much better to let the company be punished for its shortcomings so that it can adapt (slowly, slowly) or be replaced by companies that function better.

…but will exploit them

Big tech companies don’t benefit from heroes in the long run, but there is still a role for heroes. That role is be exploited. There is no shortage of predators who will happily recruit a hero for a short-term advantage.

Some product managers keep a mental list of engineers on other teams who are “easy targets”: who can be convinced to do extra work on projects that benefit the product manager (but not that engineer). During periods of high intensity, such as the run-up to a major launch, a kind of cold war sometimes develops between different product organizations as they try to get help from the engineers in each other’s camps behind the scenes, while jealously guarding their own technical resources.

Likewise, some managers have no problem letting one of their engineers spend all their time on gluing work. Much of that work would otherwise be the manager’s responsibility, so it makes the manager’s job easier. When it comes time for promotions, the engineer is obviously punished for not doing his real job.

Therefore, it is important that engineers pay attention to their factual rewards. Promotions, bonuses and raises are the hard currency of software companies. By handing these out, you show what the company really values. Predators don’t have control over those things (if they did, they wouldn’t be predators). Instead, they try to appeal to a hero’s internal drive to be useful or to clean up inefficiencies.

Summary

• Large tech companies are structurally set up to encourage software engineers to perform heroic deeds
  • This is largely coincidental and doesn’t really benefit these tech companies in the long run, as big tech companies are simply too big to be meaningfully moved by individual heroics.
  • However, individual managers and product managers within these technology companies have learned to exploit this excess heroism for their individual purposes
• As a software engineer, you must resist the urge to heroically fix an obvious inefficiency in the organization
• Unless that work is explicitly rewarded by the company, your efforts will only delay the point where the company needs to change its processes.
• A background level of inefficiency is just part of the landscape of big tech companies
  • It’s the price they pay for being so big (and reaping the benefits of scale and readability in return)
  • The more you can learn to live with it, the more you can use your energy tactically for your own benefit