Building Effective Teams at bet365

Sean Allen (: 00:01

Welcome to the More Than a CV podcast. delighted to be joined today by Adam Davis. Adam is currently Senior Systems Development Manager at BET 365. He spent his career within software engineering, holding roles up to software engineering director. Welcome Adam. Thank you for joining us today. How are you?

Adam Davis (: 00:18

I'm really good, thank you. Thanks for having me on, how are you?

Sean Allen (: 00:20

Yeah, I'm good. Thank you. It's the day of recording is Friday, so I think it's safe to say we're both ready for the weekends. Yeah, it's a pleasure to have you with us today. It'd be great for our listeners who maybe don't know who you are. Just hear a little bit more about you and your career today. Adam.

Adam Davis (: 00:28

completely.

Adam Davis (: 00:39

Yeah, sure. So kind of kind of worked my way up really. Most of my background has come from development centric. So I guess prior to that, from an academia point of view, I did kind of further computing at college and then I did an advanced sort of courses at university. So that kind of led me down the route of doing computer games programming. Didn't necessarily want to go into the games industry, but at the time that offered me a load of different courses.

courses. It's one of those degrees whereby it touched on like eight different disciplines I was really interested in or wanted to do more of and the kind of the standard CS degrees didn't touch on like advanced mathematics where you know computer games programming touched on that and that was something I really wanted to do. It touched on networking like between servers and clients and things like that. So it really appealed to me to do that sort of course. So that was a kind of three four year.

sandwich course with a year out in industry. I did a year out in a web development company, which was really good. That allowed me to gain some confidence being to customers, you know, working with colleagues, doing some very, very sort of basic things in the early days. And then after that, I did a little bit of contracting on my own and then kind of moved on to an organization where I worked my way up to software engineering director. So responsible for the entire SDLC from development test and release.

and kind of always been interested in kind of programming and developments. And as sort of my career went on, I was more interested in teams. So less about being an individual contributor and how to build and grow teams and grow systems around those teams. So inherently always really interested in tech. I've always been really curious about different sort of problems and challenges. And yeah, I joined BETT really for that reason. I got very comfortable in my last place. I was there for nearly 10 years.

and got that point in my career where, you know, could, probably stay here forever. Um, but it was probably not a healthy thing in the sense that I knew everything. knew all the systems. I wanted a bigger challenge. So about three years ago, I joined Betts, got offered this challenge and then kind of arrived here really, uh, which was, been a great experience.

Sean Allen (: 02:36

What?

Sean Allen (: 02:55

I was going to say, the size of bet certainly I'm guessing provided that sort of deeper and broader challenge that you're looking for.

Adam Davis (: 03:04

My last organization was probably circa 150 with about 60 folks in technology, so a lot smaller in bet, obviously that's thousands. So it's a magnitude larger than what I was used to. So it definitely presented a good opportunity.

Sean Allen (: 03:19

Yeah, how did you find that transition? it, did it sort of happen, was it quite natural and easy once you got into it or was it quite a bit to get your head around going from a smaller company where you probably know everybody and you know who to call on for different things to yeah, bet global giant, right? Like, you know, massive brand.

Adam Davis (: 03:29

Yes.

Adam Davis (: 03:40

Yeah, it was difficult in a sense that, you know, walking into a new business with no domain knowledge, no contacts. I think for me, what was interesting was I was presented an opportunity to grow out a team, build out a team that is already pretty well established, but you needed to scale with best growth.

not just through people, but systems processes along with that as well. So it was deeply challenging on a number of levels. One, you're walking into an organization where you've got no domain experience. You have no idea how a line of code goes from a developer's machine into live, and that's really important. So my first couple of days and weeks and months were understanding what was the software development lifecycle, how do people interact with that lifecycle.

And then once I fully understood that it was more about how do I then go on to scale the team? So I was brought in primarily to leverage my prior experience. So at my previous gig, where I was a software engineering director, I was responsible for trying to transform some of our services to move into Go. And that was a journey Bet was already on. So it was trying to leverage that experience, also scale out the team to be able to deal with the new market demands Bet was going into.

We're also then to provide the support to hire new individuals to grow out that team effectively. So it was really challenging, but an exciting yet quite difficult time, but it was fun. was exactly why I joined, to get that challenge.

Sean Allen (: 05:03

So when you join then, that leads on quite nicely, because I know we've spoken between us a lot about sort of growth of teams and developing those. What was the sort of team size that you came into and what were you growing it out to? Because I guess it's quite exciting when you're a new manager coming in, right, to go, I get to know the team I've got, but also bringing my own people in the sense of your own highers, I guess.

Adam Davis (: 05:30

Yeah, it's not big.

Sean Allen (: 05:31

But there's understanding the team and the culture and how they operate as well, isn't there, to make sure you're bringing the right people in with the right skills to help plug any potential gaps. How did you find that when you're a new manager? It's exciting, but also guess quite a challenge when you're new to actually just go straight into hiring, right?

Adam Davis (: 05:48

Yeah. It was really difficult in the sense that, you're joining, but you're, you're, you're already in an organization that's moving at rapid pace. So you're still expected to deliver. you know, you've come in with a manager title. So some people might just assume, you know, they don't know how long you've necessarily been at the company because you just got this new manager title. You might have transferred from a different team. So they might see you as always being at the company. So you've still got delivered BA you work on top of scaling. That's hiring people and things like that.

I spent my first couple of months before days and weeks understanding how the current team develop work, write code, test code, get out the door. Why didn't want to do is be that new manager who comes in going, I know everything. I've done this my previous place. This worked and therefore it's going to work here because you know, the fundamental truth is just because you've done it somewhere else doesn't necessarily mean it's going to land in this place. And what I tried to do is,

know, speak to the existing team. What were they struggling with? What did they need? So the first set of needs were around. They needed more training, so we're going through a transition to move our services into to go from net. There's a big upskilling exercise to train those folks from net to go. But equally, they were all really, really busy doing BA you work in net. So how do you give those people bandwidth to be able to upscale while still maintaining the work they needed to do? And it's understanding and you know those characters in the team so.

You know, the first couple of, again, weeks, it was arranging a couple of socials, a of one-on-ones with the teams, understanding how they tick. And that really led me to understand of how do I compliment that team with new hires? What kind of culture already operates in the team? Like, do they go out socially together? How do they perform under pressure? How do they perform in an out of hours situation? Cause we have on call and once I've got some of that, once we've got a basic barometer of the current team's health, I was able to understand where are the gaps.

Where do new hires come in to fill those gaps? And they might be really experienced co-developers or they may be really experienced people people, which you need to look after the people, right? It's great hiring loads of people, but you need people to look after the people. So the existing team was around 14. And I was kind of given a remit to really double that in size. We kind of went over that in the end. And that was really fueled by the growth of that was entering many new US markets.

Adam Davis (: 08:07

So in order to fuel that growth, upscale the existing team, we needed to create more bandwidth and that came from looking for individuals that would complement the existing team size.

Sean Allen (: 08:17

I like the way you describe it as like the team health and look at all the different aspects of it, not just technically, but where all the, like how they perform under pressure with out of hours, you know, and those calls, example, something I guess I probably wouldn't have thought of, know, just when you mentioned it, I thought that's great. Probably wouldn't have thought of that. Like what type of person do you need to help compliment the team already in place?

Adam Davis (: 08:24

Okay.

Adam Davis (: 08:40

Yeah.

Sean Allen (: 08:46

And obviously with BAT, with that continued growth, as you're hiring, you find out you need to hire more. that standard rapid constant change. And from what I understand, you sort of taken on more since you've originally joined. that right?

Adam Davis (: 08:54

was more about the people to generate.

Adam Davis (: 09:05

Yeah, so my remit's recently changed. Probably the last eight months we've gone through a bit of a technology restructure. We used to have kind of teams which were super focused in one area, which was great to a point. So you'd have a dedicated UI team, a tooling team. What we found with that though is that when you get business requirements that require large changes to the estate,

you'd have to engage with like 20, 30 teams. And probably back in eight years, 10 years ago, when the company was a lot smaller, that would be fine. But as you scale out, trying to engage 20 teams for one project becomes...

doesn't really become viable, you lose your agility. So one thing is we've done over the last eight months to do a bit of a reorg where we've aligned teams have multiple skillset disciplines in them. So effectively they can do many different things. can use, guess commonly referred to full stack teams, a bit of a cheesy sort of cliche, but effectively that's kind of what we've got now. We've got teams that have those multiple disciplines in them. They can do backend work, they can do frontend work and tooling work.

And that's led to that agility. So when we've got a product request coming in, instead of spanning 20 teams, we might only span three now. That means there's fewer touch points, delivery's improved. It also is an opportunity for individuals in those teams to go, actually, I really liked doing Go, but I do, or would like the opportunity to do some front-end dev. And it's like, cool, you can do that now. You can cross train. Instead of being siloed into those particular teams, it's created more opportunities for people to upscale, but also...

improve quality of service for those external stakeholders like products. So, you know, it was no longer viable to engage with, you know, 20 odd teams, whereas now they've got fewer touch points. I think from a developer point of view, it presents more opportunities in those teams to go, I can learn more or can I own more of the estate, which I think from an ownership perspective is quite good. So yeah, it's led to some unique challenges. But again, that's, you know, my remit's changed from looking after a team of

Adam Davis (: 11:08

scaling that out to around 56 to now looking after circa between 160, 180 folks. So there's obviously a huge difference in sort of size and scale really.

Sean Allen (: 11:20

Yeah, that's a massive jump. how are you finding that then? So if you're building out and growing teams across different disciplines, obviously, guess for yourself, there's probably a bit of pivoting you've had to do when it comes to hiring as well. And probably, I guess, your own upskilling and learning through campaigns that you've done hiring these different skill sets. How have you found that, you know, if you

hiring from engineering to infrastructure, example, how are you finding that personally? Because yeah, what a team of 160 to 180. That's a lot of hiring.

Adam Davis (: 12:00

Yeah, there's a lot of folks and you know, there's a lot of, um, there's a lot of added pressures with that. Um, for me, it's having that. It goes back to that point of having that you did. There's no such thing as a silly question. So I'm, I'm more than happy to be the guy in the room asking those questions to find answers to things. So I'd probably say since I've joined bet, I've always asked questions and been very honest when I don't know something. And that's led me to learn about disciplines. wouldn't really be that close to like infrastructure networks.

That's all within my remit now in terms of looking after some of that within my world in terms of being responsible for some of those specialties. So not just developers, as you mentioned, it might be CDN engineers, it might be networks. Those folks report into me. So I need to know at very basic level what they do, how does that affect the estate, how they contribute to it. For me, it is that open recognition of not understanding everything, but just doing enough to

appreciate when we need to interface with those individuals. Well, equally, when hiring for folks that don't necessarily fall under the general dev discipline, it's developing strategies within an interview situation to understand, you know, do these individuals really know what they're on about in the nicest possible way. that might be contrived scenarios on a whiteboard where we might go, we've had a major outage. This is what the estate looks like and draw up some of that and then

see if an individual in an interview situation can get to certain aspects of what we might perceive to be an answer. So one of the scenario questions I would typically ask, and I don't want to give everything away because it would probably spoil it is, you know, we might have a contrived scenario where we might say customers are experiencing this scenario, but it's only happening every 20 times out of

Sean Allen (: 13:38

You

Adam Davis (: 13:53

out of 40 or something like that. Some weird arbitrary sort of situation where it's not a situation that happens all the time, but it's happening semi randomly. What that does to the individual, makes them think we're trying to understand whether the person who's coming into that interview is going to go, it's a code problem, it's an infrastructure problem. And then if it's an infrastructure problem, it's like, where is it? Is it a firewall problem? Is it a white listing problem with a third party vendor? And we're trying to look for those key.

breadcrumbs really where people can go, I roughly know where that is and provide those scenarios where people can demonstrate not necessarily by having all that experience, but by having that curiosity to find where the problem might be, if that makes sense. So I don't profess to be a master in any of those kinds of disciplines. My background is purely developments. I would say the last 18 months, two years, I'm an awful lot stronger in those areas. But I think when you can have a scenario like that, which is pretty open and pretty vague, think

someone who really understands or is a really good problem solver is able to get some of those answers. Whether it's a developer or a infrastructure engineer or a networks engineer, most of these things come back to being a problem, right? It's just how you solve it. So we're looking for people who can solve those problems.

Sean Allen (: 15:13

Yeah, it's a good way of doing it, isn't it? Cause it's sort of that thought process. What do they consider? How do they get from A to B to C? And then there's also that bit in there, isn't there? If you or someone on the panel to go, well, have you considered this or what do you think of this? How they respond to that as well. So you can start to gauge how to collaborate within a team as well. as opposed to just going, well, I'm right. Cause I would just always do it ABC rather than going consider the people's opinions.

Adam Davis (: 15:42

Thanks for your time.

Sean Allen (: 15:42

and then work out what maybe the, what we think may be the right solution that comes out of it.

Adam Davis (: 15:46

And that's typically what we do in those scenarios. So when we're doing a whiteboarding exercise, if it's developer, it's a pretty clear cut thing where it's a coding kind of challenge. It's like pseudo code this on a board. There might be 18 different permutations of how you get there. For someone on an infrastructure side of things, might be there is this contrived scenario, customers are affected. We might say customers are affected all of the time, part of the time, or they're experiencing this randomness in this part of this estate. And what we do is we layer that scenario to

Apply some pressure in some ways. So we might go, you know, at nine o'clock, there's a release. the website has gone down five minutes later. What do do? You're the only person around. There's no managers available and it's hopefully not panic. But you know, some people might go, I need to do some investigation. need to, I need to drill into that incident. I need to speak to developers and then we'll go.

Sean Allen (: 16:26

panic.

Adam Davis (: 16:37

There's no one else around. The website's down. You can't possibly make any worse. And there was a release. So there's a couple of different scenarios there. People might go further investigation, need to speak to management, or if none of those options are available to you, one of the options might be to roll back the release. That might be the most pragmatic option because you can't make a situation like that worse. If someone fundamentally can't do something and you know there's been something that's happened like a software release.

especially a few minutes after, you can tie that back together. But it's understanding whether a candidate will see that and go, you know, if they're really rigid in their thinking or they're going, you know, actually, I would probably just roll that release back. But some candidates might go, need to seek authorization to do that. And that is not necessarily the wrong answer either. So it's interesting to find out where candidates would sit on that spectrum. Would they just roll it back? Would they find somebody? Or in the time of trying to find somebody and press that button.

You know, that could be 20 minutes, 30 minutes. So we're trying to apply different categories of pressure in some of those situations to determine what people would do to change their output and actions. But it's not there to put pressure on the candidate. It's there to really to change the ways of thinking, if that makes sense. Like if you say to someone you've got full team, they'll go, oh, I'll just speak to the team to fix the problem. You haven't got the team. It's just you. What would you do? And you get different answers, which is interesting.

Sean Allen (: 18:04

Yeah, and I guess it depends what they're sort of used to in their current role as well. Someone's maybe been somewhere for a while and they've got a process that they have to follow. Your default, even in an interview, would be to give that, you think this is what we do, and to give the answer, isn't it? So sometimes it's quite hard to break out of that if you've...

Adam Davis (: 18:13

Yeah, yeah.

Adam Davis (: 18:24

And that part is really good because in an interview situation, they can go, interesting, why did you give that response? And the candidate may go, well, in my current role, we have this major incident procedure where we do X, Y, and Z. And it's like, that's interesting. And then we can tie that back to potentially how BET works or what we'd consider being pragmatic about a major incident like that.

And the nice possible way sometimes it might be like ask for forgiveness because it's like if you know, if you're 99 % sure this thing can't get any worse and you can press a button to potentially alleviate it, you know, you probably wouldn't chastise people over things like that. But it's really that pragmatic view. I think doing those scenarios in a whiteboard would just allow people to.

have that conversation if that makes sense. So providing those scenarios really just generate those conversations which that's what an interview should be about in my opinion. It's great having your CV but I think that's to get you through the door almost. And then the whiteboarding sessions that I like to do is more about, well if you worked here what would some scenarios you make face look like?

And it's kind of those sort of things really to drive some of those, those conversation points that our candidates hate it being sort of a tick box exercise going, know, tell me when you, when you worked at this place, you said you, created, you know, 20 % improvement in delivery. It's like, okay. But in a real life scenario, what does that, what does that look like? If that makes sense.

Sean Allen (: 19:49

It sounds like it's much more conversational the way you drive. Obviously there's a structure there behind it, but then at the same time, in my experience, when you're just being fired questions, it feels quite pressurized, doesn't it? Because you're just getting hit. Whereas when you, in the same way, you can still hit quite a few questions, but when it's conversational, I don't know, as a candidate, I've always relaxed more and you're probably going to get more authentic answers out of me.

Adam Davis (: 19:54

Yeah.

Adam Davis (: 20:12

Yes.

Sean Allen (: 20:17

that are actually more real than taking a second to think and give a very structured answer back to a very structured question thinking you've given them what they want. How do you find that? I mean, it is a pressurized environment, isn't it? When you're a candidate interviewing and especially in this market where we've seen, you know, people facing layoffs at different organizations and, you know, everyone's got bills to pay.

Adam Davis (: 20:23

Okay.

Adam Davis (: 20:39

Yeah.

Sean Allen (: 20:44

probably more precious some candidates put on themselves as well if they're out of work. So how do you deal with candidates and I guess setting that environment up for them to succeed, if that makes sense, when they're meeting you and your colleagues?

Adam Davis (: 20:58

think we've had a couple of examples, probably the last 12 months we've in an interview and we've had some people who've really put lot of effort in, know, so in a nice possible way, they've dressed really smartly, they've come in, they've sat down and then just been paralysed by complete fear. And we've had that on a number of occasions and I've always thought that as a bit of a thing to go, how do we turn this around almost?

you know, generally speaking, you know, you'd hope everyone would try and do that. I imagine a lot of organizations that just need to hire really quickly time is, you know, time, it can be a limited sort of resource. Some people might look at that straight away and go this candidate is not for us. But we've seen that on a couple of occasions where we've had those individuals, we've kind of just gone, we've seen something on your CV and it's like I've gone traveling around Europe for the last eight months. And we've drilled into that to try and pull them out of that paralysis where they've come in going

I really need this job, you know, and all the stress that they've been in an interview situation. We've just try and pluck them out of it. So conventionally, you know, we might start about, you know, we might say, can you just go over your CV before we jump into some kind of scenario questions? But when those when those candidates come in and really been paralysed by kind of fear or anxiety, we might just draw on something that's just completely off field a little bit might be a hobby. might be an activity they've done. We'll spend a bit of time talking about that just to

I guess normalise a room almost to reduce some of that anxiety and stress and then trying to go into trying to then lead that back into where we want the interview to go.

It goes back to what you said before. reason I've done those whiteboards whiteboarding sort of technique, especially in the last 18 months was it's got to feel like a conversation. You know, that might not be me holding the pen. It might be the candidate drawing some lines between two different things. And that feels more engaging than having, you know, someone cornered behind a desk with two of you looking at the other person going, OK, let's go through every year of your CV and why is there a gap here? And why did you do that? And what I found is those those candidates who were the quietest

Adam Davis (: 22:59

ones or perhaps parallelised by the fear or anxiety of coming in have been some of my best hires to be honest. So I've always tried to keep it, I've always tried to see it as it's not just on the candidate to kind of push forward with that sort of stuff in terms of getting out of that paralysis. It's really on the hiring managers to...

Sean Allen (: 23:07

Nice.

Adam Davis (: 23:23

to allow some of that to happen. And for me, that's very much, know, let's have a conversation about something you really enjoy. And that might not be anything to do with the interview situation. But if we spend five, 10 minutes talking about that, might be someone's really passionate about football or really like martial arts or they like hiking. If you can find some synergy, we'll stalk in that space for a bit to, I guess, calm the candidate down, if that makes sense. Normally speaking, when we got an interview situation recently, my style is to...

understand the candidates CV and their history, go into the interview and spend only just a few minutes on what is the CV because the CV has got them through the door. I'm really interested in the person at that point. It's like, how do you how do you solve problems? You know, what can you bring? And that might be different life experience. And I'm really interested in that side of things. So I try not rely too much on a candidate CV through the interview.

unless they've said, you know, I'm really good at cloud and then you do a scenario on the board and they're like, they've never used cloud before. That's not great. So I think that conversational style comes out of using some of those techniques, but equally for those candidates who are a bit paralyzed by fear, then it's really on us to try and help with that.

Sean Allen (: 24:24

you

Sean Allen (: 24:39

Yeah, I really like that. it shows that care, you know, that you're putting into the candidate as well. And for me, whether they, if I was like candidate, whether I was successful or unsuccessful, I'd leave with a positive experience that I was, I was set up for success as much as possible. Right. And, you know, sometimes it might not work out and that's fine, but it seems like you're looking for that reason to hire somebody rather than to say, no, when you mentioned that before, people may see that and go, no, not for us. Whereas you're like,

Well, we've brought them in this far, so there's something there. So we want to try and pull that out, right? And give that person as much opportunity to be their best self in that process. You talk about whiteboarding a lot, I really like that because it's a lot around that thought process and spikes that conversation. Are there any other parts of the process that you look at? Are you a big fan of sort of like technical testing or if it's in development or?

Adam Davis (: 25:13

Yeah, yeah.

Sean Allen (: 25:38

other things you sort of, guess, have quite a variety of tools that you use when it comes to hiring.

Adam Davis (: 25:44

Yeah, we do. there's a whiteboard audience great for bringing someone in and doing a deep dive into scenario based questions. Sometimes we now do upfront screening from technical tests as well, which, you know, when we're aggressively trying to hire and grow out that can help screen. And, you know, sometimes we do get candidates who will say on a CV, they've got all this experience in a particular particular technology, and then they'll go into an interview situation and then perhaps that experience either isn't at the level we need or just doesn't exist.

which isn't always great. So we do use screening tests occasionally. Not all teams use it that, you know, we kind of open up. We operate on a model whereby teams can have the freedom to detect how they hire. So there's no mandate to go. We use technical screening tests all over the place and we do use them where appropriate. We increasingly use them more. I think now we fully established ourselves into Go because what we don't want to do is

From our point of view, we've gone through a massive training exercise and we brought a lot of Go developers in. So we're really looking for strong Go developers and candidates to compliment that. That's not to say we are only hiring people with Go experience or a particular technology experience, but it does mean we can be a bit more selective now in terms of we've got our main growth and headcount up to where we need it to be. Largely, we can apply a bit more rigor up to that upfront selection process.

But I'm also a firm believer that someone who may not fare too well in a technical test could still be an amazing hire. I've seen that a couple of times where someone may fare quite poorly, or actually in an interview situation, a problem solving situation, the race. So you have to take that with a bit of balance, I think. I think there's a massive part of technical screening tests to play in recruitment.

but also I think I'm really keen on having conversations with people. I think that upfront 30 minute conversation we do, we typically do a 30 minute conversation, potentially a technical test and a, face to face interview with potentially scenarios. And that'll be with a hiring manager and another representative. It might be developer to join. I think that works pretty well.

Adam Davis (: 27:53

So I'm mindful there's a place for that technical screening process, but I'm also acutely aware that some candidates may not fare very well in those situations for a number of factors and therefore, you know, might fare better in a different scenario. But yeah, it is part of the technical world now in terms of, you know, those tests are a thing and they're a part of that interview process and really is to filter out those candidates that I've said potentially they're really good at something or perhaps are weak or don't have as much exposure.

A great example of that, you know, not too long ago I was doing an interview with a candidate who had put a key skill as being a Google cloud platform. It was in the key skill section of the CV. When asked about it, it was like, I've read a tutorial on it and it's like, it's kind of probably not a key skill. So.

Sean Allen (: 28:30

Okay.

Sean Allen (: 28:40

Probably my level of GCP knowledge. Yeah, a ready tutor on it. I went to a tech talk and someone talks about it. So I've got an idea. But yeah, it's really hard, isn't it? I think it's always difficult on a CV when you speak to a candidate as well, because people put their skills and they list where they feel they are with them, don't they? Some people do know everyone, but like expert, intermediate, whatever.

Adam Davis (: 28:43

couldn't comment potentially.

Adam Davis (: 28:50

that's it.

Adam Davis (: 29:09

you

Sean Allen (: 29:09

our very own definitions are different to someone else's definition of that. So I could think I was really, really good at Java, for example, but actually compared to your expectation of what really good at Java looks like, it might be completely different. So it is really hard. So then there is that part of how do you assess for that? Where you get a good enough gauge to make that right higher. So you're not bringing someone in at the wrong level of role.

I mean, it disrupts the balance of the team. So it is a, yeah, I guess that's where tech tests help and that conversation afterwards, isn't it, to understand it and you can get a good idea of their thought process when completing that challenge as well. And I know you mentioned before as well, you you've got people, you don't put too much onto the CV and then you've got some people that maybe have,

I've had gaps in employment and you don't really put too much weight into that. do you sort of consider a lot of, someone, especially, know, we've seen it since COVID, a lot of people see these are a little jumpy just because of the market conditions and the economy. So do you try and look at something else if someone's been out of work? Do you try and look at other stuff that they've maybe been involved in to highlight what they do? How do you sort of...

Adam Davis (: 30:35

Thank

Sean Allen (: 30:38

How do you address that for those that have struggled to get back into work and looking for that next opportunity?

Adam Davis (: 30:44

think the biggest thing there is, what folks been doing to, still, you know, still stay within the kind of technology sort of space in terms of keeping their skills fresh or learning stuff that might be looking at accreditation. So we've seen some folks in those kind of places where they just go and learn to load yourself about Google cloud platform and got some accreditations or AWS in the same sort of way. or they might've just started a little side project. So we have hired people off the back of just doing a side project. So in the interview, you know, they might

just go, I want to present this project to you that I've worked on. And they'll open up a git repo, they'll go through all the code. It might be something they contributed with several other people, they'll explain why they've done it. And I'm always really passionate about side projects. In terms of I've done lots of hackathons before. And it's always appealed to me, folks who do that, and then use that potentially.

in interview situations because it's a really good demonstration of you're going out your way to construct something and present it, but you're doing it off. You're your own boss with a side project. You can make it wherever you want it to be. You can use whatever technology you want it to be. It can be as interesting or as weird and wonderful and presenting that in interview situation. Sometimes just

it's not even on the CV, they've just mentioned it offhand and gone, oh I've also built this, I've had experience with this, and it's like, can you drill into that? Oh yeah, I've got a git repo for it, let me show you, let me show you, and I'll spin it up, and it's like, that probably should have been on your CV, because I would asked you about that, that would have my first question, and often we've hired people just off the back of them showing us what they've produced.

And that can be as valuable as a university degree in some respects. What are you doing to keep your own skills up to date? But what are you doing off your own back? show, side projects show that you're interested in something. You're not being forced to do it when you're in a work scenario. You're, I don't want to say being forced, but you're mandated by the company to deliver projects, right? That's why you're there.

Sean Allen (: 32:33

in

Adam Davis (: 32:51

When you're doing a side project, no one's mandating you to do the thing. You're your boss really. You're telling yourself, I really want to do this because I love it. So we've had lots of people in those situations where they've really stood out and perhaps not highlighted it enough on their CV to go, I've also done these side projects or I've built this thing. Especially with those folks who have got less commercial experience. I would argue that isn't just as important. You you can really, you can really go to town on stuff you've done.

off your own back, if you've been involved in a hackathon, definitely put that in there. know, people who are prepared to stay awake for 24 hours producing something in Manchester Science Museum like I've done a couple of times for Hack Manchester. It just goes a long way to telling you about that person and what drives and what interests them and why do they use that technology. So that's really good for us.

Sean Allen (: 33:42

shows a passion for it, doesn't it? And it's interesting, because with BAT, there's been a lot of movement to Go, as you mentioned. I imagine if I was a software engineer and I wanted to work there, but I've not worked with Go, I'd probably have a Go side project with it, just to upskill myself a little bit. But that would be an opportunity for me to then show you, I may have this .NET background, but actually I've been doing some side projects in Go. And it shows that sort of aptitude for learning as well.

And then obviously that's a big part that when you're an engineer, it's just constant learning, isn't it? Let's be honest, everything's evolving and changing all the time. I don't honestly don't know how engineers do it because I feel like if you took a year off, you'd be three years behind. But it is that aptitude, isn't it, to constantly learn and evolve and progress. So I love that.

Adam Davis (: 34:22

It's cool.

Adam Davis (: 34:32

I did that. They they got they shared a side project as part of their interview and it was in Python. They joined the company and it was.

maybe a couple of weeks ago, they bumped into me in the office and said, Oh, could I show you this? And it was basically their project rewritten in Go. And there's no reason to do it. There's no motivation to do it other than to go, I'm just, still learning on my go journey, but I've done this at work again. I just re-engineered it. And it was like, it's still the same thing, but you this person's gone out of the way to do that. was like, that was a really big thumbs up for me. was like, you care deeply about trying to learn more in this, of this language and technology.

Sean Allen (: 34:47

nice.

Adam Davis (: 35:08

and it just cemented the fact why we hide this person if that makes sense.

Sean Allen (: 35:11

Yeah, and they're people you want to work with, right? They're great people to surround yourself with, they? I'm conscious of time, Adam, because I know we could talk for hours, but you've probably got a lot of hiring to go do as you keep scaling your teams out. I guess for any of our listeners, obviously engineering leaders or time acquisition folks in the tech space, is there any sort of tips or advice that you'd give them when it comes, I guess? Yeah.

Adam Davis (: 35:14

Absolutely.

Adam Davis (: 35:20

where we can see through from here.

Sean Allen (: 35:40

just hiring in general, I guess what would be interesting is hiring at scale, the way that you're doing it would be interesting.

Adam Davis (: 35:48

Yeah, I think using some of the approaches around whiteboarding is useful. I appreciate doing that also comes at a cost because you kind of have that healthy balance of if you need to scale really quickly, there's a huge time investment to sitting around a whiteboard for potentially two hours with candidates. I think some of that upfront screening with technical tests, there's definitely a place for that. Those certainly have a place to get you the folks that probably will.

give you better odds of being in that situation that are going to generate those results. What I would say though is

I would just take that with a pinch of salt as I mentioned before in the sense that you don't want to eliminate candidates that could otherwise be an amazing fit but might not have all the skills quite now so they might fair low on the technical test but you know culturally they might have had a really good diverse set of life experience and that could be really useful to complement the team in terms of they'll just be great socially to glue a team together you know we might have had people in the past that technically weren't that great at the start because they were still new there could be grads

They have less experience and we've had to build that up. But equally they've got those side projects. They bring all that social sort of stuff with them. So they complement the existing team base. And really it's just about just keeping an open mind. I think what I would suggest to candidates if they're applying for roles as well as ask questions. The biggest red flag for me is, know, it's a two way street. It goes back to what we said before. It's a conversation, right? So you've got to be interested. You've got to know a little bit about the company.

about the role, you you've to do a bit of research. It's a two way sort of conversation. If I'm predominantly leading the conversation, I want to know why you're interested in working at BET or any other company. You know, you've got to show that interest and it has been authentic really. And first impressions do count. You know, you go into an interview and, you know, there's always an acceptance that you're going to be nervous and things, but having those things where you can ask lots of questions, you can have those written down so you don't have to fumble or forget about them.

Adam Davis (: 37:46

But yeah, it's a conversation really. But what I would say to the hiring managers is, you know, doing some scenario questions around a whiteboard for me has worked really well. And I don't rely too heavily on someone's CV once they're through the door. I've always seen that as a mechanism to go, this person's great on paper. Let's really dig into that through conversations and scenarios.

Sean Allen (: 38:08

Now I love that and if anybody wants to find out more about what you've discussed today and dig a bit deeper, what's the best way to contact you and I guess importantly as well if anyone clearly wants to work with you after what you've discussed, what's the best way to find out what jobs are going on in your team as well.

Adam Davis (: 38:28

Yeah, so you can find me on LinkedIn. I've also got my own website, adamdavis.co.uk and we've got a Bet 365 career site. So it's full of different roles at the moment, plenty in my sort of area, player account management. If anyone's interested, more than welcome to reach out to me directly. You can sign, post people or give people some advice. So absolutely.

Sean Allen (: 38:46

I will share all of those links in the show notes for everybody. But it's been an absolute pleasure. Thank you so much for your time. I've really enjoyed that conversation. And yeah, I'll catch up with you soon.

Adam Davis (: 38:58

Yeah, thank you very much. Cheers for having me. Thank you.

Sean Allen (: 39:00

Thanks Adam.