I (Don’t) Know Kung Fu

Why traditional ‘fast tracks’ to tech team learning don’t work, and what does. Also, Matrix references.

When I hired my first dev team, I ran into the same problem that every other startup CTO faces. Attracting great people without great budgets is tricky for a startup, in part thanks to competition from tech giants (👀 looking at you AppAmaGooFaceSoft). But growing — and retaining — your own tech folks requires a serious time investment — something I didn’t have. As a busy technical founder, all of that felt like a luxury to come back to later. I was wrong.

The 2018 HackerRank skills report asked ~39,000 developers what they want most in a job. The top two responses were work-life balance, and professional growth and development opportunities. Lots of tech companies don’t even pretend to offer the former, so they should at least take the latter seriously.

‘Organic’ learning: when slow and steady doesn’t win the race

A desire for professional growth isn’t surprising: learning is a really important part of the job in a world where languages, frameworks and the definition of “good” are constantly evolving. In my experience, typical dev learning is organic and slow and it mainly happens through:

• Breaking things and, most of the time, fixing them again
• Building something you don’t know how to build
• Working out how something broke
• Pair programming or mentoring with a more experienced developer (the best option most people can hope for).

To see the fruits of this kind of learning, you need time. Lots and lots of it.

As co-founder and CTO of a growing startup, time was never something I had in abundance. I needed my team to build fast, or we’d be out of runway, out of business, and out of a job. Hacking skills together by scouring Stack Overflow just didn’t cut it. Without the option to simply *download* skills into my team’s brains (I watched the Matrix about 30 times as a teenager and, ironically, the script for that film is probably the only thing I feel like I’ve ever downloaded into my brain), I turned to more formal learning options.

Enter: online training (Udemy, Coursera, Pluralsight, Codecademy etc. etc). Then quickly exit again.

‘Jug and Mug’ Learning is … Boring

According to Axonify’s State of Workplace Training study, 85% of adult learners want training to be flexible on time and location, making online courses (videos or ‘show, then do’ courses) an obvious way to learn. On paper, this looked perfect. On-demand, cheap content designed to fill the gap that was causing me pain. My hopes were high — what’s not to like?

Well, for one thing, it’s really, really, really boring.

The ‘video lecture’ is where my learning joy goes to die. It’s passive and un-engaging, but on the flip side, it’s easy to make and upload, so the format dominates in online learning. The benefit of its simplicity is that we have a lot of content from a lot of experts.

The downside is that, apart from often being a rather boring option, this ‘jug and mug’ learning (in which an expert pours content from her ‘jug’ into your ‘mug’ of knowledge), is often not the best way to learn a practical skill. To bring this to life with an example: if a friend’s driving lessons had consisted only of video lectures, I would not choose to be a passenger in their car.

But returning to the issue at hand: I could ask my team to suffer through a bit of boredom, if the training works. But it doesn’t — my team either didn’t use the training, didn’t complete it, or didn’t retain much of what was covered. Talking to other CTOs, I heard exactly the same story. It was a small comfort to know that I wasn’t alone, but I was still frustrated.

Talking to my team, I could immediately see why they were bored of online courses — they were generic. I looked again at the Axonify data and noticed that while 85% percent of learners want training to be flexible, even more — 90% — want it to be personalised.

I know what corporate training is like; I’ve watched The Office. You sit in a room for a day, checking your watch every 30 seconds, while someone says things that you already know interspersed with things that are completely irrelevant to you. Anyone, particularly someone busy with real and important work to do, wants to learn things that are appropriate to them. And herein lies the biggest problem with online courses.

The Bucket Fallacy

Software development, like any real human skill, isn’t learned in a straight line. Not every developer started with ints, moved onto strings, and made sure they learned their O(n) notation before implementing their first doubly-linked list. Many developers are hugely advanced in one aspect, and have gaping holes in some ‘beginner’ topic.

Here’s an analogy: spoken language. A friend of mine once told me about her experience of teaching English to a second-language student. The student had an excellent grasp of English grammar, perfect in their usage of advanced constructs like modal verbs (‘would’, ‘could’, ‘might’), but had major problems with pronunciation, meaning they were rarely understood. Were they a beginner? Definitely not — making them sit through hours of basics would have been a huge waste of their time. Were they intermediate? Definitely not — they desperately needed to revisit the basics of pronunciation.

This story stuck with me because it illustrates the problem with the bucketing approach you see in online courses. Once you decide there are 3 buckets, or 5, or 10, “personalising learning” means hunting for the right bucket to stuff someone into, because it’s the best fit for them.

We can do better than that.

Expertise Is Not Optional

So what would be the ideal way to invest in the people in my team? My initial thought was that it should take the best parts of pair programming, but it would have to be with an external expert, so that my team would be challenged and stretched, without the seniors losing productivity. And it should focus on the things my team needed to know, rather than the occasional questions that might arise while pairing. I tried to work out why this felt like the best solution, and landed on five reasons:

1. It’s focused on the tech we actually use, developing their skills by solving relevant problems.
2. An expert can ask difficult, stretching questions of the learners, give feedback, and help them past obstacles by tailoring explanations to the areas they’re struggling with.
3. The pairing would happen in short blocks around my team’s ‘day job’.
4. It gives even senior developers ‘aha’ moments where they discover something they didn’t know they didn’t know
5. It’s focused on things my team actually need to know — no more wasting their time sitting through “the basics” again.

Point 2 in particular seemed impossible with the way that online courses are set up. They aren’t live, and they don’t have an expert to answer difficult questions, and stretch each participant to discover what they didn’t know they didn’t know.

In my team, the highly motivated learners started courses, grew bored with watching videos and copy-pasting the almost-answers provided, or became disillusioned with sitting through things they already know. They dropped out (like the majority of people who start online courses).

My view was that focused, expert-led, hands-on learning would mean that my team came away completely ready to do something completely new. And the right approach would apply equally to the juniors right through to the most senior developers. Even the most expert programmers still have things to learn.

Finally, and perhaps most importantly, online courses can only teach you what you were looking for. But we all know that to really grow you need to learn the things you don’t know you don’t know.

Whale Hello There 👀

That inspiration grew into the concept of a live learning platform for tech teams with short expert-led sessions, flexibly scheduled and focused on each individual’s needs. My friends and I all like awful wordplay so we decided to call it Skiller Whale.

I wanted to offer the kind of learning that would have a ~100% completion rate, give people immediately usable skills, and guarantee that nobody wastes a single hour learning something they already know.

To me, this all sounded like the best thing since sliced bread, or wheels, or when peanut butter met jam, but I hadn’t banked on the biscuit problem.

Read my essay “I Was Told There Would Be Biscuits” to see how learning can change what a team is capable of. And, well, biscuits.

If you’d like to know more, or are interested in joining our team, get in touch through the website or by emailing hi@skillerwhale.com