Ryan Grey - You Can't Always Be Right In Software Development

Speaker A: Welcome to another episode of Talks with Tech Leaders. Today. I'm delighted to be joined by Ryan. Thank you for joining me today. Would you mind just giving a bit of an intro to yourself?

Speaker B: Of course, yeah. Um, I'm Ryan, I'm CTO at a company called Mara, uh, who are a power platform consultancy. I'm, um, based in Gateshead and I've been in the software development industry for uh, I think about 15 years now, maybe slightly more brilliant.

Speaker A: When, when did you start off in tech? Was it from a young age? Were you in school, university? What sort of path did you take to, to get into technology?

Speaker B: Yeah, that's uh, an interesting one. I know normally a lot of people are in tech. Uh, they've been in it since they were extreme, extremely young. They started dabbling with their, uh, with their home computers. I actually got into it a little bit later. Um, so didn't do any programming or software development when I was a kid. My first degree was in maths, so I didn't touch like any coding languages or anything like that in my first degree. And then what happened was that I was living in, I guess it was still kind of a student house, even though I wasn't a student anymore. And uh, one of the people I was living with, uh, they started doing a master's in computing science, um, but it was like a conversion course. Uh, so it was for people that they had a degree but their first degree wasn't in computing science. So it's kind of like three years, uh, compacted into one year, so quite intensive. And uh, he was telling me all about it. It just sounded so interesting to me. Some of the things that he was talking about just seemed to click naturally for me. And he was talking about this, um, didn't know what one was at the time, uh, an IDE called, um, Blue Jay, um, for, for Java. Uh, he showed me this thing and so interested in it that I just decided to download the thing like in my own time and started playing and tinkering and it was just so much fun. Uh, I actually ended up signing up to the exact same master's course. Um, what happened at that time is I was working like a bunch of kind of admin roles. Um, nothing was really sticking for me. I wasn't really. The degree that I had in maths was really great and really fit with my sort of logical way of thinking. But I couldn't find something that really landed the mathematical skills in a career. So, yeah, the master's degree in computing science, um, just again really clicked with the way that I think about things. Got um, that degree and then got a job FOR uh, ah, ScottLogic, a software consultancy in Newcastle and the rest is history.

Speaker A: Yeah. How? Because I have seen a lot of people with maths degrees get into software development. So I know this might sound quite similar but is there a link there or is there methods uh, used within that, that if you've got solid ground in mathematics then that you can take that to coding?

Speaker B: Yeah, I think that, I think the sort of abstracted ways of thinking uh, in mathematics that's what's useful. So there's no particular module that I did that like I use on a day to day basis but just the way of thinking that there's often when you're doing development with code there's quite a concrete end result that you need to get to and that's kind of the same thing in maths, in mathematics. So yeah, I'd say that it's the style of thinking more than any particular like skill that I picked up.

Speaker A: Yeah. Where would you be if you hadn't met your housemate and he showed you that?

Speaker B: Who knows? I could still be leaping from admin job to admin job. So uh, who knows?

Speaker A: Yeah. Oh great. So you start off at Scott Logic. Was it um, a graduate scheme or um, something similar to get your first ah you know, experience underneath you?

Speaker B: Yeah, so it was um, it was their uh, graduate developer program that I joined um because I had my first degree. And then a pause uh, while I uh, I guess you call it the floundering years. Jumped from admin role to admin role. I was slightly, slightly older than the other grads that joined uh, which was an interesting experience, um, a good experience. Um, so yeah the, the graduate program with ah, Scott Logic is where. It's where I started. Yeah. Yeah.

Speaker A: And did you get thrown into the deep end quite quickly or was there a bit of a gearing up period where they showed you a little bit, trained you how, how was that? Because um, as you mentioned they're a consultancy so I can appreciate there's you know, a lot of projects are working on a lot of work that they've got. So how, how was that initial period for you again not coming from, you know, developing from a young age. You know it's still, you know, you've done the theory, you've probably made some projects at uh, university. But what was, what was those early months like uh, at Scott Logic for you?

Speaker B: Really, really difficult. It was for me it felt like it was in, at the deep End a, uh, huge amount of imposter syndrome. I mean everyone in tech always talks about imposter syndrome. I think almost everyone has, like, has a slight issue with it. Uh, but, yeah, being surrounded. But that's, that's what I was referring to when I said it was interest. I kind of felt a slightly older. I felt a little bit behind. Some people that I was on this grad program with, they'd been doing it since they were a kid, so I felt like I was constantly having to play catch up. In my. In the early days, I'd be stopping until something like 7:00pm, 8:00pm some nights. Um, it felt like I was just banging my head against a brick wall. Other, uh, people just seemed to get certain things. Um, I wouldn't recommend doing that, by the way. Um, uh, staying till 7pm and 8pm has its downsides as well. But I do think that for somebody in my position, I did need to put in that grind like early on, like to make sure that I kept up to speed. And I, I think this connects with um, something that we might talk about later on, which is like how to learn and how to um, upskill. I think you've got to do it by doing, not by just sitting and reading documentation and like theories on how to do these things. I think that something that ScottLogic did incredibly well is that they put us on projects like from the get go. Um, it wasn't like sitting in training all day long. It was, here's something you have to build as part of a team. Go and do it. Yeah.

Speaker A: And was there a lot of support there as well and.

Speaker B: Oh yeah, yeah, yeah, yeah. There was, um, they kind of pair us up with, uh, mentors, make sure that we were, you know, sat with the senior developers and things like that. So it's not thrown in at the deep end without the armbands. It was popping the armbands on and then chucking us in.

Speaker A: Yeah. Was there any moments then in your early time there at Scott Logic where you know, sometimes things start to click or you kind of think, okay, well actually I can do this. Was there any like, moment, any particular time working on a project or working with a team that you kind of felt like, you know what, actually I'm, I'm doing all right here. I'm comfortable.

Speaker B: Yeah, I guess, um, my earliest memory of that type of thing was where we were talking about the, um, the quality of one of the products that we were developing. And I suddenly realized in this room, in this meeting that I had like the most to say like on the topic. And up until that point I had felt like I had things to say but maybe I wouldn't get listened to. Maybe other people in the new in the room knew better than me. Um, but there was this moment where I distinctly remember it. I knew all about the test pyramid unit tests, integration tests, end to end tests. And not to get into the detail of it but that we were focusing too much on the end to end tests which was making our testing strategy brittle. And just having all these things to say and seeing some of the seniors in the room kind of nodding and agreeing and I was like, oh okay, these people are going to listen to me. This is great. Um, so yeah, I think that's really, really important in tech leadership is um, now as a leader I try to mirror that. I try to give people the space, like to have a voice and when they're saying something, even if it seems obvious to me, um, but they're saying something, it's like give them the encouragement, make sure you give them the eye contact, the uh, the enthusiasm.

Speaker A: Yeah. And then from scotlogic you moved to um, a product based company, is that right? I was there a few steps before you got there.

Speaker B: Yeah. I mean actually interestingly I started in product at ScottLogic. So ScottLogic is a consultancy but they were um, they had a couple of products. One was called Visiblox, I think it was for web, uh, which was a uh, data visualization library for web and they wanted to create the same thing for iPhones. Um so me and a few of the grads and um, a tech lead, uh, were put onto this project was called Shinobi Controls. Uh, so yeah, we were developing this developer um, tool that was a product. Um, so it's like a product arm of a consultancy. And I did that for five years. Um, and it was, it was super interesting because what we were doing wasn't kind of the normal developer experience for people within ScottLogic. Uh, you had to be a little bit more, um, you know, your, your eyes on the long term a little bit more. Not saying that consultants don't do that, but consultants uh, because of the way the contracts are set up. Um, you do in principle have your eyes set on a near term goal. Um, so yeah, it was interesting being part of a group that thought slightly differently about things. But then after those initial five years moved into consultancy, um, which kind of really shaped me into a generalist because you could be put on any kind of project with any kind of technology. I remember being, having spent five years on iPhone. So it was Objective C and then Swift, um, then moving into consultancy. I was suddenly thrown into um, HTML, JavaScript, React had to upskill in that very quickly. I think I basically had two weeks before uh, I went onto a project and that was kind of the experience from then on. Ah, the number of different technologies where I would have a week or two to upskill in um, was considerable and I think that that really helped me to form ways of spotting like patterns like within technologies that you can then go and apply to other patterns. It really accelerates your ability to learn new things and extrapolate ideas from one area to another. Um, which is a really interesting part of working in consultancy. But yeah, um, what happened with consultancy versus product later on? Well I was at ScottLogic for I'd say six years in consultancy and then had a brief stint at another consultancy and then went to become head of engineering in a company called Grid Smarter Cities, uh, for I think nearly two years. And that was product, that was a SAS company. So very different experience there. Uh, yeah.

Speaker A: And um, yeah it's great because like you said you worked inside product within a consultancy so you were used to working in that environment. Then you've worked as a consultant and then you've got a variety of skills that you've picked up as well. So I think there's that adaptability part to it where some, some developers can be stuck on a project for a long time.

Speaker B: Yes.

Speaker A: And then they think well yeah, maybe it's time to move on. Yeah, maybe, maybe do something interesting. So you kind of, it was weird because you've kind of got that test within the same company whereas typically somebody would maybe move from one to another. When you then went to work at ah, a product based company I guess then you've already got those skills and experiences. So did that make that transition a bit maybe easier or maybe some that you were used to when doing that?

Speaker B: Yeah, I'd say uh, a little bit easier. So I talked before a little bit about kind of product thinking and kind of having your eyes on the end goal like the maintainability of the thing. Not just that though, kind of long term iteration like on an idea as well. Um, how do you get user feedback and how do you, how do you decide what feedback to take account of and what feedback to ignore? Because he can't please everybody, which is another thing. So yeah, I had some of those ways of thinking um, when I went into Grid Smart Cities having ah, spent six years doing consultancy though the flip side of that was that Uh, I found that going into that type of company it's interesting in that I felt like I had a sort of consultant sheen. Uh, to me uh, that the people working in a product company they can be a little bit scrappier. I um, and just kind of tell it how it is to each other sometimes. But when you're working as a consultant you tell it how it is but you've formed, you form this very professional way of doing that. Um, so that, that was an interesting change as well to go through to be honest with you. I love it when people just tell it how it is.

Speaker A: Yeah, yeah. And were you, with you getting into a leadership position, did that start at Scott Logic when yeah. You were working with other team members and then progressed to head of engineering. And could you tell us a little bit about that journey? Did you fall into management or fall into mentorship leadership or was it something that you'd, you know, wanted and uh, aspired to?

Speaker B: Yeah, yeah, it's a great question. I'd say that it just naturally happened over time. Um, I think that with my career I've never had a particular long term goal in mind. I think I've always more been of the mindset of take, um, the opportunities that appear and that seem interesting. Um, but it's like iterating over like short term opportunities rather than having some kind of long term goal. So yeah, uh, the way that panned out with like leadership and management uh, is that uh, when I moved to uh, being a senior developer um, I started doing some of the um, tech leadership on the Shinobi Controls project. So that was in my first five years. Within the, within five years I'd become a senior um, and that was a small team. Uh, on the iPhone side of things I think there was maybe about four or five of us. Um, there was a tech lead that sat across uh, Android and um, my iPhone. Uh, so that was a really great experience for me because it meant that I uh, was getting the ability to experience doing some tech leadership whilst there was somebody to learn from and mentor me as well. Um, so I didn't feel alone. Uh, that was really great. And also the, the people that were working on it with me, they were just so great as well. It always felt more like collaboration than tech leadership in that initial, in that initial taster of leadership which really helped me feel comfortable as well. Especially with that uh, sense of um, imposter syndrome. And then beyond that, once I moved into the consultancy arm I got the opportunity to lead some very small projects. So uh, Two or three people, which really helps you to slowly build up that uh, tech leadership muscle, uh, without. Without being responsible for too much at once. I did run into a kind of um, trial by fire type situation soon after that though, which was a um, a consultancy project that we had, um, for a retail bank where I went in to start the discovery just by myself. Then once we moved out of discovery we ramped up to there being three developers, which then went to six developers, then went up to 12 developers. And that happened over quite a short period of time. And that was an intense experience. I guess one of the things that helped me with that was the smaller experiences that I'd had earlier on. Uh, that was really useful. I already had some mental models around how to do this. Um, I think the thing that helped me scale from 1 to 12 in that situation was having had the chance to uh, put in place a lot of good uh, processes like both manual and automated, uh, which really helped the skill like from 1 to 12. Um, I. Thinking through, and there's a real tension here. It's thinking through what is the defined process that you and everybody else has to follow whilst making sure that the space within that, that people can contribute and bring their own ideas and there's kind of room for flex in it as well and really understanding what the backbone uh, of that process and your automated processes are, uh, and trying to funnel people through that. But when you funnel people through that, trying to make sure that it doesn't feel like they're being controlled or hampered and if they do feel that way, making sure that they've got the air time to express it, take on board the ideas on how you can change like that agreed way of working together. I suppose there's a difference there between uh. M. You have your way of working and you're going to impose on everybody versus how do you get everybody to communicate, to make sure that we all continue to agree on our shared way of working. Um, and I think that accidentally fell into doing that uh, in that one to 12. And then I've tried to kind of model that ever since.

Speaker A: Yeah. And we were talking most recently in your current role at Mara as a cto, you've um, delegated a lot more. So you've um.

Speaker B: That's right.

Speaker A: So you've maybe got less reports. So how. How did you find that? And how. I guess how are you finding that compared to having multiple reports in previous businesses?

Speaker B: Yeah, again really interesting transition and early on actually quite difficult transition. I don't want to pretend that all of this stuff has been smooth sailing. Absolutely not. Um, the biggest difficulty with that transition was, I guess it's moving from uh, doing and the tactical to um, creating the right processes and space where uh, the doing can happen productively and can continue to happen productively. And this, this is something that a lot of tech leaders talk about all the time. There's always the, there's always the allure like of going and doing yourself, especially if you think you can get it done faster. But there's a great expression which is, um, to go fast will go slow. Which is if you take the time, uh, and create the space for people to learn how to do the thing, that's going to take longer initially, but over time it compounds and the team around you get quicker and quicker at doing the thing. And imposter syndrome plays a part here. Uh, there are times where you are trying to be hands off, uh, and you suddenly think to yourself, I'm now too hands off. Maybe I don't understand what's actually being developed anymore. And then you have to try and take a step back in without making the team feel like you're controlling or trying to uh, step in and change things. So a constant push and pull. Uh, it's been an interesting journey.

Speaker A: Yeah, I've got a quote from Steve Jobs here. Uh, great things in business are never done by one person, they're done by a team. How true has that been in your experience and development?

Speaker B: Yeah, uh, absolutely true. Um, even if I think about the sort of smallest, uh, teams that I've been on, it was still a team. Um, so the smallest teams or something like three or four people. And if I really think about what was going on there, um, you couldn't have reduced that down without impacting. It's tempting to just talk about the productivity, but it's not just the productivity that would have went down, it's the quality of the thing would have went down. There are just, you know, this plays into diversity in possibly a non intuitive way in the diversity of thinking. Like on that team you do need people that are going to think in slightly different ways and understand things slightly differently to you. Ah. So the quality of the output of a team purely, uh, because of their life experiences and their skill sets over a longer period of time will generally be higher than just if one person did it.

Speaker A: Yeah. What, what steps have you taken or do you take then to keep uh, happy, healthy sort of team culture.

Speaker B: Yes. Um, so psychological safety, it's a uh, word that everybody loves to uh, talk about. It's quite fashionable to talk about psychological safety now. Incredibly difficult to do though. Um, really, really important to try and do it though. So I mean to me psychological safety is effectively, uh, can people like bring, bring a large part of themselves to work and not be afraid to do that? Um, if people are masking too much or holding too much back like in the workplace, like that's where there's a problem. There's a two sided problem as well. On one side you're not going to be getting all of these potentially great ideas and challenges which you do want to invite in the other side is that you could develop resentment. On the other side of the fence, uh, not even consciously, subconsciously it can happen that if a person is masking uh, just over time they feel that they're not being true to themselves, like of their own values. So they may not even understand why it's happening. But it can lead to burnout, it can lead to people not wanting to be part of your team. So yeah, making sure that people feel like they can just be themselves and that they can speak openly about problems. I mean litmus test number one is like, do the people on your team feel like they can say it out loud when something isn't working? Um, as a tech leader it can be, how do I say this? I think people in tech and um, who work as developers, I mean we just talked about how mathematics um, connects to this as a very logical way of thinking. Um, and a large part of developing software is being correct. Uh, so the functions that you write, uh, the software that you write, you can have one character type wrong and the whole thing can collapse. So there's this, there's this eye of Sauron from uh, the leaders, the entire company on this thing, that the quality is super high. So what that breeds is just this, we have to be right, we have to be right, we have to be right kind of mentality. But the interesting thing about that is that you can't always be right. Uh, and this is where the, you know, the idea of agile software development that you iterate like towards correctness instead comes from. So how does that play into psychological safety? Well when you are, when your team members are raising things that might be wrong and you've had bred into this, you must be correct like type mentality. And so to hear that it can sting, like when people are challenging you, it can really sting. But you know, going back to the Steve Jobs quote, um, teams that work together and um, raise issues, like if you're curious about that and you think through, well, wait a minute, like does this person actually have a point here? Could their objection lead to an improved way of working? That's just so important. And if you manage to do that, um, it will increase the team's confidence over time that they're going to get listened to, which is what happened to me. Um, you asked about what was my first experience of, you know, where were people going to listen to me, that that's what someone gave to me. And so it's really important that I try and give that to other people as well.

Speaker A: Yeah, because I guess in that moment you felt safe and confident even if it was subconsciously you just felt like, I can talk in this meeting, I can say how I feel. I feel like I've got the confidence to, that I've got the most knowledge in this area at this time. So yeah, I think it's like you said, create an environment like that. It's great that you've had that personal experience of it as well.

Speaker B: Yeah.

Speaker A: Have you seen examples or have you seen any companies that maybe are uh, doing it wrong when it comes to psychological safety or what? Do you have any ideas in terms of how companies can um, bring more of this in to their organizations?

Speaker B: Yeah, I think that it's hard for me to comment on the tech sector in general with this, other than what I just said about you kind of have it bred into you that there's this correctness thing. Um, so I think what that leads to is quite counterintuitive in that you have a lot of people that are kind of psychologically formed to initially uh, be quite brittle, to like having their ideas challenged. But um, because uh, agile software development is about iterating towards like correctness and iterating towards like an improved outcome, I think what it means is that it, it kind of leads to a lot of people having the same experience of me. Like at first it feels difficult, it feels sharp and it feels brittle. But because um, agile software development and iterating towards solutions, it is like I believe is the status quo in good companies that what it leads to is just putting those people like through that experience where most people over time begin to learn that no, like we have to like have a culture of criticism. Like criticism can sound like a dirty word, but like being um, uh, like positively critical like of each other's work. I, I do think that that is like the normal journey for people like in tech now we've all had like bad experiences on teams like with bosses, with colleagues where we've not Felt safe. And that does happen. Like in tech. It happens a lot. Um, but yeah, in general I think that because we've got to get to that correctness and iterate towards it, uh, I think it leads to an industry that is quite good at psychological safety or teams tend to start to arrive at something or even feel the need for it. They at least feel the tangible need for it.

Speaker A: Yeah. You talked a little bit about diversity in teams earlier. Um, one of the things that uh, I really like about Mara is the, the ethos of um, getting more females in attack and getting more people from underprivileged backgrounds in the tech as well. How has all that experience been for you and how have you found diversities helped Mara?

Speaker B: Yeah, it's been a really good experience. It was, um, one of the things that attracted me to Mara when I first heard that, uh, the company was being started. Um, you sometimes see the um, the Tech for Good hashtag, um. I hadn't realized it in the early part of my career that, um, feeling that you were doing some kind of good or that there was, you know, a big green tick next to the morality box. I didn't realize how important that was to me early on. But then I did have a couple of experiences of um, working in domains that started to indicate to me that I had a sense of moral compass on this stuff. And so ever since those experiences, I've been kind of looking for, um, to work in domains and on projects that it feels like they're doing some kind of good in the world. Uh, so, yeah, initially attracted to Mara for those reasons, um, it's been really Great. I mean, 50% of the leadership team at Mara, um, are women. Um, we have ah, good gender diversity within the team. And as I was saying before, the most important thing for me, uh, is not that we're hitting some kind of quota. Uh, it's that a diverse team leads just a higher quality output. Um, so you need those different ways of thinking. Uh, you need people that are going to challenge you, uh, in different ways on different things. You need people on teams that are going to challenge, um, you in different ways. Um, and um, yeah, I think, um, one of the ways in which that plays out at Mara is that early on, uh, we were bringing in, uh, career changes, um, into Mara. Um, we've had, uh, people with lots of different backgrounds come into the company, which has been amazing to see. Um, one of the career changes that we had was, um, a doctor. So she'd worked as a doctor for many years, uh, prior and was interested in technology. We brought her into the company, um, trained her up, um, and she was a great consultant at Mara and she moved on, uh, to go into Android development. So at Mara, we were generally low code. She wanted to pursue it even more and get into the code aspect of it. Uh, sad to see people go, but, you know, it's, uh, probably worth considering that as a success story.

Speaker A: Yeah.

Speaker B: That we brought someone in from a different background and they've went off to explore something like that.

Speaker A: Yeah. That's amazing. I think it's just providing people with opportunities and like you said, they then started getting interesting to the code inside. What you were saying was pro chord earlier.

Speaker B: Sure.

Speaker A: Um, with regards to technology and how fast it's moving, we were discussing prior to the podcast regarding AI tools, um, how. And we were talking about how quickly it's developing, how much it's changed even in the last few years.

Speaker B: Um, in the last three months.

Speaker A: Yeah, yeah, last few months actually. Yeah. How have you found that? As you know, how do you see, um, the industry moving with that? Um, and, yeah, I guess. What are your sort of thoughts on AI and can it be good? Can it be challenging?

Speaker B: Yeah.

Speaker A: What are your sort of thoughts on it?

Speaker B: Yep. Um, my personal experience with it has been that it's great. I, I love working with, um, things like cloud code, uh, Codex, Um, prior to that I loved working with ChatGPT and Claude Web chat. I think that the industry is still figuring out, like, if you're actually more productive with it or without it. I've seen these studies where it talks about how people feel, um, more productive. But then when you look at the metrics, they're not more productive, which is extremely interesting. And I'm glad that I read that because it makes me stop and check myself on a few things. Um, I think that as with all leaps in technology and new developments, uh, you've got to explore it. Uh, you've got to explore it and you've got to figure out, uh, is it making the software development experience better? Is it making the quality of the output better? Um, I think that it's incredibly interesting what it might do, uh, to how people learn. Um, you know, there are other studies that show that the people who are benefiting the most and become the most productive are the senior and lead, uh, developers, not, uh, the juniors. So the juniors are using it, but they don't see the same, like, productivity gains. The theory around this is that the seniors and the leads know how to challenge, like the AI and the LLM they know how to stop it and go, oh, wait a minute, this is a strange rabbit hole that we're going down. And if you sort of play that out, uh, into the future, um, there's a real concern there which is that how do the people that are just starting out develop that muscle? Like if they are being led down like the rabbit holes, look, that the LLM or the agent is going to take them down. I, I don't think that many people have an answer to that yet. I feel like part of the answer has something to do with um, it's the Socratic way of learning which is questioning like an asking questions. I think that AI and LLMs and agents are incredibly good if you ask good questions and you are continuously skeptical and scrutinize. Um, and I think that that was a good attribute to have as a software developer and tech leader anyways, uh, which is why are we doing this? What are we looking to achieve? Does this make us more productive? Why have you implemented something in that way? Uh, now back to making uh, sure that there's psychological safety and making sure that people don't feel like they're being controlled. There are ways to word those questions, um, turn them into coaching questions rather than objectives. But those skills are transferable to uh, LLMs and agents where if you ask the right questions it actually turns the uh, situation of you being led by something into, you're just accelerating your own learning because you're asking the right questions and it's giving you the information. So if you make sure you always understand, um, the decisions that are being made and that you're part of it, um, then you're good, you're golden. I guess a good way to think of it is that people talk about doom scrolling like on Instagram and what have you. I, I saw it written somewhere. Someone described working with an LLM or an agent. You can get into this kind of almost doom scrolling situation with it where it just, it's feeding you the prompt and the next thing and you're just kind of typing. Yes, that sounds good. You got to make sure you're in the driver's seat at all times.

Speaker A: Yeah. And I can, from what you're saying. I can see similarities in the recruitment industry as well. Where I'm in, where um, if you've got entry level junior level recruiters and then they're getting introduced to all these AI tools. Yep. And like you said, it's sort of building that muscle. Like they haven't built the resilience muscle. They're Thinking this is all coming quite easy, that I've m. Been reach out to thousands of people within minutes. But then how are they dealing with rejection? What if the tools are breaking? Then you know, there's some errors with it. What have you done to, you know, what, what experience have you built up to? Yeah, think of other things and question things and receive challenges. Uh, I can see maybe some similarities with, even with recruitment with that because there's a lot of rec tech and AI companies that are spawning in this area as well. But have the juniors, have the entry level people getting into it, have their developed enough skills outside of what, what AI can help them with?

Speaker B: Yeah, absolutely. Yeah, it's a super interesting topic. Um, the resilience thing you just mentioned. Um, yeah, you're right. In order to have resilience you need to, you need to have some battle scars and have some war stories and have gotten things wrong. And um, working with alums and agents, you know, we've, we've seen the horror stories where it just affirms everything that you're doing, which is why it's so important to be skeptical, like continuously questioning like what it's doing and the reasons why decisions are being made.

Speaker A: Yeah, just going back to yourself and leadership, how would you describe your leadership style and, and how do you think that was shaped?

Speaker B: Yeah, so I think that my leadership style is to try and be hands off with the doing, uh, but try to be hands on with uh, the what? And I try to catch myself on that. I sometimes get it wrong. Um, but trying to make sure that you're focused on, I think leadership should be something like you are clarifying the goal of vision like as clearly as you can and then allowing the team to do their best work. So allowing them to define the how, like as much as possible. That's really, really difficult to do. You know, there's, I think read certain numbers and metrics from marketing. It's something like you've got to have repeated a message seven times to a person like before they really take it in. You know, when you're first starting uh, out tech leadership, you think, I'm going to write a document that explains this and I'm going to send it in a message and that'll be that everyone will understand and like they'll just stick to it. Nope, you're gonna have to say it seven times in seven different channels and you're gonna have to keep saying it over and over again and you can end up feeling like a broken record. And that's not to indicate some kind of, um, frustration. That's just to indicate that, um, that is like the main part of leadership is just to make sure that vision is understood by the entire team. So that. That's what I try to do. Don't know if I'm successful all the time. Um, I guess the other thing that I attempt to do is to give like, air time, like to make sure that people can feed into, like, how that's done and change that process for the better. Um, another thing that I would say that I try to do and comes quite naturally to me is aim for consistency, or aim to be, uh, traveling towards consistency. Ah, at any given time. So I love the expression, um, uh, consistently bad is better than inconsistently good. I have to pause before I say that every time. It's such a complicated sense, but it's. And it's uh, deliberately an inflammatory sentence. So consistently bad, this idea that, uh. Well, what's. What does inconsistently good mean? Inconsistently good means that, oh, maybe it's not defined and maybe we have a bunch of talented people on the team and they're doing all sorts of great things. Things, but in slightly different ways. Now what that means is that, uh, when I'll use the code business as an example, when you're working in one area of code and you move to a different, like part of the code base and suddenly the pattern has changed. And maybe the pattern is objectively better, like in this other area of code, but the cognitive overhead of switching from this way of working to that way of working, if you extrapolate that out to a team of five or 10, that causes chaos, absolute carnage, like at times. So if you can have an agreed way of working where everyone looks at it and goes, you know what? I. There's maybe an objectively better way to do this. But right now, like, this is what we agree on and it gets us pretty decent results. That's kind of the situation you want to be in because removing that cognitive overhead, it removes miscommunication between people. So yeah, leadership style is trying to always be traveling towards, like what. What is our shared understanding? Yeah.

Speaker A: So I guess over the years you've interviewed a lot of developers and been involved in an interview processes yourself. Um, have you. Is there any particular traits or anything that you look for when you're interviewing developers that you look out for to enable them, I guess, to, to impress you and get the job?

Speaker B: Yeah, I guess, um, like curiosity, like being curious around, um, why we're making certain decisions, how things work. It comes Back to that, maybe that's a better way to describe it. I was describing it as being skeptical before when working with agents and LLMs. But curiosity is probably a better word. It's why are we doing things in certain ways and if, if, if the like lead dev on the team is trying to make a decision, well, curiosity as to why is that potentially a good decision. So that's, that's number one I guess. Um, looking for people that have the ability to like transfer ideas like from one domain into another domain uh, is really good. I might have a slight bias towards this because I um, I myself am um, not a specialist, I'm a generalist. So I find moving between technologies um, relatively easy. But what it does mean is that I don't have that uh, deep, deep, deep, deep knowledge like on any particular area. I do think that generally um, that uh, generalist skill makes for a better developer. And I would say that not to keep going on about AI, but in a world where teams are in theory going to get smaller because smaller teams can get more done because of the productivity or skill set of AI, that your ability to switch between like different tech stacks, uh, different programming languages, different domains, people that can do that, they're going to fly like in that world. Whereas people who are just specialists in Python for example, I'm sure they'll still have a place but they will find themselves um, working with people that can be as productive as they are in that particular specialism and others. Um, so I think that people who can transfer ideas, that's really, really important.

Speaker A: Yeah. And um, what are your thoughts on tech tests and what do you think has worked well for you as you near experience and much you think works well when you're analyzing um, and seeing what developers can do?

Speaker B: Yeah, I think that um, one of the best experiences I ever had being interviewed was uh, it was a company called Makodo, uh, in Newcastle. They're a consultancy, specialized or did specialize at the time in mobile development and it was called uh, TDD Ping Pong. So that's Test driven Development Ping pong. Uh, so in test driven development you do, you write a failing test, then you write an implementation that makes it pass, then you refactor and then you start that again. In TDD Ping pong you got this imaginary ping pong ball that you're batting backwards and forwards. So I write a failing test, uh, knock the ping pong ball over to you, you make it pass by writing the implementation. You then write a um, or you might refactor Then you write failing tests and you pass back over to me. And in this interview experience we did that. And what was so amazing about that to me was that I got to see the interviewer skills as well. So, and it told me something about the culture. If I, if I can see their skill set and how they think I can see a little bit about the culture of that uh, team as well. And I remember we, there were a couple of instances in that uh, interview where I got myself into a tangle and the interviewer helped me get out of it. There was another instance where the interviewer got themselves into a tangle and I managed to get them out of it. And I think that, that I've just described it can be tempting to think that because you're doing test driven development in an interview that the interview is all about it being extremely technical and did they write this, you know, Python function correctly? The point of that interview and what was so great about it was that making a mistake was permitted. Like, that didn't mean the end of the interview didn't mean that you'd failed. Um, what was, what was being assessed was what happened when a mistake happened. Like how did you get yourself out? Or did you help you, the person out? Did you get defensive, did you have low resilience, did you collapse in a pile of sweat and tears and couldn't go on? Or were you able to work together, uh, as a pair, like to get out of it? And it, uh, was an amazing interview experience. Absolutely loved it. And I've tried to kind of, when I'm doing interviews, I've tried to replicate that in some way, like ever since, like going forward. I, um, think that it teaches you so much like about the candidate, um, to see how they're reacting to situations. But yeah, my emphasis here is that it is not that they need to do it in a particular way, it's what happens when mistakes happen. The final thing to say about that is that the load uh, that that puts on the interviewer is extremely high. Uh, the interviewer has to have the resilience and ability to get it wrong in front of somebody and be okay with that. Um, right. Um, when you are the interviewer, uh, it can often feel, feel like you back to this feeling of needing things to be correct. It can often feel like you've got to be the one that knows more than they do. You've got to get it correct. You can't be seen to be making mistakes in front of them. And I think this, this links in with the psychological safety as well. If you can run an interview like that, where you make a mistake, the other person helps you out of it and vice versa. Ah, like the experience of that candidate is going to be, oh my God, they have such a great culture over there. They've just, they've just been vulnerable in front of me in an interview. I want to work for that team.

Speaker A: Yeah. And um, you mentioned earlier about the um, ex doctor who came in, she career changed and she's progressed to um, working as like a Android, ah, developer. Now on the questions, I like to ask that have you seen examples of somebody who has like progressed really quickly in their career? So I appreciate that's one example. But um, is there anything you can talk about when it comes to what sort of traits they're shown or what helped either that particular individual or anybody else that you've worked with where when they've started in software, then they've managed to then progress up the career quite quickly. I mean even yourself, you know, to uh, to be in the position you're in and I'd say still quite a relatively short space of time. Um, it's great. So any, any tips, any examples you can give would be great.

Speaker B: Yeah. Not to sound like a broken record, but I think that the curiosity in asking questions, um, it just means that you're constantly learning and that the learning is compounding. Um, one of my favorite um, development principles is um, avoiding uh, programming by coincidence. So programming by coincidence is uh, when uh, you write the function or the new feature in the software and it works. What a bad developer does there is they stop and they go, oh, it worked. Brilliant. I can move on to my next task. The great developer, the truly great developer goes, this works. I'm suspicious of why it works. Why does it work? I can't trust this. It can't work. First time I have to go and explore this. I found myself early on code that worked. I would step through it line by line just as much as code that didn't work. Uh, so you are making yourself certain that that does not work by coincidence. Like it works because of the reason that I thought that it would work and the number of mistakes that you find that you have made in um, code, not even code. Like, let's move it away from code bases. In decisions that feel like they're working, they can often be working for reasons that you actually realize that they're working. So yeah, that curiosity and healthy skepticism, uh, let's call it like that's been absolutely key. Um, I also think that I Know that grind culture, uh, is rightly maligned. Like, we don't want to, um, suggest to people that they should be burning themselves out. But that kind of maybe grind is wrong. Maybe it's back to your word resilience, which is the ability to come up against a hard problem and just keep going. Like in my early days as a software developer, the amount of time spent banging my head against a brick wall because I couldn't get something to work. If I hadn't been resilient and kept going, um, I wouldn't have learned as much as much as I had learned. And I'd say that it's an extremely steep learning curve. If you put in that effort and be resilient, like early on and be okay with the fact that you feels like you're not making that much progress eventually. I, uh, think that people see, like their learning curve just go exponential and explode.

Speaker A: Yeah. How, how critical do you think that continuous learning is?

Speaker B: Oh, it's super important. Um, I don't think that you can rest, uh, on your laurels, uh, in like, technology and software development. Personally, I don't think that people can rest on their laurels in any domain, in any industry at the moment. Um, I think that the best people in any given domain are the people that continuously want to know m more continuously want to figure out better ways of doing so. Yeah, I think that continuous learning is extremely important. I think that especially with what's going on with tools like Claude code, codex, that type of thing, I think that it's very important that, um, people are at least playing with that and figuring out, does this actually work for me? Is this actually something that can make the team more productive? Um, I mean, let's, let's play this out and assume that we're all wrong. And, um, hard code and AI agents are all a big mistake. Um, this goes back to iterating your way towards success, like in the best answer, like, we've got to explore those dead ends. So you, you, you, in learning that something doesn't work, you've still learned something and it's not a failure if you can incorporate into your decision making in the future. Um, so I think it's really important that people explore this stuff. For sure.

Speaker A: Yeah. And, um, is there any, like, resources or habits or, you know, learning paths you'd recommend people to take? Um, I appreciate you just mentioned there about not playing around with this stuff, but is there anything else, any books, any habits you think could be useful to anybody who's either starting off their Career or looking to progress in their career.

Speaker B: Yeah, yeah. Um, well, if I go old school first, um, the, the uh, Pragmatic Programmer I think was an incredible book. Like when I read it, maybe I haven't read it in a while, so there's maybe some quite outdated stuff in there. But the, the kind of uh, abstracted ideas, like they were really formative for me. So I'd really recommend um, that book for anybody. I think that, um, YouTube, uh, is just unbelievable, like source of information. Um, I've heard people describe it as basically like a free university. Yeah, it's absolutely incredible. Um, I watch stuff every day. Um, podcasts are an amazing source of information. Listening to like people discussing new ideas and then figuring things out, um, is just so good for people's learning. Um, I think that finally the last thing to say on it, which kind of combines what I've been saying about asking good questions like using the tools. I think that the way that knowledge and knowledge creation works is that you, you can't just pour information into another person's head and then they understand a thing and can do a thing like that. The way that it works is that uh, is through uh, conjecture and correcting, um, errors. So you kind of take a guess at a thing, you try it and then you error correct. That's, that's how real learning works. And what I think that means for pretty much everybody is that you've got to do like, you've got to build. You've got to have a stab at a thing. If you like run an experiment where you set one dev off and all they get to do is read documentation for a day. The other person can't read the documentation but can build. Like, the person that can build in that day is going to know so much more by the end of that day purely because they ran into problems. Problems. They know what not to do. So my biggest piece of advice here would be do not get stuck just listening, watching videos, reading. Um, you must, must pair it with actually like giving it a go and doing it very quickly as well and not worrying that you break things.

Speaker A: Yeah, no, I found that myself. So I've been learning quite a lot of AI tools myself and recruitment. And initially I was just watching videos on YouTube and thought, yeah, okay, yeah, I can do this. This looks quite simple. Then the first time I tried to create something I was like, oh, uh, like. And it go back much. But I only figured out I'm only learning by doing building. And then when something would break and then I'm like why did that break? Going back, fixing it, then understanding it more of yep, now I know how I've broke that I won't do that again. So I can definitely see similarities with how and developers will develop their skills as well in that area. So just to wrap up then what, what's next for you and um, the business, what, what are you I guess looking to achieve in the near future?

Speaker B: Sure, yeah. So Mara, at the moment we're extremely interested in uh all sorts of things that are going on in you know Microsoft and relating to AI. So I have heavily involved in things like Code M. There's all sorts of things being announced like co uh pilot tasks, co pilot co work uh, which are like competitors to things like Claude cowork. So we're hard at work at uh figuring that sort of stuff out um, and incorporating, incorporating it into um services that we have around um adopting technology. Um so it's an interesting thing to be getting involved in. A large part of my career has been in building things. Um what Mara is uh starting to move into and is extremely capable in is um helping companies adopt off the shelf things as well. Which is slightly different from building uh, it's making sure that companies um, and teams can get good uh ROI on these off the shelf tools. Um you know we were talking about before like the speed that things move at. It really does seem to be the case that teams and organizations do need a bit of a helping hand like distinguishing between the tools and how to adopt the tools and how to get like really good value out of the tools. So that's a little bit new for me personally. Um, really exciting, uh, excited to be a part of that. Um and yeah just in general for me personally um, I spent the last 3 months m take a step back. A large part of my career was um code uh and software development in that sense last uh 3 years has been low code. And uh, when tools like Claude code and codecs have been appearing for me personally over the last three months I've been deep into that stuff as well. What's extremely interesting is that the, the way in which the two worlds are colliding. Um, we're seeing Microsoft open up um command line tools, MCP tools, um that enable more um interaction through those tools with like the Power platform and the low code tooling. Which means that Claude code and codecs can be your development pair programmer on low code which is an extremely interesting pairing. It's something that we're starting to um, get quite involved in.

Speaker A: Yeah, I think one of the things I'm going to take away from this is when you talked about productivity with AI and is it actually making you more productive or less? Because yes, I think you can just go down that rabbit hole and try and automate everything. But if it, is it actually benefiting you, benefiting your business or is it just a fancy shiny tool that uh, yes, it's. You're just thinking of more problems to solve rather, you know, like an ideas rather than actually solving the, the problems or solutions that you've got. You're just probably thinking of more problems over time.

Speaker B: Um, this is the thing about being a builder, isn't it? Like you're, you're tempted by uh, the cool new problem. Yeah. Brilliant.

Speaker A: Ryan, it's been great speaking to you. Thanks so much for, for making the time to, to come down and um, yeah, I really enjoyed the chat. Thank you.

Speaker B: Yeah, it's been amazing. Thanks for having me on.