Thanks Unblocked for supporting today’s article!
A very interesting open-source visualization I ran on my team’s repos 2 weeks ago: Unblocked’s Social Graph Builder. It builds a weighted collaboration graph from your team's GitHub PR history - who works with whom, and which parts of the codebase have a single expert vs evenly shared coverage.
It's one of the cool parts they open-sourced from their context engine, which solves the hardest problems in codebase context: conflicts, permissions, freshness, relevance, and cost.
Last week, in a managers’ offsite, I got asked this question: “If you would build your team again today, knowing what you know now, would it look the same?”
I ‘inherited’ my team 9 months ago, and I absolutely love working with them. The strongest team I’ve managed or worked with, and I’d love to work with each of them in any future job.
Still, that prompt made me do one of my favorite management exercises that I haven’t done for the current team yet, charting a ‘knowledge & skills map’.
It’s a pretty simple process that requires a spreadsheet and 15-30 minutes:
You start by defining which skills/knowledge you want to map out. I usually have 3 categories:
Product areas - different parts of your product/systems your team is responsible for
Tech - specific technologies your team uses
Soft skills - things like ownership, mentoring, etc
This time, I added a 4th one:
Non-eng skills - how knowledgeable are we in things outside engineering
Then, you define how you score each category. I went for 3 options - basic, good, and expert. For product areas/tech, I defined it as follows:
Basic - can do with Claude, but won’t know to push back.
Good - will know to guide Claude to the right parts, and can work solo on new additions.
Expert - fully knowledgeable and the one defining our standards.
Here are my results. I changed the 4 product areas and all names but mine, everything else is the same:
Let’s go deeper into each section:
Product areas
The scope of your team is growing bigger and bigger, and most of us are spread much thinner than in past years. This means it’s more critical than ever to make sure we have true experts in the product areas we work in.
Someone who doesn’t really understand an area can get very far with Claude, and it’ll look like great work, but only an expert will be able actually to tell if it’s in the right direction. That’s how the "I don't know, Claude wrote this" pandemic gets spread.
We had multiple cases where teams worked in domains outside their own, implementing what seemed like a good solution, which ended up harming customers.
As you see, I have ‘basic’ across all of them, as we moved to a greenfield project soon after I joined (while still supporting the existing areas). Not an ideal place to be, but at least we have a couple of experts in each.
Tech
It’s the same deal as in the product areas.
Every engineer with Claude can do an ok job when working with Kafka, MongoDB, or Temporal, but only those who actually have the knowledge will be able to guide toward the best solutions.
MongoDB is a good example - we have a few people with ‘good’, but no experts. For now it’s ok, but if we need to do something a bit more complex with the database, I’ll probably want to bring someone more knowledgeable to hear their opinion.
Core skills
Every time I do this exercise, I write down different skills, based on what my company values at the moment and what I feel is relevant:
Ownership & Agency
Curiosity
Claude code Judgement (how much do you challenge what you get)
self sufficiency
Collaboration
Leveraging AI
Scoping/focus
Prioritization
My main takeaway is that we can improve as a team in scoping, focus, and prioritization. As we have more and more responsibility to actually make product decisions, those skills become critical.
Non-eng skills
This section is currently mostly relevant for very small startups, or when working on greenfield projects. As my team tries to build a ‘startup inside a startup’, we touch almost all of those worlds:
Design
Copy
GTM
Ideation
Data/metrics
User research
Specifically in the user research part, all of us will start to have customer conversations soon, which is quite a new skill to learn for those who have never done it before.
What to do with this map?
Like any good map, it can help you plan what’s the best path to your destination.
I’ve used it in 2 main ways:
In 1:1 with your engineers. Share your categories and rating definitions, and ask them to fill in their own values. Then discuss the differences.
Analyze the skills/knowledge you lack in your team. Then you can either train for it, or hire for it (or just be aware it’s lacking).
Adding the team interactions map
A 2nd (shorter) exercise I did this time is to run the social builder graph on my team’s repos. The result let me see who tends to collaborate with whom.
My interesting patterns were:
The 2 most experienced engineers tended to work together (team 6).
I tend to work with the 2 least experienced engineers on the team.
I already knew we need some more knowledge sharing and mentoring, but the data gave me a nice story to discuss with the experienced engineers.
It was made by Unblocked, who sponsored this article, but this mention is not part of the deal - it’s just me actually finding that tool useful.
Final words
The point of both exercises is to have better data and context on how your team works, and what might be their needs.
Coming back to the question: “If you rebuild your team again today, knowing what you know now, would it look the same?”
For me, the answer is yes. I feel the skills of the engineers complement each other, the team is not too big, and the dynamics are great.
What I enjoyed reading this week:
Generated and suppressed demand. A great addition to the theory of struggling teams Will Larson covered 8 years ago. On how a team that overcame technical debt and started innovating falls back behind.
Why stepping in to improve things is always wrong. I wouldn’t go as far as to say it’s always wrong, but an interesting take on well-intentioned managers.
The Best Advice You’ll Get Is the Advice You’ve Already Heard. This one really resonated with me: “Every time I sat down to write something, I’d ask myself the same question: Is this original? Has anyone said this before? I wanted my advice to stand out - some fresh insight nobody else had stumbled onto.”
Loved the conclusion, as it gives me reason to continue writing about things I know most of already heard before.
