Ever heard that software developer productivity can't be measured?
When we focus on tech roles, particularly software developers, the distinction becomes more pronounced. As Drucker aptly noted, many knowledge workers, which he termed "technologists", straddle both realms: manual and cognitive. He cites professions such as surgeons and dentists as examples. But where does this leave software developers?
Both manual and knowledge work yield outputs, outcomes, and impacts. The stark difference lies in the input. While manual work's primary input is muscle effort, software development thrives on cognitive effort. This becomes evident when we realize that in manual tasks, much of the necessary knowledge is already embedded in the machines and procedures. In contrast, software development demands continuous knowledge acquisition and application, necessitating a deeper level of problem-solving and innovation.
Software development isn't just about typing or producing lines of code; it's deeply rooted in the acquisition and application of knowledge. This is particularly true for the knowledge developers initially lacked—the information they needed to procure to fulfill their tasks.
This notion becomes palpable in activities such as problem-solving sessions to decipher both the 'what' and 'how' of building a software system, meetings focused on filling knowledge gaps, and code reviews that solicit insights beyond the visible code.
If we insist on evaluating software developers by the metrics of manual labor, we're not just using the wrong yardstick—we're playing an entirely different game. Understanding this distinction is crucial, especially for leaders aiming to harness the full potential of their software development teams.
#SoftwareProductivity #KnowledgeVsManual #McKinsey