Some of you were introduced to automation in school, or at work, or perhaps even by a family member or friend. Our guest on this episode began his automation journey in the US Marine Corps. Corporal Dwayne White’s first automation project involved “digitally transforming” a manual process done on a Xerox typewriter into a far more efficient solution done on a PC. From there, he progressed through successive levels of technical & executive responsibility, until reaching his current position as VP of Technology Automation at LPL Financial Services.
As the largest independent broker dealer in the country supporting nearly 17,000 financial advisors, technology plays an outsized role in LPL Financial’s success. Dwayne was instrumental in leveraging automation to power LPL’s growth, both as a hands-on techie and as a manager. He shares some key insights with us in this episode, and we learn how automation mitigates risk for LPL Financial, the specific kinds of processes LPL automates, and why you shouldn’t look at automation as a replacement for your staff.
Guy Nadivi: Welcome everyone. My name is Guy Nadivi, and I’m the host of Intelligent Automation Radio. Our guest on today’s episode is Dwayne White, Vice President of Technology Automation at LPL Financial Services. For those not familiar, LPL Financial is considered to be the largest independent broker dealer in the US, with nearly 17,000 financial advisors and $762 billion in advisory and brokerage assets under management, as of June 2020. Dwayne is a hands-on IT operations executive in charge of technology infrastructure automation. He’s also worked a lot with L1 and L2 NOC engineers, overseeing their efforts in a never ending pursuit of reducing incident MTTR. Automation has played a big role in Dwayne’s success at LPL Financial, and since he brings a unique dual perspective, with both first-hand and managerial experience in automating various IT processes, we wanted to bring him onto the podcast and see what we could learn. Disclosure: LPL Financial is a customer of Ayehu, the company sponsoring this podcast.
Dwayne, welcome to Intelligent Automation Radio.
Dwayne White: Thank you, Guy. It’s a pleasure to be here today. I always enjoy listening to the Automation Radio podcast.
Guy Nadivi: We appreciate that, thank you. So Dwayne, you started out at LPL Financial as a developer, and 20 years later, you’re Vice President. What were some of the bigger IT challenges you overcame during those two decades while the company was growing as rapidly as it did?
Dwayne White: Well, for me, it was both a personal, and I guess you can say, IT challenge. On a personal nature, for me, early on it was deciding in my career if I wanted to be a techie, or did I want to be a developer, did I want to be a manager? And for me, I wanted to be a manager. And what that meant to me is it meant I can go ahead and mentor and train new staff, and have a voice with my managers, my leadership. Outside of that, early on still in the back at LPL. We were a small company, and as a small company, we had our issues, our challenges, and some of those having to deal with how we managed incidents. Back in that time, our pagers would go off, we would jump on a phone call, everyone would talk over themselves. It was just organized chaos. Now, that seemed to work for us at the time, but like everything else, we knew we can do better. And what better meant for us is we started looking at ITIL. ITIL basically is a framework that people used for instituting IT business processes. And once we started moving down the ITIL model and we started maturing our processes, things got a lot better for us. It was a good thing to do. Outside of that, was learning how to adopt to our change and transformation. Most people aren’t comfortable with it. I’m not comfortable with it sometimes. And usually, when change is implemented and transformation is implemented, sometimes it’s done well, sometimes it’s done poorly, and when it’s done poorly it’s mainly due to lack of communication out to the teams. What we found is that our teams, they want to be involved. They want to know what change is coming down the pipe. They want to have a voice in that change. As an example, if you were to come in on a Monday morning and tell your team that instead of working Monday through Friday, they’re now going to work Tuesday through Saturday, they wouldn’t be too keen on that change. But if you involve them in the process, communicate to them the need, not only for business, but for themselves, we can start getting their buy-in on it. We found that actually works a lot better for us.
Guy Nadivi: So what were some of the bigger reasons you decided to look into automation at LPL Financial?
Dwayne White: Well, for us, my boss actually got me down the path of looking at it, and he had concerns about how we were delivering our services. And services can be defined as how we processed our service request tickets, how we responded to incidents, how we communicated. And bringing automation into it just seemed like a natural fit for us. So, back in 2015, that’s when we started looking at the various tools, the different processes, we dealt with Gartner, started looking at some of their Magic Quadrant work, and we started moving forward. So, for example, one of the inconsistencies that brought us forward would be if you had a ticket assigned to somebody, and let’s say it had to do with the Windows server, a disk problem. You can assign that to three different admins and you’ll get three different results. One person has one way of cleaning up disk space, the other person has another. So we needed consistency in that. Automation? That was the clear path. It does one thing. You tell it what to do, it does it, and it repeats. The nice thing with automation, just like a disk space problem, is you learn as your applications grow and capacity changes. You change the script. You change the automation to adapt to it. The other part of it was risk. No one’s perfect, but with automation you can reduce the even element of risk. Even elements could be missed alerts due to outages. Staff’s not always at their desk watching their ticket queues 24×7. Or a slow response time to an incident. Again, you’re counting on your staff to be sitting at their desk, glued to their ticket queues, or waiting for their phone to ring. With automation, it’s there, it’s live. It’s 24×7 and it’s waiting to be called upon. It was a natural fit for us. I’m glad we did it.
Guy Nadivi: Okay. Now, you mentioned the need for uniformity and consistency, and it’s well known that financial services firms have very rigorous regulatory requirements to comply with also. Given that reality, how challenging was it to persuade management that automation was worth a try?
Dwayne White: It’s true. I mean, we’ve got a whole bunch of regulations. It’s interesting, we learn more and more each day as our government changes them, or FINRA or the SEC. There’s always something new to adapt and change to. But at a high level, when you look at the financial industry, its regulations are there to protect our consumers, prevent fraud, and limit risk. And the risk limiting is mainly what can that financial institution do to investor’s money? So, looking at risk, that was probably one of the big selling points. So, as we approached our architectural review board, I basically highlighted basically how automation can help lower the risk, as previously mentioned, as well as the rewards, such as consistent delivery of service, improving mean time to restore service improved SLAs, satisfactions. I mean, the list can go on if you can put the case properly. And basically, with the help and guidance of the review board, we were able to adopt it and we’re now moving in the right direction.
Guy Nadivi: Dwayne, I think it would be very interesting for the listeners if you could talk a bit about the platforms that you’re performing automation upon in your environment.
Dwayne White: So, platforms, integrations, an example would be Active Directory. So we currently have automations that deal with self-services to modify Active Directory to find user accounts. We revoke user accounts. We add users to various security groups. And we can schedule the automations. We have hooks that are tied into Microsoft Exchange, we’re hooked into the file shares, we’re doing work with ServiceNow. With ServiceNow, basically, we use that as the catalyst to monitor the ITSM queues, to pull back service requests and incidents that we can respond to with automation, as well as you’ve also got to look at your automations you’re creating as not being dealt with. So, for example, if you have an automation that is going to reach out and do something with Active Directory, what happens if your Active Directory controller is not working? You need to put in some error checking and then detect the error and then go ahead and create an incident for someone else to look at it. So that’s how we go ahead and create incidents with ServiceNow. We also hooked into Microsoft SQL servers, we’re doing access provisioning, space consumption and alerting. We do work with Windows servers, we take incidents, we call them “level zero triaging”, as well as we’ve got scheduled service restarts. We’ve also got automations that are tied into third party web services. With that we do REST APIs, data extraction and reporting, as well as we create incidents off of those. What we’re working on now, and hopefully over the next few months is the integration packs for AWS. So we’re starting to hook into the Cloud and see what we can automate out there. We’re going to start working on SharePoint here soon. Also, let’s see, Oracle database access provisioning. And it’s interesting, in talking about the regulatory stuff above, when we first got the platform, our regulatory team came to us with some automation suggestions, and we got those implemented for them. So it was nice to have that as one of our first automations. We’re happy.
Guy Nadivi: Okay. Clearly you’re automating and attempting to automate lots of different processes. So how do you define success once you’ve automated a process?
Dwayne White: Success, we actually try and get the success defined before we automate. And what we do is we basically engage with the teams. So an example, if someone comes to our team and says, “Hey, I got this widget and I need this widget and process automated.” So what we do is we look at the number of requests that would come in, that’s being done manually. We’d take a look at the triggers that would trigger the workload, and the time that it would take to complete the request manually. And what is the current SLA for the request and/or work incident, what’s the mean time to resolve it? Outside of that, we also look at the effort we put into the automation versus a manual task. So, for example, if the manual task, right now it takes an hour, but you’re only doing it three times a month, maybe that’s something we’ll keep in place. That’d be a manual process because it’s the development effort to design the automation might be longer than that. So, for example, recently we did a thing with Active Directory, a simple automation to add somebody to a security group. Our current statistics have basically shown us that the manual process had averaged about 1.5 days for the team to actually do the work. And that’s with the ticket coming in, somebody approving the ticket, and then, over the next one and a half days, somebody actually doing the work outside of their normal daily routine. We found out we were averaging about 265 of those requests a month, but once the team actually got the ticket and did the work on it, it actually only took about five minutes. So, doing the math, and this goes back to the success part, the manual process was 265 tickets, five minutes each; basically we were spending about 22 hours a month on that one ticket item in a manual process. Also, you’ve got to remember, it took one and a half days for them to finally get this ticket done. Now, you throw in some automation with it, you get to take the same 265 tickets, instead of being five minutes, it’s now done in 30 seconds, and we’re only spending 2.2 hours of automation time on it. So we just freed up 22 man hours. And the other nice cherry on the top is, if you remember, it took one and a half days for the manual process to finally open and close. With automation, we’re talking 30 seconds, because we’re constantly polling our ITSM tools for the next ticket. So now you have a clear, consistent, repeatable process that your customers will see, and it’s a win/win.
Guy Nadivi: Okay. So now I’m a bit curious; do you ever get more formal by calculating the ROI of automating a particular process? And if so, other than time-savings, what kind of metrics are most relevant for you?
Dwayne White: So for us, I present my management, I try to at least monthly, to know how our team is performing. And part of that is showing the automations that we took over and what the manual process was keyed up at as far as SLAs and time to resolve for incidents … I’m sorry, mean time to resolve for incidents. And I’ll put together a nice little dashboard showing them the savings done with it, as well as any failures within our automation, which is very, very limited. But it’s a nice dashboard that shows them the KPIs that they want to look at.
Guy Nadivi: Dwayne, with all the processes you’ve automated, I’m curious if there’s any particular one that stands out as the most successful IT business process you’ve automated?
Dwayne White: So I would say the most successful one that we’ve automated … oh, let’s see. So we have about 43 automations right now. Of those, most successful, I would probably have to say it’s probably the employee offboarding automation. What makes it successful is that one’s actually looked at from a internal audit perspective. So for an example, when an employee decides to move on or is terminated, whatever the case may be, once the effective date comes in, we have two business days to get them terminated and off-board properly out of our systems. So what was different about this is they can actually put the ticket in a couple of weeks in advance. So, for example, if a guy wanted to move on from Ayehu, he would tender his resignation and they would go ahead and submit the termination paperwork, but it wouldn’t be effective until let’s say two weeks down the road. So for us, it was trying to pull in and design the automation to where when the ticket was put into the system and it had all the approvals, how not to process it until the actual effective date. So that one did stump us for a while, but we did work through that one finally, and we’ve got it in place and it has been running successful right now for probably about four or five months. And the nice thing is we’re able to use that as a framework for other automations that had similar characteristics with it. If you look at what we had to do with our employee offboarding, it would take a system admin 30 minutes to go through and touch upon the different areas that they had to remove accounts from, or pull them out of different security groups or distribution lists. Now, automation does it in two minutes, and it does it within the 2-day SLA, the second the effective date happens at, let’s say this Friday at 5:00 PM, automation is kicking off. So we don’t have to worry about, “Uh oh, you were working over the weekend,” or, “You didn’t have to work over the weekend to make sure you kept your SLA.” And it’s kept our internal audit team happy, Infosec’s been pleased, and haven’t had any issues. So.
Guy Nadivi: Dwayne, you were in the Marines for nearly six years, but not in an IT capacity. First off, I’m sure I speak on behalf of all of our listeners when I say thank you for your service. Secondly, I’m curious to hear how did being a Marine prepare you for a career in IT operations?
Dwayne White: Yeah, let’s see. And thank you, it was my pleasure. I actually enjoyed the service. Actually I joined when I was in high school. So they had a program back then called a delayed entry program; you could join in your senior year, and upon graduation, you can go ahead and jump into the Marine Corps. So that’s what I did. I had a nice two week summer vacation. And this was … oh, let’s see, back in 1984. So I served in the Marines from ’84 to 1990. And Marines, there’s different jobs in the Marine Corps. So I was assigned to a helicopter squadron and my role was an aviation ordinance technician. Normally you’d think that sounds like fun, and it was, but as an aviation ordinance technician, a lot of people think, “Oh, cool, you get to play with bombs and missiles and things like that.” And there’s not many things to automate, it’s a lot of manual work, it’s heavy lifting. But what people don’t think about, and sometimes they forget, is our government and the military, they love their paperwork. And the paperwork has to deal with maintenance on the aircraft, personnel changes, scheduling, you name it. There was a ton of paperwork that was being done. And we didn’t really have a computer back then, but we had a nice typewriter, a beautiful … probably, if I think about it, maybe a Xerox typewriter. And that’s how I learned how to type. That plus high school. But from there, I went ahead and took a course at a local community college. I was stationed out in Jacksonville, North Carolina. And the class I took was around data processing because I thought that would be a good fit because I got tired of trying to type on the typewriter and make everyone happy, because my penmanship’s not the best in the world. And after graduating from the community college, I was able to come back to my shop, convince our Master Sergeant that, “Hey, we really need to get a computer because I can help us with all this typewriter stuff by taking it from a typewriter and putting it into a computer and then producing the same paperwork, the same forms, changing what we needed to change.” And I got that implemented. It took a little while, a lot of hit and misses, but it soon started working for us. And that’s how I got going with the automation. Outside of that, I’m in the Marine Corps, it’s great. I mean, how they prepared me, like everything else, it’s how they train you. It’s the discipline, it’s the operational efficiency of the Marine Corps. If we wouldn’t be efficient, we wouldn’t be disciplined. That’s it, pretty much, in a nutshell.
Guy Nadivi: Dwayne, for the CIOs, CTOs and other IT executives listening in, what is the one big ‘must have’ piece of advice you’d like them to take away from our discussion with regards to implementing automation?
Dwayne White: I would probably tell them that they need to invest into a dedicated automation team. What I mean by that, it’s not going to be someone’s part time job, it’s not going to be an afterthought, it’s truly a team dedicated to automation. And once you have that in place, you get them involved with your projects. You get them involved early on, because they’re going to bring a skillset that they haven’t seen before, because there’s still a lot of IT companies who are used to manual processes. If you look at a lot of the data center operations or batch operations, you’ve got these operators glued to your computer monitors, and all they’re doing is staring at it and waiting for something to happen. Or maybe they have a task list that they have to go through at nighttime to make sure the batch processes are running properly. Those are opportunities for automations, and you’re not going to see those unless you have a dedicated team who’s out looking for them. The other thing, and I tell this to my team and the teams that I work with when I’m trying to get them to bring me more ideas for automation, is do not look at automation as a means to replace your staff. That shouldn’t be your first thoughts, thinking that you could save a few dollars. You need to look at it as an opportunity to give back to your staff time. As we mentioned earlier, that one automation, it went from 22 hours down to two hours. There’s 20 hours of time back to your staff for them to focus now on your manager’s next big project, or give them time to invest back into their training through their career development. It’s a win. You can’t go wrong.
Guy Nadivi: Great advice from a hands on practitioner. All right, looks like that’s all the time we have for on this episode of Intelligent Automation Radio. Dwayne, our listeners have told us they want to hear more firsthand insights from automation practitioners like yourself, and you’ve definitely delivered that to our audience today. Thank you very much for coming onto the show. Dwayne White: Oh, thank you. Have a good day.
Guy Nadivi: Dwayne White, Vice President of Technology Automation at LPL Financial Services.
Thank you for listening everyone. And remember, don’t hesitate, automate.