"The Role of Leadership in Software Development" is a paper or extended presentation by mary-poppendieck and tom-poppendieck, dating to approximately 2008, bridging the territory between implementing-lean-software-development-2006 and leading-lean-software-development-2009.
Intellectual Position
This work occupies a transitional moment in the Poppendiecks' published output. implementing-lean-software-development-2006 had provided practical tools for lean transformation — value-stream-mapping-for-software, pull-systems-in-software, queueing theory applied to development workflows. But the Poppendiecks were observing a consistent pattern in practice: organizations that adopted the tools without changing leadership behavior failed to sustain the transformation. The bottleneck was not technical or methodological; it was organizational and cultural, and it started with how leaders understood their role.
The paper addresses this gap directly. It argues that leadership in a lean software organization is fundamentally different from leadership in a traditional command-and-control software project: instead of directing work, lean leaders create the conditions for work. The distinction between managing results and enabling learning — which became the central thesis of leading-lean-software-development-2009 — is articulated here in preliminary form.
Content
The paper examines what leadership behaviors amplify-learning versus what behaviors suppress it. Performance management systems that reward individual output, approval processes that create decision bottlenecks, and organizational structures that fragment ownership across functional silos are identified as learning suppressors — each creates a delay in the feedback that teams need to improve.
The empower-the-team principle receives leadership-level treatment: empowerment is not delegation without context. Effective empowerment requires leaders to communicate clear strategic direction (so teams can align their judgment), ensure teams have access to customer and outcome feedback (so teams can learn from results), and remove organizational impediments (so teams can act on what they learn). When leaders treat empowerment as "leave the team alone," the result is autonomy without alignment, which is not lean — it is just unmanaged.
The optimize-the-whole principle also has leadership implications the paper explores: optimizing the whole requires someone with organizational authority and perspective to identify and eliminate the local-optimization behaviors that functional managers naturally default to. This is a leadership function, not a team function.
Bridge Function
The paper's primary significance is as a visible milestone in the development of the Poppendiecks' third book. The learning-not-results thesis, which became the subtitle and core argument of leading-lean-software-development-2009, appears here in formative articulation. Practitioners who read this paper in 2008 and then read the 2009 book can trace the conceptual development: the paper identifies the problem (leadership behavior as the bottleneck), and the book provides the fuller theoretical and practical treatment.
The paper also contributed to the professional discourse within the agile-alliance community in the period between major books, maintaining the Poppendiecks' intellectual presence and continuing to develop the ideas in dialogue with practitioners who were implementing lean software in real organizations.