Discover more from Refactoring
Skiller Whale — Inventing the Future of Tech Learning 🎓
The story of the company that wants to change how engineers learn.
Hywel Carver knows CTOs like few others.
He has been CTO at various startups for 10+ years, he coached others, and for the last 6+ years he has been running a community of CTOs who meet for dinner and problem-solve together.
He is also the CEO and co-founder of Skiller Whale — which is the reason why we met a few months ago.
Over his career, and by talking with other leaders, Hywel gradually became obsessed with one problem: how engineers learn.
On paper, training engineers on your team is a no-brainer, with fantastic ROI:
⚡ It improves productivity — by adding new capabilities and improving the existing ones.
🚪 It reduces turnover — by helping personal growth and making people happy.
Yet, extremely few companies invest in regular training, and when they need to add a skill/capability, the only option they consider is hiring.
There are reasons for that, and Hywel wants to fix them.
Skiller Whale is a peculiar company and one of my favorite products. In the past two months I sat down with Hywel, his co-founders Dave and Hayley, and other people from the team, to learn more about how they work and their unique insights about this space.
So, this article is a deep dive into Skiller Whale’s culture, processes, and product, and an insightful conversation about the future of tech training.
Here's what we are going to cover:
🔮 Vision — why training is broken and companies default to hiring, and what the future of education looks like.
🎨 Product — a unique approach that blends technology and human interaction, and stays focused on business value.
🔄 Processes — a case study on the unique workflows of a 100% remote, globally distributed team, where almost everybody is an engineer but very few of them are actually working on Skiller Whale’s app!
Let’s dive in!
This piece was written as part of the 🌀 Refactoring Partner Program.
The program is an opportunity to work with exceptional engineering teams and write deep case studies about the way they work.
You can read about the guidelines I adhere to in the link above. I always note partnerships transparently, and only share my genuine opinion.
As a Refactoring reader, if you decide to try Skiller Whale, you get 50% off for 6 months. Redeem the offer below 👇
🏋️♀️ Training is broken
As an engineering team, there are many situations where what you need to build requires some skill or capability that you don’t have.
You want to level up the impact of your data science efforts. Your team can put together some scripts but most aren’t experienced with production-grade Python.
You want to develop a mobile app for your service. The web app uses React and you would go with React Native, but no one has ever worked with it.
You want to adopt API-first practices throughout your apps. You have relied on one or two senior engineers to start implementing this, but they are now a bottleneck, and having well designed, maintainable APIs across all your services is critical.
In my experience, the default option in these cases is hiring. However, this isn’t always optimal — or viable at all. For some positions there might be a few candidates (e.g. React Native), or you may not need a full-time hire (e.g. API-first practices).
Also, hiring takes a lot of time — when you factor in onboarding and ramp up — and money.
The main alternative to hiring is to teach those skills to your engineers. Over the years, Hywel tried the most common options out there, but the outcome hasn’t been great:
1) Online courses 🖥️
Courses on platforms like Udemy or Pluralsight are popular for entry-level training.
These are largely passive, and interaction is usually limited to copy-pasting some code examples. This is by design: since courses are one-size-fits-all, and there is no human in the loop, you can’t give people hard problems, because you can’t help those who get stuck.
2) In-person training 🧑🏫
Regular training has a higher grade of interaction, but it is optimized for the teacher’s convenience — that is, you put people in a room for a full day, and it’s done!
Retention is still low — our brains simply can’t retain 8 hours of new information — and the feedback loop is limited to some exercises during the session.
3) 1:1 coaching 🧑🤝🧑
Coaching is at the other end of the spectrum. It is bespoke and tailored to individual needs.
However, it has two main problems:
Expensive — 1:1s are obviously expensive and most companies can’t afford to use them at scale.
Theoretical — coaching mostly happens through conversations. You don’t have a hands-on dimension that helps learners with technical stuff.
So, coaching in our industry is used sparsely, mostly for upper management and leadership roles — because it makes more financial sense, and because it lends itself better to managerial challenges, rather than technical ones.
For all these reasons, in most companies, learning is treated as a perk, with no expectations attached. You may have an education budget and buy an O’Reilly sub, but your job doesn’t depend on that.
Is there a better way?
🏗️ The ICAP Learning Framework
In 2014, Michelene Chi introduced the ICAP framework, which demonstrates how higher student engagement leads to a better learning outcome.
Based on the framework, learning experiences can be organized into four main categories, in ascending order of engagement, and, therefore, effectiveness:
🔴 Passive — experiences where you are just exposed to some learning material, like a book, or a lecture.
🟡 Active — experiences where you have exercises to complete as part of your learning like regular online courses.
🟢 Constructive — experiences where you learn by doing. The building is a core part of the learning process, like in a workshop.
🟣 Interactive — experiences where constructive learning is augmented by asking questions and getting continuous, real-time feedback, like in pair programming.
Interactive learning leads to the highest retention, especially in areas that are very hands-on, like tech skills. However, such experiences are hard to design, because to build something meaningful that involves new capabilities, people need strong guidance and a tight feedback loop — to avoid getting stuck.
To solve this problem, enter… Cambridge!
🐋 The Skiller Whale Way
Hywel, Dave, and Hayley, the three Skiller Whale co-founders, all studied at Cambridge.
Hywel told me that, at that time, courses organized sessions where students worked in small groups, led by a junior professor. The junior professor acted as a coach, guiding other students through the material, and correcting them when needed.
Years later, when designing an effective way to upskill engineers, he took inspiration from that experience.
So, Skiller Whale runs live sessions of coaching to small groups of engineers, about specific technologies. During each session, a coach works through engaging material that has been carefully crafted in advance, and supports the engineers as they tackle challenging exercises.
All of this happens in a custom product that blends conferencing and coding, so engineers get live feedback from the coach. Exercises done by learners during the session are stored in a remote repository and associated with the respective authors. So, the feedback loop between learners and coaches combines live interaction and async back and forth.
The Skiller Whale approach is based on four main qualities:
1) Interactive ⚡
Interactive sessions, with a coach, guarantee better retention than passive courses. People can ask questions, and, crucially, the coach creates a feedback loop that allows for more challenging material and exercises.
2) Group-based 👥
Learning with others has two big benefits:
It drives more motivation through accountability, and is
Cheaper than 1:1 sessions.
Small groups of 3-6 people are the sweet spot that guarantee high quality learning while being sustainable for companies.
3) Business-oriented 🎯
Each collaboration with Skiller Whale starts with business goals. What does the company want to achieve? The team agrees on some business KPIs, and these will be reviewed in a given timeframe (e.g. after 6 months), to measure success.
Such KPIs might be about engineering productivity — e.g. cycle time, PR turnaround — or the delivery of a product/feature that requires the newly acquired skills.
4) Personalized 📐
After setting goals, Skiller Whale runs a detailed assessment of the engineers’ skills around the chosen technologies.
Based on the results, a curriculum is created by including only the parts that are relevant to the learners, and to the goals.
Skiller Whale doesn’t create completely custom curriculums for companies — it assembles them, by putting together parts from an enormous, fine-grained body of learning material, that they hand-crafted for the various technologies (more on that later).
Then, curriculums are batched into 1-hour sessions, usually held every two weeks. This cadence gives people time to apply the learnings to their actual work. During the sessions, actual code from work gets reviewed and receives feedback from the coach.
🗺️ Remote-first + globally distributed
The three Skiller Whale co-founders all studied in Cambridge and live in London. Yet, they envisioned Skiller Whale to be a remote company from day one.
Other than personal convenience (e.g. all founders have 2+ kids) they just knew that Skiller Whale would grow into a distributed company, because of the very nature of its product. In fact, learners are available anywhere, so coaches should be, too, and so should be people in sales.
Today, Skiller Whale employs 19 full-time people, plus a network of ~30 coaches. The company doesn’t have an office, and has employees in Hong Kong, India, Ireland, Spain, Italy, UK, and more.
The coaching team is bigger than the rest of the company, and is made up of senior engineers who usually work other jobs alongside the coaching. This makes their availability only loosely correlated with location: there might be coaches on the same UK timezone as the founders, but who prefer to work in the evenings.
Skiller Whale’s uniqueness, as a tech company, is that the vast majority of people on the team are engineers—40 out of 50 people—but only a few of them work on the app. In fact, most are either coaches or on the curriculum team — where the latter creates the learning material to be taught by the former.
So, let’s look at how these teams work together 👇
🔨 Tech & Product dev
Dave, Skiller Whale’s CTO, walks me through the tech behind the company.
The user-facing app, that powers the actual sessions, is written in Rails + React. Dave cares about not reinventing the wheel, and they chose Rails because it is quick to build with and extremely battle-tested. They store data on Postgres and Redis, run their CI/CD on CircleCI, host the app on AWS, and use Terraform for the provisioning.
A separate app hosts the curriculum content, acting as a CMS for the various modules. This is maintained by the team of engineers who work on curriculums — and is entirely decoupled from the coaching one, interacting with it through JSON API.
The curriculum team is extremely polyglot, as they need to develop content for a variety of technologies, so, the base app is written in Python + Flask, which was an easier lingua franca to work with than Ruby + Rails.
Coaching material is version-controlled and content gets updated via PRs, going through a typical code review process. This is mostly handled by the curriculum team, but coaches may occasionally submit PRs to suggest changes/updates to the parts they teach.
Overall, Skiller Whale’s engineers belong to three groups:
💻 App team (3 people) — they build the main apps that power the sessions, assessments, and management of coaching plans.
📚 Curriculum team (6 people) — they are experienced engineers who create the coaching material, demo apps, and exercises that get taught by coaches during the sessions.
🎓 Coaching team (> 30 people) — they teach the learning material created by the curriculum team, on the platform created by the App team. This group are not full time coaches — they are expert senior or lead engineers working elsewhere, who want to spend a few hours each week coaching other engineers.
These teams all work independently, but share constant feedback with each other. Engineers may also occasionally jump in and contribute to another layer. E.g. a coach may submit a PR to change some content, or a dev from the curriculum team may push a fix to the main app.
The app and curriculum teams, both made up of full-time employees, work on a weekly schedule. They run daily standups and a 1 hour meeting on Monday for review + planning.
Together with the coaching team, they all work on shared company goals 👇
Skiller Whale runs quarterly OKRs for the whole company.
Marco, Head of Engineering, tells me that OKRs are participated by all the teams: higher-level objectives trickle down into objectives and key results for the specific teams, and the teams themselves contribute to creating them.
The process goes like this:
The leadership team defines company objectives.
The various teams define KRs for those objectives, which are challenged and improved through discussion with the leadership.
Within each team, Objectives and KRs are created to contribute to the wider company ones.
The whole tree of OKRs is then shared transparently across the company.
For example, a recent company goal has been about making the initial skill assessment easier for customers. Both the curriculum and the app team contributed to this goal, in different ways:
The curriculum team had an OKR about improving content clarity.
The app team had an OKR about improving the UX of the assessment flow.
The whole goal-setting process is grounded in the tons of feedback that the team collects, both internally and externally, about the product.
Here are the main sources:
Session feedback — after each session customers provide a happiness score and individual scores about the content quality and coach quality. Likewise, the coach votes on content quality, too, and on the ease of teaching.
Sales — people on sales and customer success teams maintain a database of companies organized by the team size and tech they work with, and receive input from current and prospective customers.
Business Intelligence — analytics about how people interact with the app and the materials.
Coaches — other than scoring individual sessions, coaches are extremely vocal about content and app improvements.
A lot of these inputs, like session feedback, are expressed with numeric scores (1-5) that can be directly used to set quantitative KRs. For example the curriculum team may aim at getting an average score of 4.7, from coaches, on content quality and ease of teaching.
I know many tech leaders who despise OKRs, feeling they are cumbersome or too heavy for modern teams. Personally, I believe they can be extremely good at creating alignment and rallying people towards shared goals. This is important in all companies, and even more so in distributed ones.
OKRs, stripped away of all the bells and whistles, are just a way to create good goals and make sure people know how they are contributing to them.
I spent several weeks researching and talking with people on the Skiller Whale team.
I genuinely love their approach to coaching and I would use it myself if it wasn’t for the fact that… I don’t have an engineering team anymore 🥲
Still, they are in for a tough challenge.
Training is not on many leaders’ minds. These have been trained (pun intended) to think that training belongs to the perks budget, rather than as a genuine alternative to the hiring one.
To be successful, Skiller Whale not only needs to create a fantastic product — it also needs to change companies’ posture about upskilling itself: from perk to strategic asset.
Doing both is hard, but as Hywel told me: “on paper, they may not get it — but when we demo, they get it”. That’s the only thing a founder needs to hear.
As a Refactoring reader, if you decide to try Skiller Whale, you get 50% off for 6 months. Redeem the offer below 👇
See you next week! 👋