SkillZone

SkillZone: the side project IBM adopted

SkillZone is an interactive technical enablement platform I built at IBM to replace a pile of markdown files, Git repos, and PDFs with one place to actually learn the stack. It started as a for-fun side project. It ended up as an adopted internal product used by roughly 10,000 IBM sellers and 5,000 partners, hosting 100+ hands-on labs from Level 1 to Level 5.

It's an internal IBM platform, so there's no public repo. The story is the part I can share.

What were we dealing with?

IBM's technical content wasn't missing. It was everywhere. A markdown file in one repo, a PDF in someone's inbox, a Git project you only knew about if the right person sent you the link. If you were a seller prepping a demo or a partner trying to get hands-on with a product, step one was a scavenger hunt (and step two was usually asking someone who'd already finished step one).

Nobody owned the problem, because technically nothing was broken. The content existed. It just didn't behave like a product. What I wanted was something that:

1. Put every lab in one place instead of five
2. Made content interactive, so people learned by doing instead of reading a PDF and hoping
3. Showed a clear path from beginner to expert
4. Worked the same for an IBM seller and an external partner

So what did I build?

One interactive site that turned scattered content into a structured library of labs.

• One front door: every lab lives on the platform, not in a folder someone has to share with you
• Hands-on by default: labs are built to be worked through, not skimmed
• Leveled curriculum: Level 1 through Level 5, so a new seller and a seasoned architect both know where to start
• Two audiences, one platform: internal sellers and external partners get the same experience

How it came together

1. Start with the mess: Look at how content was actually being distributed and what people kept hunting for.
2. Build the whole thing: I owned the front end, the back end, and the UX. One person, one set of decisions.
3. Ship it rough: Early versions were not pretty. They worked, which mattered more.
4. Watch, then iterate: How people used it told me what to fix next better than any roadmap would have.
5. Grow the library: Scale from a handful of labs to 100+ across all five levels.

Why did it move so fast?

No committee

• I was the only person making decisions. No approval chain, no design review, no meeting to schedule the meeting.
• The tradeoff was polish. I'd make that trade again.

Pull, not push

• Nobody was told to use it. People found it, used it, and came back.
• That's how a side project becomes a product: adoption shows up before the org chart does.

Ownership end to end

• Front end, back end, and UX were all mine, so fixing a problem never meant filing a ticket with someone else
• One builder meant one consistent experience across every lab and every level

Results

What started as a for-fun side project became an adopted IBM internal product.

• ~10,000 IBM sellers on the platform
• 5,000 partners on the platform
• 100+ hands-on labs, Level 1 through Level 5
• One home for technical content that used to live across markdown files, Git repos, and PDFs

The takeaway

If everyone is quietly working around the same mess, you don't need permission to fix it. You need a working version.

Turns out Kevin Costner was right. Build it, and they come (mostly because they're tired of hunting for PDFs).