Skill Trees as Platform Capability Maps

The first time I drew my handstand training as a skill tree, a year of confusion made sense. I’d been trying to learn a press to handstand while my freestanding hold was still a coin flip and my compression was weak. Laid out as a tree, the problem was obvious: the press sits three tiers up, and two of the branches feeding it weren’t unlocked.

You can explore the tree I use on the Lab page: a few dozen nodes in tiers, from wall holds and wrist prep at the bottom to presses and one-arm work at the top. Each node has a clear unlock condition — “hold 30 seconds”, “five controlled negatives” — and a set of prerequisites.

Roadmaps hide dependencies; trees show them

Most platform roadmaps are lists. Q1: self-service environments. Q2: golden-path templates. Q3: a developer portal. Lists hide the thing that matters most: what depends on what. A capability map drawn as a tree makes it visible.

Tier	Training example	Platform example
Foundations	wrist prep, hollow body, wall hold	identity and access, infrastructure as code, CI
Core skills	chest-to-wall line, kick-up consistency	reproducible environments, secrets management, observability
Applied skills	freestanding hold, straddle work	self-service environments, Golden Paths for common services
Advanced	press to handstand	ephemeral preview environments per PR, policy as code, an agent-ready platform

You can’t do self-service environments before infrastructure as code and identity are solid, in the same way you can’t press before you can hold. Trying anyway is how teams end up with a beautiful portal over a fragile estate.

Three things a tree gives you that a list doesn’t

1. A way to say no. “That’s locked” is a much easier conversation than “that’s not this quarter”. When someone asks for a developer portal, you can point at the two foundation nodes it needs and show the shortest path to unlock it.

2. Mastery, not just completion. Skill trees usually carry levels: you can have a freestanding handstand at five seconds or at sixty. Platform capabilities are the same. “We have CI” can mean a flaky pipeline only one person understands, or fast, cached, self-serve pipelines with clear ownership. Give each node a maturity level, not a tick box.

3. Multiple routes. Good trees offer alternative branches when one is blocked — no parallettes, use the floor variation. Platforms need the same honesty: if one team can’t adopt the standard deployment path yet, what’s the supported stepping stone?

Building one

1. List the capabilities product teams actually ask for (the top of the tree), from interviews, not guesses — this is the product side of an Internal Developer Platform.
2. Work downwards: for each, what has to be true first? Stop when you hit things that already exist and work well.
3. Write an unlock condition per node in observable terms (“a new service reaches production in under a day without a ticket”), not activity terms (“adopt tool X”).
4. Colour what’s unlocked, in progress and locked. Review it like a training log, every few weeks.

Where the metaphor breaks

A body has one tree and one owner. An organisation has many teams on different branches, so the same node can be “mastered” for one team and locked for another. I’d keep one shared tree but track unlocks per team.

And capabilities decay in a way strength mostly doesn’t over short spans: a pipeline that was excellent two years ago can quietly rot. Nodes need re-testing, like a periodic max test, not a permanent badge.

Takeaways

• Draw the dependencies; most roadmap arguments are really disagreements about prerequisites.
• Give nodes unlock conditions and mastery levels, not just owners and dates.
• Use the tree to sequence and to decline: locked is a valid answer.
• The same structure works for personal learning paths — it’s how I plan what to learn next, too.

Related: Hypertrophy and Skill Phases: Build vs Harden Cycles covers when to work on a node; Golden Paths and the Recommended Routine covers what to hand beginners while the tree is still growing.