S2E4 - How to handle knowledge gaps on your development team - P1
Season 2, Episode 4.
Listen here
Show Notes:
This is part 1 of a 3-part mini-series on handling knowledge-gaps on your development team.
When you really REALLY deep dive into the issues that plague your team, the root cause will nearly always raise it’s many heads as the horrible hydra of Knowledge Gaps.
In this episode we’re going to discuss their 3 types, before talking about how to tackle them in Parts 2 and 3!
Show Script:
This is part 1 of a 3 part min-series on handling knowledge gaps on a development team.
Whether you’re an Engineering manager, Lead, Senior or honestly just any level of Developer; knowing the issues teams face can help you actively work to avoid them. Issues can come down to company culture, interpersonal issues, communication problems and team experience, and there’s a myriad of rabbit-holes you can dive down there. In my experience though, when you really REALLY deep dive into the issues that plague your team, the root cause will nearly always raise it’s many heads as the horrible hydra of Knowledge Gaps.
Today we’re going to discuss knowledge gaps and their 3 types, and in episodes 2 and 3 of this mini-series, we’ll talk about ways to mitigate them, and ensure you won’t be hit by them.
Well it's natural to have different levels of knowledge and specialisation of the team especially given that you have developers with different years experience, different types of experience and they will come from different paths. So maybe they have a degree, versus they went to boot camp, or they are self taught (all of which are totally valid by the way) but it's natural to have a difference in abilities and knowledge through the individual members.
The issue here is that when there's holes in the knowledge in regards to things that they really should know. These holes fall into 3 categories:
Framework and Tooling
Problem Domain
Roles and Responsibilities.
1. Framework and Tooling
The first is framework and tooling. You may have developers on your team who might not actually know the full extent of what their chosen language, framework or tooling can actually do for them. This can lead to
a lot of really awful reinventing of the wheel
very confusing or duplicate code
very poor performing solutions
and an awful lot of expense later on because
A) That code will have to go through the code review process in multiple passes and what happens is that a senior or staff level engineer will need to waste a significant amount of time trying to instruct developers on things that they really should already know.
B) that code will inevitably end up being refactored or rewritten; that's a significant amount of developer hours lost.
2. Product Domain
The next type of knowledge gap can be the product domain. Now issues stemming from this type of gap can be extremely expensive to find and diagnose.
So to give an example: if you are a Fintech team and you have a member who doesn't know how to effectively implement audit trails, or is doing something really silly like using floating point math for their calculations - that’s not a great position to be in.
Likewise if you're working in Marketing and you have a team-member in Europe that has no idea about GDPR - that can result in all sorts of trouble.
The issue with this kind of knowledge gap is that the problems are often not discovered until well after a solution is deployed. What typically happens is that your client finds an issue despite all of the testing, or worse one of their clients finds the issue. This results in an awful lot of backtracking, running through emails, checking commits, finger pointing, blaming, and just an all-round horrible rigmarole that you really don't want to go through. Even if there's no direct financial implication, in terms of fines or fiscal loss; for your clients there is often a massive goodwill hit, and that can be almost impossible to recover from. If a client doesn't trust your deliveries or your output, then that can be the death knell for what might actually be a really great team that just should have been trained better.
3. Roles and Responsibilities
The third and final kind of knowledge gap is within the team, and its every individual members’ duties, roles and responsibilities.You may have mid level developers on your team who are not contributing to documentation, comments and diagrams, etc because they don't know that they have to. They were never explicitly told. You as a lead, or your staff or senior engineers might not have the time to constantly check-in to see what everybody is doing. There may be a correct expectation that your mid level developers should be writing docs as they're going - that's part of the development process, even if that's not as closely scrutinized as the software part. It can be a blow to discover this hasn’t been happening, and usually is only discovered at the worst moment.
Likewise you may have staff or senior level engineers on your team who were not actively mentoring your juniors or mids because they haven't been explicitly told it's part of their job.This means that they're not making time for this task, and this often flies under the radar because the time they should be mentoring people is being used for active development - and nobody is going to question if a high performing senior dev should direct their attention elsewhere.
Now, you may run or by on a team that has high velocity of deliverability, and at a first glance you don’t see these problems, or don’t give them credence. This is extremely common in dev teams in SMB or teams with a ‘Start-up’ mindset. I want to offer a warning here that every team I’ve either seen or been on where these were not taken seriously has always gotten a heavy smack from reality, at the worst possible moment. It’s the stuff that staff will actively leave over, and you don’t want to be the one left holding the bag.
It’s not all doom and gloom though! In the next 2 episodes we’ll discuss how to remove all those pesky knowledge gaps, and to supercharge your team’s ability to both deliver quickly and in confidence! Don’t miss out!