Every organization I have ever worked with has a Dave.
Dave has been there eleven years. Dave knows why the release process has that one strange step, which client will escalate to the board if you miss a Thursday, how the billing integration actually behaves as opposed to how it is documented, and which of the three environments named "staging" is the real one. Dave is generous with all of it. Ask Dave anything and Dave will tell you, at length, happily.
Dave is also the entire map.
Not part of the map. The map. And when Dave takes two weeks in July, the organization experiences something that feels a great deal like a power cut. And when Dave eventually leaves, which Dave will, an eleven year survey of the terrain walks out of the building inside one person's head, and the next party sets off and discovers the same crevasse, at the same speed, with the same surprise.
We do not call this a failure. We call it tribal knowledge, which is a lovely phrase that means folklore, which is a lovely word that means we never wrote it down.
A map is just a survey somebody did once and had the decency to record, so that nobody has to learn the same terrain the same painful way ever again.
Onboarding is a person, and that is the problem
Here is the shape of the failure, and you will recognize it.
Somebody joins. They are assigned a buddy. The buddy is well meaning and busy. Over six weeks the new hire absorbs, through conversation and osmosis and being sent the same three links, an incomplete and highly personal subset of what the organization knows. Which subset? Whichever one the buddy happens to know and happens to remember to mention.
Two hires, same week, same team, same buddy program. Different buddies. Six months later they know materially different things, and neither of them, nor anyone else, can tell you what the difference is or which pieces are missing. There is no inventory. You cannot audit a folklore.
And then, years on, someone asks the Part 1 question. What would I need to learn to reach the next level? And the honest answer is: nobody knows, because nobody has ever written down what there is to know.
You cannot draw a route across terrain you have never surveyed. Every other thing this series argues for, expectations, measurement, guidance, all of it, sits on top of a map. So we had better make one.
The map has three levels, and that is enough
The instinct, when somebody says "document what we know," is to produce a wiki, which is where knowledge goes to be buried alive with full honors. What is needed is not more documents. It is a structure, small enough to hold in your head, that gives every piece of knowledge a place to live.
Three levels does it.
Knowledge Bases. The big territories of what your organization does. Not departments, not teams. Bodies of practice. Portfolio Management. Discovery. Client Engagement. Execution. DevOps. And the one every organization forgets to name explicitly: the way we do things here, the house method, whatever you call it. Half a dozen to a dozen of these. If you have forty, you have not written a map, you have written a list.
Knowledge Areas. Inside each base, the distinct competencies that make it up. Discovery contains interviews, workshop facilitation, deliverable management, read out. Execution contains requirement management and business modeling. DevOps contains version control and infrastructure as code. These are the regions of the territory, the things a person could plausibly be good at as a unit.
Topics. Inside each area, the specific things. This is the ground level, the place where a person can say "I know this" or "I do not know this" and mean something concrete by it.
That is the entire structure. Bases, areas, topics. It fits on an index card, which is the point, because a knowledge structure nobody can recite is a knowledge structure nobody uses.
The matrix, and why it is worth the tedium
Once you have the hierarchy, you lay each Knowledge Base out as a matrix: the areas and topics down one side, and levels of maturity across the top. What does basic look like in this topic? What does strong look like? What does mastery look like?
I will not pretend this is fun. It is genuinely tedious work, it takes real hours from your most experienced people, and no one has ever received a standing ovation for it. It is also the highest leverage documentation an organization can produce, and I will tell you exactly why.
It converts folklore into inventory. The moment the map exists, you can ask questions that were previously unaskable. Where are we thin? Who else knows the thing Dave knows? If Dave left tomorrow, which cells go dark? That last one is not a hypothetical. It is a risk register, and most organizations are carrying a large one they have never read.
It makes learning navigable. A person can look at the map, see where they are, see where they want to be, and identify the specific terrain between. That is a route. That is the thing my engineer in Part 1 was asking for and I could not give her, because I did not have a map, I had opinions.
It survives people. This is the compounding foundation from Part 1, and it is the same argument I made across the whole Building on Solid Ground series about a single source of truth. An organization that writes down what it learns gets smarter every year. An organization that keeps its knowledge in people resets to zero every time somebody resigns, and then wonders why year eleven feels a lot like year four.
You train the rope team, not the climbers
Now, the part that most organizations get wrong even when they get the map right.
Having drawn the map, the natural next move is to send individuals off to learn things. Courses, certifications, a training budget, a learning platform with nine thousand videos and a completion rate that would embarrass a gym membership. Individual learning, individually consumed, individually forgotten.
But look at how the work actually happens. Nobody delivers software alone. A product manager, an analyst, an engineer, and a DevOps practitioner deliver software together, and the failures are almost never one person's ignorance. They are the seams. The requirement that meant one thing to the analyst and another to the engineer. The release plan that assumed an infrastructure reality nobody validated. Roped climbers do not fall individually. They fall together, at the seam.
So train the seam. Teach the fundamentals of software delivery as a shared body across the whole team: portfolio management, product discovery, coding and testing, infrastructure, with each role going deep in its own lane while everyone shares enough of the neighboring lanes to hand off cleanly. Run it as workshops, team projects, individual exercises, and mentoring, in that mix, because knowledge that has never been used is not knowledge, it is trivia with a certificate.
A team that has walked a practice route together has something no individual training budget can buy: a shared vocabulary, and the knowledge of how the person next to them actually works under load. That is what makes the rope worth anything.
What the map is not
Two warnings, because I have watched both failures happen.
The map is not a competency police force. The instant people believe the matrix exists to catch them being deficient, they will manage their appearance in it, and you will have built an elaborate machine for generating flattering self assessments. The map's job is to describe the territory, not to judge the climbers. That comes later, in Part 4, and it is a different instrument used for a different purpose.
And the map is not finished. Terrain changes. New tools, new practices, new client realities. A map maintained once and never revisited is worse than no map, because people trust it. Someone has to own it, revisit it, and be permitted the time. If that ownership is nobody's job, it is nobody's job, and in eighteen months you will be back to Dave.
Go find your Dave
Here is your homework, and it takes about an hour.
Write down the six to ten bodies of practice your organization actually runs on. Then, for each one, name the person everybody goes to. Now count how many times the same name appears.
Then ask what would happen if that name gave two weeks' notice on Monday. Not emotionally. Operationally. What, specifically, would you lose? Can you name it? Because if you cannot name what you would lose, you have already lost the ability to protect it.
Most organizations run this exercise and go quiet. That silence is the finding. It is also entirely fixable, and it is precisely what GSD's Maturity Assessment is built to surface: where your practice actually lives, who actually holds it, and which parts of your map have never been drawn. Find the gaps first. Then close them.
Next week we get to the part everybody actually wants, which is how you tell whether somebody is getting better. Because a map tells you where the terrain is. It does not tell you how high you have climbed.
For that, you need markers.
Nobody summits alone.
Next in the series, Part 4: "Altitude Markers: A Language for Better."
*Not sure whether your organization's knowledge lives in a map or in a person? GSD's Maturity Assessment is the entry point, a structured look at where your delivery organization really stands, people included, before you invest in closing the gaps.*
Back to Blog