← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
CTO Series: Engineering Leadership, Automation, and Trust with Dan Hollinger
00:45:34
CTO Series: Engineering Leadership, Automation, and Trust with Dan Hollinger In this CTO Series episode, we sit down with Dan Hollinger, an accomplished engineering leader passionate about fostering empathy, transparency, and trust in tech...
Loading summary
Transcript35 lines
- [00:04]
Vasco Duarte
Hey, how are you doing? I'm Vasco Duarte, your host on the Scrum Master Toolbox podcast. And I've got some exciting news. So right now, as I record this, I'm holding in my hand the signed contract for our very first Global Agile Summit. We're all in and I couldn't wait to share this news with you. So mark your calendars. May 18th, 20th of 2025 in Tallinn, Estonia. We're gonna have a transformative experience. We're putting together an event that is all about real life Agile. It's not theory or buzzwords. It's practitioners sharing what's working, what's making an impact, and how they've overcome challenges that you too will have to face, or maybe even facing. Right now, we're bringing together the best stories in Agile. From product leaders to engineering wizards to business visionaries, these will be stories that will inspire you to action. This isn't just another conference. It's a chance to connect with the people that are shaping the future of Agile. And here's the best part. Right now, we're in our super early bird phase. And that means you can grab tickets at just 25% of the final price. Look, that's not just half off, it's half off of the half off. It's an incredible deal for our dedicated community members, just like you listening to this right now. So at the summit, day one will be all about hands on workshops. And days two and three, we'll dive into leadership, product strategy, coding, testing, and everything that makes Agile thrive in organizations. Right now remember, these are all first person, real life stories. Now whether you're a leader, a developer, or part of a consulting company, this event is built to take your Agile game to the next level. So don't wait. Go to globalagilesummit.com and grab your ticket. Today, let's all make 2025 the year agile truly transforms your teams, your business and our industry. I'll see you all in Tallinn. And Remember, go to globalagilesummit.com and get your super early bird ticket right now. It only be available until the agenda is announced, so don't wait. Grab it right now. Right now that that's out of the way, on to the episode. Hello, everybody. Welcome to one more episode in this CTO series. For this episode, joining us from the US is Dan Hollinger. Hey, Dan, welcome to the show.
- [02:52]
Dan Hollinger
Thanks for having me. Appreciate it.
- [02:54]
Vasco Duarte
Absolutely, absolutely. So Dan is a proven engineering leader who champions empowerment through support, empathy and transparency. He fosters a culture of Trust prioritizing, alignment over dictation. He is also technically adept. Dan advocates for automatable solutions and a blameless environment, ensuring his team thrives both personally and and professionally in a collaborative space. And I really like the bio you sent in Dan because it expresses some very core and clear values that we will definitely want to explore in today's conversation. So when you reflect on your career, what was that pivotal moment that kind of really influenced your approach to both technology and leadership within technology.
- [03:46]
Dan Hollinger
So especially for the technology side, I have to think back to around 2008 when I joined a company called CCP which some listeners may know as the makers of EVE Online. They had a team in Georgia and us, Georgia, not Europe, Georgia, building a new mmo. And the thing that I loved is that they put together this really nice automated testing system and I was still fairly new to my career. I'd been working for a handful of years and this was the first time I'd seen any sort of automated testing system and it just blew my mind. And I loved it. And that was sort of the moment that really kind of got me on the whole automate and scale what you're doing because there's only so many people that you can hire to do any given job. If you take the things that a computer, if you take the things that a human could be doing, but you instead let a computer do it, that enables your humans to do other stuff. Typically the more interesting stuff too, as opposed to the, well, you know, hey, I'm going to fire up the game today and turn left and see if that works and then turn right and see if that works and run forward. And this not. And not just, you know, saves the person time, but when you are addressing that sort of thing, it just ensures that you have this really high level of quality that you're then dealing with. From a leadership standpoint. That was, it was also that that company was also pivotal in that the teams were very self directed. The team basically got a very high level mission statement, hey, we want you to work on social systems, we want you to work on combat. And then they gave it to the team and let them come up with what to do. And ever since then it's been my main goal is that it's not something where I want to see, I personally want to be dictating to people exactly what to do. Now it's not, that's not helpful. I'm one person. I'm not going to see things from all angles. I'm going to miss stuff. I'M not going to claim to be the absolute authority on exactly what we should do. I want to facilitate people and I certainly have got about 20 years of experience being, you know, I can show some, shine some light on the wall, give us some targets to aim for. But it's just as likely that someone, you know, with a couple of years experience, you know, 10 years, a producer, a game designer, somebody else will come in and say, well, I've got this really great idea and take, you know, whatever I was talking about, turn it on its head a bit and we come up with a new direction that's better, that's, you know, it's sort of the essence of collaboration and thankfully, you know, the game industry is generally speaking rife with it and it's, it's a thing that I really love, so focusing. So just going back to the ccps, you know, that's where the automation side came in and that's where that, that trust in the people who are doing the work came in. It also was actually my first introduction to Scrum as well. It's when I became a certified Scrum Master back in the day.
- [07:15]
Vasco Duarte
So very apropos indeed, indeed. And I was kind of interested because when you talked about, you know, you joined CCP and then you found out that they had developed this or they created this awesome test automation system, a lot of the things that then become part of our approach to leadership happen almost like by accident, but they catch our attention, right? And they say, oh wait, this is different. And then we start looking at it and we start to understand what is behind it. And one of the things that you said that I want to highlight is that, and I love the quote, automation allows your humans to do other things, potentially the much more interesting and impactful things that they need to do. And in the world of AI, right, like we are in end of 2024 as we record this, AI is only like, I mean AI, meaning widely available to us normal people, is about two years old, so it's quite recent. But the potentials that it brings to us to automate things, to let the humans do the human things. And as Agent Smith said in the Matrix, never send a human to do a machine's job. Right. And to understand that we can enable people to do a lot more, to be more creative, I'm sure that kind of sparked imagination and inspired you also in your leadership approach.
- [08:43]
Dan Hollinger
Yeah, just being able, I mean, speaking to AI is also interesting because it also helps with that sort of key point where a lot of people stumble at the start they don't have quite enough material to put together and they're just kind of looking for something and being able to go to ChatGPT and ask a question to it and say, how should I structure a all hands meeting? And getting a seed for you can be really, really advantageous. Right? But going back to the leadership, right, seeing where these interesting opportunities pop in those again, it's just more collaboration points is really the way I see it because you want to collaborate with people to do things and you also, in a way, you know, especially in technology, you're collaborating with machines too. And we've been doing this for ages. You know, there's, there's whole disciplines of people who focus on computer, human interactions and we're just taking something where before it was like, well, how do we make the human, computer interaction better? Well, we make the human think more like a computer and we do that in programming languages, right? Where that's the essence of what being a software engineer is, is that you think like a machine to get things out. But now we're coming to the point where we can. It's less, I wouldn't necessarily say that the point where the AI is thinking like a human, but it's getting to a reasonable facsimile of such that smooths out that interaction that enables the non engineers to ask, to say things, to again, get that initial bit started, right? We can have someone say, hey chatgpt, write a code, give me the code for a platformer and it'll spit something out. It doesn't work right, sure. But it gives somebody a starting point as to what that might look like, whether or not they could write a lick of code beforehand. And that just having those seeds essentially, which then lets a human take that and cultivate it, I think is just an amazing thing.
- [10:59]
Vasco Duarte
Absolutely. I like how you described having a seed, right? Because the beginning is always the hardest step of whatever you are trying to do. And just having a seed can be, well, can be an amplifier because you might even have an idea of what you want to do, just not how to get started. So I really like that metaphor. Now as a leader, of course there's a lot of work to be done on making sure that you implement a tax strategy that has been defined or that you have been defined, but also align it with the business objectives, the overall business goals of the organization that you're working at. So how, how have you, in your experience and in your career aligned those two. What are the key processes you've implemented to ensure that tech strategy and business objectives are aligned and remain still agile enough to adapt to change.
- [11:54]
Dan Hollinger
So I think from a very broad strategic standpoint, what you want are processes where part of the processes to correct the process. You know, something self correcting, a real straightforward one to talk about is a crisis management process. This is also something that's near and dear to my heart. And because making sure that people can still work and, or that your customers are still happy, depending on what phase of the project you're in, is critical. And so Facebook introduced me to this idea of SEVs which are referred to as site events or you know, things what, what they call a ticket for when things start going very, very wrong. And I've adapted this process. They had it for a live system, right? You know Facebook, they serve what, 3 billion people across all their different apps? Literally half the world. And I've since adapted it to work for games that are in early production before they've hit players. So the basic idea there is that when someone can't work and they have no workaround and that thing used to work yesterday, they initiate the sev process, which is meant to be loud and shouty, almost not shouty in the bad way, but, but shouts into your slack channels, pokes people, says hey there is this. Someone is having this critical problem and they really don't know what to do except except hit the big red panic button. And the whole process then is designed from that point to drive it towards someone who can help. And then once they do come up with a solution, whatever that solution may be, it could be something that is very simple as hey, go delete your character, save files and that'll fix the corrupted thing. It's not a permanent solution, but it's a solution. And it's something that remediates the issue quickly. But then we follow that up with a retro. And you know, retros are very common in scrum in general, but for this it's important to make sure that you are then adjusting the process. Hey, what things could we have done to address this faster? In hindsight, was there a path of investigation that we didn't follow, but we could have chanced upon it earlier? What could we do in the future to kind of better improve our odds of picking the right solution when we're in this, when we're in this urgency. And I think this one is very important when it comes to this whole business alignment because when it comes to your customers are not able to access your service, your, your employees, your colleagues are unable to do their job that they, you know, they want to do. If you don't have that, you're very likely going to be, you're very likely going to be throwing money into a furnace and just burning it. And in some cases, you know, something that's, that's really something, you could just be completely trashing the company. So that's sort of the, the first line of defense that I look at in terms of like a very specific key tactical process. And then just the strategy of make sure that every, every single one of your processes that you adapt, you're doing those retros, you're going back and saying, are we doing the right thing? You're listening to the people who are, who are, who are involved in on a day to day basis. A lot of people in games are very process averse.
- [15:24]
Vasco Duarte
I can totally see that by the.
- [15:26]
Dan Hollinger
Way, and rightfully so. Because the more process, the more onerous and this gives you taking that step back and go, should we actually be doing this? Is important because it's very easy to let process just chug along the tracks and be it be its own end almost and never actually stop the train. Check the engines, check, check the wheels, check the tracks themselves, check your bus, check your train stops. Make sure you're going to the right places. It's easy to start doing things by rote and habit. And having a defined point where you don't, where you just stop and say let's make sure that we're doing the right thing is critical.
- [16:07]
Vasco Duarte
So if I hear you right, what you're saying is whatever processes you've already implemented, just make sure you don't follow them without having a retro to review how they are working. Like for example, if you trigger a process, whatever that is, let's say it's a process to hire a new team for a new project, whatever, then make sure that at some point you have a stopping point where we review. Did we trigger that decision to start a new team at the right time? Did we have the right processes in place to support the adoption or creation of that new team, etc. Etc. Is that what you mean?
- [16:45]
Dan Hollinger
Yes, exactly. So you just want, and also, especially for something like that, pull in that person too after they've started. Because that, that process of triggering is, is not just actually one process, it's probably three or four. Right? You've got the recruiter, you've got the initial interview, you've got the, you know, the team panel interview, you have the higher call and then you have the onboarding. Just, just those things that's five processes in and of themselves. And oftentimes, at least for me, it's very easy to skip over any individual portion of those and just go, well, you know, we've been doing, we've been doing hiring this way. Did we, did we ask that that was a good idea? Like how, how do we want to conduct interviews? What, what is the purpose of an interview? What do we do technical interviews? Do you do the technical whiteboard interview? I think the answer to that, generally speaking these days, is no, for a variety of reasons. But sitting down with the team and saying, hey, do you care? What do you care about when it comes to interviewing someone? Do you care about their technical adeptness? Do you care about their ability to sound like a reasonable human being? Hey, onboarding, what is it? This? One of the more common traits to have, hey, one of your first onboarding jobs is to update the documentation you're following to onboard. That's a perfect example of the sort of little mini retro that you can attach to something where you're just going, hey, did this process work for you? Did something go wrong? And then go back and make the right decision? And the hiring one also is interesting because I think that there's another retro point six months down the line or so where you say, for hiring a team, was this the right choice? Do we have enough work for them still? Or was this something where it appeared that we had a lot of work for them and now we're kind of struggling to pick things and they're now working on stuff that, you know, we'd call like P2, P3, as opposed to your P zeros and P1s. And that'd be a very clear indicator that there's something wrong with how you hired or, you know, that you hired.
- [19:04]
Vasco Duarte
Folks then I really like that. Well, you, you've expressed it earlier. Never execute a process by rot. Make sure that you're reviewing how the process is actually working in practice and make sure that you build in those, those, I guess you could call them checkpoints that. Through retrospectives or as you said, like these mini retros of somebody updating the documentation that they're supposed to be following. Which is a great example, very pragmatic example as well. When you think about collaboration between tech and business, what are some of the key practices that you've learned? Work to foster collaboration in your experience because you have the people who, who think about the business, whatever that may mean, and then you have the people who think about technology, whatever that may mean, and usually they are not aligned unless we do some work to align them in that specific regard. What are some of the strategies you've put in place to make sure that the tech teams and the business teams are really working well together?
- [20:09]
Dan Hollinger
So for games, it's actually interesting that there's a couple different divergent teams. It's not even just the tech team and the business team. You've got the technology team, you've got the design team, you've got the production team, you've got your QA team. And all of them are sort of typically collaborative departments, but they all have their own various goals and the sort of mantra that I use, I guess there's sort of two. There's no enemies. It's very easy to fall into this habit where you think of one of your colleagues as the enemy because they have a different point of view. And while game design wants the most flashy stuff, they want the most intricate systems. They want this creative vision to be realized. And engineering is under a time crunch of some sort, right? Because there's only so much stuff that they can do. And if you are not careful, you fall into this. This pattern. And so even when you think someone is your enemy, treat them as if they're not. Treat them as if they're, you know, give them. Give them that trust, even if you feel it is not perfectly deserved, give them that trust that they're trying to do what they feel is best. Which leads to the sort of second. The second mantra is focus on the project. It is, we are. We are coming together as a group to do a. To make something happen, something that we would not be able to do on our own, because if we could do it on our own, especially, you know, at the prosperity level that we're accustomed to, we just do it on our own and not have to deal with, you know, all the other people. But we're come, but we're not, right? We're not capable. We're not capable of doing this stuff on our own. So focus on the project. Don't worry about whether or not that person that you're working with is the enemy. Focus on what is our goal. Okay, you want to make this, you know, you want to make the next Tears of the Kingdom. We don't have that time. What. Can we scale back and talk through the problem with them? Oftentimes I find that asking questions rather than making statements is also a good way to diffuse situations where there might be a bit of animosity. Hey, John, we can't do this. There's a problem here. Let's figure out how to solve it together. What do you think that we can do to reduce our scope? What do you think that we can do to make the game design more streamlined and have less exceptions? And if you need to direct those questions less into a simple scope reduction, if you're concerned about that, but into an iterative development process, hey, we can't do all of that right now. What's that first observable step that we can take that will get us to test it out and being able to put together a demo of what you want, a first pass of what you want that we can then to prove out and then iterate upon and make adjustments as we go. Because as I'm sure you and almost all the listeners who've been dealing with this stuff, if you come up with a solution from scratch and implement it, you're almost entirely, you've done 100% of the work for the wrong problem. If you do it in pieces, there's going to be those, there's going to be those adjustment points going back to retros and checkpoints. There's going to be those checkpoints where you do something, you realize, oh, hey, this is actually good enough, or oh, we're actually solving the wrong problem, or oh, this revealed a different problem that's actually more important that we need to pivot to and deal with. Before that you, before that you come up with the whole solution. So, you know, in summary, treat everybody, treat every, treat everyone with trust that they're looking to do what's best. It's very rare, at least, especially in the games industry, that you have just simply bad actors that are out for their own ego. Purely focus on that high level goal of what that project is and then try to break down those pieces and come up with those small observable steps so that you are then adjusting what you're doing as frequently as possible and focusing on what's observable. Because very quickly if someone's got this magnum opus that is not achievable, if it takes you a month to do 1/100th of it, they will quickly realize that reality does not work or they're going to need to find more funding and chances are they won't be able to do, there's going to come to an end of the ladder.
- [25:12]
Vasco Duarte
So I really like how you've always been referring to this concept of getting feedback faster, like the automation part you started with and then building checkpoints into processes and now again, like slicing things down, delivering a big opus in small pieces so that you get feedback early on. But there are decisions about the future as well. And of course as a CTO and as an engineering leader, you have had to make decisions and also keep track of a roadmap. Right. So how do you keep that future still in your focus even though you're helping teams of course achieve what they need to achieve very much on the day to day.
- [25:55]
Dan Hollinger
So I usually lean into a bit of forward thinking, I'd say on a weekly, if and at worst monthly basis. But definitely it becomes a bit more frequent when you're coming into your milestone planning, which for me generally is around three months when you are looking at your problems. The one of the biggest concerns, particularly in leadership is what is the scope of the solution if you have a. If you have something that needs, that is, that is going to survive for two years, let's say that needs a much that need that, that needs less of a solution and less of a robust solution than something that's going to survive. 10. Identifying how long you expect some system or process to live then is what informs where you need to. Where you need to focus your efforts on the roadmap. So at a previous job, for example, we were working on putting together the company's second game and part of that was adding in some live service type stuff. Not necessarily like live service in the traditional sense of like. Well we, we are wanting to deliver repeated content years but more in the sense of like. Well we want to put in. We would like to develop long lived systems that enable us to deal with problems faster. Like a feature flag system specifically in this case, looking at that and coming up with the small observable features that get you to that eventually was a great tool for putting together that sort of long future help thing. Whereas some of the other code, specifically the game code, we're actually still working in an older version of Unreal. Unreal 4 and Unreal 5 has been out for I don't know exactly off the top of my head, but about a year plus now and going through knowing that the next game was going to be an Unreal 5 game, that very clearly indicates that pretty much all the work you're doing with some exceptions is going to be tossed out. So we could keep the scope down on our game specific stuff and then use that compromise to then deal with ensuring that we've got these better longer term solutions with stronger foundations to make the next game easier to build. Because now we have all these things that don't necessarily, that aren't necessarily tied specifically to the game engineering that we can continue to work on. And so now we've got this nice system of, like, how long do we expect the solution to live? That makes it. That makes it. That makes roadmapping way easier. Yeah.
- [28:50]
Vasco Duarte
And that's such a simple question that sometimes I am surprised that people don't ask, because obviously what you want to think about needs to follow that expectation of duration.
- [29:02]
Dan Hollinger
Right.
- [29:03]
Vasco Duarte
Like if you're developing a system that is going to be there for, let's say, for an event, right, and the event happens in six months and that's it, that's one challenge. Or for an early demo for a potential customer, that's one challenge. But if you're. On the other hand, if you, as you said, if you're going to put something together that needs to last 10, 15, 20 years, you now need to start thinking about, okay, but what does that mean? Right. Like, for example, 15 years ago, nobody would expect your mobile phone to have 128 or 256 gigs of storage. That is real time synchronized with the cloud.
- [29:39]
Dan Hollinger
Yes.
- [29:42]
Vasco Duarte
So when you think about, like, your career and all of the stories that you went through, what's the biggest challenge you faced in your career as a leader and a cto?
- [29:52]
Dan Hollinger
So I work for a company and we ended up having a significant leadership change. It was a. It was a amicable leadership change, but like a complete leadership change. Shortly after I joined the company where the three founders who had been with the company about seven, eight years just went and they, they went to go start their own thing again. And that then meant that we had a huge amount of turnover at this company because a lot of people had been working for the company three to six, seven years, and they wanted to work with those folks again, which is, you know, great. I'm glad that they got to work with the people that they loved and wanted to work with. But it caused a huge problem because we had about a team of about seven, eight engineers and all but one left, not counting myself. And the one that didn't leave, though, you know, one of the. One of the best engineers I've ever worked with, if not the best. He was also the newest engineer at the company. If he had been there, he'd been there for about a year, I think, when I joined, or maybe even six months. And that was a gigantic challenge because there is this whole. There's a morale issue. There was a what are we doing issue. There was all the people that, that I'm used to working with have not all but like 50, 60% left in the span of about six months. Some, you know, the new leadership came in and there is, there is no easy, safe playbook for new leadership walking in the door. And that's going to cause people to feel upset and the new leadership is going to rub somebody that can rub people the wrong way. And even if, you know, someone had every intention of staying, they might just be like, nope, we're out. We don't like these people. They said something that we didn't like and we just don't think it's worth the effort. And so I had to, as part of this, I had to manage not just the transition of people who wanted to leave, but the off the, the offloading of their, of their tribal knowledge while also spinning up, hiring for a bunch of people that we, that you know, we now need to staff the team again back to, you know, six, seven people doing so as some people are out the door, some people are, have their foot out the door. Other people think, they think they might be staying, but they're not sure. It was, it was a, it was a wild, frantic time.
- [32:33]
Vasco Duarte
In short, when you think about that story, like what, what are the key lessons that you take with you from that story that, that that might be applied perhaps in such a critical story like you just described, or a less critical story.
- [32:49]
Dan Hollinger
So one of the things that I'm really happy with myself there is that despite all the stuff that was going on, I had still earned the trust of the engineering team who was outgoing and they were still, I made it clear to them that when I, when I step in to take a job in leadership, for me personally, and I don't know how it is for the rest of the leaders out there, but for me personally, it is not a one off for this job commitment, it is a commitment to them forever that I'm going to be available to them and that my job is to, is to incur, is to get them to grow. And if that growth happens with me, great. And if that growth happens without me, great. And that they understood that and believed me because in all sincerity, it is very much true that when they're like, hey, I want to go do stuff that's, I want to leave, I'm not upset at them, I'm happy for them. They're getting to do something that they want to do. They're getting to go work on this new project with people, with people that, you know, that they've been working with and like and care about. And when you take that stance For a team that's. For a team where especially team that you know is outgoing. It means that you get so much more warning and they, they give you more than they would otherwise. They're not concerned about saying hey. In fact, this is an actual example. One of the engineers like, hey, I wasn't sure I was going to leave, but I'm going to leave, I'm going to go in about two, three months time. That's the timeline that was given to me. I go, that's great. I appreciate you giving me this warning. I'm happy for you that you're going to get to go do this thing that you want to do. But having three months of warning is so much easier than two weeks. You can plot out that person, you can get some of the important work done that they're really good at. You can get them off offloading things, you can get them, you can get them to mentor someone over months instead of a couple of days where it's like, let's be reasonable, someone leaves in two weeks, they're spending a week writing documentation and they might have a week to do stuff and they've got no real time for mentoring, no real time for, for onboarding people. And having three months and two months is a, is a gigantic game changer that is four to six times the amount of duration that you've got with them. Having other folks come to me and say, hey, you know, I'm thinking about saying this because I feel, because I'm outgoing, I feel that I'm in a position where I am safer and I can say things that other people want to say. Do you think that this is a good idea when what they, what they're saying is, could be very reasonable to say or it could be some dramatic white knighting stuff going on and being, being given the trust to help facilitate, you know, communication, better communication or, you know, or, or get this stuff out there or you know, say yes, you know, I, you know, if nothing else, it also gives you an insight into people's concerns at the time.
- [36:20]
Vasco Duarte
Giving them comes from that trust that you were able to build even in a short time with that team.
- [36:26]
Dan Hollinger
Yes, exactly. Yeah, it's, it's having that trust and making sure that the people recognize that, that your job isn't just, it isn't just the company, it isn't just, you know, the project, you know, as a manager, as a leader, it's, it is to uplift everybody, it's to make a better project and better people. And as far as I'm concerned, you know, once you've worked with me, I, I will, I will be, I will bend over backwards to try and help you out down the line. No matter, no matter what that, you know, it could be 10 years, could be 10 years. Never have talked actually had a, had a guy reach out for me for a referral that I hadn't spoken to really in like 15 years. And I was happy to do it. It's, you know, making sure that people realize that this is, and in the game industry this might be a little bit more common because it is such a smaller industry and because layoffs are so common. There is, there's a very much sort of rising tides lift all boats kind of mentality where you go to help people that you've worked with and that, you know, but for me, I take, I take it very, very seriously.
- [37:30]
Vasco Duarte
Absolutely. When you think about your role as an engineering leader and a cto, what was the most surprising aspect of that role for you as you were growing into it?
- [37:41]
Dan Hollinger
So yeah, so same company I had gone from being hired as a technical director without necessarily with looking at and go well, I might end up in a position where I could go be the CTO in a year or so. And having that turn into the four months with the leadership change, the amount that I went from, I pivoted from my scope is the engineering team to my scope is the company and everybody. It was pretty fast. It's not very surprising in hindsight, but at the same time it was something that was in the thick of all this. It was a big adjustment. I'm like, oh yeah, I really need to pay attention not just to my team and not even just how my team interacts, but the health and the morale of everybody all at once. It wasn't a simple like this isn't a department scope anymore. It is a company wide scope. Uh, and that, that led into. I did an old thing for, for levels and expectations. So we didn't have that documented where like I put a little pithy what your scope is per level and I had for my own role, your scope is the company. Because I wanted people to understand too that it wasn't just me worrying about the engineering team anymore. It's I'm worrying about the designers, I'm worried about the artists, I'm worried about qa. What everyone said matters because that making sure that those wheels stay greased and you've got the trust not just of your department, but everybody is critical to getting useful collaboration done and is the first step into enabling Collaboration for the people that you're working, the people that you're working with in your department and in other departments.
- [39:37]
Vasco Duarte
And I really like that approach. First of all, the humane approach that you bring to the role, of course, which you just illustrated magnificently with the idea of the scope changing from engineering to the whole company and everybody, so not the company as an abstract entity, but really everybody in the company. I think that was a beautiful illustration of it. Was there a book or something like, you know, I don't know, a video or. But I usually ask is there a book behind that kind of realization and really the embracing of that part of the role?
- [40:15]
Dan Hollinger
Not. I don't have. I haven't done a whole lot of like specific reading around management philosophy. For me it is. For me it is just looking at the leaders I've worked with and what, what the, what the things that I find that I value and empathy and treating someone as a human understanding that it is, you know, life is difficult these days. Yes, we've got untold prosperity with, you know, all the technology, but we also have all these complications as well. So treating people humanely is just a critical thing in terms of just like a book that, that's really influenced way of thinking though is more. Is less about the management side and more about the metric side and the data gathering. And so the book is called Building and Scaling High Performing Technology Organizations which took the data from over about 10 years, I think of a bunch of different organizations and tried to find key metrics that they could use to indicate the health of the organization from a technical standpoint as opposed to not necessarily a personal standpoint. But I think those will almost always go hand in hand. And so they identified the, your, the DORA metrics, you know, your cha. You know how many what's your change fail rate, what's your lead time? What's your deployment frequency? What's your time to resolve crisis? Which you know, goes back lovely to the talk on SEVs and using those as your sort of four primary, your KPIs for is this company working well? And if those metrics you have your time to resolve crisis are well, your change fail rate is low, your deployment frequency is high and your lead time is low, then you can generally say that we're doing well and you can then watch those metrics to then suss out what's going wrong. Hey, did your change fail rate suddenly spike through the roof? Okay, well why is that? What changed to cause that or lead time? Before we were averaging this and this was our outlier. Now there is a brand new set of outliers. And if things are really lovely, well, not lovely, but obvious, maybe it's one person who now suddenly has a bunch of outliers. What's. And then you get to ask yourself what's going on? And take that and then use that to then treat the humane problem. Right. Because these are usually when these things change for the worse. The answer is usually because someone had someone, someone's life is upset in some fashion or you had a very significant business change and there's relationships that need to be reforged. But it's not usually a simple like, oh, we're using the wrong middleware. It's usually something deeper and more personal than that.
- [43:22]
Vasco Duarte
As Jerry Weinberg said, no matter how it might look at first, it's always a people problem. Yes. And that's the reality of the software world. Dan, it's been a pleasure. Thank you very much for being here. But before we go, where can people find out more about you and the work that you're doing?
- [43:40]
Dan Hollinger
So LinkedIn is the simple way to find me. I'm Daniel Hollinger there for work. Unfortunately, the project that I'm currently on, which I'm having a lot of fun with, is still unannounced. But if you keep your eye on extra games for the next couple of years, we will be saying something. I think it's really exciting. It's a great team, a lot of game industry. There's several game industry luminaries that I'm getting to work with which is dream come true for me and we're going to have something I think that's going to be a lot of people will be really cool. Awesome.
- [44:16]
Vasco Duarte
Great to hear. So check out Dan's LinkedIn page. The link is in the show notes, so check it out and why not ask a few follow up questions. Dan, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [44:30]
Dan Hollinger
Thank you again for having me. I really enjoyed it.
- [44:36]
Vasco Duarte
Oh boy, I bet you are buzzing with ideas after listening to this episode. I know I was. Now there are so many ways we can help the leaders we work with. So I hope this episode helped you get some of those ideas going and getting inspired hopefully also to take action. That's what matters in the end. Don't forget that. Now, if you want to check out the key lessons from this episode, check out the show notes at Scrum mastertoolbox. But for now I'll say goodbye and see you in the next episode. We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.