Season 2, Episode 5.
Listen here

Show Notes:

This is part 2 of a 3-part mini-series on handling knowledge-gaps on your development team.

So last time round we went through the 3 types of knowledge gaps a Development team can face, and how each one can be quite a pain in the butt!
Now that we’ve identified the problem, we can solve it…

In today’s episode we’ll talk about preliminary actions you can take to mitigate Knowledge Gaps.

---

Show Script:

This is part 2 of 3 in our min-series about dealing with Knowledge Gaps on your Development team.

So last time round we went through the 3 types of knowledge gaps a Development team can face, and how each one can be quite a pain in the butt! Now that we’ve identified the problem, we can solve it…

Today, we’re going to start talking about solutions to these issues, and how to get your team I’m going to categorise these tactics based on two types:

1. There are Preliminary actions you can take, which we’ll discuss in today’s episode.

2. There are also Continuous actions you can take, and we’ll discuss those the next day.

Let’s roll through the preliminary actions!

Tactic 1: Formal Job Descriptions

It's something I rarely see done correctly in companies but can make a huge difference. It effectively sets expectations clearly and allows you and your team members to understand their roles, duties and responsibilities, without doubt. Before you get to the stage of writing those descriptions though you need to categorize your team type and the contributors within.

Org development is a skill! My recommendation would be to categorize your developers into only three or four levels and to standardize the titles and roles.

So what do I mean by that? If you have multiple titles defined in your team like “Web applications developer”, “Full stack developer”, “Software engineer” and “JavaScript programmer” all in the same team, then you're doing it very wrong. Instead, you should use obvious, cascading terms like:

• Staff engineer

• Senior engineer

• Mid level Developer (or just Developer) and finally

• Junior Developer.

I highly recommend against using generic or level names like

• Developer2

• Engineer3

• L4

• Etc..

I promise you that outside the Bay Area bubble that nobody will understand or entertain these titles.

Once you have your categorization or classification clear, the next part is to write the roles’ duties and responsibilities. My advice here is that they should be value-add or progressive, so that each role level builds upon the next. For example, a mid level developer should have all of the roles and responsibilities of a junior level developer, but then also some of their own. A senior level developer should have all of the roles and responsibilities of both the mid and junior developers, but then also some of their own.

It's important to not be too vague here. The idea is to have a very formalized, clear list that you can point to, without ambiguity, to show the strength of how they are engaging with their role. Having these described in this way allows you to accurately track if you or your reports fulfil them. It also makes it easy to either encourage or redirect team-members performance in their 1-1s, and quarterly/yearly performance meetings and compensation reviews.

I would also advise making these “public-knowledge” within the team, insofar that everybody has a crystal clear idea of what each team member needs to do or achieve in order to qualify to progress to the next level.

Tactic 2: Developer Roadmap

The next tactic or tip is to put together a developer road map for the team. If you have a developer road map, this then serves as a clear baseline of knowledge for the team. You’re effectively defining the minimum standard for what everybody should know.

What I love about these is that you can sit down with each individual team member and just ask them directly if there's anything on the road map that they are not familiar with. If there are any gaps, it's quite easy to walk through these with your individual contributors during their weekly 1-1s, performance reviews, etc. and guide them. You can put together a list of links, articles, tutorials, etc. ahead of time and share them as required.

I'm of the opinion that pretty much every team member should be able to act on almost any task on the systems and projects that your team owns. Now this would be with the exception of hyper-specialized stuff like security, cryptography, authentication or authorization and this is where your senior and staff engineers should have specific competencies.

This can help with shortfalls, pivots, and taking advantage of new opportunities later on. Imagine you’re working on a V2 of your platform in parallel to your existing offering. Just because a developer isn't on the shiny V2 project now, doesn't mean that they shouldn't know about the shiny V2 technology. They'll be put under V2 project eventually and at that stage they most likely will not have the time to both up-scale on the new V2 code architecture, as well the changes in the language, framework or tooling that were used for the V2 Implementation at the same time.

I think it's fair to say if they are a serious developer it's not unreasonable to expect them to learn and upskill at will in their own time in order to stay relevant in their field. Do be very careful here though as you don't want to put too much on them, and disturb their work life balance. This will have the complete opposite effect!

Following on from that, you want your developer road map to accurately reflect the tools and technologies that your team uses day-to-day. It should not include everything and the kitchen sink. If your team does not do a ton of graph-based work then it doesn't make sense to include tree-traversal algorithms and tools as part of what they are required to know.

Tying back into the formal job descriptions, I would recommend having a single map for the whole team. You can then color-code topics based on the minimum developer level that should know that topic. You should also approach this in a progressive or value-add manner.

One last benefit of having a clear road map means it's obvious the scope of what your team does. If you have a team member that's suddenly decides to branch off into learning data science or machine learning, then you will have a clear picture if this can fit in with your teams competencies. You can then make the decision to either nurture this new branch of learning, or have them reassigned to another team or project where these skills would be more of use.

Counter argument

Now there's a common rebuttal that I come across when I explain these tactics to people and that is that it seems like an awful lot of management overhead.

Having been in teams that don't implement these measures, and also being both part-of and directly leading teams that do implement these measures - I can safely say that doing things right in the first place is significantly less stress and work than the constant fire fighting, politics, and less-than-pleasant client interactions when things go wrong. A stitch in time saves 9!

You find that once you get set up you don't actually need to do an awful lot of active maintenance on these two resources for your team. They'll also make 1-1s, check-ins, reviews, etc. much easier to handle as there is a well defined yardstick to measure against.

Summary

So today we've covered the preliminary work you can do to help fill in knowledge gaps within your team with that you should have a clear path for both yourself and your team on the level they should be at, and how they progress.

Next time we’ll take it one step further and talk about continuous actions that you and your team can take that will help you cover potholes that haven’t been paved over by everything that we’ve just discussed. Its going to be an epic conclusion so don’t miss out!