Season 1, Episode 7: "How do I up-skill my team for digital transformation?" with Thomas Sweet, VP in IT Solutions @ GM Financial

Speaker 1: How have you enabled your infrastructure fundamental change over the last five years and partnering with the business is critical? The tools exist on the cloud change at the rate necessary, secure by design, Network Disrupted.

Andrew: Hey, it's Andrew, and welcome to Network Disrupted, where IT leaders talk about navigating the disruption in our industry. In this episode, we talk with our guest, Tom Sweet over at GM Financial about how he's transforming his QA team into part of a unified engineering team and empowering his team to stay along for the ride. Tom is a VP in IT Solutions at GM financial, and he's got a real focus on lifting people up in the workplace. And to give credit to where credit's due, I'd also like to thank our friends at Linux Academy, or rather A Cloud Guru for introducing us. Tom gets into the tactical weeds explaining how he's doing, what he's doing, which is really valuable. Christophe, thanks for that. And before we get into the show, I've been asked to say, Tom's opinions are his own and do not reflect those of GM or GM Financial. Let me know what you thought of this episode. You can tweet me at network disrupted, leave a review on Spotify or Apple podcasts, or email me at andrew @ networkdisrupted. com. So Tom, tell me a bit about yourself. I know you're a GM Financial, and you're very much involved in the transformation of technology, but I'd love to hear it from you.

Tom: Sure. I started in IT back in 1997. Prior to that I'd worked in civil engineering, which is traditional engineering roads and bridges worked on that big dig in Boston. I had an opportunity to go to NEC, which at the time was NEC computer systems division. I made this career jump because I just was excited about IT. Back then I was really trying to get what you'd call like a help desk job today, but the recruiting agency recommended I get a QA job over at NEC, testing laptops and the Windows 98 and MP4 pre- installed. I was like," Okay, I'll try that." And that was an awesome job. It's one of the biggest, the best jobs I've ever had. It was just a lot of fun. I get to go to Japan. And I've been in kind of the software development, software QA space ever since I had an opportunity to go to Microsoft for a couple of years, work on Office 2010 and SQL Server Kilimanjaro, went to work in another company called Mapmaker, which was a software for mineral mining. So think of AutoCAD, but for geology. And then, when I ended up at GM Financial they needed someone to come in and take over the QA team and help reduce the growth of the QA team, upskill them to more of a software development skillset. And that was in 2016. And that's where I've been ever since. We had a big project that was in place for about a year and a half, once that was done, then we really started pushing this transformation, which we'll get into, and it's been a of fun. And I've had a lot of personal reward from it because I really like investing in people, growing them, and helping them become better. That's really one of my passions.

Andrew: That's fantastic. And transformation is always fun, at least from my perspective. And nowadays so critical as new skills are required to deal with new compute, and I think that's around practice and process, and skill sets. And when I look at it from my perspective, especially on the infrastructure side, I mean, everything is becoming software and software- driven. And the quality aspect of that has changed quite significantly. Maybe you could give me some sense from your perspective how quality and the process and practices around quality have changed over the last few years.

Tom: Sure. So I'm a big fan of Jez Humble. I don't know if you know him, but he's active in a DevOps space. And he says, if you want to improve your quality, you have to go faster. And that may seem counterintuitive, but in order for you to go faster, you must have automation. You must have really good processes in place. And so, as we continue to shift left, that means more and more automation. That means better pipelines for our DevOps tooling. We want to make sure we have a template for the pipeline or pipelines that everyone can implement and make sure that we're all in alignment with the different scanning and security scans, or SonarQube, or Checkmarx, or whatever tooling we have in our pipeline. But it's shifting left, and it's moving as concept from finding defects to reduce the introduction of defects.

Andrew: Yeah, I think that's critical. And I think a lot of the processes and tools around that build stuff that works, and that works from the quality perspective of the functional side, but also, of course, the non- functional side and security related requirements, and scalability, and performance, and driving that continuously, right?

Tom: Yeah. I mean, that's what we really want to get to.

Andrew: Yeah. And obviously, that leaves a gap in skills in some cases. And I know, obviously, as you stated before, it's a huge passion of yours. So I'm curious how you... What's your approach to that skill set gap, and how are you working with your teams to ensure that they have the skills they need so they can help move everything left?

Tom: Sure. We have been doing an awful lot around that. When I first started here, I had about 135 team members, and five were titled automation engineer, and the rest were some sort of QA analyst. And when we look today with total head count, 117 and 40 software developers, and 60 QA analysts. So we're reducing the team size because we're getting more efficient. And as maybe people move to different roles, we're not necessarily backfilling them, but we're hiring software developers in place of QA analysts. The QA analyst is a legacy roll list end of life, and we're transitioning QA analyst to software developers. We're also hiring software developers off the street. When I worked at Microsoft, I was called software development engineering task. And I worked alongside the platform developers working in Office 2010. Well, Microsoft has since eliminated the best set role, and everyone's moved towards unified engineering. Well, that's what we're going to do here. So I'm either hiring software developers off the street who have the skills I need and are willing to work in the QA team until it blends into this unified engineering model, which we're moving to, but I'm also hiring software developers out of college. And they're excited. We have University of Texas at Arlington that's close, UTD also Dallas, and we're hiring graduates to come work with us. And then, we're also training the QA analyst to become software developers. And we've promoted about 12. We have a pretty intense training program that's internal. Part of what we do is I provide an hour a day for my team to upscale, which is either used for innovation, it can be used for learning. And I asked for this from the CIO, because it's important that we reinvest. We have to create this culture of continuous learning. And some companies give this time other companies don't, but we feel it's important to reinvest and allow team members to get better. So we're providing that.

Andrew: That's fantastic. Do they need to propose how they want to use that time, or is it really just left up to them to pursue what they think might be interesting?

Tom: Oh, it's mostly free form, but they have to upskill. So for the QA analyst specifically, they have to learn a coding language such as Java or C Sharp, or standardizing and C Sharp, and potentially no JS. And they're going to have assessments. So one thing I was doing with the QA analysts, whether I was going to have them do either an official Oracle certification or a Microsoft C Sharp provided by the vendor. And then, the reason for that was as a third party, there's the perception that there's no bias in the exam, because Microsoft and Oracle give this exam to all these different people around the world. Whereas when I started looking in depth at those two exams, there were a lot of peculiarities or oddities of the language that I didn't really find appropriate for my team. So we're creating assessments for them that they have to meet. And we just had one at the end of February, and we have another one coming up at the end of April, which has different concepts, such as object- oriented design figure inheritance, encapsulation, polymorphism, those concepts. And we're going to quiz them on that at the end of April, and help them understand where they're at and where they need to go. For the software developers who are already in that role, they have requirements for certification. So they have to do two Microsoft certifications this year in Azure. So they can use that time to get better in Azure for those either the AZ- 400 or the AG203 certification, which is programming, or we're also moving towards Docker and Kubernetes. So they can use that time towards advancing their knowledge of Docker and Kubernetes.

Andrew: So is there any sense of the team, for instance, sometimes... So this is happening a lot, across many different types of teams, and I'd speak to a lot of people in networking who have as individuals have a great deal of skill and what they're doing. And it's not people who were the traditional QA analyst role didn't have a great deal of skill in what they were doing. And sometimes there's resistance, and there's resistance not because there's not a desire to change. Maybe the resistance is in, I mean, these individuals have accumulated a great deal of skill in what they do. Their intent wasn't to be a software developer, maybe there's fear of change or fear of going from an expert in something to being a beginner in something else. Do you mentor and talk to your team about that? Do they reflect back to you with any of those sorts of individual concerns?

Tom: Oh, sure. I mean, that's an ongoing process. When you look at the traditional QA analysts that I have, some of them come from QA organizations outside of the company. Others came from different business units, and they showed aptitude and desire, and they were moved into IT as more of a user acceptance testing type approach. I'm taking those team members and helping them completely transform. That's scary for some of them. And we use this ad car approaches, awareness, desire, knowledge, ability, and then, repetition. So my job as a leader is to provide them the awareness. They have to provide the desire themselves. But what I do is I also share with them a lot of what's going on in the DFW area. There's a lot of high- tech down here, especially North Dallas. And a lot of these companies, I'm not going to list them, but they've either outsource their QA to India, or they've gone to more of a unified engineering approach and they've released their QA teams and laid them off. What I'm telling them is we are investing in you. We are providing you with a future, and this is what the future looks like. And you can get on the bus, or you can find another bus that goes someplace else, but this bus is moving more toward unified engineering, and you're a part of that. We have a seat for you on this bus. We paid for your ticket. We just need you to get on the bus. And for the most part, most of the team members are excited about that. Now everyone's at a different pace, but some team members have decided," Hey, you know what? I really want to maybe move to a role in the business." And that's fine, right? We'll give them a reference and help them find a good path for them, but it is hard and programming can be overwhelming. And now you're talking not only programming, but we're talking cloud, we're talking command prompt and networking, and a number of different parts of this job. I mean, the job now is software development, is DevOps, it's automated testing, it's networking, it's cloud, if I didn't already say that. There's all these different pieces to it. It's not just one thing. And it's not only one language, it's Java, it's C Sharp, it's Node, it's Angular. And they're going to have to be able to pick up these different languages. Now we're talking about Go and Google Golang. Someone who knows C Sharp well he or she just may have to learn Go in the next couple of months to maybe work on a different project. So it's having this culture of continuous learning, but being excited about it. And what we try to tell the team when we get this kind of a joke is keep up with the Cloudashians not the Kardashians because we had this meeting, a staff meeting and we had some trivia questions and we had cloud- based questions and we had Kardashians questions. And everyone got the Kardashian questions right, but not everyone got the cloud questions right. And yeah, I can appreciate that someone knows the name of Kim Kardashian's fourth child, but I also would need them to know what platform of the service is and how that differs in infrastructure of the service.

Andrew: Yeah. No, for sure. Just to highlight a couple of things you said, I think that for one, and actually maybe this turns into more of a question. So oftentimes when there is resistance to change, when people start seeing the effect of the change, and so that might be in their own skillsets, but it might also be in your ability as an organization to release things faster or to the massive reduction of escape defects, because you had moved things left or... So what sort of metrics do you look at and do you use those metrics to sort of create that enthusiasm and drive success?

Tom: Sure. So we do have a pretty big metrics program that we're... I don't think we're starting it. We have always used metrics, but we've used more of the traditional activity or task- based metrics. What we're trying to move to is more end- to- end values for metrics. And one mistake that I guess I'm responsible for is I kept calling them the fourth DevOps metrics, and I should have rebranded them internally as before valued delivery metrics, where it's how long it takes you to go from check- in code until it gets to the customer, your frequency of delivery, your mean time to resolve, and your frequency of change failure. So the four metrics that Nicole Forsgren has in their state of DevOps report. We're trying to really move towards end- to- end metrics because it doesn't matter how quickly one person does things, it's how quickly you move through the value stream. And for example, in the old waterfall world, it might look really good if a development team dropped their time from four weeks to three, but if it added six weeks to the QA team, and then two more weeks to the monitoring team, are you really saving anything? This is no. But if you were to say," Hey, look if the dev team spends one more week and we can save six weeks down stream that's much better." But unless you're really looking at the whole value stream, you don't always see those efficiency gains.

Andrew: Oh, no, for sure. And I really like using that term value and really driving this as value, and unfamiliar with those metrics and appreciate them quite a lot. Yeah, it's our ability to release. It's our ability to get stuff to customers, and the faster we can do that, the better, assuming we're meeting those quality requirements and... So it's all interwoven. You set goals over time, you set targets on these metrics. Is there a drive to release in a week, or... I mean, I know there's many different platforms you probably work with that have their own historical constraints and other concerns, and compliance concerns about changing. But oftentimes, do you rally the team towards metrics or it's more of a overarching theme?

Tom: It's an overarching theme because we're still trying to find the right way to collect them. Because we'll use one tool for our DevOps pipelines in our cast management and such. We also have service now for our change management process.

Andrew: Right.

Tom: And trying to make sure that we have all these metrics, and we also have different tools for the project intake process. So right now we're trying to find a way to actually collect all this data and make sure this data is correct, and then, we can start really getting metrics towards better working metrics and then work to improve them. And as we move more towards a product based team model, or like Toyota calls it a factory team where you have everyone on the team has all the skills necessary to deliver the product, it'll be a lot easier to focus on and to measure.

Andrew: Yeah, for sure. Yeah, and absolutely. And I have my own share of mistakes in the past where the old adage be careful what you measure, because if you don't necessarily know that driving that metric there is going to yield overall quality, or driving that metric towards that goal could potentially cause problems somewhere else. Like the example you gave great. We reduced the amount of time it took to code this but we've increased QA, so who cares? The net result isn't there. And so, I think metrics are measuring and metrics are very important. We always need to think about whether or not we should be challenging their usefulness, or maybe better said, making sure we're looking at the whole system, the gestalt, this metric might be getting better, but what's happening in general?

Tom: Yeah. And getting to that, another point is I want you to know Martin Fowler. He's a really good programmer, much better than I'd ever be. He's also one of the finders of the Agile Manifesto. He has a blog post about measuring programmer productivity, and he talks like it's really hard to measure programmer productivity. You can't look at lines of code, you can't look at defects because you could have... So if you can read his posts, it's not that long, but he makes a lot of sense. And so, when people say," How do you measure individuals?" It's hard, right? You can look at rework, you can look at attention to detail, but it's hard to compare one person to another objectively only through metrics. So yeah, there's always areas of improvement there.

Andrew: Right. No, Martin Fowler is great, and I appreciate his blog and also his books. I'll misquote this, but page one, line one, or maybe it's in the forward introduction of his refactoring book is if you can't test the system, close this book and put it back on the shelf. And he's been a proponent of driving everything left for as far as I can remember in my career. And certainly, measuring productivity of an individual developer by the historical lines of code or something is in many ways nonsensical. You have to look at broader things. However, I'm not a fan of throwing out all metrics. Things need to be measurable for sure. What about different? So now, great. I was a QA analyst or software developer, so I'm learning either new languages or new practices because now I'm testing with code, I'm building software. I'm building software that's built along with everything else. But there's also other skills that are necessary, right? You mentioned earlier security, and both in terms of writing secure code, which is important in that test stack as well, but also, ensuring that the software itself is meeting security requirements. But also, with infrastructure as a code in cloud, in general, there's everything from networking and all aspects of networking, whether it's stuff near and dear to my heart like DNS or load balancing, or application load balancing. I mean, there's these other stacks that have great deal of knowledge, sometimes esoteric, sometimes otherwise necessary to understand. So how do you infuse those different knowledge sets in your teams? Do you have cross- functional teams? Are you upskilling in non- programming areas, as well?

Tom: Yeah, exactly. I started pushing the certifications and cloud back in 2018. And at that point it was AWS, and we had about 10. Then in 2019, by April of 2019, it was pretty flat. No one had been certified in anything. And I was talking to my budget analyst and he was saying," Yeah, we're going to have to give back some money. We're not using it. I was like,"Oh, okay." So I came up with this idea for a contest to send people to Microsoft Ignite, which was later in the year. And then I had to kind of guess when I'd be able to buy tickets, which I guess a little bit too late. But I guess by August I could still get tickets for the November conference. And I came up with this approach to weigh the different Microsoft Azure certifications based on my perception of how hard they were and give people raffle tickets based on how many certs they got. And I opened it up to not only my team, but the architecture team and some other development groups in the org. And I was going to pay for the whole thing. So we managed to send four people to Microsoft Ignite from the contest. And that really drove about 60 cloud certs. And following that in October, the Cloud Center of Excellence needed some help because they were creating this new system for our public cloud, which had hub- spoke model, had a lot of work infrastructure as code, then networking all those pieces. And they say," Can I borrow a couple people for two weeks?" I'm like," Okay, you can do that." And two weeks later they asked for two more people and I'm like," Sure, we can do that." And here it is in March and I have six people that have been down in the Cloud Center of Excellence since October or so, and they're setting up, two of them are setting up the new firewalls we just bought. This is something maybe a year ago no one would have considered anyone from my team capable of setting up firewalls, but this three people working on the cloud on it. And two of them are developers from my team, and one of them is the cloud architect, but the three of them are the ones that are setting up firewalls. And they've done all the infrastructures code and Terraform. And they're really hands- on inside this and they've learned an incredible a lot. So even though the certification is good it helped provide them the base education, but the- on- the job training that they're getting down in that group is amazing. And they are probably going to want... Five months is a long time. They're probably not coming back. Stop kidding myself, right? They're at the center of excellence until further notice. And that's been really good. They don't want to come back.

Andrew: Yeah, for sure. But that's actually a sign of success, right? I mean, you're working with the crosstalk team [inaudible 00:24:48]. Yeah, it's 100%. And at my company we have a support team that pushes hard in training, in skills, and they end up being, it opens up opportunities across the company for them. And so, now you see them in professional services or sales engineering, or the product development team. And it's a shame when somebody who's great at what they do isn't there anymore, but it's way better if they're inside the company in a different position that is exciting to them and also helpful for the company. So I think it's a great sign of success if the individuals are creating value outside of your team.

Tom: Yeah. I mean, and to flip it the other side, what if they didn't want them? Right? What if they said,"Here, take them back. We don't want them here." Right? That's not the case, right? They want to keep them, so that's good. Yeah.

Andrew: Yeah. No, that's fantastic. All right. It was really good talking to you, Tom.

Tom: Awesome. Thank you.

Andrew: Thank you for listening. I'd love to know what you thought of this episode, and I'm all ears if you have a guest recommendation. You can tweet at Network Disrupted, leave a review on Spotify or Apple podcasts, or email me at andrew @ networkdisrupted. com.