In a recent Inc. Magazine article, “Google Has a Productivity Problem That Has Stumped Managers for 113 Years. Will Sundar Pichai Be the First to Solve It?” (Aug. 2022), Pichai said the tech giant’s productivity levels do not match its growing headcount. Google executives have reportedly said they want to “get better results faster” with the people they have, and employees have been warned to boost performance or “there will be blood on the streets.”
By some estimates, more than half of Google employees are software developers. So when Pichai talks about their productivity challenge, it would be reasonable to assume that he is greatly concerned with developer productivity.
Author Nick Hobson, Chief Behavioral Scientist with Apex Scoring Solutions, pessimistically concludes that Pichai is unlikely to solve Google’s productivity problems. His conclusion assumes that Pichai’s approach to managing productivity can be traced back to a seminal 113-year-old book on the topic called The Principles of Scientific Management
The article goes on to critique adroitly the many issues and flaws with the modern incarnations of this approach. When this approach is applied to software developers, we at Gradle refer to this practice as Developer Productivity Management or DPM.
DPM assumes developer productivity is a “people management” challenge that can be addressed with management decrees and “best practices.” This includes tracking and measuring how developers spend their time and using that information to evaluate and manage individual performance and skills gaps. A key issue with DPM is that it is susceptible to some dubious activity-based measures of developer productivity which can incentivize the wrong type of behaviors and discourage the right ones.
For example, if a developer is measured on software lines of code (SLOC) written, they are encouraged to write verbose code. This can be problematic as developers are not encouraged to hone their craft in writing concise and elegant code which runs faster and is easier to maintain and troubleshoot. If a developer is rewarded for writing bad code and the consequences become somebody else’s problem to address (i.e., build, test, CI, and operations engineers), can you blame them for cranking out shoddy code?
As Hobson points out, this approach also has some potentially fatal flaws in terms of its impact on developer trust and morale (think Big Brother). And questions may arise about the accuracy of activity-based productivity measurements and, by extension, the implied ROI.
The fatal flaw in Hobson’s conclusion, however, is that it assumes Pichai’s only, or at least primary, option for addressing his productivity challenge is to take a DPM approach. There is another approach called Developer Productivity Engineering or DPE.
As its name implies, DPE takes an engineering approach to improving developer productivity. As such, it relies on automation, actionable data, and acceleration technologies to deliver measurable outcome-based metrics (e.g., faster feedback cycle times and associated cost avoidance). As a result, DPE has quickly become a proven practice that delivers a hard ROI with little resistance to product acceptance and usage.
Organizations successfully apply the practice of DPE not only to achieve their strategic productivity-related business objectives, such as reducing time to market, increasing product and service quality, and minimizing operational costs, but also to win the war for developer talent by improving the developer experience.
Companies like Google are already investing in strategies to maximize developer productivity and provide a highly satisfying developer experience. DPE does this by engineering solutions that minimize the pains in the developer experience like waiting for long build and test cycles to complete and troubleshooting problems without the data necessary to determine the root cause quickly.
| A Closer Look at Idle Time
Those who evaluate productivity through a management lens and those who look at it through an engineering lens view idle time very differently. These views put the difference between DPE and DPM approaches in stark relief. Idle time is mentioned in the Inc. article (along with “focus scores” and “point ranking” systems) as “newfangled tech” used to evaluate and measure productivity. The article implies that the information is used to identify low performers, weed them out, and motivate them as necessary. But what if idle time is not something that can or should be managed but rather engineered? What if the root cause of a lot of idle time is not developer motivation or laziness but problems with the performance of the developer toolchain? If it takes an average of one minute to complete a feedback cycle (i.e., run your builds and tests), much of that time is often unavoidable idle time because there is not enough time to context switch to another task and back. However, if through engineered solutions you can reduce cycle time to a matter of seconds, developers can stay in the creative flow and idle time can become a non-issue. With moderate-sized projects in which a couple of hundred developers are running on average 20 builds per day, 300+ days per year, this adds up quickly to millions of dollars a year in lost productivity. The fact of the matter is that most developers don’t welcome idle time; they are frustrated by it. They want to stay in the creative flow and keep doing what they love to do—creating useful code. In summary, management would do better to trust their developers and fix their toolchains rather than try to fix their developers and trust their toolchains. |
Conclusion
There is good reason to be optimistic that Pichai will solve his productivity problem if he leverages an engineering approach—rather than relying on a management approach—to fix it. And who better than Google to do that?
To learn more about the pros and cons of DPE and DPM, check out Exploring the Developer Productivity Solution Landscape.
To learn more about DPE, concepts, practices, and tools, download The Developer Productivity Engineering Handbook.