00:00:15

All right. Well, thank you everybody for coming to my presentation. Uh, today we're going to talk about identity and access management and how our infrastructure product model has accelerated our delivery and transparency to really drive outcomes and increased engagement, uh, across our team. Uh, so first a little bit about me. Uh, my name is Todd Beckley, uh, on the AVP and the technology engineering. Uh, and more importantly is I'm a new technology product manager for R D for our identity and access management team. And when we talk about identity and access management, in this context, we talk about things like authentication authorization, a multi-factor authentication, or identity governance, certificate management, kind of all those things that wrap around, uh, associate identities and consumer identities. Uh, I have about 25 years of experience in technology industry. Um, I do have a big passion for identity and access management.

00:01:10

This is where I started my career actually as an engineer, um, done a number of other things throughout technology, and recently came back, uh, to this team, uh, to help deliver a big program and really introduced, uh, the new product model practices. And now that we've been in this product model, uh, for a year or so in my team, uh, have a huge passion, uh, for, for these product model, uh, practices. Uh, that's my picture, that's me in a suit and cleanly shaven pre pandemic when we had suits and, and we had razors and, uh, now we don't really do that anymore, so I, I feel much more comfortable. Uh, so a little bit about nationwide. Um, you know, obviously we're, we're a big company, we're a fortune 100 company. Uh, so, you know, we're, you know, in the top 10 and almost every insurance and financial services category, uh, in the U S we are a U S bound company only, uh, we're number one in 4 57, we've got great ratings from our credit agencies.

00:02:04

Um, we're about a 2 billion revenue company a year kind of on average. Um, you know, and I think the big thing for us from an identity standpoint, we have about 35,000, about 45,000 internal identities from associates and contractors, and we manage about 8 million external identities. So, uh, really when you think about it, uh, we, we've got some pretty big scale here. Uh, we have a lot of demand and a lot of things going on in this space, obviously with, uh, uh, insurance and financial services, uh, being a really customer focused, uh, sort of, uh, industry making sure that we have smooth practices with our identity and secure practices practices with our identity are really critical. So, uh, let's talk a little bit about kind of the journey that we've been taking, uh, in the IAM team to get to this product model. Um, you know, if we think about, uh, you know, product models and agile and DevOps, uh, it's obviously been around for, and really Nationwide's development teams, um, they started focusing on, on their agile and dev ops journeys way back in 2006.

00:03:07

Um, so, you know, around 2008, uh, nationwide pulled all of the development teams out of the development areas and centralized them, uh, in a centralized development center and really started to focus on injecting agile and DevOps practices across our development platforms. We ended up with about 225 centralized lines, um, to serve all of nationwide across the enterprise by by 2016. And, and with this centralization, uh, the app dev teams were, were really able to use lean scrum combine, kind of all the agile dev ops things, uh, that we see and know, and love and hear, uh, every day. And, and honestly became, became pretty efficient on a jeans jeans come to talk at nationwide. Um, and there's just a lot of passionate and R and R development areas around, uh, agile lean DevOps, uh, and, and, and our product centric, um, uh, model. But, you know, when we think about it, you know, what about infrastructure?

00:04:04

So infrastructure is sort of the, the backbone of where things run, but we sort of left infrastructure behind. We really focused on, on, on our agile lean and dev ops and our development spaces, and, uh, didn't think a whole lot about infrastructure. Um, so, you know, from an infrastructure standpoint, our teams still operated in a, in a plan build and run model, and we had lots of handoffs. We didn't have clear accountability for roles. Um, there were times where it took up to five executives in a room to make a single decision about one technology. Uh, so it was, it was pretty inefficient. Um, it became pretty inefficient. Um, you know, we didn't have any consistent demand processes. So all of those multiple teams and playing build and run, um, all had their own demand processes and people who needed services or products from, uh, those teams had to sort of negotiate all kinds of different pathways to be able to get there.

00:05:00

And then one of the bigger things is there was really no consistent prioritization, um, or owners of the prioritization of all the work. And what it came down to with, with a lot of teams is, you know, the squeaky wheel gets degree. So whoever was escalating, those things got done first. Uh, there was no view into our backlogs. We, we didn't have any idea of how much work was ever going to come. We didn't really have a good, uh, metric on how much work we could deliver. Um, so it was a little, it was a little clunky and we really didn't have any true customer feedback loops. So, you know, we got feedback from customers, but we weren't able to really bring that into anything consistent. So we knew, or, or had real feedback on what we were doing wrong or what we could improve on to be able to really impact what the customer, uh, does every day.

00:05:45

Um, and then really we had no way to track how much work gets completed, um, or how much can be completed in a, in a certain timeframe, for example, a release cycle. Um, so it was really difficult to plan, uh, on how big projects were or how big tasks were, uh, to get that done. So, um, you know, how, how did the IAM team, uh, help to address these, these issues to increase our delivery, to provide our new capabilities, to reduce our risks, improve relationships, all those things? Well, it started, uh, in 2019, um, our development center leaders actually came over to infrastructure, uh, and said, you know what, we, we have some really great things that we've been doing in the app dev space that we can start to do here. Uh, so the IAM team, uh, was picked as a pilot, uh, to say, Hey, let's start taking some of the processes that are really good at and our development spaces and figure out how we inject those, those processes into our infrastructures.

00:06:39

So, uh, I was hired in late 2019 to run the IAM team. Um, you know, had a lot of passion for this. So I thought it was a great idea to start with, um, so we got together and said, okay, where do we start? And, you know, just like any big transformational effort that, that you're going to undertake, it really starts with, uh, our people. So, uh, what we did and from an engineering perspective is, is we had to redefine, um, all of our engineering jobs, uh, to support how we were going to drive, drive our product model, do our agile and dev ops practices. Uh, and through this, we really defined key three key jobs, uh, to support this model.

00:07:20

The first one is our technology delivery professional. Um, so our technology delivery professional, uh, he manages the flow of work, uh, into our agile teams, but also has the ability to pull cards and do hands-on engineering. So it's kind of a, so, you know, the way we saw it as sort of an evolution of a scrum master, um, so this person was, was using techniques, um, to get things in backlog, to use JIRA for our flow mechanisms to help groom backlogs, to help run stand-ups. But when that was done, that that person put the flow mechanism, flow mechanisms away and started pulling cards off the board and actually doing, uh, engineering work themselves. We then defined a very specific job called technology product manager. Um, so all of our infrastructure technologies were broken down into product products and each product had a technology product manager assigned.

00:08:11

And really the key with the technology product manager is that person is accountable for the end to end management of our technology products. That includes finances, vendor, relationships, operations, currency, uh, project delivery, uh, new technology, innovation capability delivery. All those things are what the technology product manager, now that person can farm some of that workout or delegate it to people on their team or to peers. But in the end, the product manager is the one person accountable for that. And really kind of the biggest change we made, uh, to support our product model is defined a technology product owner. So our technology product owner, uh, is accountable for helping us set our priorities, uh, for our technology product managers and working closely with the technology product teams and the business teams, uh, to be able to understand what those priorities are, uh, help, uh, participate in our backlog grooming sessions and really work daily with our teams to make sure we're working on the most important things.

00:09:09

Um, the second thing that we had to do, uh, after we defined our new jobs is we had to reorganize our teams into actual product teams to make sure that we could support that whole build it, run it foundation. Uh, so if you remember before we were on plan build run, and we had products spanning multiple teams. Um, now we have one single product in one single team or multiple products in a, in a, in a single team and really in a, in a, in a build it run it mode. Uh, and this really helps to drive that end-to-end accountability, uh, for all of our products. So from an organizational standpoint, each product team, uh, is led by a technology product manager and each product team is supported by a technology delivery professional. Um, and then over the top, uh, you know, at least for the IAM space, we have an executive level technology, product manager, uh, who's accountable for all the product teams, uh, underneath their purview.

00:10:00

Uh, so from the I M space, we went, we ended up with three product teams, three product managers, and three delivery professionals, uh, that were going to manage the flow of work and manage everything about our products, uh, day in and day out on the flip side. Um, you know, we had to identify an organization that was really gonna, uh, kind of perform that product owner sort of role, uh, and in the case of IAM at nationwide, uh, we, we had some pretty clear lines with our information risk management group. Um, they ha they had an eye, they had an identity and access management capability team who worked very closely with components of our team, um, you know, on, on things that needed to happen. Uh, but it was a, it was a pretty clear, uh, cut and dried line between who could be our product owner to help us do these things.

00:10:47

Uh, so the, I, the, the information risk management team, the IRM team also reorganized to sort of match the, um, infrastructure team, uh, in terms of product. They also came with three, uh, product teams, uh, and they have three, um, technology, product owners, uh, over each of those teams that face off to the technology product managers on my team. And then they have a technology product owner executive, uh, who I faced off with. And then these owners work with my team day in and day out, uh, very well connected on a priority, backlog grooming, all those things that, that we see from an agile, uh, construct, uh, being helped to clarify work for the team. One thing I do want to note here too, is that, um, you know, it is, it was, it was much easier for our team to be able to define product ownership, because we do have some pretty clear lines with risk management.

00:11:42

Uh, this becomes more difficult when you get into other infrastructure teams where those lines aren't so clear. Uh, for example, uh, our server teams, obviously everybody can consumes our compute technologies. Um, so who do you define as that? So we're, we're starting to work through is sort of a federated product owner model, uh, to see, to see how that's going to work. Um, so, you know, to S to support the product model and to support the IAM team and some things that were happening at nationwide, um, you know, that sort of helped to instantiate the product model is we have a three-year multimillion dollar program that started, uh, up in early 2020 with really a focus of reducing our risk and the identity and access management space and upgrading and adding new capabilities in the IAM space. So, um, you know, to support this program, we, we utilize these product teams to be able to do these deliveries, uh, in, in this, in this agile context.

00:12:38

So if you look at the graphic I have on the screen, I know it's a little busy, but if you think about the things that are in those blue dotted boxes, that's really our product team. So what you see there on the right is the INO, the infrastructure product management team, uh, on the right, you see the information, risk management team, product team on the left. Uh, and then you see this little bar on top that says, I am product management, one team, really now we, we, we really function, uh, totally as one team. Although we report up through separate technology organization, executives, we, uh, operate, uh, and, uh, we win and fail together. So we're all, we're all very aligned. And even if things in the risk management space don't really impact the INO, uh, IAM team, uh, we, we feel the same set of responsibility and, and vice versa.

00:13:26

So we've got some excellent engagement, uh, between the teams and overall this dotted blue box is accountable for every piece of delivery, uh, within the IAM space, outside of our program, but all the other things too. And I'll talk about that in a second. So, uh, in a company as big as nationwide, we do have to acknowledge the box over, over to the left. Although a lot of the IAM, uh, capabilities do sit within the dotted blue box. We do have some federated capabilities that sit on our, on our application areas. Um, and that's okay. That's just kind of the way we've grown up. And we manage that by the, by the first, um, uh, horizontal box, uh, on top called our IAM governance team. Um, so we pull everybody together to make sure we're aligned. And then on top of that, we have a steering committee, uh, who, who steers everything happening in the space. Uh, it was originally kicked off to, to steer just the program. Um, but after about six months, we were able to convince them that, uh, the delivery in this space is bigger than our program. That's specific to all the products. Uh, so now they steer all of our products for us. So, uh, that's been super helpful.

00:14:36

So, you know, you can't have products, so you start off with your people, you start off with your organizations and then, and then you structure things around it. But really when we talk about, you know, product model to a big component of it is how, how do we deal with our finances? How do we unitize identity and access management, and then how do we manage, um, all the work that's coming into the team, and then how do we know where we're spending our money? Um, so what, what we have here is really a four-quadrant bucket of how we view work from the product model in the IAM team at the top left and the light blue box. That's, that's our external demand specifically from the program, the multimillion dollar program I mentioned. So we've got a roadmap, we've got capabilities, we've got risk reduction work.

00:15:19

That's all flowing over this, into this team of over a three-year program that we're having to do in the top, right. That's just other external demand. So we've got other app teams, we've had other business areas who want to consume our products and services, and they have demand coming into our team, uh, to completely separate from the program. So we, we have a bucket for managing network and the bottom, right? That's, that's our product evolution work. That's where we see work like new product introduction, new capability, introductions, major upgrades, uh, things that actually evolve the products that we have on the team, uh, to help, to help keep things going to help keep us on the cutting edge of providing our services. And then obviously, probably the biggest on the bottom left is we have our operational support bucket. Uh, that's where we do all of our currency.

00:16:08

That's where we do all of our minor upgrades. That's where we do all of our tickets and really that's where we manage all of our outages from. Um, so if we think about this in whole, uh, that that really covers every piece of work. Um, one thing that I want to really talk about, or, or just call out from a product ownership model is, you know, previous to our product model work work was kind of like this, just not as organized and, um, our risk management folks who drove a lot of demand into our team. Uh, they, they really only focused on that top blue bucket. And the issues that ran into is if we had other demand coming in, or if we had product evolution work, or if we had currency work, we had to do, um, the people who were providing most of our demand and funding to do work really wanted all of their top blue pie sets of capabilities done.

00:16:58

Uh, now that their product owners they're accountable for prioritizing everything inside this circle, uh, and that has just made it tremendously, uh, more easy, uh, for all the teams, uh, to be able to get things done. Um, so if there's, if there's outages, although the risk management team isn't on outage calls, they feel the same amount of accountability as, as the actual hands on keyboard team does, uh, to do it. And there are many times where we've looked at some of the risk management, um, desires and prioritized either external demand, um, or operational support activities over them, uh, because we know it's better for the product overall, and that's not something that existed before. Uh, and from an engagement perspective for our associates, uh, it's been just a tremendous help, uh, for them to know what those priorities are and to have that one team that really helps us from end to, uh, understand what they are.

00:17:52

Um, okay. So we've got our roles in place. We've got our organizational alignment in place. Uh, we figured out, uh, how to manage our, our, our finances and, and, and unitize our products in the IAM space. So we have all those foundational sort of pieces in place, all those building blocks, uh, and now it's time really to have some fun and help to define our okay. Ours helped to inject our agile lean practices and our dev ops capabilities, um, throughout the whole team. So the first place we started, uh, here was with our flow capabilities, and this was level setting the team, uh, on our common vocabulary, um, and really injecting, um, the use of enterprise tools. We, we, we use JIRA here at nationwide, uh, to be able to bring all of our work intake in be able to create our JIRA cards and be able to do the prioritization, the backlog on everything within JIRA.

00:18:48

So, you know, my, my team has heard me say this at ad nauseum now, um, you know, by, by using and, and adopting these methodologies, um, no, where you don't work on our team doesn't exist. If it doesn't exist in JIRA, uh, outside of operational worker outages, no work exists unless it exists in JIRA. So our drive-bys our emails, our escalations all has to link to JIRA cards, all has to be either active work or in our backlog. Uh, other than that, it's just, it just, it just doesn't exist anymore. Um, and as we did these flow methodologies, you know, we hired our PDPs who didn't know anything about agile and dev ops at, at, at the time we had, as you could imagine, lots and lots and lots of iterations of figuring out, um, um, what, what works best, uh, were probably dozens of iterations in two boards, uh, by now on, on, on how we manage our work.

00:19:38

But, you know, that's okay. That, that was the expectation we set, what the team is, we're going to continuously evolve. And in fact, I would fully expect the boards we have today are, are not going, the boards are not going to be the boards. We're going to have six months from now because we're going to continue to evolve. The second place we had to do was, uh, developing our product strategies for each of our product teams and really doing roadmaps, um, not only for our program, uh, but also for our product evolution work and bringing those things together, uh, to help define, and really give us those, uh, headlights and guard rails, uh, in, in, in, into where we wanted to go. Uh, so we took a few months, we've got some pretty strong product strategies, uh, developed now that we anchor to, uh, the next place we went, uh, was managing through metrics.

00:20:22

And, you know, this, this was really huge. So once we got our, our flow mechanisms in place, and we got everything in JIRA and we were doing our daily stand-ups and our TTPs were managing cards and pulling cards, um, and we started to see, you know, releases pickup, and we started to see more work flow through our system with the same amount of people we had before we started to say, okay, let's, let's figure out how we determine on this team. Um, how do we assign points to cards? How do we know how big things are, or how small things are, how do we know how many points we can get through, um, uh, bi-weekly releases, how many points are in our backlog? How, how, how has our backlog health, so really kind of a level of, of, of maturity. Uh, it took us about six months to get there.

00:21:05

Uh, but now we've got a pretty good view into the work. Uh, that's that's happening and, and what it's going to take to get that work done. And then we had to focus on our, on our customer centricity. So how do we get the feedback from, from our customers? Um, we've started doing that through micro surveys. Um, and then, and then we're starting to work on net net promoter scores, um, that we're bringing back to our teams. We're also doing, uh, interview groups. We're doing group feedback sessions, really to find out what capabilities, what integrations do our consumers need, uh, for them to be more effective, uh, in serving our business, um, next was priority alignment, right? So we, we I've talked a lot about our, our, our backlog grooming and the real critical role, our, our product owners, owners play in there. Um, you know, it's funny, I look at each one of these dots and I could say how it's the most important, uh, but prior priority alignment was really important for us before we went to this product model.

00:22:00

Nobody had any clear vision of priority, like I'd said earlier, it was all, it was all squeaky wheel gets degrees, whoever, whoever yelled the loudest was where we ended up working. Uh, now with our product owners, we've got very clear priority, uh, through our backlog, uh, and, and everything, uh, that we're working on. And as you can see here, um, this is where we kind of anchor to, uh, if it doesn't exist in JIRA, it doesn't, it doesn't exist for us. And then injection of our lean management systems as well. So you can have all the boards in the world, you can have all the cards in the world, you can have great backlogs, but, but if you're not using lean management practice, lean management practices to be able to manage, uh, the flow of work in and out of these teams, uh, it's going to be very difficult.

00:22:43

Um, so obviously, you know, this, this started, we really started this journey a month pre pandemic. And by the time we got into having our first set of boards, we were all virtual. So at nationwide, where we were a huge, you know, from a development center perspective, um, you know, everybody in the office, lots of white boards daily, stand-ups where people are together. We had to really pivot that whole entire thing to, to be virtual. I think it was a little bit easier for our team because we didn't have that sort of a conditioning, like some of our app dev teams did. Um, but using our lean management practices, uh, we were able to use that, uh, through using our virtual boards, virtual huddles, virtual stand-ups, um, you know, the one thing you'll see missing out of here right now is sort of the dev ops piece.

00:23:26

Um, so there are some DevOps things that we've been starting to work on in terms of IAM, specifically around our test automation. Um, so as we start to embrace our CICD pipelines in this space, um, we are using test automation and injecting test automation scripts into our releases to, to, to be able to, to do that test automation. Uh, but we're really kind of at sort of the beginning touches of that, at least in the identity and access management space. Uh, but that's going to be a big push for us coming up this year as well. So, um, we're 14 months into our product journey. Uh, what have we experienced? Um, we have clear priority, uh, and we have, uh, you know, into all of our active and our backlog work. Um, we use big room planning. We use quarterly big room planning sessions, um, where we drive commitments on 30, 60, 90 day deliverables.

00:24:17

Uh, we've had our fourth session now, our first one was almost three days. Our last one was a half a day. Uh, so we're, we're getting pretty good at doing our big, big room planning. Um, and having that clear priority is just really great for our engineers to know what they're working on every day, second point, our engineers have clear line of sight into what they work on every day. If it's not in JIRA, it doesn't exist. This has led to higher engagement on the team or engineers come in, they pull in two, three cards a day. That's what they're working on. Uh, context switching is, is minimal. I won't say it doesn't exist because sometimes there are, you know, important issues that come up, but it's, but it's minimal to where previously, uh, we had tons of context switching and essentially we couldn't get a flow through our systems as fast.

00:25:02

Uh, we have transparency into our financials. So if we think back into that, um, uh, circle, uh, we know where all the money's spent, not only do we know where all the money spent, we know where, where we're spending the money on what types of things, uh, between operations, between capabilities, between external demand. And we've been able to unitize identity and access management for nationwide. Uh, we picked cost per ID. So we have a, we have a cost per identity, uh, that we now manage to and, and report on to our steering committee and velocity. We know how much we can complete in a certain release cycle, so we can look at our backlog and we can tell you how long it's going to take to clean our backlog. If we wanted to get faster, we can go get contractors. And we know we get a bump in our velocity, uh, and we can really manage the dials.

00:25:47

In fact, last fall, uh, one of the teams came back with a, with a giant backlog and said, one of the product managers said, if I had three contractors, I could cut this down in four months, we got three contractors and we're pretty close to where we thought we would be in four months. So just being able to plan and predict and be able to execute on that is, uh, just been paramount. So, you know, w what are the key factors for success that we've seen in implementing the product model? Uh, you know, I think it's unsafe, you know, it doesn't need to be said, but, you know, with any big transformational effort, you have to have executive sponsorship. So I'd mentioned that we had leaders from our development team come over and take over the infrastructure area, uh, and, and help, uh, get this through.

00:26:27

It's been, it's been awesome sponsorship from them. Um, obviously lots of, lots of support, lots of consulting, because they've done this for years to be able to help our teams through it. So that's been really paramount. Um, th the next one has really big too, is, you know, you have to have a team that's going to lean into the change. If you have folks who, uh, say, well, the way we've been doing, it's just good enough. I don't know why we need to change. It's going to be a struggle. Um, you know, on, on our side, uh, it was pretty painful for a number of years. Uh, and I think the team was really open, uh, to finding something that was going to help to make their lives better day in and day out. So that lean into changes is really important. Uh, this is probably the most important one out of all.

00:27:07

Uh, you have to have a dynamic technology delivery professional, so that TDP role who manages the flow of work, who pulls cards and does work too. Um, it's, it's, it's really a unique position, and it really takes a unique individual individual to be able to fulfill that position. Uh, luckily we've got a couple of great ones on our team who really dove in, um, they already have the technical skills, they dove into the agile side, uh, to be able to, to, to learn those practices and bring them on the team. And they've done a great job. Uh, and then, and then last but not least is you have to have alignment from your product owner or owners, depending on how you're going to do it. Um, they have to buy into your processes. They have to understand that they own backlog grooming. They have to understand that they own prioritization, not only for their things, but for everything that happens, uh, in, in your teams.

00:27:56

And we have that on our side. So it's, it's really been a great journey. So, um, you know, one thing, you know, uh, that I wanted to come to this group for is, is, is talk about help that we're looking for. Um, you know, for us, this is all, this is all a new journey. So, you know, experience with product ownership. Uh, and if there's teams who have used the sort of federated product ownership where you don't have clear product owners, um, you know, how, how do you do that? Do you do it through groups? Do you do it through, um, some sort of knowledge sharing sessions? That's something that we're still trying to work through. Uh, then really the, the, the second one is, you know, implementing a TDP more broadly across the organization to finding the perfect person with that mix of technical and agile skills is super important.

00:28:40

Um, you know, on our team, it kind of evolved, but as we roll it out, we, we are struggling a little bit with other teams finding that right person who, who can fulfill the agile and the technical things all at the same time. Uh, so I believe that's the end of my presentation. Uh, I just want to say thank you to everybody for listening. Uh, I really appreciate it. Please feel free to reach out to me. If you have questions I'm on LinkedIn, uh, at is Todd Beckley. And I hope everyone has a great day.