The source document/presentation ("Coordination Headwinds") and idea are many years old, and from what I recall were not aimed to be critical of the company and its organization, rather to give its employee readers a feeling of solace and understanding for why getting seemingly small things done can feel overly hard and slow… a less humorous, and less SWE-specific version of "Broccoliman" if you will.
Refer to the red panda that merely wants to serve 5TB of data.
I’ll try to continue using the organism-metaphor in my commentary.
While the “slime mold” story provides a convenient and charitable explanation of Google's bureaucracy and dysfunctions, another explanation is:
- As an organism, Google's executive decision-making functions are severely impaired by lack of accurate information, dysfunction of its middle-management “organs” or tiers, and impedance mismatches arising from genetic encodings or mental models associated with the slime-mold idea.
- Despite being on a mission to “organize the world's information and make it universally accessible and useful,” Google is far less successful at doing this with its own information. These characteristics are not unique to Google, but some of Google’s cultural history makes this a particularly challenging problem.
It may be convenient to think of Google as a slime-mold organism, and in an individual contributor’s day-to-day engineering activities it may very well be, but as a corporation it is not.
The vast majority of Google’s product areas or business units, are not self-sustaining entities and all rely and draw upon resources, namely headcount, that unavoidably go through a centralized prioritization and allocation process. Ruth (Google CFO) and Sundar’s (Google CEO) jobs are quite difficult if you consider that: (1) they don’t have optimal or very accurate internal information, (2) they are constrained by what is provided to them and what people will actually do, (3) tributary sources of information generally have little understanding of broader processes, aside from what they expect to receive, and also have many incentives to fashion information in a manner that maximizes their own benefit – based on what they assume or understand.
Avery Pennarun (apenwarr@) touched on some of the above internally in a document called “View from Above” (go/vfa) and post-Google, on similar dynamics in a public blog post: https://apenwarr.ca/log/20190926
From my own experience at Google, where I served in engineering leadership roles and joined as an experienced industry hire, is that over time Google's culture – Namely its performance rating and promotion process, over-weight certain accomplishments and neglect critical characteristics and understandings needed from employees as they move into upper echelons of leveling (middle-management and higher), most importantly in the L6/L7 (manager, sr manager) and L8 (director) levels.
Many Googlers in those ranks continued to operate based on the understandings they held as project / technical leads (“TLs”), typically a Level 5 role, and continued to be promoted based on those understandings and/or increased headcount below them. Meanwhile, these roles, and the corporate organism’s need from these roles, are fundamentally from being a TL or project lead.
Compounding this problem is the fact that for most Googlers in these roles, scarcity of resources was rarely a problem, and getting headcount was easy. Most managers know how to ask for headcount but have no idea how to help support the conditions for its creation.
To be less wishy-washy, many people were promoted for continuing to do their jobs as they understood them, and their expanding team size to some degree, rather than understanding the full scope and understanding of the new level or role they were stepping into. And to some degree, it may not have been their fault as the persons and examples before them did the exact same thing.
Some might say this is the Peter Principle in practice, but at Google-scale.
Anyways… to wrap this up, I regularly encourage people to think about and learn to understand their boss’ boss’ problems, and ensure they are able to evaluate and represent their work in relation to those problems. Without establishing that context, your work may be completely misaligned or difficult to value when viewed from above.
> many people were promoted for continuing to do their jobs as they understood them
While this link below isn't the best take on this, it does get concrete about the kind of thing you're saying. Each level of management is not doing the prior level better. Each level is doing management quite differently:
OKR really should be used as the North Star and constellations. It usually isn't, though, because people write either task completion percentages or KPIs instead of outcome-supporting qualitative measures that can be undershot or overshot based on priorities and effort allocation (much like SLAs, bad, vs. SLOs, good).
Promotions seldom relate with OKRs on tech ladders, and more specifically for SWEs it is rarely the case, as the promotions are judged by committees who evaluate for difficulty and skill by ladder standards, not business objectives.
Launches are catalysts but insufficient for promotion.
The source document/presentation ("Coordination Headwinds") and idea are many years old, and from what I recall were not aimed to be critical of the company and its organization, rather to give its employee readers a feeling of solace and understanding for why getting seemingly small things done can feel overly hard and slow… a less humorous, and less SWE-specific version of "Broccoliman" if you will.
Refer to the red panda that merely wants to serve 5TB of data.
I’ll try to continue using the organism-metaphor in my commentary.While the “slime mold” story provides a convenient and charitable explanation of Google's bureaucracy and dysfunctions, another explanation is:
It may be convenient to think of Google as a slime-mold organism, and in an individual contributor’s day-to-day engineering activities it may very well be, but as a corporation it is not.The vast majority of Google’s product areas or business units, are not self-sustaining entities and all rely and draw upon resources, namely headcount, that unavoidably go through a centralized prioritization and allocation process. Ruth (Google CFO) and Sundar’s (Google CEO) jobs are quite difficult if you consider that: (1) they don’t have optimal or very accurate internal information, (2) they are constrained by what is provided to them and what people will actually do, (3) tributary sources of information generally have little understanding of broader processes, aside from what they expect to receive, and also have many incentives to fashion information in a manner that maximizes their own benefit – based on what they assume or understand.
Avery Pennarun (apenwarr@) touched on some of the above internally in a document called “View from Above” (go/vfa) and post-Google, on similar dynamics in a public blog post: https://apenwarr.ca/log/20190926
From my own experience at Google, where I served in engineering leadership roles and joined as an experienced industry hire, is that over time Google's culture – Namely its performance rating and promotion process, over-weight certain accomplishments and neglect critical characteristics and understandings needed from employees as they move into upper echelons of leveling (middle-management and higher), most importantly in the L6/L7 (manager, sr manager) and L8 (director) levels.
Many Googlers in those ranks continued to operate based on the understandings they held as project / technical leads (“TLs”), typically a Level 5 role, and continued to be promoted based on those understandings and/or increased headcount below them. Meanwhile, these roles, and the corporate organism’s need from these roles, are fundamentally from being a TL or project lead.
Compounding this problem is the fact that for most Googlers in these roles, scarcity of resources was rarely a problem, and getting headcount was easy. Most managers know how to ask for headcount but have no idea how to help support the conditions for its creation.
To be less wishy-washy, many people were promoted for continuing to do their jobs as they understood them, and their expanding team size to some degree, rather than understanding the full scope and understanding of the new level or role they were stepping into. And to some degree, it may not have been their fault as the persons and examples before them did the exact same thing.
Some might say this is the Peter Principle in practice, but at Google-scale.
Anyways… to wrap this up, I regularly encourage people to think about and learn to understand their boss’ boss’ problems, and ensure they are able to evaluate and represent their work in relation to those problems. Without establishing that context, your work may be completely misaligned or difficult to value when viewed from above.