Beyond The Code

Maulik Sailor (00:02.876)
Hey, are you? How are you? How are you doing?

Hywel (00:05.812)
I'm good, thank you, Maulik. I'm very good, thank you. And I'm very glad to be here.

Maulik Sailor (00:10.482)
Cool, thank you. And if I'm just before we begin, know, did I say your name

Hywel (00:16.046)
I go with Hywel actually, so it's Hywel,

Maulik Sailor (00:17.938)
Hywel, yes. Yes, sorry for that. you know, I know you did ask me what my name, know, again, I'm very used to getting my name wrong. And it's all right. There was a time where I will be like not bothered with my name at all. As long as I know somebody is talking to me, I'm okay with that.

Hywel (00:34.73)
Yeah, exactly. My name is Welsh, so there are very few people who know how to pronounce it correctly. You can probably tell from my accent that I am not Welsh, I'm English, and I'm told by Welsh people that even I say my own name wrong. So I don't feel I can hold other people to a high standard when I'm not saying my name right myself.

Maulik Sailor (00:56.008)
Right, I mean, it's weird, know, when your name, I found this myself, you my name is like, not the same name as the most common name, but very similar to it. And then people will just assume and say Malik, you know, all the time. you know, but then over a period of time, I'm like, you know, I'm not really bothered with what they call me, you know. So nevermind. Yes.

Hywel (01:10.624)
Yes. Yeah.

Hywel (01:18.442)
As long as you know they're talking to you, it's the main thing, right? As long as you know you're being spoken to.

Maulik Sailor (01:23.128)
Exactly, exactly. So never mind, you know, I, it was interesting to you how, how do have one of your presentation recently, you know, we were in that event, you were talking about this whole skills based hiring more than the organization. And I thought it would, it would be interesting for us to do a podcast together. And thanks for making time for that. So we'll get into that deeper. But before we go there, why don't you tell us about your background?

and how did you end up doing your current startup?

Hywel (01:57.196)
Yeah. So I think my background probably starts by saying that I really like learning. Like I'm always someone who did, I did quite well in school learning wise. I'm always someone whose hobbies have involved lots of learning. And so I've just always been very passionate about learning and I care a lot about learning and I just enjoy the process of learning. And before starting SkillAware, which is my company, I'm the CEO and one of the co

I was a CTO leading scale up startups for 10 or so years. So I was often the founder. If not the founder, I'd be advising the in -place CTO about growing the company, growing the tech organization, how companies should, early stage companies should find customers and things like that. And I kept feeling

that learning should be more of an answer than it was. I was often in situations where I wanted my team to maybe more full stack so that they would have fewer handoffs and they'd be able to deliver software faster, or maybe just stronger in the technologies we used to take more load off our more senior experienced developers. I remember one team I worked with where they had a team of data scientists and a Python developer.

And the ratio was something like six data scientists to one Python developer whose job was to productionize everything the data scientists came up with. And through no fault of their own, this person was a bottleneck for the team. And it felt so obvious that if we could just make all the data scientists write slightly high quality Python, this person would have less work to do and without having to hire any new people, the team would be able to ship stuff faster. And my realization was

all of the learning that we have access to, all of the training is really well optimized for information. It's very well optimized for giving people new data, new knowledge, new facts, but not for skill. And these are really different things that we have to, we should approach in a different way. And I was lucky enough to be a student at Cambridge University. Cambridge does lectures. Lectures are an excellent way of giving people knowledge. So are podcasts, by the way.

Hywel (04:19.95)
Whereas what Cambridge does really well is as well as your lecture you then go away try and solve problems that relate to what you learned in the lecture and then you sit down with a master student, someone who's a bit bit further ahead in their studies than you, a master student or even a professor sometimes, and their job is to go through the problems you got wrong and work out why you got them wrong and correct your understanding.

And for me, that was where all of the learning of my degree actually happened. It's not when you hear the information, it's when you try and apply it. It's when you try and turn it into the skill and you get stuck. Getting unstuck is how we actually learn to do stuff better. And so with SkillAware, we took that approach and said, how do we scale this? How do we make this available for tech teams? How do we make people more productive, write better code, ship their product roadmap faster?

essentially the model was we take that form of learning and make it readily available to companies that need it and want

Maulik Sailor (05:26.376)
That's interesting. And I have got so many questions based on what you talked about. But we'll start with a few things, right? So I get the idea of your delivery teams or engineering team to more skill space. But I have a notion that at times the technical skills can be learned. The person that you hire, let's say you hire a junior developer,

If it's got the right attitude and motivation to learn, then it can always learn new things, always pick up new frameworks and new ways of doing things and stuff. But often what I find that some people or some developers that are hired, they were very good in what they do, but they don't want to do something else because they think that is going to degrade their skills, existing knowledge about their framework. So let's say, and random example, I hired somebody who was very good in Java programming. And then when

Java was shifting away to more of a JavaScript based Node .js programming, Then in the beginning, they were quite hesitant to try it and say, hey, if you go on to Node, then we'll lose our edge on the Java, right? And so on. What's your opinion around

Hywel (06:42.456)
my opinion. I think I've yet to meet someone who doesn't want to learn. Lots of people don't want to be trained, but everyone I've met wants to learn. But we are picky about the things we want to learn. So I consider myself a polyglot technologist, like I've worked in a load of different programming languages. But if you said part of your job now is you have to learn

Fortran or part of your job now is you have to learn cobalt. My god, like absolutely not. So I have that reluctance and that resistance. I guess I think that a really big, a big part of this is what people's expectations are for their jobs. Because when you take a job right, you have a job description which says here is part of the role. If that person's role is

you're going to be a Java programmer and Java, Java, Java is the only thing that you're going to learn. I think they have taken that with a reasonable expectation that they are going to learn and get better at Java, but not have to learn other languages they don't like so much. And so I feel a bit like that person is not me, but I have sympathy for them if that is how they want their career to go. On the other hand, if they've been hired as

developers specializing in Java, but along the way, we're going to want you to be good at other languages too. Or if they've been told we are, we're making all of our roles into full stack roles and now you need to write front end code in JavaScript or TypeScript, then I think, well, they either are part of that new, new team and therefore need to learn JavaScript as well. And they should, I would say, embrace it. And that's it in that scenario.

or they're not going to be part of that team and we have to find somewhere else either a different team in the same org or a different company for them to work in where they can go and be a full Java developer and nothing else.

Maulik Sailor (08:47.354)
Yeah. So, you know, when it comes to hiring, know, normally, I also believe that normally you should be able to pick up more things, you know, especially when you're working in tech, you know, the frameworks that come in go, you know, there's a particular framework very popular now will not be popular in few years time and something else will come up, you know, that just the nature of tech development, right? So I normally feel that people should

looking forward to picking up new things. Of course, they can't pick up every single thing that comes that way, right? And then I heard this notion of hiring people with T skills, right? So they may be very good with one, one or two frameworks or domains, but then they have enough of their range across multiple frameworks or multiple domains. And I interpreted

these things as like really the fundamentals, right? So I do it like in the worst case. So you need to know like a really solid fundamentals across a lot of different concepts and maybe one or two concepts you need to know really well, very good high experience in that. So when I interview for technical roles, I normally look into their analytical skills, their problem solving skills, their way they approach their problems.

how this construct the whole logic when they are, you know, that they could convert into programming. I rarely check that programming skills per se, you know. Do you think I can change my approach or do you think I'm heading in the right direction

Hywel (10:24.46)
I have lots of thoughts about that. I guess firstly, I want to say that when we talk about picking up a new framework, would say there's a, I would draw a line between picking up a new thing so that you can write some code in it and actually being good at it. Generally speaking, when we employ people, we want them to be good at it. think React is a great example of this, like picking up the basics of React .js. So picking up enough React .js to be dangerous is super easy. What we have found is

actually grokking how like understanding deeply how React .js works and its model for declaring what should be on the page and how you can interact with that in an imperative way sometimes when you need to and how to understand when it's going to do what it's going to do so that you fundamentally it works in the way that you expect and it doesn't subvert your expectations all the time. That is a level beyond what a lot of people get when they just try and pick it up for themselves and

My experience suggests that this is true in most frameworks and in most technologies is there is an amount people can learn to get by, but that is not the same as learning to get good. And generally speaking, we want people to get good. The thing about T -shaped people, this idea that we want people who have a kind

shallow level of ability and lots of things like there's a sort of shallow but broad part of the tea and then there's one bit where they go very deep. For me, I think that's less about being confident that they're going to be able to learn other things or necessarily become full stack, but more it gives me confidence that they can communicate with other people effectively. People who have a very sort of, people who only have shallow knowledge in everything and don't have an area where they're very deep.

I feel nervous about giving that person something for them to own themselves because when someone is really owning something, I want them to be super good at it and I want the people around them to be kind of supporting players. I want them on their own to be able to finish something end to end. On the other hand, people who are only have that depth without the breadth, I worry about their ability to interact with other folks in the team.

Hywel (12:43.362)
To pick an example from my own experience, I've written mobile apps, but I'm very much not a mobile app developer. So would say I have shallow knowledge about how Android and iOS apps work. I can probably communicate with a developer. Like I know what an activity is or a view is in one of those ecosystems, but I'm not the right person to be the senior developer on a mobile app project. So for me, I see

the benefits of that T is being more like having confidence that someone is going to sit really well in the team and have a good and be able to have a out a role for themselves in among all the other people. And then in terms of looking for those things in hiring, I tend not to look too hard at technical skills in hiring. And I look more for the kind of transferable skills and attitudes and things like that. I think technical skills are important,

What we found is that we can provide the learning to get people very good at something relatively quickly. In fact, we worked with some companies that were in hyperscale, simply couldn't find enough developers to hire for the roles that they needed in the technologies that they needed them in. And so they used us to completely lower the bar on the technical hiring standard. They looked much more

the more transferable communication, teamwork type skills and attitudes and behaviors. And then we were part of their onboarding process to make people good at the stack that they were using.

Maulik Sailor (14:20.456)
Now, again, you know, I again, suddenly have too many thoughts in my mind, but let's speak one by one, right? And I was almost going to put like a cheeky promotion about NotchUp, you know, that, if you couldn't hire, could have always come to us, but nevermind. Talking of this whole skillspace hiring, That certainly had been trend recently about building a skillspace organization, right?

companies to really understand what are the skills they currently have and which direction they need to go. For them to hire people by understanding their actual skills level, both hard technical skills and soft skills, and then figuring out, which of these skills will be relevant for them as they go into the next phase of growth, right? And not really look into their...

educational background or prior work histories and all because you may have worked at some really big brand names, possibly a fan company, but frankly, you may not be very good. Whereas somebody who may not have worked as a fan company, but could be very solid when it comes to the actual transferable skills. What are your, like, again, you work with some of these organizations, right, and for them to be more skill space, what are your top, let's say, two, three tips?

that you would like to give to a possible company, a scale up, which want to be in that mode, where they are hiring people really to support their growth mode. They have the right attitudes to support that growth journey with a lot of variability in what will happen in the next six, 12 months. What would you say to

Hywel (16:03.896)
Good question. So firstly, I would distinguish knowledge from skills. This is a really important thing. Knowledge is super easily gained. We can Google for knowledge. I will give you an example. And I was talking with a CTO some years ago, CTO of a fintech company. And this person had got to the stage where some of his reports were leading interviews without him there. And they were turning away hires.

And the reason they were turning them away was because they would give these people questions like, OK, there's an amount of money, A, in this account, amount of money, and B, in this account. We need to add them together to find the total. And these people they were interviewing were adding them as decimals, as like floating point integers, whereas all of the people who work in FinTech know that we have to convert that into a kind of decimal based object first. So we should convert it into something that understands that there are kind of two

decimal places of money or takes a pound amount in pence and then add them. And the CTO is complaining saying like, I am losing good hires because my team are evaluating them as if they're already in the door. And I know that if we got a good developer in on the first day, I can say, right, when we deal with money amounts, we don't treat them as floating point numbers, we turn them into decimals first or we turn them into an integer number of pence first.

That to me is a classic example of people treating knowledge as skills. Like it's a bit of information, but if you know it, that's fine. You can start using that in your, excuse me, in your work. If you set that up as a bar to people being hired, that is just an artificial and unnecessary bar to perfectly good people because it's just knowledge. It's not about skill or ability. I think the next thing I...

would say is to, and you touched on this already, to distinguish skills from experience. Because even if people not just have been a very well known successful company, but have been really great there, that doesn't mean that they will be great with your company. And that is because in different companies, there are often very different expectations about how broad the work is that you're going to have to do. There are different expectations about

Hywel (18:29.198)
the kind of quality bar. if you do work for a FAANG and you're like one of the big tech companies and whenever you release code, it's going to immediately go to 10 million people. You are having to think in a very different way to if you are working at a company where your code goes to a hundred customers and not everyone will make that switch correctly. Both the hundred customer people won't be able to just switch to the 10 million customer use case and change their thinking.

and vice versa, which can mean that you get really inappropriate approaches for the different contexts. And so I think we should leave experience behind as a measure. I'm not going to make the case that experience like measuring by experience is equivalent to ageism, but it does feel like there's an aspect of age related discrimination that someone could claim there. If you said

I require five years of working experience in this technology and some incredibly bright developer who had worked very hard and had picked things up really quickly, had learned really well from their peers, but had only been working for three years was disqualified from that job, essentially because their age meant that they couldn't have worked for five years. Part of me feels like that person was hard done by because I think they potentially were good enough for the role.

but because they went old enough to have met your experience requirements, they wouldn't even be considered. All of which is to say that I don't think experience is a good proxy for ability. We use it for one. We use it as one because honestly, because it's easy, because we can just pick the numbers out of the CV and it gives us a very quick way of cutting a pile of 100 CVs down to 50, but not because it is actually a good measure of ability.

And I guess that leads to my third point, which is how do you measure ability? If you need to measure those things, you have to actually get people to do them. There is no way to prove an ability without doing the thing. Certification is absolutely not a proof of ability. Experience is not a proof of ability. Whereas if you want people to be good at a particular software programming language, then get them to do something in that programming language. It doesn't have to

Hywel (20:52.074)
In the interview, it could be something that you give them as a homework task. We used to have one in my old company where we had a broken application and we told people it was broken. We told, I think we told them that there were three bugs and there were actually four. We only ever treated the fourth one as a bonus if people found that and fixed it. And they had to like go and find the three bugs and fix them. And then we'd look at their code and talk about it with them. The conversation that happened around it is much more.

about making sure that it was really them that solved the problem and they understand what they've done. But the key thing is really part of their job is going to be fixing bugs in this framework. Can they fix bugs in this framework? That was such a core part. It feels so obvious that we should set that as a problem for people. And yet most people would just say, well, have you got four years in this framework on your CV?

Maulik Sailor (21:44.072)
Yeah, no, that's an interesting one. You know, I definitely agree with you. I personally don't really like to evaluate people based on the number of years of experience. And for myself, you know, when I was early in my career, you know, I would generally very fast at picking up things. And, you know, I would feel discriminated when somebody says, oh, yeah, but you don't have 10 years of experience. so, but I like, but I know, I know I've done it. You know, I know how to get it done and I have done

Here it is. Here is the proof. But then they'll say, yeah, but based on your prior salary, this is the salary we'll give you. I'm like, yeah, but that's not fair.

Hywel (22:23.576)
wel, it isn't. mean, you're quite right. I feel like I don't want to derail this, but by getting into a conversation about how we calculate salary, but the people who are calculating salary based on how much you used to earn, what that tells me as a potential employee is you don't know what I'm worth. If you are judging by what I was paid before, all that tells me is you don't really know how to evaluate me and my salary and my value.

It is again, it is like a lazy proxy where really what we want, excuse me, it is a lazy way to evaluate salary where really what we want is people who can say, well, you are working at the level that is worth this to the company. Like for us, the range we have for people who are senior in this technology is from X to Y. I have seen that the work you're capable of feels like roughly here in that range. So your pay is going to be this.

That feels like such a reasonable expectation to me. And I, yeah, I find it frustrating that people would just ask what you were paid before because the person who hired you there probably asked the same question.

Maulik Sailor (23:35.912)
I am going to touch.

Yeah, I'm going to touch one similar note on that one. know, recently we had a client where they had a certain budget to hire a senior developer and our platform basically identified a developer which was matching most of the skills and the client wanted to hire him but he was in a different location and then the client turned around that hey and he was already asking lower than what the client advertised for.

And then the client turned around and said, hey, but based on this location, he should not be getting that. He should be getting this. And we're like, OK, it's already lower than what you are willing to pay somebody. And now based on the location, you even want to go for the lower. Now, one of the reasons why people will go remote or in a different territory is because of the cost advantage and so on. But in my opinion, cost advantage aside, I

There are certain advantage of having remote or diverse teams. Number one, can cover more, you can have longer working day. I used to work for Nokia and I had a 24 -7 delivery model with multiple teams in different location and they're continuously turning through different stuff. 24 -7 delivery model by just very strategically identifying which roles goes where and how we build the team around that. This was in office but in different territory.

And I saw very clearly the advantage and the speed of the delivery that you get. So for me, speed was the number one thing when I talk about remote teams and so on. Secondly, some countries, depending on their culture and their heritage, people there are naturally designed to think in a certain way. And I will give you an example. So for example, I could be biased.

Maulik Sailor (25:36.36)
But let's say Italians or Spanish or Portuguese, right? Generally good with designs, right? So you will see a lot of UX designer from that background, right? Indians, I mean, I'm from India, by the way, right? Indians generally very hardcore into mathematics and engineering, right? So they tend to do those kind of analytical roles better compared to creative works, right? Some

Some ex -communist countries like Eastern Europeans, some of them like Romania and so on, they're good at taking instructions. So yes, they can think through, can do creative programming, but generally they're good at following instructions. So if you ask them to do like, here is your operating manual and make sure you basically work within this parameter, then they're generally very good at doing that, right? And so on. So for

Even going into different territory or different location or based on this parameter that hey, you can get, you know the unspoken or you know, just a behavior trait in their ways of doing things. You know.

Hywel (26:44.846)
think there's two points that I want to pick up. One is the paying people based on geography. And it's one that we as a company have definitely tried to grapple with before because we've employed people from the west of the UK as Mexico to the far east as Hong Kong. And we've put a lot of thought into what even is fairness in

in that scenario. If someone has chosen to live in another country or has to live in another country, how do we justify to ourselves paying them less than people who live in a country where cost of living is higher versus the idea that, but then how do I justify paying the same when I'm to someone who's in another country, when I'm talking to someone who lives in a high cost of living country and say,

this other person on your team who does the same job as you gets paid the same, which for them in their location means like they have all of this like all of this extra disposable income that you don't have because you're in an expensive place. And honestly, I feel like at the end of a lot and lot of back and forth on that, I have no idea what the right answer is. I think I mean, I think like upbringing and and education

You like you mentioned India, which of course has the IITs, which have historically and continue to produce lots of people with a very strong mathematical background, all of which is likely to mean that people who come through that educational system are going to have lots of kind of abilities already in technical topics. I suppose all I would add is like I've heard similar things before and then met people

from Bulgaria came to mind because I've worked with a few developers from Bulgaria, some of whom I think were very much preferred to take instructions and were kind of very fast in a straight line, is how I've heard it described. And then I've worked with other developers from Bulgaria who are more creative and take more kind of ownership and push back and think more about the kind of user and ask questions.

Hywel (29:12.118)
And so I think that it seems like upbringing and education systems definitely can precondition, not precondition, but can give people abilities that mean that different geographies lend themselves to different roles, that there will always be individuals who kind of, who break any mold that you put them in. And for me, that comes back to the need to look for skills and abilities and evaluate based on what people can do.

and rather than, rather than any form of background, because I think ultimately what we want is for people to get into a role and do a thing. And we don't care about very much else. Like, I don't care if you're doing the thing and you grew up in this situation versus you do the thing and you grew up in a completely different situation as, as someone managing you or leading the team that you're in.

I just want you to do the thing well. And that's what I want to look for in interviews, which I guess comes back to this idea of the skills -based organisation. I think skills -based hiring, skills -based management all look at what people are good at doing rather than any proxy for that because I think the proxies just don't work.

Maulik Sailor (30:34.856)
I'm just going to tell you an interesting anecdote that I read about somewhere. I'm not sure how much of it is true, right? And this boils down to the, you know, the control norms and stuff like that. So apparently, both German cars and Japanese cars, they're considered to be well -engineered, right? But then Japanese cars are considered more reliable.

Hywel (30:43.564)
Okay.

Maulik Sailor (31:01.756)
from quality point of view compared to German cars. Then somebody asked why, why is that? Right? And I'm not sure whether this is a true story or not, but apparently the response is that the Germans are so for good at following instructions and doing things by the books so that when they make the cars, they expect their drivers to follow the instructions and do things exactly they would expect them to. And that's what most Germans do. Whereas Japanese expect their users to not follow any instructions and use the product

in a way that is not supposed to be used. So they basically work around that whole unexpected scenarios and hence their cars are more reliable. So when people go, you know, do things, they don't break down, right? So, you know, this is like, you know, another side of how people are accustomed or trained to do things depending on where they are, right? But hey, that's a nice story.

Hywel (31:59.319)
It's very interesting. It reminds me of a... I have a longer anecdote and it's one that I know is made up and so I'm not sure whether to share it or not on the podcast. What do you think? I think it's an interesting illustration of knowledge versus ability and wisdom. Yeah, okay.

Maulik Sailor (32:01.009)
Yeah.

Maulik Sailor (32:25.124)
Go for it, go for

Hywel (32:27.682)
So this is an anecdote, which again is not true, but and it exists in many forms. So the version I'm going to tell is about the physicist Max Planck. And it's the most famous form. Max Planck was one of the people involved in helping us understand the kind of internals of an atom. If you look up the Planck length that is named after him. And Max Planck was was doing a big tour of the US and he was giving lectures at universities. This was back in

30s or 40s. He was going around giving lectures at all of the universities. And he had this one driver, his chauffeur, for the whole tour, who took him on this big, you know, long winding route around every city in the United States. And every time Max gave the talk, he would, his chauffeur would come in and would sit at the back of the auditorium and would listen, would listen to the whole talk. And he would listen to the questions that the people in the audience.

asked afterwards and he would kind of pay attention and he would chat with Max as they were driving. He would say, he would ask questions about the theory and really get into it and he was keen to learn and to understand. They got to the very last stop in the tour, I guess this would have been down in the southwest somewhere in California probably, and they were sort of joking with each other in the car because

They had formed quite a good friendship by this point. And Max said, you've been in every lecture I've given and you've had all of the questions. And I've noticed in the car that you do quite a good impression of me. No one in this university knows who I am and I'm quite tired. It would be really funny if you gave the lecture today and pretended to be me and then I can just rest in the back of the auditorium and watch. And they joked about it, but then they actually did it. So the chauffeur

stood at the front of the hall, said, hello, I'm Max Planck. Here's what I'm going to talk to you about today. He delivered the lecture in the style of Max Planck. And then he got to the end and, you know, lots of people ask questions and he answered every single one of the questions perfectly. And then a very serious looking professor got up from the front row and he asked a question and it was a question that had never come up in any of the other places.

Hywel (34:56.44)
that they'd been to on the tour. And Max Planck paused for a second and looked down, and then he looked up and met the professor's eye and he said, that question is so stupid and so obvious that even my chauffeur could answer it. And he pointed to the back of the room, to the real Max Planck, who then stood up and answered the question. Now for me, what this story illustrates is partly like our expectations about what chauffeurs are capable of and that they

that they can know a lot more than we expect. And in fact, anyone who's familiar with the knowledge that the London taxi drivers have to learn should have very high expectations of what drivers are capable of. But also it illustrates the difference between knowing things and being able to do them and knowing things and having wisdom. Because the chauffeur was able to go around the entire tour and essentially learn everything

that Max Planck said in response to the questions and the content of the talk. He was able to deliver that knowledge verbatim just by sitting there and absorbing it every time. But when it comes to the difficult questions, when it comes to the things that are slightly different to what he's seen before, he still has to refer back to the real Max Planck at the back of the room.

Maulik Sailor (36:22.51)
Yeah, so, you know, this is similar to the Big Bang Theory, I one of the episodes where Saldar is participating and there was this, I can't remember, like a cleaner or somebody basically answers the question and he does not believe him, but the answer happens to be true. I'm not sure if you saw that episode or

Hywel (36:44.402)
I never watched it, but this story is quite well known and I could well believe it would be the basis of an episode of a TV program.

Maulik Sailor (36:53.188)
Yeah, so it's similar where Salden is like, you know, they're competing in some quiz and stuff. He's winning, but there's one question he's not able to answer that he's thinking really hard. And then one of the cleaners said, hey, this is the answer. And he believes, yeah, you are a cleaner. What do you know? You know, that's not the answer. But that answer actually is true. And then he asked him, like, how did you know this answer? Like, look, I was like, you know, a senior scientist in some Russian army or something.

but now I'm living like a refugee or something in the US, right? Whatever. Right? So that's the story behind that. All right. Let's move on to something else, right? So where's your firm heading? Tell us more about your company's skill of win.

Hywel (37:38.892)
Yeah, so I guess we are finding that we are doing more and more in learning for tech teams. So we started out doing very specifically things in hard technical skills. So we worked with teams that had JavaScript developers and React developers and Python developers and whatever technology. And our job was to go in and just make them better, work out exactly what each person didn't know already so that we didn't waste any of their time on telling them stuff that they already knew.

And then just like always be working at the edge of what they need to increase their abilities to make them better at the tech they were already using. And then over time that has evolved so that now as well as doing hard technical skills, we also work in slightly more abstract skills. So we work with companies on things like API design and to help people get better at designing and building APIs and API first organizations. And we...

also now are doing more on things like test -driven development and effective pair programming. And then most recently, our latest curriculum launch has been in skills for managers and leaders. So this is about six months old now, and we've been working with often it's newer team leads or engineering managers and the kind of interpersonal and leadership and management skills you need to succeed at those positions. We've taken our existing model for learning, which

very focused on only working on gaps and the gaps that matter and then having all the learning be learning by doing with a real practitioner whose job is to give you feedback and add context and bring the nuance of the situation to so that you can really apply it. And we now are working with companies where we'll work with developers in every stack and with some of their managers and leaders and with

with some of those kind of cross -cutting concerns like API design. Where we're going is really more of the same. Ultimately, we don't want to stop with what we're doing now, but I think it'll be a while before we move out of tech teams. We are always adding new curricula. We're always starting to work with new companies. And I think what we find is that once companies start, they don't want to stop. We actually just published

Hywel (40:04.814)
case study with PLEO a couple of months ago. So PLEO, the Danish Expense Management, I call them a Sunicorn. They're not a unicorn, one billion dollar valuation yet, but I think that they will be soon. And they were hitting productivity bottlenecks because they had a monolith. Teams had to have had to chat to each other before they could release code to understand what each team was doing. They wanted to become API first. And after working with us, they saw productivity.

improved by 40 % across their 200 person team. And now we're working on them with a load of other topics as well around management and leadership. And I we're working with native teams. Generally speaking, we see our job is to go in and find out what hires people would be making or what skill gaps are in the way of tech leaders achieving their strategies.

and we come in to help with those skill gaps so that people either don't have to hire or so that they can hire and be more flexible about who they hire or so they can just take their existing people and make them more skilled while also

Maulik Sailor (41:16.86)
Yeah, we're working on something similar as well. We're enabling these tech leaders to first understand what skills they have in their team, who brings what to the table, and how are they working together. And obviously not everything will be well balanced or well optimized. So basically help them understand what gaps they have in terms of where they want to go. And the next hire they want to do, we identify a profile

complements that existing theme. So the profile we identify basically have all the required technical skills, but also have the soft skills, behaviors, and motivations and working styles which are complementary to your existing themes, right? So we have a working like a platform like feature on our platform, but the challenge that we are facing is like, I think the UX, there's a UX challenge, visualizing all this information in a nicely like a 2D screen is difficult.

You know, we have concepted quite a lot of things. And we have, I don't think we have got to the perfect solution yet. We got something working, you you can see what's going on, but I don't think it's perfect. There's still a room for a lot of improvements on it. Right. And it becomes more and more complicated as your team size grew. Like, you know, let's say you're comparing two people. I think that's an easy one. But let's say you have four or five people on your team. Like a typical scrum team will be anywhere from four to six people.

And then let's say you are on the smaller side with four people and you are trying to get on a higher side of eight people, you are recruiting four more people. So now you are comparing eight people's view across a lot of different dimensions. And trying to represent that information in the UI, I think that's a challenge. So that's something that we are working on at the moment. Our frustration, I tell you where our frustration is, apart from the CWX side. We definitely saluted

like the tech leaders who are in charge of running the delivery teams. Most of them know it. They kind of get the idea of what we are doing. They like the product. They like, yeah, it's good, but I'm not hiring. It's my HR guys who are hiring. So you need to go and speak to the HR guys. We go and talk to the HR guys, and most of the HR guys are like, yeah, but we use LinkedIn. How is your platform better than LinkedIn? Do you have enough number of profiles that's LinkedIn? No. Do you cover for all the roles? No, we only do tech roles.

Maulik Sailor (43:41.736)
And this is where we find most of the friction that we have a solution that the tech leaders want, but they're not the users. The users are like the HR folks and they already have something quite unique in that space. And that is where we find most of the friction when it comes for us to sell our platform. So that was why we're trying to overcome that. There's one more feature we are working

is to predict the skills requirement. Now, that is also not an easy thing to do because how would you predict what you need next, right? And at this moment, we are looking into like a product roadmap. What does your roadmap have? What are the next few things that you want to do? And let's analyze them against your existing team and see if there are any gaps that you need to fill

And for you to fill in, now there are two avenues which I think you touched on as well. One avenue is to hire people and the other avenue is basically train people. Right. So our focus is on hiring site. Possibly we will integrate with some learning platforms like yourselves to provide delivery training aspect of it. But for now, this is our focus area that how do you really get them to understand what they have and what they need. Right.

And I think we've been working on it for a while and so far we have not got a right solution. We have a solution, but I don't think it's the best

Hywel (45:14.656)
It's, I think it's very hard to get the attention of tech leaders. So one of the things we have always found is we have to wait for people to approach us. Whenever we reach out to people, we get put into the kind of training bucket with all the other things that people know don't work and people feel frustrated by. And we are, our approach looks really very different to most other forms of learning.

And so we find that when we actually get a call with a potential customer, they get really excited and sign up because they're like, I'd assumed it would be very different. I thought it was just going to be like a load of videos or a platform. Like the fact that it works like this is really exciting. I see how it's going to work with my team. Getting to that point is really hard for us. As soon as we get people on a call, they get really excited. As soon as they see what it's like, they get excited.

And I wonder if there's a similar thing for you here. Like this question of visualization, we use a couple of things that we like. show heat maps of skill distributions in the team. We show what are called radar graphs, also they're also called spider diagrams, where you can have like a spoke for each area that you're looking at. And then within, you have kind of lines that go around the edge of the spider graph, but how far they are away from the middle at a certain point.

tells you the level of strength, maybe that would be a way for you to do that visualization. But it might be that having that visual that people look at, they can be say, wait, so I just, I can get my team on here and it's going to show me where the gap is in the skills profile. it's going to show me like three candidates who I could be talking to who compliment the people I already have. It might be that that makes something click, even if the design isn't perfect.

Maulik Sailor (47:10.118)
Yeah. Yeah, so I get you what you are saying. And I think people do get excited when they see that team on the platform. That's OK. You know what? They see the potential. So we have some teams that we have set up on the platform for them to see. And they say, yeah, that's interesting. I never knew that my team is in this structure or that structure. Or my team member has this skill. I never realized that he brings that skill to the table.

But again, we have a school start problem. As in for you to understand your team, you got to onboard your team. And your team members are not going to onboard because there's nothing in, I don't really care about why do I need to go through this process so that you know more about me. Right. So I think there are a few friction points we are trying to overcome, know, trying to make it more interesting for the talent, you know, make them relevant for what they might want to do with their career. So that was one of the features I think I mentioned to you.

in our earlier call that we want to do this career design tool where they can design their career based on that existing skill and where they want to be. then based on that, they may have some trainings delivered to them. So I think there are a few avenues we are looking into. Let's see. I'm doing this because I felt excited about this whole proposition. I have been a product manager, tech lead.

And every time you're building your team or recruiting people, you're like, okay, I don't really know whether this person is going to fit in my team. You know, it sounds good, you know, in the interview, he's doing really well, but I'm not sure what happens when I bring him on the floor. And that's where this whole thing started that, Hey, you know what, let me build a platform where we can possibly do this. You know, you can know better about your team and can figure out who do you want to bring

Hywel (49:00.371)
Yeah, it's interesting and it is hard to get so for us we assess each individual but the pitch for them is if you go through this assessment then we aren't going to waste your time with learning that you already know. So don't go through the assessment you're going to have to through every session and it's going to be really boring for you. Go through the assessment we're going to start at only at the stuff that you don't know and it's going to be genuinely interesting and useful from that first session. It's harder to do

when they aren't individually getting something out of it. Maybe it has to be the leader, the leadership who put in that sort of skills map without their individuals taking part.

Maulik Sailor (49:41.372)
Yeah, possibly, possibly. But the thing is, you know, this is another surprising bit that I found. Maybe you might disagree with me, but most of the tech leaders that I've spoken to, they don't know much about that team. They generally know who is the best performer and who is the worst performer. So best performer is that go -to guy that anything goes wrong, they go to that person. Hey, you know, this is not working, that is not working. Can you just look into it? Right.

And they know he will fix it, right? He or she will fix it. And the worst performer is somebody that they're like, hey, this is creating a lot of maps. And the next time when his review is coming up or the next round of layoff, he's going to be in real trouble, right? So that's the most track leaders or team managers know these two variables. But anyone in between, they don't know much about them. They may know, OK, he's doing this page, he's doing that page.

But nothing more than that. What are his motivations? What does he really want to get out of this job? Where does he want to take his career next to? They don't really know much about

Hywel (50:52.854)
I think, so it depends on the structures in the organization, but to me that feels like a question I would ask the engineering managers rather than the team leads. I know some companies combine those into a single role and then it does feel like a really key part of managing those people that a team lead should be doing is to understand where they want to go and how that aligns with where we need them to go for the company's sake and working out which direction they should be growing in.

Maulik Sailor (51:00.312)
Hmm.

Hywel (51:22.358)
where their next promotion is going to come

Maulik Sailor (51:25.089)
Yeah, cool. All right. Look, I'm just mindful of your time you mentioned about you need to head on on the tube. So why don't we wrap up? And I think we probably should book one more podcast given the amount of topics that we have been talking about. But you know that for another day, let's let's just wrap today's chat. And but before we end, are a few questions that we normally ask.

Hywel (51:33.581)
I do.

Maulik Sailor (51:51.464)
everybody who comes on this podcast, right? That's genetic, they're not technical. So, you know, it would be good to know your thoughts about them. So if you're ready, I can start.

Hywel (52:04.215)
Yeah, go for it. I'll try.

Maulik Sailor (52:05.872)
Yeah, good. the first one, right? Who is one person alive or dead that you want to meet?

Hywel (52:16.15)
all of it I want to meet

Hywel (52:27.32)
I don't know actually. I think I worry about picking someone who I really admire and then like what if they didn't, if they went or that they were cracked up to be. You know what, I'm gonna pick someone who is just really funny. I think Andy Sandberg from the Lonely Island who was on SNL.

Maulik Sailor (52:41.266)
You never know.

Maulik Sailor (52:54.386)
Kiss.

Hywel (52:54.573)
know, 10 years ago, I think seems like just a really funny person. And I feel like whatever I brought to the conversation, I would have an amazing like time just hanging out with him. So I'm going to say Andy Sandberg is my like one person

Maulik Sailor (53:07.728)
Okay, cool. And who is one person, again, alive or dead, that you were most inspired by in your

Hywel (53:15.41)
that I was most inspired by.

Hywel (53:22.194)
I, this is going to sound so lame, but I am very lucky. I find my parents genuinely quite inspirational in terms of their, their like dedication to hard work, their belief that you essentially that like you can, if you want, if you want to do the thing and know the thing, you can learn it if you put in enough effort. And that has always been, that has definitely shaped like how I see the world. And it's always been really,

inspirational to me. They don't know that but I don't think they're going to listen to this podcast so it won't go to their heads. We should be okay.

Maulik Sailor (53:56.392)
You never know, you never know, you know. All right, and last one. Who do you think we should bring as a guest on this podcast?

Hywel (54:09.528)
Who should we bring as a guest on this?

Hywel (54:18.274)
That's a good question and I guess I'm thinking

skills -based learning, is that the of the area where you're thinking?

Maulik Sailor (54:29.096)
It could be anything. We had a few guests say, like, bring on Elon Musk. And I said, OK, maybe one day we will be able to, you know, if we get big enough.

Hywel (54:39.214)
I, well, I'm probably going to go in a different way with my recommendations to Mr. Musk. I would say someone like DHH from Basecamp, so David Henmeyer Hanson. I don't always agree with his opinions, but I think he gives his opinions in a really entertaining way. And I think at Basecamp, they've taken a lot

Maulik Sailor (54:54.225)
yeah.

Hywel (55:08.834)
bold decisions like they recently moved back from cloud to their own infrastructure. And I think understanding the decisions that they've made at different times in their journey would make for an interesting podcast episode.

Maulik Sailor (55:22.856)
that interesting. Definitely. know, slowly, once we have got enough, so we're still, I think we have done about 10 episodes so far on our podcast. And like, you know, once we have done enough, maybe about 15, 20, then I'll start trying to reach out all these guest suggestions directly and see if they would like to come on. You know, I need to build some audience before and you know, some some sizeable audience.

Hywel (55:45.783)
Okay.

Maulik Sailor (55:49.766)
And then I'll try to approach them and say, know what, had you on this and you want to come on. So let's see. I'll try. I'll try.

Hywel (55:59.374)
Yeah, fingers crossed.

Maulik Sailor (56:00.882)
Thank you. Thank you. So anyway, Chivin, I think it's time that we wrap up, just mindful of your time as well. But thanks a lot for coming onto our podcast. It was really interesting to know your opinion about building a skills -based organization, how to go about building teams, how to hire people, and strategies about upscaling the organization as you grow. So thanks a lot for joining today.

Hywel (56:27.84)
No worries, thank you for having me, I really enjoyed it. Nice to chat.

Maulik Sailor (56:30.363)
Yeah, no worries. And hopefully we'll get to do one more very soon.

Hywel (56:34.424)
Sounds good, I'm up for

Maulik Sailor (56:36.006)
Yes, good. Thank you, Bye. Let me stop.

Hywel (56:37.974)
Alright, bye for now.

‍