# Skillforests Method Guide

The Skillforests method — concepts, structures, and the practices built on them. Draft generated from the method repo.

# The Skillforests method

# What Skillforests is

Skillforests is a way of managing skills that borrows its best idea from video games: the skill tree. Instead of job descriptions full of adjectives and reviews full of vibes, every role gets a **forest** — a living map of all the skills that role needs, how they connect, and the order in which they're learned.

A forest is made of **trees** (areas of knowledge, like "Testing" or "Styling"), trees are made of **skills**, and every skill is something concrete you either hold or don't — at a level you can name. Look at someone's forest and you can see where they stand, what they can take on next, and exactly what the next promotion requires.

Three things make it different from the competency frameworks you may have met before:

- **It's team-specific.** The trees are built *with* the team doing the work, not downloaded from a generic framework. A map of the work you actually do beats a map of work in general.
- **It's collaborative.** Building and maintaining a forest is a shared activity, and that's part of the point — the conversations are as valuable as the map.
- **It's honest by design.** Levels are defined so concretely that placing yourself doesn't require guessing, and the whole method leans on keeping that placement truthful.

And you don't need software to start. The method has been run for years on paper, sticky notes, and wall charts. The map matters more than the medium.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-01-01.png)

# Where it comes from

In early 2020, the question was simple: professional competencies relate to each other in complex ways — could those relations be drawn as a graph that's actually easy to understand?

Games had already solved this. Path of Exile, the Diablo series, Skyrim — all of them present sprawling systems of skills and experience to players through some version of a **skill tree**, and players navigate them without a manual. You see where you are, what's unlocked, what's next, and what it costs. Nobody writes a self-assessment essay to level up.

The move Skillforests makes is taking that presentation layer and pointing it at real professional competencies. Two convictions shaped how:

- **Trees should be team-specific.** A generic "front-end developer framework" fits nobody exactly. A tree built around the work one team actually does fits like a glove — so the method builds trees per team, not per industry.
- **Trees should be built collaboratively.** With a background in Design Thinking, the natural way to build them was together — workshops where the team maps its own work into skills and trees. People trust a map they helped draw.

The method ran for years on paper before it was ever software — growing real teams from a handful of people to a department. The forest metaphor stuck because it earned its keep: skills grow, trees have roots, and a healthy forest needs tending.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-01-02.png)

# The problems it solves

Most organisations manage skills through a fog. The information exists — in people's heads, scattered across CVs and review documents — but nobody can *see* it. The forest replaces the fog with a map, and a few chronic problems dissolve on contact.

**Reviews made of adjectives.** "Shows real growth." "Strong performer." Nobody can compare that year over year, and both sides of the table know it. With a forest, a review reads "moved three skills to confident, holds the mid-rank set" — concrete, comparable, and visible to both sides before the meeting starts.

**Promotions without a bar.** "Is she ready for senior?" is a debate when senior is a feeling. When a rank is a defined set of skills at defined levels, readiness is something you check, not argue about — and the person can see the exact shape of their next step all year long.

**Invisible gaps and single points of failure.** The skill only one person holds is invisible right up until that person is on leave, busy, or gone. A forest shows coverage at a glance: which skills are thin, which have one owner, where the next project will hit a wall.

**Hiring by buzzword.** Job ads list technologies; interviews probe vibes. A forest defines an opening by what a hire must actually walk in knowing (the roots and entry rank) versus what the role will teach them — a sharper filter for everyone, including the candidate.

**Learning without direction.** "I should learn more" is a mood, not a plan. A forest turns it into an ordered path: these skills, in this order, a few at a time.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-01-03.png)

# How to read this book

The book has two parts, and the split is deliberate.

**Part I (chapters 1–6) is the shared foundation.** It defines the building blocks — skills, levels, trees, roots, forests, ranks — and the two disciplines that keep a forest trustworthy: honest assessment and regular upkeep. Everyone should read Part I, whatever their role. It's short, and every later chapter leans on it instead of re-explaining terms.

**Part II (chapters 7–10) is one chapter per way of using the method.** Read the one that matches your seat; skim the others to understand what the people around you are doing with the same map.

| If you are… | Read | You'll use the forest to… |
|---|---|---|
| Growing your own career | Chapter 7 | See where you stand and pick your next skills, in order |
| Leading a team | Chapter 8 | Read coverage, gaps, and risks; plan growth and hiring |
| Coaching or training people | Chapter 9 | Baseline each person, find the gap, guide the path |
| Running HR or leadership | Chapter 10 | Tie ranks to reviews and pay; report and plan org-wide |

A **glossary** at the back holds every term in one place, for the moments you need a quick reminder rather than a chapter.

One reading tip: the method is simpler than a book-length treatment makes it look. Skills connect to skills; trees group them; forests group trees; ranks slice forests by seniority. Everything else is practice and discipline. If you ever feel lost, come back to that sentence.

# Skills

# The skill as building block

Everything in a forest is made of **skills**. A skill is one concrete ability: something you can do, demonstrate, and — crucially — name precisely.

Precision is the whole game. "I know marketing" tells you nothing; it's a continent, not a skill. But break it down and suddenly you have a plan:

- social-media posting — *confident*
- SEO basics — *beginner*
- email campaigns — *don't have it yet*

That's the test of a well-cut skill: you can honestly say whether you hold it, and at what level, without writing an essay. If the answer is "well, it depends on which part," the skill is too big and wants splitting. If the answer is a plain yes or no with nothing in between, it's a small skill — and that's fine too, the method has a place for those.

Skills are also where **connections** live. A skill can require other skills before it (its prerequisites) and can unlock many skills after it. Those links are what turn a pile of abilities into a map with paths through it — but that's the next page.

For now, the one habit to build: whenever you catch yourself or anyone else using a continent-word — "marketing," "leadership," "React" — ask *which part, specifically?* The answers are the skills.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-02-01.png)

# Prerequisites

A **prerequisite** is a skill you need before another skill becomes learnable. You can't write media queries before you know CSS basics; you can't run an email campaign before you can write one email. Prerequisites are how the forest knows the *order* of things — they're the arrows on the map.

Two rules make prerequisites work, and both are about defining things once.

**Prerequisites live on the skill itself.** They're defined once, at the organisation level — not inside any particular tree. A tree only *shows* a grouping of skills; the connections between those skills already exist on the skills themselves. So if two connected skills are both pulled into a tree, they arrive already linked. Define the connection once, and every tree that ever shows those skills agrees about it.

**No double-linking.** If B depends on A, and C depends on B, then C connects through B — never *also* directly back to A. The chain A → B → C already says everything; an extra A → C arrow adds clutter without adding information. Keeping chains clean is what keeps a tree readable at a glance.

A skill can have several prerequisites and can unlock many skills — chains branch and merge. That's normal and healthy; it's what makes the map look like a tree instead of a ladder.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-02-02.png)

# Two kinds of skill

Every skill in a forest is one of exactly two kinds. The split answers a simple question: *is there anything meaningful to grade?*

**No-level skills (yes/no).** Some abilities are small enough that you either know them or you don't. Media queries are the classic example: once you can write them, there's no interesting difference between a "beginner" and an "expert" at media queries. Grading it would be theatre. These skills are a plain checkbox — you hold it or you don't.

**Three-level skills.** Bigger abilities are worth growing *through*. These carry three levels — **beginner**, **confident**, and **expert** — and the levels behave like rungs: each one is a prerequisite of the next. You pass through beginner on the way to confident, always. In a tree, each level is treated as its own skill, which is why you'll see names like "React I" and "React II" sitting one above the other.

How to choose the kind when cutting a new skill:

- If progressing through it would take a month or more of real work, it's three-level.
- If there's nothing between "can't" and "can," it's no-level.
- When genuinely unsure, make it three-level — a level that turns out unnecessary is easier to live with than a checkbox hiding real depth.

The next page defines what the three levels actually mean, because the method leans hard on those definitions being concrete.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-02-03.png)

# The three levels

The three levels are the load-bearing definitions of the whole method — everything from self-assessment to promotion runs through them. They're written so you can place yourself without guessing.

**Beginner.** You know the basics — say, right after an online course or a book. You *can* do it, but you need help or a lot of documentation along the way.

**Confident.** You have hands-on experience. You do most tasks and deliver on your own, reaching for docs or help only on the less common parts.

**Expert.** You have considerable experience. You handle almost everything without help, looking things up only for the obscure or uncommon cases. A useful framing: an expert is *confident enough to teach others*.

Two footnotes that matter more than they look:

**Even experts look things up.** Skills evolve; needing materials or research at any level is normal and expected. "Expert" never means "memorised everything" — that bar would be both impossible and pointless.

**The invisible zero.** Under the hood, a skill is stored at level 0, 1, 2, or 3 — where **0 simply means "no level"** (a yes/no skill). It is *not* a secret rung below beginner, and it's never shown to people. Humans only ever see beginner / confident / expert, or a plain yes/no.

One cultural note: the level *names* can be adapted. "Beginner / confident / expert" travels well across cultures precisely because the steps are broad; finer gradations (five-point scales, percentage mastery) tend to spark debates the method is designed to avoid. If the words don't fit your culture, change the words — keep the three broad steps.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-02-04.png)

# Granularity — how big is a skill?

Cut skills too big and people stall on them for a year; too small and the forest becomes confetti. The method uses a single rule of thumb:

**Progressing a skill by one step should take roughly a month, up to about three.**

That's the whole rule. It gives you two tests:

- **Too big?** If moving a skill up one level reliably takes more than ~3 months, split it into smaller skills. A skill that stalls for a quarter isn't teaching anyone anything — it's just sitting there being discouraging.
- **Too small?** If there's nothing meaningful to grade — you either know it or you don't — don't force levels onto it. Make it a **no-level (yes/no)** skill and move on.

**When in doubt, aim bigger.** A broad skill has a natural escape hatch: it gets separated into levels, and each level behaves like its own step. An over-split skill has no such rescue — you just end up with twelve checkboxes where one honest skill should be.

The month-to-three-months window isn't arbitrary. It matches the method's rhythm elsewhere: individual progress is reviewed roughly monthly, so a well-cut skill visibly moves within one or two check-ins. Progress you can *see* on that cadence is what keeps people engaged; a map where nothing ever changes is a map people stop reading.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-02-05.png)

# Trees

# Trees as areas of knowledge

A **tree** is a scope of view over a connected group of skills — an *area of knowledge* that forms a logical part of a larger whole.

Take a front-end developer. Their full role covers a lot of ground, but the ground has natural regions: **Testing**, **Frameworks**, **JavaScript/TypeScript**, **Styling/CSS**. Each of those regions becomes a tree. Inside each tree sit the skills of that area, connected by their prerequisites — and because most skills in an area depend on other skills in the same area, the whole thing naturally reads as a tree shape in a diagram: broad foundations at the bottom, specialised skills branching above.

Three things to know about trees:

- **The slicing is yours.** How a role divides into areas is up to the team. There's no canonical set of trees for "front-end developer" — there's the set that matches how *your* team thinks about its work. If the names feel obvious to the team, the slicing is right.
- **Every tree gets a clear name.** The name describes the area it covers — a person glancing at the forest should know what lives in each tree without opening it.
- **A skill is defined only once, anywhere.** Trees show skills; they don't own them. The same skill is never defined in two trees. (It may still *appear* under another tree as a root — that's the subject of the roots page.)

A tree is deliberately human-sized: big enough to represent a real area of expertise, small enough to take in at a glance and reason about in a conversation.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-03-06.png)

# How trees connect inside

Inside a tree, the prerequisite chains from the skills page become visible paths. Arrows run from each prerequisite up to the skill it unlocks, so the tree isn't just a grouping — it's a route map. Reading one is mostly instinct once you know two conventions:

**The path is the prerequisite chain.** You start at the bottom of the tree and work up. You can't take a skill before the skills beneath it, the same way you can't take the third rung of a ladder first. If a skill high in the tree looks impossibly hard, the explanation is almost always a missing skill somewhere below it.

**Chains stay clean — no double-linking.** The rule from the skills chapter does its real work here. If B depends on A and C depends on B, then C connects only through B; there is never an extra arrow from A straight to C. Every dependency is expressed exactly once, at the closest link. This is what keeps even a large tree readable instead of becoming a plate of spaghetti.

Because prerequisites live on the skills themselves (defined once, organisation-wide), a tree never invents connections. It reveals the ones that already exist among the skills it chose to show. Pull "React I" and "React II" into any tree, and they arrive connected — the tree didn't link them, the skills were always linked.

A well-formed tree ends up with a recognisable anatomy: a few foundational skills near the bottom that much of the area rests on, branches where specialisations diverge, and the most advanced skills at the tips. The skills at the very top aren't special — there's no notion of "exit skills," they're just the current ends of the branches. Trees keep growing.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-03-02.png)

# Roots are derived, not added

Every tree has **roots** — the skills you must already hold *before* you can enter the tree. And here's the elegant part: you never place roots by hand. The tree grows its own.

The derivation is mechanical. Look at the lowest skills in the tree — the ones whose prerequisites are *not* themselves in the tree. Those external prerequisites are the tree's roots, surfaced one level deep beneath it. In one line:

**Roots = prerequisites of the tree's skills that aren't in the tree.**

Say a "Frameworks" tree starts at "React I," and React I requires "JavaScript fundamentals" — a skill that lives in the JavaScript tree, not this one. Then JavaScript fundamentals appears *as a root* under the Frameworks tree. It isn't defined there (skills are defined only once); it's shown there, below the ground line, telling every reader: *hold this before you climb here.*

Why derive instead of declare?

- **Roots can't go stale.** Change a prerequisite on a skill, and every tree's roots update themselves. Hand-placed entry requirements drift; derived ones can't.
- **Roots can't be wishful.** Nobody can decorate a tree with aspirational entry bars that no skill inside actually demands. If it's a root, some skill in the tree genuinely requires it.
- **It keeps the mental model whole.** There is exactly one kind of connection in the method — the prerequisite. Roots aren't a second system; they're the same connections viewed from the other side of the tree's boundary.

Roots are the tree's honest answer to "am I ready to start this?" — and later, at the forest level, the same idea becomes the honest answer to "am I ready for this role?"

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-03-03.png)

# Forests and ranks

# The forest

A **forest** is a group of trees — the full scope of knowledge for a single **role**. "Front End Developer" is a forest. Its trees (Testing, Frameworks, JavaScript/TypeScript, Styling/CSS) are the logical slices; the forest is the whole territory.

The default shape: **one forest per role, covering every rank.** One "Front End Developer" forest holds everything from the junior's first skills to the senior's specialisations, rather than a separate forest per seniority level. (A forest per rank also works — but one forest per role is usually more convenient, because a person's whole journey stays on one map.)

Two properties fall out of the structure you already know:

**Forests have roots too.** The same derivation that gives a tree its roots applies at the forest boundary: prerequisites that sit outside the *whole forest* are what you need before entering the role at all. For a front-end forest, that might be general computer literacy or basic HTML — whatever the forest's lowest skills genuinely require but don't contain. Forest roots are the entry requirement to the role, derived, not guessed — which makes them unusually useful for hiring.

**Forests are honest about size.** A role is a lot of knowledge, and the forest shows all of it. That can feel intimidating on first view — until you notice that nobody is expected to hold the whole forest. You hold *your* skills at *your* levels, and the next chapter's ranks tell you which part of the forest your current chapter of the journey is about.

The forest is the method's unit of "a role, mapped." Everything after this — ranks, coverage, hiring, reviews — is a way of reading one.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-04-01.png)

# Ranks

A forest maps a role's knowledge; **ranks** map the journey through it. A rank is a seniority level — **junior / mid / senior** by default — and each rank is defined as a concrete set of skills, at given levels, that a person at that rank is expected to hold.

The key subtlety: **ranks attach to a person, not to a thing.** A skill isn't "a senior skill" in nature; the *organisation* decides that holding it (at some level) is part of what senior means here. Setting up ranks is exactly that act: for each forest, choosing which skills — and which levels of them — belong to each rank. Different organisations will slice the same forest differently, and that's fine.

What ranks buy you:

- **A visible "you are here."** A person reads their rank off the forest: they hold the junior set, most of the mid set, and there's the gap.
- **A promotion with a shape.** "Getting to senior" stops being a feeling and becomes a specific, finite list of skills at levels. Both the person and their manager can see it all year, not just at review time.
- **A shared language for expectations.** "Mid" means the same set of skills to everyone looking at the same forest — no private definitions.

On names: junior / mid / senior is the default ladder, but an alternative like **apprentice / journeyman / master** maps onto exactly the same structure. Pick whichever fits the culture; the mechanics don't change.

Ranks are also where the method eventually touches evaluation and pay — a powerful and delicate connection that gets its own treatment in the skill-management chapter.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-04-02.png)

# Roles that share skills

Skills are defined once, organisation-wide — and roles overlap. A front-end developer and a designer both hold "accessibility basics"; a data analyst and a backend developer both hold "SQL." So when you stand two forests side by side, they share ground.

That shared ground is one of the quietly valuable reads in the whole method:

**Sideways moves become visible.** Someone eyeing a move from QA to backend development doesn't face a mystery — the overlap between the two forests shows what already transfers, and the difference shows exactly what they'd need to pick up, in prerequisite order. A career change becomes a gap analysis instead of a leap of faith.

**Hidden versatility surfaces.** People often hold skills their current role doesn't showcase. Mapping someone onto a *different* role's forest can reveal they're already halfway into it — useful when a team needs to staff a new kind of work quickly.

**The organisation sees its connective tissue.** Where many forests share the same skills, those skills are the org's common foundation — worth investing in training for, and worth watching, because a gap there is a gap everywhere at once.

None of this requires extra machinery. It's the payoff of two rules established long before: skills are defined once (so the same skill *is* the same skill in every forest), and prerequisites live on skills (so paths into new territory come pre-drawn). The overlap was always there; the forests just make it visible.

> **[Image — Midjourney prompt]** *watercolor illustration of two distinct forests meeting at a shared grove in the middle, trees from both sides intermingling in the overlap zone, a small path crossing from one forest through the shared grove into the other, two subtly different shades of green blending where they meet, warm linen palette background, hopeful crossing-over mood*

>  we need a different prompt, it's too abstract for midjourney

# When roles don't fit

Some teams are too varied for fixed ladders. A small agency where everyone wears three hats, a research group, a startup where "the role" changes quarterly — forcing a junior/mid/senior forest onto teams like these produces a map nobody recognises.

The method bends without breaking. Drop the role structure, keep everything else:

**Define trees as areas to follow, not rungs to climb.** The trees still map real areas of knowledge — but instead of belonging to a role's ladder, they're a landscape on offer.

**Let people build their character.** Each member chooses which trees to take on, video-game style. One person goes deep on two trees; another spreads across four. The forest stops prescribing a single journey and starts recording each person's chosen one — which, for the right team, is dramatically more motivating.

**Manage levels across the team.** Coverage, gaps, single points of failure, honest levels, monthly reviews — every team-level read from later chapters still works. You're managing a portfolio of skills instead of progress along ladders, but the map stays true and the discipline stays the same.

What you give up is the crisp promotion mechanics of ranks — "ready for senior" needs some other definition, or the question simply matters less in such teams. What you keep is everything the map is for: knowing what the team can do, seeing risk early, and giving every person a visible, ordered way to grow.

Ranks are a feature of the method, not its foundation. The foundation is skills, honestly held, on a shared map.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-04-04.png)

# Honest assessment

# Placing a person on the levels

The method lives or dies on honest assessment — and the levels are built to make honesty achievable. They're defined by *observable behaviour*: not "how good is this person?" but "what happens when they do the work?"

The tells, level by level:

**Beginner** — the work gets done, but with help or documentation *along the way*, not just at the edges. Fresh from a course or a book.

**Confident** — most tasks delivered independently, reaching for docs only on the less common parts. The work gets done, by them, routinely.

**Expert** — almost everything handled without help; lookups only for obscure cases. The strongest single tell: **they can teach it.** Someone who can walk a colleague from beginner to confident in a skill is an expert in it.

(And the standing footnote: **even experts look things up.** Skills evolve; needing materials at any level is normal and expected. For small no-level skills, none of this applies — they're a plain yes/no.)

## The scale is fixed; the sources vary

Because the tells are behavioural, *anyone who has seen the work* can read them — which is what lets the same scale accept assessments from many sources:

- **Manager assessment** — the default in most professional environments; managers see delivery month after month, which is exactly what the tells describe.
- **Self-assessment** — the natural default for personal use, and a valuable input everywhere; nobody knows better how often help was needed along the way.
- **Peers and 360 feedback** — colleagues who work alongside someone often have the clearest view of all, especially for skills a manager rarely observes directly.
- **Credentials and certifications** — solid evidence for beginner (the basics are demonstrably known) and useful signals beyond; they certify knowledge, so pair them with delivery for the higher levels.
- **Teaching-back** — the built-in test that needs no interpretation: teach it, and expert is demonstrated, not claimed.

Which sources carry the decision is a cultural and organisational choice — the method doesn't mandate a mix. What it insists on is only this: every source answers the *same* behavioural question against the *same* scale. That's what keeps a level meaning one thing no matter who assessed it — and it's why disagreement between sources is useful rather than awkward: it's a small, concrete conversation about one skill, settled by looking at the work.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-05-01.png)

# Failure modes

Every assessment source has a bias signature. Knowing them is most of the defence — and it's why the method prefers levels that several sources can confirm.

**Inflation.** A level claimed (or granted) above the behaviour. It feels harmless, even kind — until the map assigns work that assumes foundations that aren't there. The cost arrives as frustration: tasks that feel impossibly hard, slipping deadlines, and a person quietly concluding they're not good at this — when the truth is only that a level got inflated and the missing foundation was never scheduled. Inflation doesn't skip the learning; it moves it to the worst possible moment.

**Modesty.** The same error in reverse, with a gentler face. Rate someone beginner where they're confident — whether from their own humility or an assessor playing it safe — and the map routes them around opportunities they were ready for: the stretch project, the mentoring role, the promotion case. The map can only open doors it believes someone can walk through.

**Source-specific tilts.** Self-assessments drift toward whichever of the two errors matches the person's temperament. Manager assessments lean on what the manager *sees* — skills exercised out of view get under-rated, recent wins outshine steady delivery. Credentials go stale: the certificate is forever, the skill isn't. None of this disqualifies a source; it just means no single source should be the whole story on a skill that matters.

Three habits keep placement honest, whoever is assessing:

- **Anchor on the behavioural tells.** Help along the way, or only at the edges, or almost never? That's a fact about last month's work, not a judgment of worth — and it's the same question for every source.
- **Be specific.** Broad skills invite vague ratings in any direction; "social-media posting: confident, SEO basics: beginner" leaves little room for ego *or* halo.
- **Correct cheaply, early.** The map has no memory of pride. Fixing a level costs nothing; living with a wrong one costs every plan built on it.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-05-02.png)

# Validation at scale

Assessing a handful of people honestly is a discipline. Assessing fifty — while levels feed reviews, promotions, and eventually pay — is a system design problem. The pressure is predictable: **once levels touch money, levels inflate.** Not because people are dishonest, but because incentives lean on the scale — on self-ratings and manager ratings alike — person by person, a little at a time.

The counterweight is making every level *a claim others confirm*:

**Peer validation.** A level isn't declared by one voice — whether the person's own or their manager's; the people who work alongside them corroborate it. This isn't a tribunal — most of the time it's a colleague nodding "yes, she delivers that on her own." The point is that levels become shared observations, not private declarations. Disagreement is a conversation about one skill at one level — small, concrete, and usually resolved in minutes.

**Skill champions.** For each critical skill, name a champion — someone at expert level who can answer questions, mentor others, *and validate assessments* in that skill. Champions give every skill a reference point: an agreed example of what expert actually looks like here. When someone wonders whether they're confident yet, the champion has seen enough of the skill to say. (Champions carry more weight in the team-development story too — see the team chapter.)

**Teaching-back as the standing bar.** The confident→expert test scales beautifully, because teaching is public. A claimed expert who has walked two colleagues to confident needs no further audit.

Handled this way, validation barely feels like control. It feels like what it is: a team keeping its shared map accurate, because everyone's plans are drawn on it.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-05-03.png)

# Keeping the forest alive

# The review cadence

A forest is a living map, and living things need tending. The method runs on two nested rhythms — one for people, one for the forest itself — plus one hard deadline.

**Individual progress: roughly monthly.** A short catch-up per person keeps their levels accurate. Note the word *short* — this is a check-in, not a ceremony. And nobody is expected to advance every month; most months the honest update is "still working on the same three skills," which is exactly what well-cut skills look like mid-growth (remember: one level takes a month to three). The monthly rhythm fits fast-moving roles especially well — paired with the career progress and opportunities that justify asking more of people.

**The forest itself: every six months.** Fields move. Twice a year, review the forest — the next page covers what actually changes. With fast-moving fields the changes needn't be large, but they need to *happen*; a review that changes nothing is still a review that confirmed the map.

**One year is the hard maximum.** Past a year without a forest review, the map drifts from reality — skills that no longer matter, missing skills everyone now needs, ranks that describe last year's expectations. And people notice. The moment a team senses the forest doesn't match their real work, they stop trusting it, and a map nobody trusts is worse than no map. **Owning this cadence is the job, not an afterthought.**

The two rhythms feed each other: monthly check-ins surface the small signals ("three people said this skill feels outdated") that the six-month review acts on.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-06-01.png)

# What a forest review changes

A forest review is gardening, and it makes exactly three kinds of change. Walking in knowing this keeps the session focused — two to three hours with the team and the lead, not an offsite.

**Skills move between ranks.** Expectations shift. The skill that marked a senior three years ago — containerised deployments, say — is now table stakes for mid. The review moves it down. Occasionally the traffic runs the other way: a skill turns out rarer and more valuable than assumed, and moves up. Either way, ranks stay honest descriptions of *current* expectations rather than a fossil record of old ones.

**Outdated skills retire.** The framework nobody uses anymore, the process the org abandoned — cut them. Retiring skills isn't erasing anyone's history; it's keeping the *forward-looking* map clean. A forest cluttered with dead skills makes every read (coverage, gaps, rank progress) a little more false.

**Emerged skills join.** New tools, new practices, new demands the team now genuinely faces. They enter the forest with prerequisites attached and a rank assignment, so they arrive as part of the map, not a loose sticky note on the side of it.

Two habits make reviews cheap. **Collect as you go** — the monthly check-ins surface most of what needs changing ("this feels outdated," "we keep needing X and it's not on the map"); the review confirms and applies rather than discovers. And **review with the team, not for them** — the people doing the work know first when reality moves, and a forest changed over their heads is a forest they stop trusting.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-06-02.png)

# Consistency without flattening

The moment more than one team runs forests, a tension appears. The organisation wants consistency — comparable levels, comparable ranks, reports that add up. Teams want fit — trees that match *their* work, not a committee's idea of it. Resolve this the wrong way and you either flatten every team onto one generic map, or fragment into private vocabularies nobody can compare.

The method's resolution fits in one line: **share definitions, not whole trees.**

What's shared, organisation-wide:

- **Skill names and definitions** — "React II" means the same thing everywhere it appears (skills are defined once, so this is already structural).
- **The level scale** — beginner / confident / expert, with the same behavioural tells.
- **Assessment criteria** — what counts as evidence for a level, including teaching-back.

What stays with each team:

- **The trees themselves** — which skills the team's work needs and how the area slices. Identical trees forced onto different work destroy exactly the fit that makes forests useful.

In short: **teams own their trees; the organisation owns the vocabulary.** A light central registry of skill definitions and ranks keeps reporting meaningful while every team keeps a map that matches its actual work.

And govern lightly. A small cross-area group — not a department, a handful of people — maintains the shared vocabulary and resolves naming clashes ("your 'API design' and their 'API design' are different skills; one of them needs a new name"). Its job is to keep the language coherent, never to approve trees. The moment governance becomes a bottleneck teams route around, the shared vocabulary dies with it.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-06-03.png)

# Growing your own skills

# Reading your forest

Your role is a forest; this chapter is about walking it. First, learn to read the map from where you stand.

**Follow the arrows.** Within a tree, arrows run from a prerequisite up to the more advanced skill. The path *is* the prerequisite chain — you can't take a skill before the skills below it, and you don't have to guess the order, because the order is drawn.

**Check the roots before entering a tree.** Beneath each tree sit its roots — skills the tree depends on but doesn't contain. They're what you need *before* you can meaningfully start. Eyeing the Frameworks tree? Its roots tell you what to bring to the door.

**Read levels, not just skills.** Each skill is either yes/no or three-level (beginner → confident → expert, each level a prerequisite of the next). "Knowing a skill" always means knowing it *to a level* — so your position on the map is a set of skills, each with a level attached, not a list of checkmarks.

And the single most useful reading habit in the whole method:

**If something feels impossibly hard, look down.** A skill that won't click almost never means you're not capable — it nearly always means a skill *underneath* it is missing or weaker than you rated it. The frustration you feel up the tree was caused down the tree. Look below, find the gap, fill it, and the impossible thing usually turns merely difficult, then routine.

Where your rank fits into this picture — and how it defines your next big step — is the ranks page in chapter 4; this chapter takes it as read.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-07-01.png)

# Choosing a path

The forest shows every possible path. Yours needs choosing — and five principles do most of the choosing for you.

**Clear the roots first.** Hold a tree's roots before entering it. Skipping entry requirements is the surest way to get stuck later — the missing foundation doesn't disappear, it waits for you at the worst moment.

**Follow the chain.** Inside a tree, work bottom-up. The map tells you the order, not just the destination; trust it over the temptation to jump to the shiny skill at the top.

**A few skills at a time — three to five.** Deep progress on a handful beats shallow progress on a dozen. Levels take a month or more to move; spread across twelve skills, nothing moves visibly, and invisible progress is what kills motivation.

**Balance relevant against interesting.** Your rank demands some skills; others you simply *want*. A path made only of duty burns out; a path made only of curiosity wanders. A sustainable path has both — and the map happily holds both.

**Practice, don't just study.** Skills grow through use. Courses and books get you to beginner; only real work carries you further, and *teaching a skill back is what turns confident into expert.* When you pick a focus skill, pick the real task you'll grow it on in the same breath.

That's the loop: choose three to five skills the map says you're ready for, attach real work to each, and let the month do its job. Then read the map again.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-07-02.png)

# Tracking your progress

A map only helps if it stays current. So the real question of this page isn't *whether* to track — it's where your forest should live so that keeping it honest costs you nothing.

**Paper works — and charges rent.** The method predates any software: a page per role in a notebook, an index card per skill, a wall chart with sticky notes. It all carries the method, and it proves an important point — the forest is an idea, not a tool lock-in. But paper quietly bills you for every month of use: you copy levels forward, keep dates by hand, redraw trees whenever a forest review moves skills around, and none of it is visible to the people helping you grow. What starts as a pleasant ritual becomes clerical work — and clerical work is what tracking systems die of.

**Skillforests keeps the forest alive for you.** The app is the method with the rent removed:

- **Your forest is live.** When the forest review moves skills between ranks or retires one, your map updates — nothing to redraw, nothing to copy forward.
- **History happens automatically.** Every level change is dated the moment it happens, so the growth trail you'd bring to a review or career conversation is simply *there* — months of undeniable progress, no bookkeeping.
- **It's shared by design.** The same map is what your team lead reads coverage from and your coach plans with. On paper, your progress lives in your notebook; in Skillforests, it lives where reviews, 1:1s, and plans already happen.
- **The rhythm is built in.** The monthly update — what moved, what stalled, what's next — takes minutes when the map, the levels, and the dates are already in front of you.

The two habits from this chapter don't change: update monthly, and let level changes carry their dates. The app just makes the first one short and the second one automatic.

If all you have today is a notebook, start in the notebook — a tracked forest on paper beats an untracked one anywhere. But the best tracking system is the one still being updated in six months, and the surest way to be that system is to do most of the updating for you.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-07-03.png)

# Pitfalls

Five ways people trip on their own forest — all avoidable once named.

**1. Trying to learn everything.** The forest shows all of it, and ambition says *take all of it*. Resist. Focus is the discipline: three to five skills, moved deeply, beat a dozen touched shallowly — every time, without exception. The forest isn't a to-do list; it's a menu.

**2. Skipping roots and prerequisites.** The advanced skill glitters; the foundations look like homework. But missing foundations don't vanish — they become walls, and you hit them later with momentum. If chapter 7 had a single law, it's this: the fastest path runs *through* the prerequisites, never around them.

**3. Reading instead of doing.** Reading about swimming won't make you a swimmer. Courses, books, and videos are honest ways to reach beginner — and quietly useless beyond it. If your plan for a skill contains no real task, it isn't a plan for growing the skill; it's a plan for feeling informed about it.

**4. Comparing yourself to others.** Everyone's forest starts somewhere different — different roots, different history, different luck. Their map is not your map; the only comparison the method endorses is you-now against you-last-quarter. (The dates in your tracker exist precisely to win that comparison.)

**5. Giving up too early.** A level takes a month to three of real work to move — *by design*. Three weeks in with nothing to show is not failure; it's the middle. The forest was cut so that patience is always rewarded on roughly a monthly rhythm. Trust the cut.

Most of these share one cure: read your own map honestly, monthly, and let it — not mood — decide what's next.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-07-04.png)

# Growing a team

# The team map

Point a forest at a team and it becomes something new: one picture of what the team can actually do. Three reads matter, in this order.

**Coverage.** For each critical skill: how many people hold it, and at what level? Read this first, because it's the first thing that breaks. A team's real capacity isn't its headcount — it's its coverage of the skills the work demands.

**Gaps.** Skills the team needs but nobody has — or holds only at beginner. A gap on a critical skill is a commitment you can't currently keep, discovered *before* you keep it. Gaps found on the map cost a plan; gaps found in production cost much more.

**Single points of failure.** Skills exactly one person holds at a usable level. This is the read leaders learn to fear productively: a skill with one confident owner is a risk the moment that person is on leave, busy, or gone. The map shows you every such skill *today*, while there's still time to grow a second owner.

The tool that makes all three reads instant is the **skills heat map**: team members down one axis, skills across the other, level in each cell. The whole forest becomes one glance — dark columns are strengths, thin columns are the work, and a column with a single dark cell is a single point of failure announcing itself.

Everything else in this chapter — planning, hiring, reviews, development — is a response to what these three reads show you.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-08-01.png)

# Planning growth

A team's development plan shouldn't need inventing — the map, read against the future, mostly writes it. Three inputs:

**Match the forest to upcoming work.** Take the next projects on the horizon and read off the skills they'll demand. Compare against current coverage. The shortfall *is* the plan — and because prerequisites and roots dictate learning order, the map even sequences it. "We need two confident owners of X by spring, and X requires Y, so Y starts now" is planning at its least mysterious.

**Grow people toward the next rank.** Each person's target rank is a concrete set of skills — so "develop your people" stops being an abstract duty and becomes specific: these skills, for this person, in this order. The beauty is that personal ambition and team need mostly align; the rank was defined to describe what the team values.

**Spread risk deliberately.** Wherever the heat map shows a single point of failure, grow a second owner *before* you need one. This is the cheapest insurance a team can buy: the learner gains a valuable skill, the current owner gets the expert-making experience of teaching it (teaching-back — the confident→expert test), and the team sleeps better. One decision, three payoffs.

Braid the three inputs together per person — what the work needs, what their next rank asks, what risk demands — and keep each person's active set to the usual three-to-five skills. The result is a growth plan tied to real work, honest about order, and legible to everyone on the map it came from.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-08-02.png)

# Hiring against the forest

Most job openings are written from memory and vibes — a list of technologies, some adjectives, "5+ years." A forest lets you write one from the map instead.

**Define the opening by roots and target rank.** The forest's roots are the derived, honest answer to "what must someone already hold to enter this role?" Add the rank you're hiring at, and the opening defines itself: the entry requirements, plus the rank's skill set at its levels. Sharper than buzzwords — for you *and* for candidates, who can see what the job actually is.

**Separate must-have from grow-into.** This is the hiring mistake the map prevents best. Roots and the entry rank are the bar; everything above is what the role *teaches*. Screening candidates out on skills the job exists to develop shrinks your pipeline for no reason — you're demanding people pre-learn the growth you're supposedly offering. The forest makes the line explicit: below this line, must arrive with; above it, will grow here.

**Read candidates onto the map.** Interviews assess the same way the team assesses — skills at levels, using the same behavioural tells (needs help along the way? delivers alone? could teach it?). Each candidate becomes a shape on the heat map: this one closes the testing gap, that one duplicates strengths you already have. "Best candidate" becomes "best candidate *for these gaps*" — a question the map answers almost by itself.

A quiet bonus: openings written this way promise honestly. Candidates arrive knowing what they must bring and what they'll grow — and the ones the map welcomes tend to be the ones the forest was missing.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-08-03.png)

# Reviews and 1:1s on levels

Reviews are where the forest pays for itself most visibly — because it replaces the worst part of them: the adjectives.

**Talk in levels and ranks.** "Moved three skills to confident this half, holds the full mid-rank set, two skills from senior" is reviewable — comparable to last year, legible to both sides, checkable against the map. "Showed real growth" is none of those things. Once a team tastes level-based reviews, adjective-based ones feel like astrology.

**Use the forest as the shared artifact.** The review conversation happens *over the map*, literally. Both people look at the same forest, and disagreement — the thing that makes reviews dread-inducing — changes character entirely. Instead of "I think you're underrating my year" (a conflict about judgment), it's "I'd put myself at confident on X" (a conversation about one skill at one level, with behavioural tells to check and a champion to consult if needed). Big vague conflicts become small concrete ones, and small concrete ones resolve.

**Next steps are already on the map.** The traditional review scramble — inventing "development goals" in the meeting — disappears. The next rank's skills *are* the plan for the period ahead; the only real conversation is sequencing and which real work will carry each skill. The person walks out with the same map they walked in with, plus agreement on the path.

The 1:1 version is the same thing, smaller: the monthly check-in from the review cadence. What moved, what stalled (look down — usually a prerequisite), what's the focus next month. Ten minutes over the map, and the annual review loses its power to surprise anyone.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-08-04.png)

# Developing the team

The map shows what to grow; these are the mechanisms that do the growing — and the guardrail that keeps it healthy.

**Skill champions.** For each critical skill, name the person who can answer questions, mentor, and validate level assessments. Champions turn every important skill into a place someone owns: learners know who to ask, assessments have a reference point, and the champion gets the recognition of being *the* person for something.

**Cross-training.** Wherever the heat map shows a single point of failure, pair a learner with the confident or expert owner. The learner grows a needed skill, the owner grows through teaching it, the column gains a second cell.

**Learning partnerships.** Match complementary gaps — she needs what he has, he needs what she has — and let them trade. Then *rotate the pairs*, so knowledge spreads through the team instead of pooling in corners.

And the guardrail: **keep it from becoming a contest.** A visible map of everyone's levels can curdle into a leaderboard if led carelessly — people hoarding expertise to stay special, inflating levels to keep up appearances. The countermeasures are cultural, and they're the leader's job:

- **Emphasise collective coverage over individual scores.** The team's win is a dark heat map, not a personal high score.
- **Recognise the people who teach.** If sharing knowledge is what gets celebrated, hoarding it stops paying.
- **Start with volunteers and show an early win** — enthusiasm converts skeptics better than mandates.
- **Keep check-ins brief and tied to real work** — the moment forest upkeep feels like ceremony, it starts dying.

A team run this way develops a distinctive feel: growth is normal, teaching is status, and nobody is irreplaceable in the brittle way — only valued in the durable one.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-08-05.png)

# Growing people

# Onboarding a person

Coaching with a forest starts the same way every time: four steps that turn "help me grow" into a route.

**1. Assess the current state.** Walk the relevant forest together and place the person honestly on each skill — yes/no, or beginner / confident / expert, using the behavioural tells from chapter 5. An accurate baseline is the whole point of the exercise, so resist both directions of drift: inflation (which plants frustration a few months out) and modesty (which hides readiness you could be building on). If they can't place themselves on a skill, ask what happened last time they did that work — the story usually answers.

**2. Clarify the goal.** "Get better" isn't a goal the map can route to. A target rank, a role they're moving into, or a named set of skills — anything concrete enough to *point at on the forest*. The goal conversation is often the most valuable part of onboarding; many people have never been asked to make their ambition specific before.

**3. Find the gap.** With both endpoints on the map, the route draws itself: the skills between current state and goal, expanded with their roots and prerequisites, in dependency order. This is where the forest quietly does what a coach otherwise does by intuition — it turns distance into sequence.

**4. Set priorities.** Nobody walks the whole route at once. Three to five skills at a time; clear roots before entering a tree; and balance what the goal demands against what keeps this particular person engaged — a route made only of duty gets abandoned at the first hard month.

One session is usually enough for all four steps, and the artifact it produces — a marked map with a route on it — carries every session after.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-09-01.png)

# Guiding progress

Onboarding drew the route; guiding is keeping the person moving along it. Four practices carry the months between the start and the goal.

**Work the prerequisite chain.** Don't let someone reach for an advanced skill before its foundations — even when they're eager, *especially* when they're eager. Frustration up the tree is almost always a missing skill down the tree; when a person stalls or struggles, look below the struggling skill before questioning the person. This one diagnostic habit prevents most coaching dead-ends.

**Pace against the levels, not the calendar.** Most skills move within a month or so of focused work — that's the granularity the forest was cut to. So a three-level skill stalling for months isn't a motivation problem to push through; it's a signal the skill is too big. Split it, or narrow the focus to a slice that can visibly move. Visible movement is the fuel; a coach's job includes keeping the fuel flowing.

**Make practice the assignment.** Skills grow through use — so pair every focus skill with real work, not just materials. And use **teaching-back as the test** for advancing someone to confident or expert: ask them to explain the skill, or better, have them walk a colleague through it. It's simultaneously the assessment and the final rep of the learning.

**Review monthly.** A short check-in keeps the picture current without heavy ceremony — what moved, what stalled, what's next month's focus. Same rhythm as everywhere else in the method, and it composes: your coaching check-in can *be* the person's monthly forest update.

The route will change — goals sharpen, life intervenes, the forest itself gets reviewed. That's fine. The map makes re-routing cheap; the practices above make it rare.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-09-02.png)

# Coaching many people

Coach one person and the forest is a map. Coach many, and it becomes something better: a dataset. Patterns emerge that no single engagement could show.

**Spot common starting points and obstacles.** The same roots block many beginners; the same skills stall many travelers at the same spot. Every repeated obstacle is a signal: build reusable material there — the explainer, the exercise set, the worked example — once, and it serves everyone who hits that spot after.

**Reuse, then personalise.** The journeys you see often become templates: "career-changer into front-end," "mid pushing for senior," "generalist choosing a specialisation." Keep them. A template is a head start, not a straitjacket — adapt it to the person in the onboarding session instead of drawing every route from a blank map. Experienced coaches do this by intuition; the forest lets you do it explicitly and share it with other coaches.

**Track the portfolio.** A per-person sheet — current levels, focus skills, goal — plus one across-clients view. The portfolio view is your own heat map: where your coaching is working (levels moving on schedule) and where it isn't (the same skill stalling across three clients is *your* signal, not theirs — the material or the skill's cut needs work).

**Build community where it helps.** People with similar goals can learn from each other between sessions, and the forest gives the group a shared language and map to anchor on. Peer learning scales in a way one coach never can — connecting two people three steps apart on the same route often teaches both more than a session would.

The through-line: many maps, honestly kept, teach the coach. What they teach becomes material, templates, and community — the difference between coaching people one at a time and building a practice.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-09-03.png)

# Skill management across the organisation

# Roles and ranks as one system

Every role has a forest; every forest has ranks; every person holds skills at levels. Run across the whole organisation, this becomes a single system with answers HR and leadership usually have to improvise.

**"Is this person ready for the next rank?" — a defensible answer.** They hold the skills that define the rank at the required levels, or they don't. Promotion committees stop debating impressions and start checking a map both the person and their manager have been looking at all year. "Defensible" matters: the same evidence that convinces a committee protects the decision afterwards — to the person promoted, to those who weren't, to anyone auditing fairness across teams.

**Roots as the promotion and hiring bar.** What someone must already know to enter a forest is *derived* from the skills' own prerequisites, not guessed by whoever wrote the job description. The same derived bar serves both doors: hiring from outside and moving people across roles inside.

**One organisation-wide view of capability.** With shared skill definitions and a common level scale (chapter 6), forests aggregate. Leadership can see where the org is thin, where single points of failure span *teams* — the skill that three departments each assume some other department owns — and who across the whole company is near their next rank.

**Sideways visibility.** Where forests overlap, the map shows where people can move laterally and what they'd need to pick up — turning internal mobility from a lucky accident into something you can actually plan.

The compounding effect is the point: each team's honest map is useful; all the maps together, speaking one vocabulary, are an organisational capability the org never had before — the ability to *see itself*.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-10-01.png)

# Ranks, evaluation, and pay

Connecting the forest to evaluation — and eventually money — is where the method carries the most weight and deserves the most care. Three principles.

**Anchor reviews on levels and ranks, not adjectives.** "Moved three skills to confident, holds the mid-rank set" is comparable year over year, across managers, across teams. Adjective-based reviews aren't just vague — they're *incomparable*, which makes every calibration meeting a negotiation between writing styles. Levels give the organisation one currency of progress.

**Connect ranks to bands deliberately.** The tempting shortcut — pay scales with skill count — fails quickly: a raw count rarely maps cleanly to value, and it incentivises collecting cheap skills over deepening critical ones. Instead, decide *which* skills and ranks matter for *which* band, and **write it down** so it's consistent across managers. The forest gives you honest inputs; the compensation design is still a human decision — the method just makes it explicit instead of folklore.

**Keep assessment honest under pressure.** The predictable failure: once levels touch pay, they inflate — self-ratings and manager ratings alike; not from dishonesty, but because incentives lean on the scale. The counterweights from chapter 5 stop being optional at this point: **peer validation** (a claimed level is one colleagues confirm) and **skill champions** (each critical skill has a reference person who validates assessments). An organisation that ties pay to levels without standing up validation first is scheduling its own credibility crisis.

Sequencing advice hides in that last line: let the forest prove itself in reviews and development *first*, then connect money. A map the org already trusts can bear the weight; a brand-new one can't.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-10-02.png)

# Reporting and planning

With every team's forest speaking the same vocabulary, the organisation gains four reads that used to require expensive guesswork.

**Coverage and gaps.** Which critical skills are thin org-wide? Where are the *cross-team* single points of failure — the one person in the whole company who holds a skill four teams depend on? Team-level maps each show their own risks; only the aggregated view shows the risks that live between teams.

**Talent pipeline.** Who's close to their next rank — nearly ready to step up, or step across? This turns succession from a name-on-a-napkin exercise into a live list: for each key position or rank, the people within a few skills of it, and exactly which skills. Development budgets can be pointed at the shortest real distances.

**Capability vs. strategy.** Take the next two years' priorities and read off the skills they'll demand — then compare against current coverage. The shortfall *is* the workforce-planning agenda: what to grow internally (and how long the prerequisite chains say that takes), what to hire (and against which derived entry bars), what to reconsider. Strategy meetings acquire an unusual property: the capability question gets answered with data.

**Project readiness.** Before committing to an upcoming project, read off the skills it needs and check how many people hold them, at what levels, and where the gaps are. "Can we staff this?" becomes a lookup instead of an opinion — and when the answer is no, the map shows the cheapest path to yes.

A note on spirit: these reads are for *planning*, not surveillance. The moment reporting makes individuals feel watched rather than developed, honest assessment — the input everything rests on — starts to corrode. Report on the forest; develop the people.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/kRvmethod-10-03.png)

# Rolling it out

The org-wide system of the previous pages is the destination. Nobody should start there. Skillforests spreads the way trust spreads — one team at a time, on demonstrated value.

**Pilot with one willing team.** Willing is the load-bearing word. A team curious about the method will forgive early clumsiness and help refine it; a team that had it imposed will comply minimally and prove it "doesn't work here." Build the first forest with them, run the monthly rhythm for a few cycles, hold one forest review — and *learn what works in your organisation* before any thought of scaling.

**Make the value concrete for individuals first.** This is the rollout's golden rule: people engage when the forest helps *their own growth*, not just the org's reporting. If the pilot team's members can each point at something the forest gave them personally — a visible path to the next rank, a review that finally felt fair, a skill they grew on purpose — the method sells itself internally. If the first visible artifact is a management dashboard, you've taught everyone the map is for watching them, and honest assessment dies in the crib.

**Scale gradually.** Let the pilot's story travel; expand to the next willing teams; stand up the shared vocabulary and light governance (chapter 6) as the *second* or third team joins — that's when consistency starts earning its cost. Connect ranks to evaluation, and eventually pay, only after the maps have earned trust — the sequencing argued in the pay page.

The pattern is the method applied to itself: clear the roots first (a willing team, individual value), don't skip prerequisites (trust before money), and let visible monthly progress do the persuading.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-10-03.png)

# Back matter

# Glossary

Every term in the method, in one place. Terms link to the page that treats them fully.

**Skill** — the basic building block: one concrete, precisely named ability. Either no-level or three-level. *(Chapter 2)*

**No-level skill (yes/no)** — a skill small enough that you either know it or you don't; nothing meaningful to grade. Stored internally as level 0, which is never shown to users. *(Chapter 2)*

**Three-level skill** — a skill large enough to grow through stages: beginner → confident → expert, each level a prerequisite of the next. In a tree, each level is treated as a separate skill. *(Chapter 2)*

**Beginner** — knows the basics (fresh from a course or book); can do the work but needs help or a lot of documentation along the way. *(Chapter 2)*

**Confident** — hands-on experience; delivers most tasks alone, reaching for docs only on the less common parts. *(Chapter 2)*

**Expert** — considerable experience; handles almost everything without help, looking things up only for obscure cases. Confident enough to teach others. *(Chapter 2)*

**Prerequisite** — a skill required before another becomes learnable. Defined once, on the skill itself, at organisation level — never inside a tree. *(Chapter 2)*

**No double-linking** — the rule that every dependency is expressed once, at the closest link: if B needs A and C needs B, C connects through B, never also directly to A. *(Chapters 2–3)*

**Granularity rule** — a well-cut skill takes roughly one to three months to progress one step. Longer: split it. Nothing to grade: make it no-level. In doubt: aim bigger. *(Chapter 2)*

**Tree** — a scope of view over a connected subset of skills; an area of knowledge forming a logical part of a larger whole (e.g. Testing, Frameworks). *(Chapter 3)*

**Root** — a prerequisite of a tree's skills that isn't itself in the tree; surfaces beneath the tree as its entry requirement. Derived, never placed by hand. Applies at forest level too. *(Chapter 3)*

**Forest** — a group of trees: the full scope of knowledge for a single role, usually one forest per role covering every rank. *(Chapter 4)*

**Rank** — a seniority level tied to a person (junior / mid / senior by default), defined as a concrete set of skills at given levels within a forest. *(Chapter 4)*

**Coverage** — for a skill: how many people on a team hold it, and at what level. The first team-level read. *(Chapter 8)*

**Gap** — a skill the team needs but nobody holds, or holds only at beginner. *(Chapter 8)*

**Single point of failure** — a skill exactly one person holds at a usable level; a risk the moment that person is unavailable. *(Chapter 8)*

**Skills heat map** — a grid of team members against skills, with the level in each cell; the whole forest at a glance. *(Chapter 8)*

**Skill champion** — the named person for a critical skill who answers questions, mentors, and validates self-assessments. *(Chapters 5, 8)*

**Teaching-back** — explaining or teaching a skill to someone else; the method's favourite test for advancing to confident or expert. *(Chapters 5, 7, 9)*

**Peer validation** — the practice of levels being claims that colleagues confirm, keeping assessment honest at scale — especially once levels touch pay. *(Chapter 5)*

**Forest review** — the twice-yearly session that moves skills between ranks, retires outdated skills, and adds emerged ones. One year without it is the hard maximum. *(Chapter 6)*