Companies are increasingly focusing on the software development team as a driver of productivity gains. Addressing the drivers of team productivity, as opposed to individual developer productivity, requires a different perspective and methodology. And it starts with sharing knowledge, since the knowledge gap between different developers may lead to unnecessary drags on overall productivity, even if it makes some team members more likely to appear a lot more productive than others.
First, some background on the business concerns that are accelerating the focus on the dev team. Development team performance is becoming so central to business that it’s become an important topic in boardrooms around the world. In March 2019 Morgan Stanley published a report entitled “A New Software Stack for the Digital Era” in which they describe a transition from the Old Stack (think Oracle, Tibco, Old Microsoft) to the New Stack represented by companies like Atlassian, PageDuty, Splunk, MongoDB, and New Microsoft. According to the report, the New Stack represents a $50B opportunity with 22% vs. 4% CAGR when compared to Old Stack growth, driven by the wide adoption of DevOps and Agile methodology. Morgan Stanley’s definition of DevOps is as “any practice, methodology or architecture that reduce or alleviate the inefficiencies in the process of delivering new features and services to end customers.”
From a more technical perspective, DevOps is a software development strategy that bridges the gap between the developers and the IT staff. With DevOps, organizations can release small features very quickly and incorporate the feedback they receive. This results in 1) Fewer software failures and 2) Shortened lead time between fixes – i.e. higher productivity. For all of this to work as intended, knowledge sharing is often a missing link.
Knowledge Sharing is Top of Mind
According to the State of Software Development report in 2019 by Coding Sans, the second biggest challenge tech companies are facing is knowledge sharing – right after capacity. Typically, knowledge sharing suffers when the backlog is full and the deadline is approaching. In other words, in a world where developer demand outstrips developer supply (as is the case for the foreseeable future), alleviating the inefficiencies is dependent largely on the ability of the organization to share knowledge.
The report also points to a difference between management and developer perspectives of the most significant challenges in 2019. For developers, Knowledge Sharing is the most important challenge they face at 24.57% of the respondents, up from 18.11% in 2018.
If sharing knowledge is so important, how do teams tackle that fundamental challenge today? The Agile process places strong emphasis on face-to-face conversations for conveying information, but is that the same as having a comprehensive approach to sharing knowledge? With teams distributed across many time zones, conversations are increasingly not enough. What will supplement or replace these face-to-face conversations?
Remote is the New Normal
Remote is increasingly becoming commonplace among developers in organizations of every size. According to the same report, 72.2% of developers report that remote work is allowed in their organization.
Organizations with remote developers often turn to solutions such as Skype or Zoom that can easily replace a face-to-face conversation. A conversation in Slack or Microsoft Teams where knowledge can be shared asynchronously – and tediously when it comes to code – can also answer questions and share knowledge. However, these approaches do nothing for the team or the organization in terms of capturing and organizing that shared knowledge so that it may be easily accessible a month or a year from now. They lead instead to repeated and wasteful interactions as the same issues and concerns are raised again and again, or worse, they become barriers for new developers who are afraid to ask a simple question for fear of becoming an annoyance to more senior team members.
Team Productivity and Sharing Knowledge
Developers know that there is a relationship between the team’s ability to share knowledge and its ability to be more productive – as a team. There are different kinds of knowledge that a team can share. The first kind, general knowledge about coding, can be conveyed in posts, papers, webinars, books, etc. and can be helpful in lifting all team members to a common understanding of the approaches and methods the team embraces. For instance, Davide de Paolo writes in his post What makes a 10X developer? that among the characteristics of a rockstar is knowledge sharing: “As soon as you learn something, try to help someone else, teach other colleagues, share your learnings. It can be giving some advice after your daily standup, making a short presentation to your team, writing a blog post or becoming a mentor on an online coding platform.”
A second kind of knowledge is specific to the code itself. It is not possible to acquire this kind of knowledge by posting a question on Stack Overflow or Quora, since only your team members might know the answer, and further, security concerns may require the code to be discussed only internally.
Many developers report frustration at spending a large percentage of their time – sometimes up to 75% – trying to understand code written by someone else. Less than 20% of developers in Stack Overflow’s 2018 survey state that they use the company’s internal documentation in trying to figure out how the code they are working on works. In the context of team productivity, how should this kind of knowledge be shared?
Sharing Knowledge about Your Code
For this second kind of knowledge to contribute to team productivity, it must meet four criteria:
- It must be easily accessible at any time
- It must be contextual
- It must be persistent
- It must allow for interactivity that will further clarify its meaning and applicability
It’s time for knowledge about your code to move from isolated and disparate sources to the code itself. Knowledge in context is more easily understood. Teams must set aside notions of code that explains itself and adopt instead solutions and technologies that address the knowledge gap and lift the whole team to higher ground. Shared knowledge then becomes a competitive advantage for the whole organization.
You might think code comments might take care of this, but that is not the case. Code comments have been used for a long time to explain how the code works, but they suffer from three major drawbacks: 1) They become stale relatively quickly as the code evolves, 2) they are not conversational, and therefore are not great for iterating around an explanation, and 3) you cannot easily ask a question using a code comment, and questions are perhaps the most important element of knowledge sharing. That’s because whoever is explaining his or her own code does not know in advance what aspects of the code will not be easily understood by another developer. Therefore, the ability to ask questions within the code leads to better quality and better documentation.
Teams who are concerned with capacity and knowledge sharing should therefore look for solutions that meet the above four criteria and fit within their existing workflow and toolset. Sharing knowledge within your favorite IDE should simplify conversations about code, while integrations with your preferred messaging and issue tracking software will allow developers to stay in context while notifying the whole team when new questions and answers are being created.
Summary
Team Productivity is achieved when team members share knowledge widely. Developers already feel the pain if too little knowledge being shared and rate this as their number one concern. Traditional face-to-face conversations can help address certain kinds of knowledge, but with remote becoming mainstream, new solutions are required that address both the immediate need and the long term need for knowledge sharing. Specific information that describes how your code works should not be divorced from the code itself, as it makes that information less usable and less understandable. The next wave of solutions and tools for developers must address the knowledge gap and lift the whole team towards greater productivity.
Top comments (2)
The primary purpose of code reviews, in my opinion, is to transfer knowledge. A developer gets a chance to walk someone else through their world. It's more efficient than trying to predict what team members will find relevant and it encourages a sense of shared ownership that further motivates team members to stick with the discipline, open-mindedness, and gentle spirit of inquisition.
Hi Scott. I believe you are right. Code reviews are an opportunity to transfer knowledge (even though the primary purpose is IMO to improve the quality of the deliverable). My view is that we should find ways to share that knowledge widely, among all the developers who might benefit from it within the team and the organization. Transferring knowledge to one developer is useful; sharing in with the team actually moves the needle in terms of team productivity.