Welcome to the Evolution Exchange Gaming Podcast, where we bring together technical leaders from across the gaming industry to discuss passions, challenges and ideas. The views expressed by the speakers on this podcast are their own and are not necessarily representative of their organisation. Hello, I'm Nina from Evolution Recruitment Solutions, where we connect businesses without sending tech professionals. I'm your host for today's episode and today I'm joined by Tim, technical director for Jagaxe Thomas, software engineering director for huge games. Thomas Lev, former Nordius director of engineering who is starting up his own venture and PIM, engineering director for Bray. We are here today to discuss engineering leadership in games, balancing people, process and tech. Before we delve deeper into the topic, let's work our way around the room with some introductions. I'd like to know who you are, what you do, and what your biggest passion is currently. Who wants to kick us out any volunteers? Yeah, I can go first if you like. Go on, Tim. Yeah, I'm Tim. I'm technical director at Jagaxe, as Nina already introduced. I have a long standing relationship in kind of the tech industry. I've been a software developer, product manager and working in the tech for about 30 years. I remember the 1990s, even in terms of software development paradigms, I've been software management for most of that time since the late 90s. Working both inside and outside the games industry. I have quite a breadth of knowledge and understanding from what I've got, which are one shot. You've got to get rights, got to be in the market and it has to work to the more modern day paradigms of constantly updating software coming through. A lot of changes happened over the last 30 years. I'm really interested in understanding how old software is used in modern applications and how things like technical debt get addressed in modern systems especially, where we have software stacks now, which are sometimes 20, 30 years old, right? It's going to that point in the industry. That's what I wanted to have a hub chat about today. Okay, thank you, Tim. Let's move round to Toma. Okay, thanks, Nina. As you said, I'm an engineering director at Huda Games. I'm really passionate about games, so that's basically why I'm here. I've been leading engineering teams for over a decade, small teams, large teams, entire departments. Today, I want to focus on a really hot topic right now, with all of the AI trending and how we can utilize it in terms of mobile gaming and in terms of personalization. Definitely something I want to know what's your mind about that and how can we exchange ideas? How can you use this in different genres or even different platforms? Perfect. Thank you. Let's move to Tim. Thank you. I'm Tim. I'm responsible for engineering at Brink. We are more on the technology side of the industry, especially passionate about solving problems in creating and leading teams and also in technology and especially what those two mix. I'm trying to get a lot of insight out of this conversation today. Perfect. Thank you. I'm finally Thomas Love. Hello, everybody. My name is Thomas Love. I started my career at Nordius as a front-end engineer on top of 11. I finished my career there as an engineering director on the same game. In the meantime, I did a lot of different things, lots of different jobs. I'm here because I'm passionate about gaming and I live playing games, so I've built in games and I like the business of gaming. And like I said, I did many different things. It's not important to me what is my role. I would do like anything to get shipped, but with this experience and where I am at my career now, I'm interested in leadership topics and I would like to cover those. And I forgot to mention the biggest thing after Nordius. Nordius decided to start up my own gaming company and that's happening right now. Very exciting. I can't wait to hear a little bit more about that in the future. So now we've established a context to each of you. Let's move into the topic of today. So each of you will have brought a topic statement or scenario relating to engineering leadership in games. So as usual, I'll work my way around the room, asking each of you to pose your topic and also the reasons why you brought it today. And then each of you will have the opportunity to give your take on those situations. So we obviously already have established a order here. So we are going to start with as opposed more of the end as raised the engineering leadership topics. So Thomas, do you want to introduce us to your topic and also give us a bit of context for the other gas, but also the audience as to why you brought it today? Yeah, like I said, I recently quit my job to start up my own company, still unnamed. And of course, I'm doing a lot of retrospecting on my whole career and my latest chapter was very interesting and exciting. But you know, I'm retrospecting and thinking, oh, did I do a good job or no as a director? So I came here with the question, what does a director do? We are all here, director, directors in this room. And that's my core question. What is exactly an engineering director's job? And how do you go about structuring your teams and how do you go about technology? How deep are you going to technology? How do you support your managers? That's a great question. Just start with that. Yeah. It's to start. So who wants to kind of give their take on that? So why exactly does an engineering director do? What are you there for? Well, maybe I can start. So basically, this is a pretty complex question. And actually, multiple questions you asked here. So in my case, I do feel that it's very relevant for any engineering leader to still be relevant in terms of like text, that attack you're using. So at least you need to understand what is your team struggling with. We've actually transitioned from a very hierarchical organization into a more flat one. So we're trying to be more hands on even like this senior leadership or senior management. We need to understand the problems because like, how can you be efficient in decision making if you're not understanding what's your, what's the biggest problem that your team is facing? So from my perspective, it's very important to understand the problems. But not necessarily coding at this point, even though some people do what's trying to be hands on, it's not always the best way to go. You need to be an enabler. So knowing or identifying the potential in your teams, helping them achieve the potential and without the proper knowledge, like the technical knowledge and the understanding of the tech you're using, it's very, it's going to be very hard. So I guess like the short answer is like there's no one profile and most likely each of us has has a different experiences recurring that but I do feel you're, it's very important to have like deep technical knowledge, but obviously we want to be able to build the strategy. So you also need to see ahead of your team and set some milestones for them. So building the proper strategy, this is where the engineering director comes in and laying the groundwork for the teams to follow them, self over important. And then again, and you need to understand what the technology you're using. So yeah, I would agree with most of that. And I think I particularly can relevant there is that you know, what engineering does best is it provides solutions to the problems that the business has, right? So you know, that's its gets core focus and those problems change regularly and therefore so do the solution. So does the structure around that, right? If you're, if you're just starting
off through ideation of a new game, then that's a very different structure to you just shipped and you've got a, you know, one year, 18 months of DLC coming or you've got a game that's going to be a live service game that's going to be five, six, seven years in duration. There's a very different problems that you have to solve, very different structures. And quite often many of those things will be, you know, particularly if you've got a, either a multi studio organization or a multi title studio where, you know, one phase is in ideation, one the other is in final polish or is in getting their vertical slice out. There's a very different problem. And your team will be structuring around those problems that you need to solve. And so, you know, they're very, very different, different structures that you want to put in place across your organization. And it will be very dynamic as well based on the kind of phase of the game or the type of game that you're delivering. Yeah, I also agree on those points. I especially liked the fact that you brought up Thomas where that's not one profile. And I fully agree with that. I do think there is a few, let's go to axes where you move up as you move up in title, I would say. And for me, the most important ones I think are like level of responsibility and then abstraction of responsibility and how much you need to take the business into consideration. And like if you increase in seniority then of course it increases. But for me with the director is like the first one where it really feels like the buck stops at me is like if something goes wrong then there's no one giving any oversight anymore. And you are responsible for that. And if it goes wrong then you will be totally held accountable and engineering managers. I would say that is not the case. There's a director that will take responsibility for you at that point. Yeah, I love that point. And it took me honestly like some time to realize not that but the implication of that, what you said just PIM. And the implication of that is as a leader you can do whatever you like. You know, you can change the rules, you can change the team and do whatever you like. But ultimately the buck stops with you and you are responsible for the result. And when you realize that you can do whatever you'd like it's kind of liberating but it's also a bit scary because yeah, you can mess it up. Yeah. And you have total accountability. Right. As you say, you know, the buck stops with you and one of the things that I have I found very early on in my kind of senior management career. And when you get to a director the name is in the title, the title right, you're directing more than you're actually doing. And one of the things I found very early on was that if you become the expert, right, the subject matter expert in any particular area or you are the person that knows technically how best to do something and you start to do that rather than directing to other people to do it, you soon very quickly become the bock and meck in the team because you have so many other responsive other things that you have to undertake. It's a really careful balance if you do want to stay very hands on and technical, you know, not to be, you know, necessarily the subject matter expert or broadening that knowledge base so that as a team, you're you're enabling others to take on that responsibility for doing things and you're just taking accountability for ensuring that it's done and is this kind of very very fine line sometimes, particularly you've got a small team, right, you've got very small teams. You have to do that, but you have to do it in a way that's scalable and doesn't create bottlenecks across the delivery, so you have to make. And that's kind of one of the things I learned very early on is you have to have that balance, right, it isn't easy and especially if you've got smart teams, you know, I've had teams of kind of five or six, seven people versus, you know, teams of 50, 60 people, always much easier to be to to to to delegate more when you've got large teams. Yeah, like also like two topics that I keep touched on, like first of all, like, PIM, like I think the business awareness aspect is also very important because you as a senior manager do have a broader perspective on like the consequences of decisions you're making, right, so maybe from like engineering perspective, you're making the best decision, but this isn't the best decision for the business. So also very important, like accountability team, you've mentioned it's also very important. So yeah, I would say the decision making is the most important aspect of the of the job. Like somebody asked me, okay, what do you do? And then I said, yeah, I make decisions and what I also learned in my career that most of the decisions are not that consequential, but there are a few of those that are really, really consequential and really important and you need to be prepared to make those decisions. And everything you do as a director supports this, you go on a mission to gather information that helps you make better decisions by talking to managers, peers and reports and their reports. And then you spend time on one of once or or technical talks or meetings where you give direction based on what you decided. So that's like the way I would describe this role to somebody. Okay. How has anyone got anything else that they would like to add to this section before we move into PIMS? I think them actually mentioned something pretty important where you shouldn't become the bottleneck. And I think for people that want to move to more senior leadership roles, I think that is one of the things most people will probably struggle with, with letting go of things. So if people want to move up that leadership ladder, then it's something to keep in mind and also ask yourself the question, if that is something you want and can do and if you can't then it might also not be the right role for you. It doesn't have to be right. Yeah. And sometimes you know, you just end up doing the mundane stuff. You know, the stuff that you just has to be done, but isn't really critical right? And you want your team focused on the really important stuff so that they can go to the right, the right process, not have to shortcut, not actually become a bottleneck. And sometimes you just have to do the really awful stuff that you have to do like the paperwork and some of the devolks stuff maybe, you know, and some of the background stuff as well. I've got a question before we move on to PIMS actually. What would you say the biggest challenge is within that space, engineering leadership and definitely zoning on the leadership side? What's the challenges? Who is that to? Anyone, all of you. Do you mean more from moving into the role itself or do you mean when you're already established in the role? I would say either all. So I said to you, what is the biggest challenge that you've had relating to and to doing leadership? I think, think for me, it's not technical. It's actually keeping teams motivated when you have a three-year project. And sometimes it's not going so well, right? You know, not every project is going to hopefully 80% of your project will go well. But there will be times where you have to keep people motivated despite the fact that things aren't going too well. When you've been in the industry more than years, you will know that you will have project cancelled, right? You will have things that change or pivot in a completely different direction than you were expecting when you develop your first ideational strategy and keeping people motivated around that and actually enabling them to understand the reasons behind why things happen. It's quite key. And that's probably one of the biggest challenges when you put a game. You have big teams or you have teams that are competing for limited resources across different projects. And some things have to give and keeping the motivated is quite hard. And I think the thing about engineering is that money is not always the best motivator. It's a short term fix for most things. And so trying to get that balance is sometimes one of the biggest challenges for any director or manager, I think, in kind of creative or incredibly engineering industries. I guess from my perspective, what was the biggest challenge is to start talking with the same language as our counterparts on the business side. Because starting in engineering, as we're getting, it might get hard to explain rather complex technical problems that were facing and convey this to business counterparts. And understand the point of view and getting to know all of those, taking this into account and making those good decisions that everyone mentioned. I think that's right. You do have to start talking business, speak a lot more most definitely because they will never be technical. You have to become more business. I think that part is. Yeah, what were you going to say, Pam? Sorry. I think that part is very important indeed. Another thing for me that is a very big challenge is the fact that you're working with people and they all can be very different. And I'm putting them together in a team. The team dynamic can vary very much between different project different teams. And something that worked wonders in one team with one project doesn't work at all. With another team and other project and identifying that this not easy. Yeah, let's say repeating
success year after year after year is the biggest challenge for me and that can be a lot of different things but in in mobile gaming where you're doing a game as a service you can spend a lot of years improving things and that's also gratifying when you succeed to do it but it can very challenging. Absolutely and before you obviously I threw in a curve ball there I just wanted to get your perspectives and also I'm sure if you're having these challenges lots for the lead as are to so it would be nice for them to hear that they're not on their own with that. Let's move into PIMS question so we did touch on it a little bit in this section but if you'd like to give us your question and also provide a little bit of context on it. Yeah of course for me what is quite interesting is how much engineering directors or managers need to be connected to the code and how do you actually do that in that context. I think it can be very hard to manage your time staying connected to everything and you obviously can do that but how do you identify which part of the code or what technical issues you should be connected to and how you actually do that and then even maybe more interesting as once you maybe lost a connection to some parts that are important how do you get it back again because of yeah you lost the connection because of time constrained or something like that. So for me that is a very interesting topic and it will not be the same for I don't think you have a one answer to that and that's why I'm very interested here to opinions of people here to see what they have experienced. Great question. I touched on this one we discussed like PIMS question because like I'm actually in the process of like a transition of engineering managers into a closer to code position. So we actually had an issue when managers were very disconnected from what the teams were doing and that then that started to generate a lot of constraints of the next misunderstandings between the direct manager of a team and the team itself. So it started to be very inefficient because like if the person who's responsible for the team is that the riverboles is understanding what the team is doing how can this person represent the team with talks with with business public parts again. So we definitely we make that the broader concept is that the engineering manager should be rather close to the code in terms of like engineering directs because like those are competed to different roles right. This is a senior manager but it's not a manager of people coding maybe if the engineering manager is coding you are but like that's that might be different for everyone but definitely like for me personally like I want to be close to what the teams are doing to understand the problems what I said in the first question but it's not easy and to be close to the code I do a lot of like personal projects aside from my main job so I still tend to be relevant in like the current tech stack like game engines new the tools that there's are using I'm also trying to use to to understand the problems but this is something that this is additional work each of us needs to do to be in the loop still like that easy you're not never able to catch up with everyone because obviously like there's so much new tech coming every week basically at this point that it's basically impossible to follow every trend on the market at this point but you need you're not able to code on a daily basis but you need to make an effort to at least understand what the team is doing so yeah thanks the insights time I'm not being in let's be friends to Thomas love well obviously I agreed that the engineering managers especially have to be close to the code I would define it as at minimum you have to be able to help your people and to be able to help your people you need to understand what are they working on and then secondary to that is when you talk to business people you need to be able to provide the early estimates in order to help them with the direction and that's like a minimum for me and of course I think that the good ACs make better managers in the end but I had an interesting strategy when I promote somebody from IC to management position I would usually tell them hey you can stop coding sometimes so you need some time to think so make some time for thinking and then the second thing I tell them is hey you you're very good at coding you are very good at what you do but that also means that when shit hits the fan you will default to the thing that you know doing the best and that's sitting down and coding and then need you to get it out and think about people and see how to help them instead of jumping to the code because I see that like mistake the team managers do so I actually try to pull them away from the codes to make the balance work okay okay Tim do you want to jump in yeah I kind of agree with that I think that as I mentioned a little bit earlier you know what you want to avoid for doing is getting so close to the code that you are the person the only person that can do that that particular task and you know when I you know when we promote new people in your management structure you know we kind of try to you know have a discussion on how much time they should be spending on the code and how much of the subject matter expert they are so that we can put in place a strategy to make sure that gets slowly moved across to other people in the team I it's not going to be an instant thing because quite often you know you have to come across challenges in order to learn how to solve them you can't just give people information because it will very quickly disapparate it you know across out of their minds because they're not not actively actively working on it so you really want to kind of ease people into that but you know initially we start off with having an 80/20 split right if you've just taken on people manage may you try to keep the teams you know my generally I don't allow people to have more than about five direct reports so these prefer teans that come that way and make sure that they it's very clear that you know they're people management responsibility versus their engineering responsibility and maybe they'll be working very closely with production and product staff so that they don't have to manage the day-to-day scheduling management of work tasks and so on or the product interface and they're then able to just focus on the technical side of things with the team and they should you know they should be spending no more than 80% of their time at that first stage actively hands on coding right and that will slow you reduce as they get as that information as that knowledge gets shared across across the team so it happens over time you know you can't go to somebody who's been coding 100% the time and saying you know coding 0% at the time you know that it won't work anyway it's not practical solution but also it means that they won't ever get into that understanding of how to share and how to manage people and how to develop people in the right way so yeah it's very much about a good gradual process when when people can be managers. Thomas I could see you nodding along there so is that kind of a similar kind of thing for you so? Well I'm just wondering team like what's the ideal proportion of like time spent on coding for an experienced engineering manager for their position? Yeah I think it's not about the time spent it's about the tasks that they undertake and as I said it's about them not becoming a bottleneck because certainly you know if they have to spend 60% of their time doing strategic work or doing work across the business or product with the product teams you don't you have to do that that's their primary role going forward so the thing the other things that can do is blocking you know I've been in the situation even as a technical director where I've taken on responsibility for example for localization tasks right and building localization because you know at the beginning of the project that's something you don't really need for quite a long time into the project right but you need people to understand how let's go to operate from a a localization perspective so that you're directing the engineers how to put their text in the game right but you don't leave that system in place until very late on so I can have handed it over by that point so yes I'm involved in coding at that point building the tools around that but it's not going to block anybody for the first 18 months of the project okay until we actually have to realise that system in the
in the code booth. So those are the kind of things I mean is that it's not just about the percentage. It's about what tasks they're working on and ensuring that they don't become the blocker because of that. And sometimes you know you have to fire fight, you know every project goes through at some point and at that point you know you can just die when because you have the bandwidth potentially to do it. If you're already spending 20% your time looking after a system and you have to fire fight, you suddenly that becomes unmanageable and unscatable. Yeah, I think sorry. Like one interesting thing like because you said this as well to myself is like promoting senior engineers to managers. Like that's a very very often make mistake because like we're usually promoting the more most senior engineers to people management positions. Then they become less efficient in what or less comfortable with like those people management tasks or like from the engineering perspective like less meaningful like business discussions and they get frustrated a lot that is counterproductive and like instead of us like our them be doing the things that they are very effective with they're starting to be frustrated and very disengaged because of like improper like assignments of responsibilities because maybe not the first of all like an engineering manager position isn't just for everyone like you don't need to be a very highly positioned manager to be successful in a gaming company like you can be a very good engineer and be successful with this. That's a good point to make. Pym I'm in treated here. Your perspective here. Yeah, a lot of interesting things were said. I would like to jump back a little bit to what Thomas said in his at first where he does a lot of personal projects to stay close to code or technology. For me what has helped me a lot is having foundational knowledge where you can have conversations with engineers and you can ask questions based on like the more foundational knowledge that you have and you can you can challenge them on certain solutions to say well this will not work because I know that this this is how things in general are supposed to work so this will probably not work or have you thought about this or and I do think that doing a lot of personal projects can definitely help with that so that was really resonated with me. You can ask for any piece of code or component you can ask why like a million times can be the most stupid person in the room and you can learn a lot from your engineer. I agree with that being willing to be stupid in a room definitely does help. Yeah definitely definitely. Definitely. Yeah and one of the things that we'd be very conscious to do when we're talking about how people become people managers and you said that but you know when they become move from a senior engineer to the kind of people management level what we do a lot of is that we assign accountability and ownership to senior engineers for specific systems. Now whilst that's not a triple management role it's a role of accountability and actually they then have to interface with other people other systems are the parts of the business around that system that they have accountability for. It teaches them how to be accountable for something and how to interface you know whether or not it's a tool which requires you know licensing terms they have to talk to legal about GDPR issues or personal data issues or whether they're it's a technical system that they have to work with maybe kind of application layer or even that damn that they're kind of the lower SDK layers so they have to learn how to interface with those people so they learn that as senior management level then taking on people management is about learning how to manage people not learning how to manage systems and things right so it's a more gradual transition and then that as I said earlier starts to broaden once they become that people manager and they start then to widen this scope within within that area so it's not a sudden like you know I'm promoting you and now you're responsible for all this new stuff that you've never done before it's all about making sure people are guided into and through that process over quite a long period of time in many instances. So you're saying give them learn that teach them to have responsibility first and then give them people to manage yes yeah. Great insights guys before we I suppose move on to some of the as there's more technical topics as anyone got in thin leadership related that they want to put into discussion or add your guess. I think I was important to underline here that this especially now the roles are evolving very rapidly right now and it's not like even like this is like the outline of like how we see things right now it's changing like even the perspective of like a couple of less months or years like the role definition has changed dramatically so I guess like this might this discussion is relevant for for us right now but it might be completely different in five or ten years so absolutely continuously evolving so if we move into more technical topics of today I put top-ass next so do you want to introduce us to your topic and also by some contact. Sure so as you well know I'm working in a mobile gaming studio so the topic I want to touch on today is related to like challenges of mobile gaming that being personalization versus performance. So by performance I mean like technical challenges we were facing technical strategies we might be using to actually introduce this personalization aspect in the game especially with the new tech coming it's very interesting to see other people's perspectives and like different types of games how they utilize not only mobile gaming right because like not not everyone here is mobile game developer but like other genres other platforms how they utilize this personalization because again some context from our past experimentation with personalization and even AI for example and first of all it might get very expensive very fast and is it worth it right so guys should we come this. You want to see the take? Well I think it's a very hard question for me at least because I think this is a lot on the product like this we have a question for the product people as well like well they want to see and for our models like game designers because besides technical challenges and maybe performance challenges I think it's super super hard to create individual journeys and then keep track of all them and optimize them properly and in my opinion what I've seen what worked best for us was always proper segmentation and it's insights from there like dolphins whales minerals hyper whales and then you can create a to do those segments specifically but hyper personalization that sounds super tough. Yeah I agree with Thomas Love it's a very hard question and I'm like obviously there is a there's an effort versus rewards kind of trade of that we're doing here like doing doing 20% of the efforts will give you 80% of the rewards normally but but also it's very interesting to know and hear which I don't have insight in is is that line shifting now with new tools and maybe with AI assisted tooling coming out like how easy is it and how detailed can we get with with segmenting players is that becoming a lot easier? So becoming a lot cheaper? So can we do more now that we have those tools? Is that that line shifting? So I can even start to answer this before like we go over to Tim but it has changed it's it's changed dramatically like there's our multiple new services that are being made available for game developers even if if you're a small studio or in the dev you can use a couple of things out of the box with basically no knowledge as a black box basically with no knowledge of how those tools are working but you you can personalize experiences definitely more more easily than it used to be so yeah well it's in them mobile landscape this is being used and used and used more and more to make that move over to yourself maybe? Sorry yeah so with with AI especially it you know the way that I see it being used is very utilitarian right it's about
systems where you know they may look at the geometry in your level and be able to map out how things move around those right and it could be that you've got you know seeing demos of the way that spiders crawl up the walls right so you don't have to artistically or programmatically generate those things right they just you generates the geometry and the level based on the gameplay and then the things that happen around you dynamically get overlaid onto that by the AI right. That's a very utilitarian approach right it takes away the technical need not from a aesthetic point of view but to map out and as that geometry changes you know the AI will adapt in order to change to follow the geometry right and that's kind of how I see it being used mainly because you know if you look at some of the AI generated games right. They really have no emotion or soul within them you can't AI can't give you that right that has to come from a human being at least right now what will happen in the next 10 years I don't know but right now it's really very utilitarian right you can see them use in you know in machine and in in natural language processing for example right is another thing that you know you you seek seek coming in a lot whether that's for localization and again. Even that today isn't really very effective right it does probably 60% of most of the common language but again once you start bringing emotion into that into that into that dialogue machine natural language posing doesn't really work very well it's only doesn't translate very well to other language in the same way if you have games that use a lot of local local text and and you know whether it's American or whether it's British humor for example right is a very different thing you know if you talk to an American or a British humor they won't get what you're talking about most of the time and so it does it does translate in that way so I think there's lots of utilitarian ways to use AI going forward but whether it will ever become intrinsic to the game play itself is to be seen you know you know Google has done a lot of experimentation around the world and I don't think they produced anything worthwhile yet yes it's a game that you run around a level and do things in but I wouldn't say that it would be something you would pay more than 10 cents for on Google we will play at the moment. So what do you think about that because this there was a lot of conversations about AI slop being produced by gaming companies or gaming studios and being published directly to the platforms and like the quality of that content how would you rate this yeah I think they will always be accident in what AI does same as humans sometimes just come up it just does something good but it's very rare that it's an entire ecosystem or entire game that it can come up with right and this is why I think it's a tool it's a very useful tool you know for for helping you to have tole show shortcuts or create environments around what you're doing but it will never be able to design a level not not what where it is today it would understand how to puzzle somebody for example how to fool somebody or to create a narrative I just don't think it's at that level yet. What about the another aspect of like the services because like the most common use of AI engines right now is for other cool data there's a lot of data that we can gather from our players have you seen this work and in an efficient way I mean. I'll let somebody else answer that you mean like yeah helping you understand the data about the game yeah my decisions because this is also like from my perspective like this is the input for this personalized journey of our users right so the data we gather and maybe you had experiences like efficient experiences of how you can utilize the data well I didn't experience that. I'm not I'm not sure where the tools are yet for that personalized journey but I think the main problems that that you will have is I think it's very personalized to your game what the context of the data needs to be you cannot feed it all the data because the context when there's not big enough and trying to get context out of it just using AI will probably not give you the best the best results you have have to have some probably some. Personal step to your to your company or to your project on how to get the right data out of it and feed it to a generative AI before you can get anything meaningful out of it and context management is not an easy problem I would say. That's true like this is like one of the issues we've encountered while like the one of those PLC's is like how many data points are we able to provide and how many of those are meaningful to get the best value out of this because this like the processing part here is like key. Did you run already into cost benefit problems there where you like what kind of models are you using because if you're using the most expensive models I can imagine that the benefit that you get out of it will not give you return on it at all. The answer that question like we stopped the experiment there enough yeah because I think one of the techniques that you'll probably want to do is to chain models like use cheaper models to formulate what you try to do and let expensive models handle it from there like to make sure that the context when the state is small as possible for the more expensive models yeah that's one of the strategies here has anyone got anything else that they want to add or input to torsion. So much what would you say the biggest as we learn is from what people's responses have been today. Well I think like the biggest outcome from from my perspective is like that we're all struggling to use the new tech at this point and well everyone's looking into like how this can be used. In a specific use case and for those particular specific use cases this can be effective as for like general purpose words ongoing there so there's still space for improvement I know like there are few is that game development. Or games studios won't be needed in the north 20 years because like the games will be like generated end to end by models I don't know if that's true I don't know if it's going to happen that way but it's definitely helping us understand like how the users interact with the game. So what can we do for the players to enjoy the game more and yeah like specific use cases for now and I think that this is helpful great and let's move round to Tim because you've got a question that I think a lot of engineering directors will relate to. So one of the things that I've been kind of really thinking about is how we manage that or technical debt through and there are many different reasons why technical that exists you know it's not just bad code sometimes it's just I did dig code or sometimes it's just that you made a really good system but your scope has been very narrow and really you start start a one I you can broaden that out but kind of interesting thing for me is this. Try and try to get kind of an understanding of how people approach technical debt you know if you say yeah great if you say you don't have technical debt and that's great and sometimes you know when you start from scratch and you're in that first couple of months of the project and you think you've great great a great group of concept and then a year into the project you find that actually that group of concept has just created a huge bottleneck in your in your in your your your evolution of the product. Because these actions design decisions were making it could be just a burn design decisions and so just kind of what get kind of an input from anybody on what their experiences in you know what kind of technical debt they've experienced and also what they've done to try to tackle that you know what are the world what are the kind of solutions that they they put in place to try to to avoid or what tackle technical debt. Question I'm sure people I've lots to say on that so I think I can this has been touched also today but what's important is the ROI of tackling tech debt because like first of all like there's always this rule where if the codes working don't touch it unless there's a good reason to do that so and that reason is very often like expense of the performance of the system if this introduces or challenges or maybe call a sense of the answer obviously there is a reason to to actually manage this tech debt or result the problem obviously like prior to the [BLANK_AUDIO]
organization is key because I'm working with the tech stack that's over 10 years old. So we've got a lot of tech depth, but what's also important is that to understand that you can't tackle everything at once. So you need to find like the places where it makes sense to actually tackle the challenge, to tackle those that bring the biggest ROI, what was said today. So if you are able to choose that and using like modern architectural patterns, modern design patterns, you're able to do this pretty efficiently, especially if you're tackling a monolith and most of us usually at some point do so, yeah, gradual but very conscious management of the tech couple that is very important. So this is the short answer. Yeah, I fully agree with where ROI is the most important thing I would say there. For me, I think the term technical depth is both a blessing and maybe a little bit of a curse there. I think it's a very good term when we're talking to stakeholders that are maybe less technical because it translates so well to financial depth, maybe like I'm doing something now that pays off now and we have to pay this back in the future and even the concept of interest makes sense there where we are saying, well, everything is slower now because we have this technical depth. But when we're talking to each other, it might also be a little bit of a curse because depth has the implication that you have to pay it back at some point and I don't think that is the case. You don't always have to pay technical depth back and I think we have to be very aware of that. That it is sometimes fine to just have technical depth in your project for all eternity if it doesn't pay it back if you pay it off. Yeah. Well, I used to work on a plan which is like 15-year-old game and team, maybe compared to you and the rest, I was a bit more hands off or yeah, hands of a director and added much in the code. I focused more on building up the team and the system. So they take care of the depth. My direction was, hey, we want us to go faster and that can mean a lot of different things. One of those things that is making us slow, although of course technical depth. But when talking about ROI, I didn't always think about depth. I also bought innovations what we can improve in general that can help us go faster. So that's something that goes into that calculation. And I think we had a pretty good system where we would gather feedback from all engineers, even junior ones and senior ones. Like what are their pain points? What are their bottlenecks in their quality of life issues they are having? And then cross that with the most senior engineers, feedback where they want us to go in the technical sense. And we would like combine those inputs and prioritize and choose what to work on. And interesting thing about technical depth is, there is this in serious technical depth to keep smiling on. And if you don't care about it, it can bite you in the ass. But there is also technical depth, which is sometimes painfully obvious that it's impacting business or something. And those things are no brainers for business. And these negotiations should we do this or no? Sometimes it's obvious to everybody that something makes sense. Like Thomas Mendes, Monolith to microservices transition was like one of the big things that required a lot of effort, but everybody was on board. Because everybody saw the value in that. And during my time there, one of the biggest impacts in this area we made was in combination with UUX. Like my engineers saw this opportunity. And this is a technical depth. This is always slowing us down. It's about core gameplay. And they saw, hey, if you figure these things, this is going to improve the UX as well. And when they framed it like that, everybody was on board. We fixed it and everybody was happy tickets in the sport for less because the users had the less issues as well. Yeah, I think everybody they touched on kind of the key one, which is ROI. And analysis shows that if you have technical depth in an agent code base, then you're slowing your development down by up to 20%. If you've got a small team of five or six developers, OK, right? But if you've got 50 developers, suddenly you're talking about opportunity savings of over a million pounds a year in that 20% snow down across the development team. So then the ROI is a very different discussion with your finance directors, don't why aren't you delivering fast enough? Particularly with modern programming and DevOps, where you're doing continuous integration, continuous deliveries, and you're having to hit very short time scales. And 20% of a one week turnaround means that you're doing six day turnaround, right? And so the five days, it's a 20%, 20% less. And you're delivering then over the course of a year, get an opportunity. There's a big opportunity lost there for additional feature development. Trying to explain that you're going to do this work. It's not actually going to add to the product. You're just tackling debt. In financial terms, it's a million pounds a year. No, is it a good conversation to have? But on smaller teams, that conversation does necessary work. So ROI is a very big part of this from kind of the return on investment perspective of time to develop. But also, just on things like workflows and DevOps systems where, again, back and really slow down what you're doing because you're using archaic systems or you've got servers that aren't building within a two hour window. So you're having to wake up and throw QA runs on daily integrations. You can start seeing that actually, it becomes the old adage of the time as money, right? It really does affect your bottom line when that happens. So, yeah, ROI is a very kind of salient point there. And I was just going to wondering as well as, like, terms of the types of technical debt that people see. And you talk a lot about prioritizing what those are. But kind of classifying those is also and being able to identify them is also quite important. And we've seen many instances of where code, which was great, right? Because it was running on Python 2.1 five or six years ago. Suddenly, it doesn't need the security requirements that we need for modern systems. And you're having to upgrade your Python suddenly everything around that becomes impacted, right? So, it's not just, yeah, the code may run as is, but all of the libraries around that, all of the systems that interface with it, suddenly your API requirements may be changed across your system. And that doesn't just mean that on a live service system that you have to update the systems, you have to have downtime to do that. Which again, is opportunity gospel customer perspective as well. So, there's lots of different ways of looking at code that. I'm just going to add any other kind of instances where you've seen big wins or big losses as a result of this. I don't think I could take it. One other thing that also was quickly mentioned by Thomas Love is the pain points for engineers. And I think here is where engineering leadership can really shine is technical debt. Yes, it slows down people. And it maybe slows down the business, but it obviously also has impact on morale of the team. And that is often less obvious and cumulative over longer time. So, getting a good grip on when it may be a good time to tackle some of that, where people's morale is really affected. And before your team falls apart basically, to tackle those topics are in the tech depth. But you have to be very careful with that. I'm very on point because you also don't want to waste time there. So, it's a very fine balance on tackling those points in the technical depth versus not doing it. Yeah. And I wanted to touch on like the 20% team mentioned because like in some engineering, especially larger engineering organizations that have conscious tech depth, there's also, I've seen this, there's a constant allocation of time for addressing tech depth. So, and so,
engineers, obviously, we still need to prioritize which are important and which are less important, but we just being as a mature engineering organization, we're just saying we know we have tech depth and we need to address it and the security aspect is also key here because like if we're not addressing security vulnerabilities, like we're exposing ourselves and that's a very dangerous position to be in. So yeah. What about yourself, Thomas? I would like to add also one more angle. Tech depth prevention is also interesting way to look at it. Like building these systems, rules of engagement, best practices that can help managers to take depth. And like Thomas said, you can also be, you can be, you can consciously create some technical depth because like building even feature goes through some phases, you know, the phases you really need to be fast, then you can consciously create it, but you need to have like full plan how to tackle it and prevent it. Yeah, there's definitely a fine line between doing enough as an MVP versus over engineering and making it so robust that, you know, and so scalable, you know, you're really, then the ROI goes the wrong way. And in some cases, you're also building more tech depth because you're building in robustness that's not needed and later make it any way as well. So yeah, there's different views on this, you know, and actually identifying, quantifying what that's impact is, you know, then you can go through that XO, okay, does this really drive it in a positive way, right? And there's lots of measures around that not just the ROI from a financial perspective, but as you say, morale is a big thing as well. And I think if you're in a position to be able to build tech debt, you know, how to combating tech debt at source as you're developing, you know, so you're basically actively avoiding it, then that's the best way to do that. But that means constantly revisiting your product through a single game title where you've got a finite end, you know, that's part of the natural evolution of the time. And you know, I'd gone through games where suddenly we've got the same boss defined in several places because different teams have actually defined the same functionality, if you like. I think they look different, but effectively, they the same thing, I'm up right in the same way, you know, which is introduced in efficiencies and actually what that means is that when you then come to modify the behavior, sometimes, you know, another team what you'd realize that the behavior exists in several places and across several areas. So actually actively managing those kind of design elements, if you like, is also quite quite key to this and making sure that you're not duplicating code or you're not make or you're kind of not creating inherent multiple instances of code that you then have to. Yeah, that reminded me how important tell us the pms and business people can be because bigger joy for me is when we duplicate the feature and then we can completely remove it. Yeah, yeah. The reason we have very few controllers is that if you have a neat again, it's there, but ultimately, are you right? You know, removing things is really important. And it's true, you know, over, you know, if a game development takes three years, you will naturally lose people and even lose knowledge within that to actually manage it from a documentation point of view and making sure that everything is is written down, you know, fight everything down is the mantra is quite key as well to making sure that people are able to fall back on, you know, understanding of stuff that happened even as far back as kind of proof of concept or vertical slice stays or horizontal slices if you do those as well. So people are aware of stuff that's happened in the past and can get a conform back on that if needed. I was like, no one else got anything they want to kind of add to this topic or anything else that we've discussed today before we round up. We'll get. That was a guess, I think. Yeah, I just want to say that this was a very, very nice discussion and a really happy to be able to have it with you guys. Thank you. Thank you for the insights. So before we end the podcast, I'd like to say thanks so much to all the guests for sharing their thoughts in today's discussion. Once again, our guests have been Tim, technical director at Jaggett, Thomas, software engineering director over at huge games. Thomas Lave, former northerous director of engineering, starting up his own studio and PIM engineering director over at Brink. If you are hiring new technical roles or looking for a new role yourself, please feel free to get in touch with us here at Evolution or if you or anyone else you know would like to be featured on a future podcast, you can drop me a message too. I'm Nina and you can find me on LinkedIn or email me at
[email protected]. Thanks for listening and I'll see you next time.
PodcastTranscript AI