The collective knowledge of a team's individual members is one of its most valuable assets. Whether solving individual problems or making high-level strategic decisions, that collective knowledge will enable better results. It should go without saying then that taking time to make the most of that collective knowledge is a worthy investment.
In one form, this means finding ways to better use existing knowledge. There’s a large body of research and articles out there around collaboration and collective decision-making, which is all very much worth understanding.
Today, I’m here to make the case for putting in extra effort to cultivate this collective knowledge, and to provide some tips for doing so.
An example
Imagine a product delivery team with a few high-priority features to deliver this sprint. Also within the sprint is a medium-priority feature that involves integrating with a new third-party API. This API also happens to have a complicated configuration and authentication flow.
What usually happens
All too often, the typical approach here would be to simply do the work in this sprint, despite it having to be squeezed in around higher priority tasks. The allocated story points are low enough to fit within sprint capacity. The task is completed to specification, and the feature works as expected. Everyone is happy.
However, the individual who implemented the feature is now a knowledge silo. Six months down the road a credential rotation is required. The original implementor has moved on to a different team. The current team wasn’t aware of the credential expiration and fumbled trying to make the proper configuration change, causing an incident.
What went wrong? How could this have been avoided?
The learning-focused path
During sprint planning, the new API integration could have been taken into consideration as a new item that the team needs to have collective knowledge about. Additional story points could be allocated to the task to account for both documentation and a team knowledge-sharing session about the API.
This documentation becomes a core part of the project, ensuring that new team members have ready access to the information necessary to maintain and debug this API connection. When the upcoming required credential rotation happens, the team is able to be proactive and prevent the incident.
The key to achieving this result is keeping team knowledge front of mind when making decisions about how work is approached. From that point, the team can establish practices that work best for them to ensure that valuable and necessary learning opportunities are prioritized.
Learning should be part of the goal
It’s a simple hypothesis: if knowledge makes a team better at what they do, cultivating knowledge will result in better output.
The quality of the work that a team produces is largely a function of how well they understand the problem they’re solving and its context. Spending the effort to involve every member of the team in every opportunity to understand the problem, stakeholders, and organizational context will enable better decision-making through the entire delivery process.
It’s not just about the gained knowledge contributing to the work itself, it’s also about individual growth. People want to learn and grow. Giving them the opportunities and permission to do that intentionally as part of their work is empowering. Empowered and intellectually stimulated team members are going to do better work, period.
When making decisions about how to approach various bits of work, take note of what there is to be learned from the task and have a plan for capturing and sharing that knowledge.
Of course, there won’t always be something of major value to be learned, routine work is a thing. But if something important is changing, or something new is being introduced, be intentional with how that knowledge is made available and create space for it to happen.
Create norms and processes
Making this happen means dedicating the necessary time and energy to learning. Figure out what it looks like for learning to be a priority on your team, then start making adjustments in that direction.
Establish team norms of documenting and sharing worthwhile information during the course of work. Have biweekly tech talks to share new concepts or interesting bugs encountered, and encourage people to share them when you notice they’ve taken an interest in something new they’ve encountered.
Slow down to create space
Whenever possible, slow down a bit and focus on gaining and sharing knowledge from your day-to-day work. It’s all too common to feel the pressure of completing work quickly, which can lead to shallow understandings, misguided solutions, and knowledge silos.
Encouraging team members to slow down in order to learn about the problem with intention, thoughtfully craft a solution, and bring along their colleagues for a shared understanding will lead to a more cohesive, effective, and, dare I say, happy team. Not to mention the boost to work quality.
Identify gaps in knowledge
Knowledge silos are a common problem in engineering teams. Often it’s a certain layer of the system or some specific knowledge of the product and its users. It’s inevitable that some members of a team will have more knowledge of certain things than others, but the effect can be minimized with some effort.
Taking steps to minimize this effect doesn’t just save you from the bus factor, it actually improves the team across the board. All new knowledge is additive. This compounding effect is subtle but more powerful than I think people often realize. It will show up in thoughtful comments during code review and more well-informed design discussions.
Collaborate often on documentation
Documentation is also a big part of this story. There’s plenty written about the extra maintenance burden that can come along with documentation, and it’s absolutely true. Not writing documentation is clearly no real remedy though. Instead, regularly groom your documentation. Reword things, make them simpler, delete and consolidate.
Write less, write better, and improve it incrementally. This is a way of creating a focused effort on the written knowledge of the team and ensuring a consistent shared understanding over time.
Balancing learning and doing
Learning is great, but we also have work to do. So as with all things, there must be a balance. There’s no silver bullet here. Each project is different and you will have to figure out what works best for you and your team. I’m simply advocating that, in general, we should focus a bit more on learning in our day-to-day work.
However, learning by doing is often one of the most effective ways of learning. So why not create some structure and culture to maximize those learning opportunities while work is happening? Continuous learning and growing are important aspects of this industry. Organizations and team leads have a responsibility to enable it. Hopefully, this post has provided some ideas on how to make it a reality.
