Project Oxygen and Cost Mitigation Value

In this article I argue that corporate management chiefly achieves value through cost mitigation, not genuine productivity enhancement. I do this in part by drawing on Google's Project Oxygen, as well as my own experience. I previously discussed <a href="http://www.afterecon.com/other/googles-disconcerting-project-aristotle/">Google's Project Aristotle which is tangential.

In the eminent piece <a href="https://rework.withgoogle.com/subjects/managers/">referenced by Google themselves, the <a href="https://www.nytimes.com/2011/03/13/business/13hire.html">New York Times declares at one point:

PROJECT OXYGEN started with some basic assumptions.

People typically leave a company for one of three reasons, or a combination of them. The first is that they don’t feel a connection to the mission of the company, or sense that their work matters. The second is that they don’t really like or respect their co-workers. The third is they have a terrible boss — and this was the biggest variable. Google, where performance reviews are done quarterly, rather than annually, saw huge swings in the ratings that employees gave to their bosses.

That is, project oxygen began by operationalizing a good manager as one who minimizes employee turnover. This is one of the three key sources of value of managers in my view, and this value is based on cost mitigation. If this was the sole value of management in a company with no turnover, managers would be an overhead cost without any benefit.

<a href="https://www.youtube.com/watch?v=QC_PGHkRvTw">Here, Michelle Donovan presents the ultimate findings of Project Oxygen. Some good stuff in there, but I find it unfortunate that they ended up optimizing against survey data instead of more objective measures like turnover. This seems to be a common thing in the industry, including the company where I currently work. My intuition is that it's a matter of convenience data because companies are running these internal surveys anyway. As an economist, it seems sub-optimal to me because employee satisfaction is only an intermediate good. Turnover seems to be a better final measure. If one can't decide between the two I would say to use both, but the idea of going purely for survey data strikes me as a fumble, <a href="http://www.afterecon.com/other/googles-disconcerting-project-aristotle/">like what happened with Project Aristotle, though probably not as bad.

Project Oxygen came later in the history of Google. Earlier, in 2002, Google ran an uncontrolled experiment and let all managers go. Michelle Donovan talks about that time period as a disaster, but economics says that's not the case. Google's <a href="https://www.statista.com/statistics/266206/googles-annual-global-revenue/">revenue grew by more than 300% in 2002, a feat they have yet to repeat. Michelle Donovan says it was a disaster because all developer concerns went directly to the executives and the executives eventually decided this was too much work and re-implemented the management class. In my view, this amounts to managers as a luxury good, or an executive consumption good. They act as proxies of executive leadership, improving executive happiness, but reducing efficacy. After all, managers as proxies never perfectly represent the actual views of the executives.

The inefficiencies of proxies relates to advice given by Amazon's Jeff Bezos. <a href="https://www.recode.net/2017/4/12/15274220/jeff-bezos-amazon-shareholders-letter-day-2-disagree-and-commit">Bezos says to "Resist Proxies". He says, "'You've worn me down' is an awful decision-making process." He cites process and market research as proxies for the customer, but I see managers as a proxy for executive leadership.

The above is intuitively matched to the high performance of small business and the growth of the management class within medium and large organizations, along with declining productivity.

The third source of manager value which I see is that they can execute business tasks. Business tasks do not overlap with technical development tasks. Thus, the manager here is reducing the developer's workload, but not improving the developer's productivity.

Business tasks include administrative tasks like handling time sheets and also such tasks as modifying legal contracts. Business tasks also includes business analysis, but business analysis is a distinct skill set from management and specialist business analysts are a common role. There are advantages to having a specialist business analyst and also to allowing developers to reach out to the client directly, but there are also costs, so there is no generally preferred solution. At least some of the time it is the program or project manager who knows the customer best, and there is value there, but it's not clear to me that a manager executing a business analysis task is acting in his or her role as a manager.

Notice that in no case does the manager improve the developer's technical productivity. The manager does not allow the developer to produce code more quickly. A perfect manager simply allows a developer to produce at full capacity, unhindered by what's called administrivia in business jargon.

Hybrid roles do exist. A Team Lead is a role in which an individual may be both a supervisor and a senior developer. In that case the Team Lead can set standards and teach more novice developers to code more efficiently. I chalk all such mentoring capacity up to the Team Lead qua developer, not the Team Lead qua manager.