Rohan Ranade

When I take on managing a new engineering team, whether by inheriting an existing one or hiring from scratch, one of the first things I do is create a Team Knowledge Density document. This document helps me understand how knowledge is distributed across the team, identify areas where expertise is siloed, and take action to mitigate risks. Over the years, it has proven to be one of my most effective tools for setting up teams for success.

Why I Created This Document

I started using this approach after a key engineer left one of my teams shortly after I joined. Their departure left behind a knowledge gap that was difficult to identify and address in real time. Since then, I’ve made it a practice to proactively map out the team’s knowledge areas early on, so that I can take action before such gaps become critical issues.

What the Document Captures

The Team Knowledge Density document is a structured record of:

1. Key knowledge areas in the team’s primary domain that the team needs to deliver.

2. Individual knowledge levels in each area, categorized as:

   • Newcomer – No prior experience in the area
   • Competent – Some familiarity but needs support for larger tasks
   • Expert – Deep knowledge, capable of handling tasks independently and strategically

3. Connected domains – Areas owned by other teams but important for cross-team collaboration (e.g., APIs, services, or dependencies that the team relies on)

This document is typically maintained as a shared table where each row represents a knowledge area, and each engineer self-assesses their proficiency level.

---

An Example: The Knowledge Density Document in Action

To illustrate, let’s consider a hypothetical Payments Engineering Team responsible for payment processing, fraud detection, and transaction reconciliation.

Primary Knowledge Areas

Connected Knowledge Areas

---

Looking at the example above, a few key insights stand out:

1. Knowledge Silos – Alice is the only expert in Payment Gateway integration and Refund & Dispute Handling. This presents a risk—if Alice is unavailable, the team may struggle to maintain these critical systems.

2. Gaps in Connected Domains – Bank Compliance is a key area that the team interacts with, yet multiple engineers are newcomers in this space. This could slow down work that interfaces with this area.

3. Opportunities for Knowledge Sharing – Diana has expert knowledge in ledger reconciliation. This is a great opportunity for them to mentor others and spread knowledge in this space.

With this information, I can now take action to close these gaps.

How I Build and Maintain This Document

1. Interviewing Engineers – When I join a new team, I first interview engineers to identify key knowledge areas based on the team’s charter.

2. Self-Assessments – Each engineer assesses their knowledge level for these areas.

3. Quarterly Updates – I revisit the document every quarter, updating it based on my observations and validating changes in 1:1s.

Once the document is in place, it becomes an actionable tool rather than just a static reference. I use it to:

• Close Knowledge Silos – If only one person is an expert in a critical area, I find opportunities for others to work on projects in that space or arrange knowledge-sharing sessions.
• Create Development Goals – New team members can use this document to identify areas to ramp up on.
• Advocate for Team Growth – In one case, the document revealed that the team was responsible for too many knowledge areas, helping me make a case for additional headcount and splitting the team into two.
• Prioritize Learning Investments – When I discovered that no one on the team had expertise in certain parts of the codebase, I used this document to align with my product counterpart and carve out roadmap time for engineers to learn and build knowledge.

A document like this requires careful communication. I always clarify upfront that this is not a performance review tool — it’s a way to help the team succeed, which in turn supports each individual’s success. I also keep the document public within the team, so engineers know who to reach out to when they need help on specific topics, especially in urgent situations.

If you want to do this in your team…

If you want to implement a similar approach for your team, here’s what I recommend:

1. Involve the team in building it – Let engineers contribute to defining knowledge areas and self-assessing their expertise.

2. Frame it as a tool for team success – Set clear expectations that this is not a performance evaluation, but rather a way to identify opportunities for growth and reduce risk.

3. Use it to drive meaningful action – Don’t just create the document — use it to plan knowledge sharing, advocate for team resources, and ensure resilience in critical areas.

By consistently using this document, I’ve been able to proactively strengthen teams, improve collaboration, and create a more resilient engineering organization. I hope this tool helps you achieve the same for your teams!