My team has worked with the same product team for the past three and a half years. In that time, we have worked closely with the client developers to facilitate product requirement definition and to develop features rapidly while championing code quality.
While it’s great to have such a solid and trusting partnership with the client development team, it’s also important that we help encourage the client developers to build those same skills and become stronger contributors. This is an important goal: reliance on only a few key individual contributors can cause a serious bottleneck in team productivity and may lead to burnout for those individuals. And, it helps build everyone’s confidence that the product will find long-term success even after our team disengages.
After two and a half years of working with this team, I was finally scheduled to rotate off of the team. So, we used this major team transition as an excuse to help us start brainstorming a plan for knowledge transfer. Here, I’ll walk through the process we followed to help kick-start this knowledge transfer process.
Identify areas where expertise is needed.
To start brainstorming what kinds of skills needed to be built, the team posed the following question to me: When people reach out to you, what things do people typically need help with?
Then, from that initial list, we grouped these into related categories. In turn, that helped us determine top priority areas for skill building. For our team, we identified the following buckets and brainstormed action items to address the following concerns:
- Unblocking Development. Can team members troubleshoot build errors, failing tests, or deployment issues? Are they willing to?
- Feature Ownership. Do developers understand the requirements? Are all developers engaged in the story writing, refinement, and estimation process?
- Technical Best Practices. Is the team adhering to technical best practices around code review, the use of types, writing tests, etc.? Do they encourage other newer devs to do the same?
Plan knowledge transfer activities.
After identifying our focus areas, we scheduled a handful of knowledge transfer sessions over the past few months. We ran an overview of the team’s CI/CD and release process to try to help make sure that devs had a better understanding of the various continuous improvement pipelines in place. We scheduled a few sessions to introduce test-driven development to the team. And, the team has an upcoming session to revise team working agreements with links to resources explaining language and development best practices.
Schedule recurring check-ins
Still, most, if not all, of these skills are built through practice over time, rather than one-off intro sessions. Unfortunately, we often failed to encourage skill-building behavior. We jumped in to review PRs and fix emergent issues, rather than forcing client developers to share this responsibility with us. We needed to keep ourselves accountable to the goals of, say, encouraging devs to do more code reviews or troubleshooting their own issues. So, our team’s delivery lead scheduled weekly check-ins to review our goals.
Review lessons learned.
This type of knowledge transfer is different than the typical knowledge transfer activities we schedule when handing off a project and completely ending an engagement. We could have made sure the team had just enough skill to keep the project afloat until we could return for another round of maintenance and small enhancements. But, our goal was long-term, sustainable success, with or without the Atomic team.
Developing these skills is a long and slow process (especially when there is limited availability to pair regularly). For our team, there is still a long way to go, and, along the way, we encountered some challenges.
It was difficult to intentionally disengage and make ourselves less helpful. Atomic hires for engaged and proactive individuals who value shared team responsibility. So, to not jump in and help whenever anyone cried for help took a bit of discipline. And, it can be a tricky balance to strike between backing off while not entirely abandoning the team.
And finally, it was also challenging to build confidence. I’ve had countless calls where a client dev would ask me, “Is this okay?” only for me to immediately respond, “Yep, seems perfectly reasonable to me.” While it’s flattering that they trust and value our opinions so much, it’s also important to radiate trust and approval back once devs have demonstrated the skills you’ve been trying to build.