Season 2, Episode 6.
Listen here

Show Notes:

The epic conclusion is here! This is part 3 of 3 in our mini-series about dealing with Knowledge Gaps on your Development team.

We previously talked about how Knowledge gaps can be the silent killer about your delivery team speed, the quality of their output and of course the trust your clients have in you to deliver promised solutions.

In today’s episode we’ll build upon the last, and talk about continuous actions you can take to mitigate Knowledge Gaps.

Show Script:

The epic conclusion is here! This is part 3 of 3 in our mini-series about dealing with Knowledge Gaps on your Development team. 

We previously talked about how Knowledge gaps can be the silent killer about your delivery team speed, the quality of their output and of course the trust your clients have in you to deliver promised solutions. We talked about how falling foul of these can be quite expensive (both in time and in financial value) for a team to deal with.

In the last episode, we covered two sets of preliminary actions that you can take in order to start erasing knowledge gaps on your team. 

As a smart team lead or a strong individual contributor who now has these two strategies in place  you and your team are ready to progress onto l what I like to call the continuous actions. These help maintain a culture of knowledge sharing and continuous learning within your team.

There are three continuous actions you can take to promote this kind of culture. These are:

• Regular host knowledge sharing sessions.

• Frequently present what items were corrected as part of code reviews 

• Put in place shared projects in your Version Control System for Proof-of-concepts, one-off applications and test-bed console applications.

Let's dive into these now, and then we can review how all of these tactics tie together.
Let's go!

Continuous Tactic 1:  Knowledge sharing sessions.

The most successful software teams that I’ve seen hold frequent knowledge sharing sessions. Basically, all of the developers on the team together for an hour, and individual members (regardless of their level) take turns presenting topics. These can be:

• New techniques or patterns they’ve learned

• Cool personal projects they’re working on

• Discussion of new libraries, frameworks that have been announced

• Changes required due to upcoming legal or process changes related to the problem domain

• Or even just show-and-tell of a new feature they’ve made for your products or platform.

These sessions should be ruthlessly for the development team only, as it allows the content to be heavily tech focused. They can be railroaded by having non-tech or high-level management sit-in and this massively detracts from their usefulness. These should be high-tech sessions for sparring, discussion and group dissemination. There should be questions, banter and heckling. Discussion here should encourage critical thinking, and be a sort of ‘soft’ mentorship and cultural enrichment for the team.

There’s 2 items I’d recommend here to make these sessions worthwhile.

The first is that these are time expensive. Having all the developers on your team not actively participating in development means there is a cost to these meetings. Take them seriously and make them count! Individual presenters may have to do some research or put together some slides, etc… - take note of this and be mindful of it when assigning them tasks or tickets. Heck, it could even be one of their tickets for this sprint. Don’t half-ass these sessions. They pay dividends down the line!

The second is that participation is mandatory. If no-one has volunteered to present a topic at the next Session, then devs should be “voluntold” to present on a random, rota basis. If they can’t think of anything to present, well you can refer back to the Developer Roadmap from the previous episode. What’s a consistent weak-point for the team, or what is this particular person yet to cover? This now becomes a golden learning opportunity for them and the rest of the team.

On a final note, these should be recorded, but again only made available for the development team. Being able to point new joiners to specific sessions relative to technical or business decisions will literally half your on-boarding process and actively speed up the time it takes to get productive.

These sessions will also help developer the public-speaking and presentation

Continuous Tactic 2:  Code Review Presentations

The code that is seen during your PRs/Code review process and the corrections applied, need to be shared with the whole team. It’s not worth covering every little change, but it is worth covering the major ones. You can use the aforementioned knowledge sharing sessions, or even your sprint retros to cover items. 

Bad patterns rarely happen in isolation, and it’s a good bet that what was seen there is also to be found somewhere else in your codebase. Even if not, it's definitely worth weeding out bad patterns, practise or inefficient code before it hits the main codebase and becomes the defacto pattern. Implementations are usually discussed before implementation, and if you’re seeing frequent bad modules or methods it's definitely worth educating at a team level the right way to do things.

Be cautious here though, as the point isn’t to rake developers across the coal - its to educate the rest of the team. If possible, it's worth presenting them in a general or anonymous sense.

This means teammates won’t feel picked on, or embarrassed. Maintaining a positive sharing culture is of paramount importance.

Continuous Tactic 3:  Shared POC/Scratch Project in VCS

The final tactic I’d like to share is having Shared POC or Scratch projects in your Version Control. Many devs start a new project or feature with a crappy proof of concept or command line application just to test the theory. Especially so in the case of testing interacting with 3rd party libraries and APIs.

I’ve seen great success with having shared scratch projects in VersionControl, so other devs can see use case or ideas without being blindsided by the implementation in the full platform or product. 

Don’t discount the value of these scratch projects, as an overlooked configuration option or seemingly innocuous method call can often be missed when applying a new library, technique or integration at scale. Having a piddly example to refer back to can often save bucket loads of wasted debugging time.

Keeping a paired up-to-date list of these Console apps and POCs in your documentation like confluence etc… is also a great idea. It means you can quickly fire links when developers are coming across something that you know is new for them, or they can independently look items up as they’re working through tickets and tasks.

Summary

It’s easy to see how these tactics built upon each other, and how the output of one can become the input of the other. Regardless of the priority you give to each individual technic, the important thing is to continuously attempt to influence your team's culture to be one of sharing and kaizen, or continuous improvement.

Knowledge gap issues can be almost completely avoided with a little care and attention; and given the risk and expense of ignoring them - it’s a no brainer to use these tactics!

And with that, we finish our 3 part series. I hope you’ve enjoyed listening to them as much as I enjoyed making them!