Reframing "Productivity": What are we aiming for?

With the shift in recent years to a world of working remotely, conversations around metrics and developer productivity have sparked a lot of heated debate.   On August 17, 2023, McKinsey published an article claiming they could measure productivity [1], and a number of industry thought leaders had strong responses of concern in their tech blogs [2].  When humans measure themselves primarily under a productivity-centric lens, it can lead to the adoption of suboptimal policies and practices which impair, rather than enhance, overall productivity.  For example, any contribution that's not directly related to coding features, tends to be de-valued.  This often leads to front-line workers and their immediate supervisors having to work 10x harder to justify any work that doesn't "look like" productivity, even when the work is critical to the long-term success of the project.  Developers can become reluctant to help one another when it means a decline in the productivity metrics they’re measured by.  These are frustrating and unnecessary problems to have that keep everyone from doing their best work.

Reframing the Goal

On August 28, 2024, we organized the first Bridges Summit, a collaborative open source event series bridging minds across research and industry communities, to reframe the conversation around "Developer Productivity".   We raised the question to the community of "What are we aiming for?" to clarify the vision of what it is we want, and create new possibilities for getting there. 

At the Bridges Summit kickoff, we hosted a series of virtual community discussions led by thought leaders across research and industry with three themes: Problems and Constraints, Changing the Words, and Imagination.

Problems and Constraints: What are the problems and constraints that keep us from bridging the divide between business leaders and developers?

Changing the Words: What are the words that get in the way of us communicating, seeing, or understanding what’s happening more clearly?  How could we change the words to improve things?

Imagination: How could we build an environment where developers, teams, and organizations that support them can thrive individually and collectively?

For each theme, we started with a thought leader talk or panel discussion.  The community members then split into groups gathering around virtual tables to brainstorm ideas, then gathered back together to share ideas in a poster session “Idea Garden”.  To distill key takeaways from all the discussions, we invited thought leaders back on stage for a panel discussion, to reflect on the ideas they heard coming from the community.

The Challenge of Bridging the Divides

Our first community discussion kicked off with a panel discussion that included thought leaders from industry, Kent Beck, Dave Thomas, Domain Drewitz, and Chanté Martinez Thurmond, and thought leaders from research, Tom Zimmerman, Marian Petre, and Gail Murphy.  

Arty Starr and Margaret-Anne Storey from CHISEL (computer human interaction and software engineering lab) at University of Victoria, moderated the discussion asking:

“What are the problems and constraints that keep us from bridging the divide between developers and business leaders?”

Watch the full discussion here:

One of the fundamental challenges and barriers to improvement is the communication breakdown between management world and engineering world.  Kent Beck highlighted the challenge of learning to speak one another’s language.  Developers might talk about the importance of developer experience or thriving, but if you’re an investor in the company, why should you care about any of that?  Business leaders are thinking in economic terms.  Kent suggested we start with empathy, that there are legitimate perspectives on both sides.

Developers can learn a bit of economics, and learn strategies to translate the value of intangibles into economic terms.  Dave Thomas highlighted that developers don’t typically understand the business, and should be trained in the domain in order to speak the different languages.  By training in different aspects of the business – knowing Mary in marketing and Bob in purchasing, and knowing the nouns and verbs for how to get around – communication and coordination can be much improved.  Domain-Driven Design is a good strategy to bridge communication between business and engineering worlds by creating a shared language and understanding of the business domain.  Kent described how the value of intangibles might be translated into economic terms using the language of optionality.  For example, designing software for optionality and future change has real monetary impact, and optionality can be a helpful language for communicating benefits in economic terms.

Domain-Driven Design is a good strategy to bridge communication between business and engineering worlds by creating a shared language and understanding of the business domain.

Managers can aim to be more human and more vulnerable.  Kent highlighted the temptation for managers to want to reduce everything to numbers and count things, but if managers really want to know how the team is doing, they need to pay attention, go talk to people, and be a human being.  Tom Zimmerman, from the research side at Microsoft, highlighted that the challenges were mostly people related, and described a lack of mutual understanding around both the complexities of engineering, and also the objectives of the business, leading to misaligned goals when facing resource and time constraints.   There’s also multiple axes of complexity, with the involvement of multiple roles, with AI engineers, data analysts, UX, and many others all making contributions, and the constant changes with the rapid adoption of AI that creates challenges for everybody.  Dave Thomas characterized the communication disconnect as needing to understand one another’s “physics” of what the constraints and capabilities are, why some things are easy or hard, and that it's fundamental human factors like autonomy, mastery, and purpose that motivate people.  Domain Drewitz highlighted how the challenges are exacerbated when scaling a company, but a lot of creativity happens in the face of constraints, and developers are creatives.  By creating transparency between developers, business, and customers, including developers being able to observe the use of their product by real people, a product-focused mindset can help bridge the divide, and unlock opportunities for innovation.

Gail Murphy brought up another divide between researchers and software industry professionals.  Researchers want to work with industry on real problems that have an impact, and industry wants to work with researchers, because they don’t always have time to go deep on understanding problems.  What are strategies that would allow us to work together more effectively to have a greater impact?  Gail highlighted three main aspects of the disconnect: context, scale, and incentives.  Researchers will typically whittle down a problem to focus on one phenomena at a time, and the advantage is getting some deep insights, but often the focus is so narrow, the context of the problem can be lost.  Similarly, a researcher might work on building a code recommender that works at a small scale, but the solution doesn’t fit the scale needed for industry.  With better collaboration, we can infuse research problems with a clearer perspective of industry contexts and scale, so when the focus is narrowed, the broader context isn’t lost.  Further, the incentives need to be aligned to support this collaboration.  For researchers, we need incentives beyond the academic paper, to view contributions in a more longitudinal way.  For industry, we need incentives to take time to reflect, to look for better ways to do things that could consider new research.

Seeing Opportunities for High-Performing Teams

The conversation shifted dramatically when Chanté Martinez Thurmond had us rethinking our perspective.  Chanté highlighted the impact of framing, and contrasted asset-based framing versus deficit-based framing.  Even asking about “problems and constraints” creates a constraint, so what if we asked, what are the opportunities?  What are the possibilities?  Chanté also highlighted that conflict and friction isn’t bad, it means you have diverse thinking, and it’s an opportunity to understand a challenge from multiple angles.  The way we ask a question makes all the difference in determining the opportunities we see.

One of the key opportunities is the possibility for high-performing teams.  Marian Petre has been studying professional developers in industry for more than three decades, specifically researching what distinguishes high-performing teams from all other teams?  One of the key findings from her research is that high-performing teams address this mismatch in perspective, of language, values, goals, or even what constitutes evidence in people’s decision-making, better than anybody else.  Fundamentally, there’s a mindset of high-performing teams that is reinforced through culture and embedded in practices.  High-performing teams emphasize critical-thinking, looking for what isn’t there, looking for what doesn’t match, looking for misconceptions.  The teams do this by creating contrast, which is similar to what Chanté described as seeing opportunity in conflicting opinions.   Instead of jumping immediately to solutions, the teams maintain alternatives, contrasting different tools and processes to create options.  High-performing teams have lots of dialogue so different perspectives come into the room, all while keeping the critical-thinking going, and keeping an ear open for the thing that doesn’t fit.

Instead of jumping immediately to solutions, the teams maintain alternatives, contrasting different tools and processes to create options. 

Marian also described how high-performing teams have an absolute commitment to building a product fit for purpose, considering who the product is for, and what the customers’ real needs are.  Through a shared caring about the product, and learning how to speak business language and effectively dialogue, the teams win themselves the autonomy and space to build this type of culture.  Marian highlights the key is making space, giving developers the time and space they need to build the culture, the mindset, the tools and learning they need, in order to deliver what the business wants.  A lot of what developers do is not evident, it’s invisible work.  By addressing invisible work like refactoring, efficiency, upscaling, looking toward future options, reliability and security, there’s financial benefit to the organization.  Gail Murphy highlighted another type of invisible work, taking time for reflection.  It’s difficult to quantify intangible benefits in economic terms, which makes it difficult to get time and space for what needs to be done.

Key Takeaways from Developer Experience

Following the panel discussion, the community members split into groups and gathered around virtual tables to brainstorm ideas about the problems and constraints from their own experiences, creating a rich set of ideas and takeaways to share in the Idea Gardens.  

The community brainstorm generated 274 stickies with ideas, 94 of them related to Developer Experience.  We identified the following three main themes related to Developer Experience.

Theme: Invisible Work isn’t Valued

One of the major themes that community members brought up as a constraint to a better Developer Experience, is the challenge of invisible work.  There’s a lack of understanding of different types of valuable contributions, and any work outside of developing product features can be difficult to justify because the contribution is more invisible.  The invisible work isn’t valued, not because the contributions aren’t valuable, but because it’s difficult to quantify the value.  Further, the focus on measurement tends to exacerbate the challenge, as contributions that are hard to measure are easier to overlook.  As one community member put it, “Tech wants everything to be measurable. Productivity isn't.”

The invisible work isn’t valued, not because the contributions aren’t valuable, but because it’s difficult to quantify the value.

Community members brought up a variety of challenges that arise from invisible work not being valued.  Lack of understanding of the value of refactoring and keeping code clean can lead to codebases that are difficult to work on.   Toilsome manual processes persist, because reducing the toil is invisible work.   There’s a lack of proper documentation available for new onboarding, because internal documentation is invisible work.   Teams need time to invest in building a shared understanding of the problem and solution spaces, yet this work is often undervalued because of its invisibility.  The constant pressure to ship features limits the team’s time to reflect and improve, and even though the insights from reflection can be critical to success, the difficulty of quantifying the value makes the time investment difficult to justify.

Theme: Unrealistic Expectations and Shifting Priorities

Another major theme brought up by community members is the challenge of unrealistic expectations and shifting priorities. With constant business pressure, tight deadlines, and unrealistic expectations about how long things take, it’s a lot of pressure to do the most visible work to show progress.  Community members highlighted how difficult it can be to give a time estimate on a task, and how much of software development lacks predictability, making it hard for the business to plan, and leading to an increase in pressure on developers.  Sometimes the product group, in not understanding how long things take, would just produce timelines on their own.

The challenges are exacerbated with shifting priorities and constant change.  Community members discussed shifting priorities with changes in requirements every sprint, too much work in progress, a lack of clear communication around deadlines and goals, and unclear expectations.  The lack of clarity and direction, with simultaneous pressure to deliver features, creates a stressful developer experience.

Theme: Helping Leaders Bridge the Divides

Another major theme brought up by community members is a “lack” of leadership.  The characterization by community members varied as a lack of leadership, a lack of servant leadership, and a lack of guidance, mentorship, or support, but in all cases the problem was framed as something missing.  What does it mean to be a leader?  Where does leadership come from?  What do leaders do that helps or hinders?  Community members brought up a number of challenges related to leadership that can help us understand what’s missing.

What does it mean to be a leader?  Where does leadership come from?  What do leaders do that helps or hinders?

Leaders help to shape the culture and mindset of the team.  Many of the constraints to better Developer Experience had to do with culture.  Community members brought up feeling treated like an interchangeable cog in the machine, feeling a lack of belonging in the team, or toxicity on the team, as well as a lack of trust in oneself, others, and across teams.  Another community member highlighted that trust takes a long time to build, and can be destroyed in a short amount of time.  True leadership involves a lot of sensitivity, to the team, to its health, to the culture, and how people are feeling.

There are many challenges with creating alignment in decisions with the variety of perspectives, values, and goals of people involved in the software project, and leaders help to create alignment through effective dialogue.  Community members brought up the challenges of communication, with not having a common vocabulary or frame of reference, and business and engineering having very different views of what’s the problem to solve ("keep customer" vs "spin up a K8 cluster").  There’s additional challenges with people having different mental models of the product, and not understanding the different skills and experience of others.  Community members also emphasized an overarching problem with there being too much focus on "creating software" and not enough focus on "solving problems".

Another challenge brought up by community members was the lack of connection with customers. Community members highlighted that many developers and business executives were far removed from the end user, and there were frustrations that product managers wouldn’t include developers in discussions with users.  In the panel discussion, Marian Petre identified a key ingredient to fostering alignment in decisions was the absolute commitment to building a product fit for purpose with a shared understanding of the customer’s real needs.  One opportunity for leaders to help foster alignment is by supporting more opportunities for connection with customers. 

Summary and Next Steps

In bringing together research and software industry communities, Bridges Summit provided a unique context for rich community discussion that was full of wisdom, insight, and actionable takeaways. In reframing the goal of "productivity", and asking what it is we are really aiming for, we were able to identify many of the key challenges holding us back, and see new opportunities for making things better.   Our first community discussion centered around the problems and constraints that keep us from bridging the divides:

While this article is already rich with insight, there's still significantly more data to report on, as the community brainstorm on problems and constraints generated 274 stickies with ideas, with 94 of them related to Developer Experience, which is what we covered in this article.  In our upcoming articles, we will cover the other two major areas we explored for understanding problems and constraints, Software Excellence and Thriving. We are excited to share all the insights and takeaways from the community discussions. Stay tuned!