In our latest Digital Lighthouse episode, Zoe Cunningham is joined by Hywel Carver, founder of Skiller Whale. This organisation provides deep coaching for tech teams, believing that learning that is core to how an engineering team operates and should align with business priorities. In our conversation, Hywel discusses why Skiller Whale came about and how to make the most of any tech training for your team.
Digital Lighthouse is a mini-series of Techtalks brings you industry insights, opinions, features and interviews impacting the tech industry. Follow us to never miss an episode on SoundCloud now: See all the Digital Lighthouse interviews online for free on SoundCloud
***
Transcript
Zoe:
Hello, and welcome to the Digital Lighthouse. I’m Zoe Cunningham. On the Digital Lighthouse, we get inspiration from tech leaders to help us to shine a light through turbulent times. We believe that if you have a lighthouse, you can harness the power of the storm. Today, I’m super excited to welcome Hywel Carver who is the CEO at Skiller Whale. Welcome. Hello.
Hywel:
Hello. Hi. Sorry, I am super excited to be here.
Zoe:
Amazing, so welcome to the Digital Lighthouse. Can I ask you to start by telling us a bit about you and about Skiller Whale?
Hywel:
Absolutely. So, my background is really in software, as you know, because there used to line manage me!
So, I’ve been writing code since I was nine. I studied engineering at university specialising in Information Engineering and have worked in software, mainly as a CTO in startup and scale up companies for most of my career. And now I’m one of the founders and the CEO at Skiller Whale as well, where we do deep coaching, which is individually personalised hands-on learning sessions with a live expert, delivered remotely in one-hour chunks for people to learn and get better at writing software, and really, for technology teams to learn and get better at writing software.
Zoe:
Amazing. So, I come from a very particular perspective regarding training. And I suspect you do as well. But let me just start by saying, is there ever any reason to not train developers?
Hywel:
I have probably the same concerns with you about the word ‘training’. I think it’s almost a dirty word.
Because the things that you think of when that word comes up are really dry and boring. To me training conjures up a room. And there are people sort of watching the clock, while someone at the front is lecturing them. And no one is getting anything out of it. They’re all just waiting for the end of the training session.
So with that caveat out of the way, if we talk about learning and said ‘is there any reason not to help developers learn?’, I think, possibly not. If maybe your developers are only with you for a very short amount of time, that might be a good reason for not investing in their learning, because typically, time spent learning is time away from being productive. So if your developers are going to be leaving the company soon, or maybe on a fixed length project, you want to maximise their productive time and minimise their learning time, then that might be a reason to not do it.
But on the whole, if the learning is good, then the payoff with it will be worth doing. You know, if the learning is right, then you can spend a few hours learning every month and that will pay for itself many times over and very quickly.
Zoe:
All right. So now we’ve covered that, what are the main reasons for training developers? And do you need to have a different training strategy? Depending on what outcome you want.
Hywel:
Yes, I think you do. So, the main motivations that I see are either sort of bottom-up. There’s a sort of cost reduction element, which is about avoiding developer churn. So it’s giving training as a way for people to stay in their jobs and get all the sort of nice things that come from broadening your horizons, seeing the perspectives.
And that form of training is really about an employee perk. A way of giving people that option of seeing what else is out there, like ‘Sure in my job, I have to do this. But at the same time, at least I get to be seeing these other things that are out there’.
And I think the other perspective, unlearning is about enabling strategy. If your technical strategy for the year or the quarter. or whatever, involves transitioning to this technology or getting better at this aspect of it. If you want fewer bugs hitting production, so that people spend more money and don’t hit a bug along the way on your site, then the way that you can enable that is by having a team who is better capable of avoiding those bugs or fixing those bugs.
And I think the way that you think about their things needs to be really different. It’s the difference between a gym membership and coaching. It’s the difference between giving people access to a platform where they can go and look at whatever videos interests them, versus very targeted specific focussed learning that is enabling the tech strategy, that is getting the team to the place where you need them to be in their skills.
Zoe:
Perhaps in most cases, or many cases, you actually want to offer both, or there’s scope for offering both right, because you’ll have different people within your organisation with different needs and you want to kind of mix strategy.
Hywel:
I think yes, although I think that for people with different needs, I think the right approach to learning will cater for them in the same way.
So one of the reasons I’m quite allergic to the concept of ‘training’ is because it’s often so undifferentiated. It’s the idea of having a course, or maybe at best having three variants of courses, right, we’ve got the junior, the intermediate and the advanced. So you pick a thing that can be trained, I’m going to choose Python. And there’s like the junior Python course, the intermediate Python course and advanced Python course. And now what training looks like is really working out which of those boxes to put each person in.
And I think actually really good learning can look like saying, ‘Well, you already know about this aspect of very advanced Python. And there’s this other aspect of, it’s actually quite fundamental that you’ve not really grasped and fully grasped’. And the right approach to learning is catering to every individual’s very specific needs to just fill those individualised gaps, which, you know, we can talk about as a process.
But essentially, I think that’s what good learning would look like. It’s taking people, and whatever needs they have, and never saying ‘well, you just fit into this box’, and instead saying, ‘we can create the box that fits you’.
Essentially, we can come up with a custom plan that works for what you want. And then at the same time, you also want to have retention, you also want to give people who do want to see that broader scope of ideas – and who do want to have their horizons broadened and who wants to experiment with things that aren’t going to be relevant to their job at all – you want to give them a place to do that because other companies are offering the same thing.
And so yeah, I think for that reason, you might well want to have a next strategy where you offer people this like, focused, targeted form of learning, but also give them the option to go and be exposed to new ideas.
Zoe:
And what about because I think actually, something that happens quite a lot is you get this kind of top down training approach, and someone rocks up and says, ‘Great, we all need to be trained more, so we can be more productive’.
And that can generate quite a lot of resistance. And I wondered, what’s your kind of advice for helping developers who maybe resistance training, I think you’ve covered a couple of bits already, like calling it learning rather than training, for example, but what else can you do to really get people bought into it?
Hywel:
So one of the things that people look for most in their work as a developer is the opportunity to learn. And when you ask people about what they want from training, the most common answers involve things like training that’s personalised to them and training that’s kind of flexible on location.
So I suspect a lot of resistance to training comes from all of the associations, all of the negative associations with that word, and the world it conjures up in your mind. So I very rarely see people who aren’t enthusiastic about learning. But I do find people who are not keen on the idea of training.
And if what you’re doing does follow that approach of being slightly undifferentiated, and very kind of top down and mandated, I think there are still ways that you can soften it. You can make it opt in, you can talk about all the benefits of it, you can talk about growth. I mean, in some larger companies, 60% of training budget gets spent just on travel and so you can make training be about the opportunity to go somewhere else, and to see a new location or to go stay in wherever the training is happening.
So I think there are ways of making training look like something else. But there’s also an option of just saying, ‘what we’re doing isn’t training, it’s really different’. And actually, that was a lot of the thinking behind our approach of deep coaching.
Zoe:
So the other challenge that I think crops up quite a lot is we all know, we have to hire more junior developers, because there’s only so many senior developers to go around and we’ve got to get more people into the industry.
But you’ve got this challenge, then that junior developers have been brought into really busy delivery environments where they really need to be up and producing and, you know, closing off story points almost from day one. So what’s the best way to bring juniors in and support them in that kind of environment?
Hywel:
I think you have to embrace the fact that they are going to need to learn and learn in lots of areas, and that they’re going to make mistakes along the way.
And if you start to divide that up, some of that will be just general, office, interpersonal time management, self-management skills that you take for granted when you’re later on in your career.
But when you’re early on, actually knowing the right time to ask questions and the right person to ask them the right way to approach them are all new skills that have to be learned. And so giving people mentorship to help with that, to help answer those very practical questions is really important.
At the same time, a lot of organisations will have a whole lot of context that people have to pick up before they can start working on a problem. So imagine you’re working on a travel booking system: there’s a lot to understand, like the terminology, what counts as a customer versus a partner versus a supplier, which suppliers are the ones that are like easiest to interface with, which customers are the ones we have to manage most carefully, as well as all of the terminology of the code base that they’re using.
And so having really strong documentation is important for that, and having mentors who can point people towards that documentation, as well as encouraging lots of peer learning for that kind of domain specific context.
So having things like a care programming, that’s what I’m thinking of where those juniors can start out watching someone who’s more experienced, develop, and can ask them questions about what they’re doing, you know. Why are you solving the problem in this way? Why did you need to make the change of air rather than over there? Why are you writing the tests first, rather than later?
And then there’s also just the general software skills, right, which are different to the general work skills, and a different to the domain specific skills. And I think there the key thing is to balance the learning with the being productive, because I don’t think we can expect people to spend 100% of their time, just in being productive when they’re starting out, possibly ever.
But I also think it’s infeasible to say, well, you just get the first month of being here just on learning. It’s actually not very effective for learning either, when we’re learning new things, what we need is an opportunity to put them into practice, before we learn something else. And so I think the ideal approach to them learning those general skills looks like a continuous drip feed of new learning and understanding, which they’re then able to quickly put into delivery and into those story points.
And one of the approaches I’ve seen work really well for that is for people to tag maybe not entire features, but bugs and improvement requests with a system that says this is an ideal first bug. That’s something that GitHub encourages for like public repos. And if you do that internally, as well, you suddenly start building this collection of things that are amazing for those junior devs to start working on, when they first join.
Zoe:
Yeah, great. So it’s not just a question of finding some training and sending people on some training or writing out a big list of, ‘you need to learn this, and this and this, and this’. Actually, if you can integrate it into your working practices, that’s the most effective way of learning because you can both start deploying the skills immediately.
And also, with pair programming, you kind of talked about context and implicit information. There’s no way write all of that down, you almost need to get that from interacting with other members of the team and coming across it when it’s relevant.
Hywel:
Right, there’s a whole lot of wisdom that the team has a whole lot of kind of context specific judgement that people are making about, ‘oh, I would implement that over here in this way because that fits our model’, that is very hard to record. All of those kinds of constant small judgments that are involved in that kind of decision making, I really had to write down.
And yeah, I definitely think you don’t want to have learning that is separate from implementation, because, if you take a month to learn something, you’ll remember the first bits pretty well and then some of it will be slightly over your head and will not make sense to you because those first bits are still relatively new, and the latest stuff will just be way beyond what’s useful to you at the time. And so that will just go over your head as well.
And so you end up with large packets of learning, being divided into the stuff I already know, the stuff that’s at the right level for me, and therefore useful and feels relevant. And then stuff that just doesn’t apply to me at all, as far as I can see, because it’s too advanced, it’s too much of a leap from what I’m already really comfortable with.
And so you want learning that is, as you said, integrated, that is relevant to the work but also relevant to my current level of abilities, so that I am at the kind of bleeding edge of what I know and to have a chance to go and use that stuff, before I learned something new.
Zoe:
So much training is around training to write code, to output more code and better code, and there’s a lot more that goes into being a software developer than that.
So what are the other kinds of skills? You mentioned basic work skills. What are the other things that you’d expect developers to start to need to learn as they progress their careers?
Hywel:
So I think there are some of those skills that are very interchangeable, transferable between different programming languages.
So one of the ways that I think people grow most between being early in their career and late in their career is things like their abilities around debugging and around testing effectively. And around designing and architecting code, which are the things that traditionally, we’ve learned by almost trial and error. We try as a way of doing things and then, you know, a year into the project, we kind of turn around and go, ‘Oh, I wish we hadn’t done it that way’.
And I think if we can accelerate those ways of learning, those are great, but they’re a bit more of a meta coding skill than a coding skill itself. But then there’s also all of the learning about process. You mentioned story points. And even the concept of story points, actually requires quite a lot of explaining and learning to really understand the idea behind a story as a useful way to communicate work that needs to be done and the idea of story point, as a useful way to measure it. Those are things that you really need developers to have a very strong intuitive sense of, and are quite difficult to learn.
So you can send people on a kind of Scrum training course, for example, and that will get them to know the ceremonies that they need to undertake. But I don’t think it can teach them the wisdom to make the right judgments about story points, for example. And that’s something where you do need the existing developers to step in and help. So I think there’s there’s general work skills, but there’s also those sorts of software teams specific skills, like the language of Scrum, or agile and merge requests and git branches.
And all of those ideas together, each of which I think you can go incredibly deep on by itself. And this is where context comes in, that the answer to that question in one company might look very different to another. If the way that you’re using Git in one place is, it’s kind of very light – you know, everything gets merged to a main branch off sub branches, for example – requires you to not know too much about Git. But if you’re using Git, also, if your issue management, and if you’re using a lot more complicated branching, suddenly, you’re going to want to know about rebasing and stashing and merging and editing history. And so I’m just picking on Git here is an example of a topic that you might need to go very, very deep on, and you might be able to get away with a real surface level understanding.
And so part of the answer to that question is really looking at how you work as an organisation and understanding that and working out where you need to go deep and where actually, you can just be like, ‘look, here’s our handbook of the meetings that happened in the week. You can read this and just turn up to the ones and you’ll see how it goes’ versus ‘we’re kind of constantly reinventing our process. And here’s how we think about the trade offs inherent in extreme programming’ versus Kanban, or whatever it is.
Zoe:
Something I keep saying every time I do an interview is ‘software development is complex’. And the more you look into every aspect of software development, it’s complex, right? Including, how do you help people learn more about software development. And I think we must have used the word context so many times. And I think it’s so important to realise that there are so many limitations to a one-size-fits-all, one-order-fits-all, one-structure-fits-all, actually, the more flexible you can be with your training. And the more you can tailor it to what the developers need to learn literally right now, the more effective it’s going to be.
Hywel:
Exactly. You want to be at the intersection of their current level in their skill gaps, and what’s useful for their work and what the company needs from them. Because then you can learn something that’s genuinely new and put into practice straight away.
And yeah, I mean, I am a strong believer in the idea that context is critical for everything. So I ran up a series of dinners for CTOs before the pandemic over three years, as well as being a CTO, myself and coaching other CTOs, and kept seeing the same problems coming up again and again, but feeling like they require different answers every time because of the fact that the contexts were so different.
And I believe that to the extent that when I started hosting my podcast, we named it primarily context based on the ground. So the interesting decisions for leaders are about looking at your context, and working out how to make that decision, given the unique things that are in your context.
Zoe:
Exactly. So I get asked a lot by people who are new to the industry as someone who obviously has been in the industry for a long time. And they want to say, ‘what’s the best way to get into the industry? How do I get ahead?’ And the one question that comes up all the time is, ‘what is the best language?’, because I’m often giving the advice of, you know, you want to be able to demonstrate your coding skills, you want to be able to demonstrate that you have a passion and you love it, and you can do it. And so what’s the best language to teach yourself? And then what’s the best way to go about it?
Hywel:
Oh, my goodness, I find this question so hard to answer because I think of the things I wish I had learned earlier, and which when I did learn felt like they were force multipliers.
So as I’ve got better at bash, right, my ability to do stuff more efficiently with my computer has got a lot better. When I eventually forced myself to learn how to use Vim. I think I became a much faster developer. But those are both terrible answers to someone who is just getting into the industry.
And my instinct, and I’m hedging. I’m thinking of two languages. My instinct would be to say Python or JavaScript. JavaScript, because it’s universal that you can write front end code back and code. You can even write database code that’s written in JavaScript, and therefore, it’s the sort of least limiting in a way.
But then Python I think, is something that there’s a constant need for, right? There’s a need for back end developers. It’s a really nice language in lots of ways. And it also is becoming more and more useful because of the rise of people using it for machine learning, data science, AI. So I think one of those two feels like, if employability is your goal and if going to interviews and being able to write good code to solve a problem is your goal, then I think one of those two. But I suspect if you asked me tomorrow, I’d come up with a different answer.
Zoe:
Any particular places you would go to learn them? So I think codeacademy.com does JavaScript, for example.
Hywel:
Yeah, I think it doesn’t need to be Python as well. I believe you can learn Python on Code Academy.
The thing about both of those languages is there are so many resources out there that if you’re willing to come up with a side project for yourself, and you’re happy to kind of stumble and muddle your way through it, then I think you can find resources to help you with each problem that you hit along the way. And it won’t be the most efficient way to learn those things. But what you will start to get is the mental map, the like number of links in your brain will increase very fast, because one of the things that happens when you Google around a problem is you start to see the adjacent topics that you didn’t know were part of the solution.
And so maybe your problem doesn’t really need you to understand the difference between the stack and the heap, or between a compiled versus interpreted language. But by searching for the problem, you will sort of broaden your horizons in that way, and start to see more answers than you would have looked up yourself. I guess, if you’re looking for a way that’s going to lead you through writing an entire project, Why’s (Poignant) Guide to Ruby, I think is a really nice way to learn as well.
Zoe:
Fantastic. I think that’s super helpful advice. It’s back to how we were discussing learning within an organisation as well, right. Work on a real project. Make a real piece of software. And of course, it has this added benefit that you’ll learn the skills of stumbling along and muddling through, which are essential software development skills.
Hywel:
Absolutely, I mean, I think that’s what people spend most of their time doing writing software.
But I mean, there’s good theory behind it as well, in terms of motivation, having an aim in mind that you care about will help a lot. If you want to code and nice way of looking at all of the books you have on your shelves, and you’re willing to put the time in into listing them, then that’s a great project to have, because you’re gonna care about getting to the end.
And in terms of learning, there are models for how you learn best. And so what you’d be doing here is what’s called constructive learning. You’re not just absorbing something like reading it or watching a video, which is passive learning, you’re not just kind of interacting with the materials while you do it, like taking clips from a video or highlighting something that you’re reading. You’re trying to build with what you’re doing, constructive learning.
And in an ideal world, you’d also get other people involved, maybe find a community to build with, or someone who’s already in software, and get their help, because interactive learning, the form of learning that is constructive but involves humans, gets the best learning outcomes. And so if you can aim for that, you’ll learn not just fast, but you’ll learn thoroughly and effectively as well.
Zoe:
Amazing. That’s fantastic advice. Okay, just finally, we’ve been talking a lot about junior developers, but how can we make sure that senior developers are also getting the learning that they need?
Hywel:
Yeah, I love this topic. Because I think one of the things about being a senior developer is you don’t know what you don’t know.
Because often the more advanced bits of learning give you new ways of solving a problem, you could have solved another way. Like when your junior if you don’t know how to read in a file, well, you’ve just got to find a way to read in that file. When you’re senior, you might know a way of reading a file, you might not know that there’s a nicer way of doing it.
Like I’m thinking of Python again. So like, context manages, it’s a really nice way of opening a file and managing its closing in a kind of neat syntactic way in Python. If you don’t know that exists, you can spend a lot of time writing code in a sub optimal way.
And so one of the things that senior developers struggle with is finding learning that’s effective for them. One of the ways that we try and solve that is by advanced courses. So you can go on a very specialist Python course, say, which is going to be advanced Python, and it’s going to sort of focus on a range of advanced topics. Or you might go even deeper, and it might be like parallel code in Python, talking about different concurrency models and ways of managing that in a given language.
I think you can also take another approach, which is part of our kind of deep coaching idea, which is to assess which bits of Python you already do and don’t know. And I think this is sometimes surprising to people, but there are sometimes things that a junior might have a stronger handle on in a language than a senior because they might have taken it for granted or they might have mentally mapped it onto how something worked in another programming language. And actually, a proper assessment approach can reveal that they didn’t really understand it thoroughly, they didn’t really grok it in the way that they ought to.
But also, the right assessment will cover topics that are genuinely advanced that are exactly those points of a programming language or a technology that give you a new way of doing something that you might have solved in a more basic way, if you didn’t know the advanced way existed.
And so I’m a big advocate for trying to find what those gaps are from a sort of top-down way from saying, ‘here are all the aspects of a language, let’s work out which ones you already know, I’m sure there’ll be lots of those, but let’s focus our time on the few things that you don’t know, because that’s then going to be hopefully really interesting, but also valuable if you can find just those areas’.
Zoe:
And that’s where you want to kind of like, be able to map out the space and help people to uncover those gaps.
Hywel:
Exactly. I think one of the difficulties there, as I said, is people not knowing what they don’t know.
But one of the other sort of knock on effects of that is that the people who are more junior and being supported by that senior person and learning from them, and spending time, you know, doing peer review or pair programming with them, those people also then are missing out on what the most senior people know.
It’s genuinely hard to get seniors to learn any other way. Because opportunities for them to really see the sort of most advanced things other people are doing are kind of slim on the ground and that means that the people who are supported by that person also lose out on those things, and they’re still learn, but there will be gaps and blind spots in each individual’s knowledge that just can’t be filled in until you take the time to say, ‘Oh, we’ve just discovered that you don’t know about this concept. Let’s fill that in. I think you’re gonna find it super useful’.
Zoe:
Fantastic. Well, thank you so much, Hywel. Thank you for coming on to the Digital Lighthouse and helping us shine a light for others.
Hywel:
Thank you so much. I really enjoyed chatting.
