Developer Productivity is Really About Empowerment
A model for empowering your developers to achieve more
Lately, I’ve been hearing from a lot of organizations about their desire to increase the productivity of their developer teams. Every company is now a software company and it’s clear that the industry is in short supply of talented developers and technologists who can help companies achieve their “digital transformation”.
So, it’s no wonder that executives are looking for ways to capture the highest returns from their investment in their engineering teams. They’re looking for systems and tools that will help their teams deliver software faster than ever before. The essential belief is that developers are most productive when they have access to the absolute best engineering systems, tools, and services.
Certainly, removing friction from engineering systems is essential to having a high-performing product team. It’s hard for any engineering team to reach its fullest potential if it’s mired in issues that affect change lead time, deployment frequency, resolution time, or failure rates. These metrics absolutely matter and frameworks like DORA do a fantastic job of highlighting them for organizations.
However, I think there’s another dimension that is equally important and it’s not often addressed when discussing developer productivity.
How much fulfillment does a developer gain from their work?
Addressing developer productivity as a single dimension problem, by only seeking to remove friction in your engineering systems, will cause you to only apply systems thinking to a very nuanced problem. That strategy is incomplete and leaves you vulnerable to the risk of driving efficiency at the cost of overall developer wellbeing.
A better approach is to address developer productivity as two dimensions of the overall developer experience; by reducing systems friction and improving fulfillment. This approach more accurately acknowledges that developer productivity requires both systems and humanistic thinking. It seeks to move us beyond just improving developer productivity and toward the goal of developer empowerment.
In short, empowered developers are productive developers, but they’re also so much more. They’re motivated to reach their fullest potential and have a strong personal connection to the organization’s purpose.
We may have some understanding of what it means to reduce friction in our engineering systems but what does it mean to drive fulfillment?
Fulfillment as a goal seeks to improve developer experiences like:
- Belonging: A developer feels like they belong to their team and that their contributions are valued. Newer team members feel welcomed and supported, quickly giving them the confidence to begin contributing to the codebase.
- Psychological Safety: Product teams have the freedom to share different perspectives and are supported when data suggests they should pivot away from ideas that aren’t working. They have tools to give leaders feedback on their experience and the feedback is acknowledged and acted upon.
- Diversity and Inclusion: Teams are inclusive of diverse lived experiences and actively seek alternate points of view; particularly from underrepresented groups within their team, organization, and industry.
- Customer Connection: Teams feel empowered to create connections with the customers they serve. There’s “zero distance” between teams and their customers and learning from customers is continuous and collaborative.
- Mission and Values Alignment: Developers believe in the organization’s purpose and can make clear connections between their work and the impact it has on the organization’s business goals.
- Career Development: Developers believe they have an opportunity to solve challenging problems by offering their unique skills. The organization is continually investing in the developer’s potential by offering autonomy and mastery. As Marty Cagan puts it, “strong product teams are given problems to solve, rather than features to build.”
Empowered developers are productive developers
To explore these two dimensions: systems friction and fulfillment, I offer the Developer Experience Model. It’s a way for organizations to track both dimensions of the developer experience. By looking at both dimensions equally, organizations can ensure they avoid implementing solutions that result in unintended consequences.
Each quadrant represents the state of a developer's experience. These states are fluid and can shift as a result of a developer’s journey within an organization. They may feel themselves moving from one state to another because of a pivot in product strategy, the implementation of a new engineering process, the completion of an important project, an organization-wide reorg, the departure of a storied engineering lead, or even a migration to a different engineering system. The point is that these states aren’t fixed, and we should attune ourselves with how the developer’s experience is evolving over time.
Let’s look at the extreme states more closely:
Dysfunctional: Teams that experience low fulfillment and high systems friction struggle to get even the most routine tasks completed. They’re awash in toxic behaviors, infighting, and over-complexity. The product’s vision is malleable and constantly changing, depending on who you talk to. Responding to failures is chaotic and teams continue to repeat past mistakes.
Exploited: Teams who have highly tuned engineering systems but lack fulfillment may feel exploited. They may believe that their organizations see them only as a “cog in the wheel” — a human keyboard, typing code based on uninspired spec sheets. Questioning “the plan” is seen as disruptive and developers learn that ruthless efficiency is valued over customer connection. Developers who feel exploited often leave their organizations or become distracted by side projects that offer them more fulfillment than their day-to-day work.
Demoralized: Teams who receive high fulfillment from their work, but who also struggle with high friction in their engineering systems often feel helpless and frustrated. They have great cohesion with their team, and they believe in the vision of their organization, but the constant frustration of completing the most basic of tasks is what keeps them looking for the door. Developers who feel demoralized often don’t want to leave, but they can no longer tolerate the inefficient and broken tools, services, and systems they must interact with every day.
Empowered: This is the desired state. These teams have cutting-edge engineering systems, and they also have healthy and robust cultures. Empowered teams mitigate issues together, share knowledge freely, and invest in the development of each other. Empowered product teams are inspired each day to bring their best selves to work, because they’re not only aligned to the organization’s purpose, but they also see the direct impact they’re having on customers, through continuous and direct interactions with them. Empowered developers remain focused on the organization’s goals, because they believe that their organization is investing in their potential.
Developer productivity, velocity, wellbeing, and happiness are multi-dimensional issues. This is why there are multifaceted frameworks like S.P.A.C.E. to debunk the myth that developer productivity is only about developer “activity” or “performance”. S.P.A.C.E. addresses issues with developer fulfillment by incorporating metrics like developer satisfaction and wellbeing.
We should reframe how we talk about developer productivity. Understanding that investing in developer tools and services is important, but that it does not encompass the complete developer experience — and it’s not the only driver of productivity.
When organizational leaders pursue a path toward developer empowerment, they not only find that their product teams are more productive, but that they are also inspired and committed to doing their best work for their organization, their customers, and each other.
