We’ve all heard it before, it’s simply bad management to put all your proverbial eggs in one basket. What happens when that basket, or in this case, that talented engineer, wins the lottery and sets off for sunny shores with the lion’s share of technical knowledge? There are other aphorisms we can add, some involving buses, but let’s stay positive while ending this confusing cacophony of mixed metaphors.
The point is this: putting all the knowledge of your system, or even part of your system, into a single developer is not a safe way to build software.
While we are fortunate that the teams at Torch have not been prone to high turnover, we like to backup our engineering knowledge in the same way we backup our data. Redundancy here can be a huge advantage. To ensure we have all our bases covered, our team developed the Coverage Heatmap Tool!
Mapping Your Coverage
We built this simple tool, very much a straightforward spreadsheet, to help find both the gaps in knowledge for our engineers, but also the place where there was ultra-focus in one person holding the knowledge. All our major systems and their components were inventoried and our staff took the opportunity to self-assess their skills in each area based on the following scale:
- 0 (None): I have not worked in this area.
- 1 (Beginner): I am set up to work on this, and can do small tasks.
- 2 (Intermediate): I can make significant changes here, but may require some guidance. I mostly understand how this works.
- 3 (Expert): I can make significant changes here, without guidance. I understand this end to end.
For any particular team to avoid risk, they should have at least two level-3 experts. To avoid risk at the departmental or organizational level, there should at least be 2 experts, even if the experts are on different teams. This of course would vary from company to company, but we use it as a rubric for the minimum valuable team overlap at Torch.
To be clear: these metrics and this matrix are NOT used to measure a team’s or organization’s success or performance. This is an insurance plan to say if one expert hits the big numbers in powerball, we can still move forward, build, and innovate while they are signing a large novelty check. Not all risks are created equal, and you may find value in adding applying weights to each component accordingly.
Use the Heatmap to Drive Risk Mitigation
That said, we are mitigating risk while also taking an opportunity to foster growth. The most effective technologists are constantly looking for opportunities to learn and grow. Once filled in, the heatmap doubles as a roadmap for professional growth, at least as far as breadth of experience is concerned. Individuals, teams and departments can strive to turn those red boxes green with greater technical prowess and learning. And for the people skills, there’s always Torch!
Once you’ve identified your hotspots here are some additional tactics that can be adopted as SOP (Standard Operating Procedure):
- Thoughtful PR (pull request) reviews, without rubber stamps (plenty of comments & questions)
- Pair time
- Fostering a “how can I help?” mentality around triage/troubleshooting. Share the load.
- Excellent Documentation (Learn it. Know it. Live it.)
- Knowledge share-outs (We use a standing weekly schedule, recorded and shared)
- Spikes for new features accompanied by an open RFC period (Request for Comments)
- Establish cross-team Focus Area working groups (front end, automation, API design, etc)
- Recurring employee/manager 1:1s (regularly revisiting the heatmap to identify growth opportunities – on a set schedule. Celebrate progress.)
- Flag items in your backlog as “good first issue” to have accessible entry points into parts of your stack
In addition to mitigating risk – this effort also helps to reduce bottlenecks. By spreading knowledge we make it so that more individuals are equipped to contribute to particular efforts.
One final tip – not everyone needs to turn all of their boxes green. If your entire team puts too much focus on learning all-the-things, they’ll likely be spread too thin. Aim for just enough coverage so that individuals can still go deep and become the go-to experts in a few areas. Some call this being T-Shaped, which is a good thing.
Give it a Try
But wait, there’s more! This tool isn’t just for tech teams – it can be applied to any type of knowledge work. Here is an “open source” version of the tool, make a copy and give it a try with your teams!
Head over to our engineering careers page to learn more about how to join the team!
