I Was Told There Would Be Biscuits

Why traditional training doesn’t work for developers, and how I discovered a new model of learning. Also, biscuits.

In my previous essay, I wrote about how tech teams don’t learn. I don’t think it’s a secret that many training resources don’t work. So why do tech leaders put up with it, and pay for resources that they don’t value?

The answer started to become clear when I listened to how some CTOs, VPs of Engineering and other tech leaders talk about learning. Here are some quotes:

“Training isn’t a priority”

“My team doesn’t have time for training”

“Our team just need to read the documentation”

“It’s better to just learn things as you go”

“I don’t have time to get my team skilled up — I just need to hire someone”

“My team are senior, so they don’t need training”

“Learning is a perk, like office biscuits”

Learning ≠ Office Biscuits

Meme from the 1999 film ‘Office Space’ in which a disappointed employee says “I was told there would be biscuits”
Meme from the 1999 film ‘Office Space’ in which a disappointed employee says “I was told there would be biscuits”

There is a foundational belief behind these responses that training has no direct value for a tech company. In this worldview, training is a perk to help retain staff, like free beer on a Friday or the odd packet of chocolate bourbons. In this worldview, training is an optional, low priority perk, deserving of little time, attention, and budget.

In fact, some people actually see traditional training as less impactful than reading documentation, trawling through Stack Overflow, or waiting 3 years to learn on the job.

These people have probably encountered, and been stung by, the ineffective forms of training that I described in my first essay on this topic. That experience had no impact on people’s work, so they assume all “training” will be a waste of time.

Tech leaders that I speak to still pay lip service to it, because despite it being of low value to them, they know (or at least they should!) that professional growth and development opportunities are the second most important aspect of a job to developers (just behind having a good work-life balance). As a result, many CTOs see this box as ticked by subscribing their team to Training as a Perk (is the acronym TaaP taken yet? No? Good.). TaaP services typically take the form of a big bumper family-sized tin of recorded lectures that developers can pick from whenever they choose.

Training as a Perk providers use the same model as a gym membership, where the majority of customers barely use what they’re paying for. That’s only possible because training isn’t central to how the companies that use them operate. It’s a nice, yummy, fringe benefit designed to attract and retain talent, by giving them the sensation of personal development. It matters to offer it to your team, but it doesn’t matter if they don’t use it.

This essay is about a model for learning that is core to how a team functions, not a peripheral perk.

Learning as Core (not Training as a Perk)

I’ve spent the last couple of years thinking about what learning could be, and what it could mean for a team. I thought about the problem-based learning models I’d experienced in tutorials at Cambridge University, where I was set hard problems to try, then would sit down with a PhD student to help debug my understanding. Those were where all the real ‘aha’ moments of learning happened for me. I also thought about the few times in my professional life when some learning had really clicked for me.

In the spring of 2018, I sat down with a friend who used to run an international training company, and talked to her about this over several coffees. We ended up using the back of a crossword to write down a list of things I didn’t like about ‘Training as a Perk’, and an imagined alternative, which I’ve called Learning as Core.

For anyone concerned: yes, we did finish the crossword later 🤓.

Any one of the elements on the right could be found elsewhere. You get access to an expert when you attend a lecture; you get hands-on practice with tools like Codecademy; you get to learn from mistakes live when you do pair programming. “Learning as Core” doesn’t have any one new idea; its power and impact is in bringing all of those elements together.

I left this coffee-fuelled crossword-filled conversation with the seed of an idea which would eventually turn into Skiller Whale. I started trying to learn as much as I could about how CTOs and Tech Leaders thought about skills acquisition for their teams, and what they needed (or wanted) their teams to have. After a year of working with my first customers (Nested, Pension Bee, Hubble, thank you for being guinea pigs — you will forever have a special place in my heart!) I had refined my prototype and teamed up with my co-founder Dave. Then, in late 2019, I met Reuben, the Head of Engineering at Plandek and got some real data to back up my theory.

After using the Skiller Whale methodology with his team for 12 one-hour sessions delivered across 8 months, he saw a 4x improvement in cycle and delivery time, reduction in tech debt and an overall improvement in code quality. Read about it here if you enjoy a good graph.

Training Capability development

My work with Plandek gave me a lot of confidence that this new model for learning — one that’s intentional, aligned with the priorities of the CTO, and built to fit with how the team works — can actually change what a team is capable of.

Plandek told us that they think of this learning as “team capability development”. That’s the name we now use internally. I liked this as a description because developing the capabilities of a team would never be thought of as a perk.

Thinking about the alternative brings to life just how far this is from a perk. A friend — and CTO — Fergus Doyle, recently said to me:

“The biggest risks when introducing new technologies are the need to rely on people who aren’t in your trusted team, and the cost in lead time for hiring and on-boarding (a large part of the forming, storming, norming, performing cycle). If I could introduce a new tech using just my existing team, I’d massively reduce my risk, and save myself a lot of time and hassle.”

When I was a CTO, I instinctively knew that learning could do so much more than keep the team cheerful. Now, I realise that it should have been at the absolute centre of my strategy.

If, like me, you think words are cheap and you’d like to see the approach in action (or if you just can’t resist a good pun), you can book into a free session here.

Co-Founder & CEO of Skiller Whale; published curriculum author and keen funk saxophonist.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store