Tod Bickley

All right. Well, thank you, everybody, for coming to my presentation.

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 increase engagement across our team.

So first, a little bit about me. My name is Tod Bickley. I'm the AVP in technology engineering, and more importantly, I'm a new technology product manager 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, multi-factor authentication, identity governance, certificate management, and all those things that wrap around associate identities and consumer identities.

I have about 25 years of experience in the technology industry. I do have a big passion for identity and access management. This is where I started my career, actually, as an engineer. I've done a number of other things throughout technology and recently came back to this team to help deliver a big program and really introduce the new product model practices. And now that we've been in this product model for a year or so in my team, I have a huge passion for these product model practices.

That's my picture. That's me in a suit and cleanly shaven pre-pandemic, when we had suits and we had razors. Now we don't really do that anymore, so I feel much more comfortable.

So a little bit about Nationwide. Obviously, we're a big company. We're a Fortune 100 company. We're in the top 10 in almost every insurance and financial services category in the U.S. We are a U.S.-bound company only. We're number one in 457s. We've got great ratings from our credit agencies. We're about a two billion revenue company a year on average.

And I think the big thing for us from an identity standpoint: we have about 45,000 internal identities from associates and contractors, and we manage about eight million external identities. So really, when you think about it, we've got some pretty big scale here. We have a lot of demand and a lot of things going on in this space. Obviously, with insurance and financial services being a really customer-focused sort of industry, making sure that we have smooth practices with our identity and secure practices with our identity are really critical.

So let's talk a little bit about the journey that we've been taking in the IAM team to get to this product model.

If we think about product models and agile and DevOps, it's obviously been around for a while. Nationwide's development teams started focusing on their agile and DevOps journeys way back in 2006. Around 2008, Nationwide pulled all of the development teams out of the development areas and centralized them 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 to serve all of Nationwide across the enterprise by 2016. With this centralization, the app dev teams were really able to use Lean, Scrum, Kanban, kind of all the agile DevOps things that we see and know and love and hear every day, and honestly became pretty efficient. I know Gene's come to talk at Nationwide, and there's just a lot of passion in our development areas around agile, Lean, DevOps, and our product-centric model.

But when we think about it, what about infrastructure? Infrastructure is sort of the backbone of where things run, but we sort of left infrastructure behind. We really focused on our agile, Lean, and DevOps in our development spaces and didn't think a whole lot about infrastructure.

From an infrastructure standpoint, our teams still operated in a plan, build, and run model, and we had lots of handoffs. We didn't have clear accountability for roles. There were times where it took up to five executives in a room to make a single decision about one technology. So it became pretty inefficient.

We didn't have any consistent demand processes, so all of those multiple teams in plan, build, and run all had their own demand processes. People who needed services or products from those teams had to negotiate all kinds of different pathways to be able to get there. And one of the bigger things is there was really no consistent prioritization, or owners of the prioritization of all the work. What it came down to with a lot of teams is, the squeaky wheel gets the grease. Whoever was escalating, those things got done first. There was no view into our backlogs. We didn't have any idea of how much work was ever going to come. We didn't really have a good metric on how much work we could deliver. So it was a little clunky.

And we really didn't have any true customer feedback loops. We got feedback from customers, but we weren't able to really bring that into anything consistent so we knew 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 does every day. And really, we had no way to track how much work gets completed, or how much can be completed in a certain timeframe, for example, a release cycle. So it was really difficult to plan on how big projects were or how big tasks were to get that done.

So how did the IAM team help to address these issues to increase our delivery, provide new capabilities, reduce our risk, improve relationships, all those things? Well, it started in 2019. Our development center leaders actually came over to infrastructure and said, "You know what? We have some really great things that we've been doing in the app dev space that we can start to do here." So the IAM team was picked as a pilot to say, "Hey, let's start taking some of the processes that we're really good at in our development spaces and figure out how we inject those processes into our infrastructures." So I was hired in late 2019 to run the IAM team. I had a lot of passion for this, so I thought it was a great idea to start with.

We got together and said, "Okay, where do we start?" And just like any big transformational effort that you're going to undertake, it really starts with our people.

What we did from an engineering perspective is we had to redefine all of our engineering jobs to support how we were going to drive our product model through our agile and DevOps practices. Through this, we really defined three key jobs to support this model.

The first one is our technology delivery professional. Our technology delivery professional manages the flow of work into our agile teams, but also has the ability to pull cards and do hands-on engineering. The way we saw it is sort of an evolution of a scrum master. This person was using techniques 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 person put the flow mechanisms away and started pulling cards off the board and actually doing engineering work themselves.

We then defined a very specific job called technology product manager. All of our infrastructure technologies were broken down into products, and each product had a technology product manager assigned. 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, project delivery, new technology innovation, capability delivery. All those things are with the technology product manager. That person can farm some of that work out 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 the biggest change we made to support our product model is defined a technology product owner. Our technology product owner is accountable for helping us set our priorities for our technology product managers and working closely with the technology product teams and the business teams to be able to understand what those priorities are, help participate in our backlog grooming sessions, and really work daily with our teams to make sure we're working on the most important things.

The second thing that we had to do 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. If you remember before, we were on plan, build, run, and we had products spanning multiple teams. Now we have one single product in one single team or multiple products in a single team, and really in a build it, run it mode. This really helps to drive that end-to-end accountability for all of our products.

From an organizational standpoint, each product team is led by a technology product manager, and each product team is supported by a technology delivery professional. Then over the top, at least for the IAM space, we have an executive-level technology product manager who's accountable for all the product teams underneath their purview. From the IAM space, we ended up with three product teams, three product managers, and three delivery professionals that were going to manage the flow of work and manage everything about our products day in and day out.

On the flip side, we had to identify an organization that was really going to perform that product owner sort of role. In the case of IAM at Nationwide, we had some pretty clear lines with our information risk management group. They had an identity and access management capability team who worked very closely with components of our team on things that needed to happen. It was a pretty clear, cut-and-dried line between who could be our product owner to help us do these things.

So the information risk management team, the IRM team, also reorganized to sort of match the infrastructure team in terms of product. They also came with three product teams, and they have three technology product owners over each of those teams that face off to the technology product managers on my team. Then they have a technology product owner executive who I face off with. These owners work with my team day in and day out, very well connected on priority backlog grooming, all those things that we see from an agile construct being helped clarify work for the team.

One thing I do want to note here, too, is that 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. This becomes more difficult when you get into other infrastructure teams where those lines aren't so clear. For example, our server teams, obviously, everybody consumes our compute technologies. So who do you define as that? What we're starting to work through is sort of a federated product owner model to see how that's going to work.

To support the product model and to support the IAM team and some things that were happening at Nationwide that sort of helped to instantiate the product model, we had a three-year, multimillion-dollar program that started up in early 2020 with a focus of reducing our risk in the identity and access management space and upgrading and adding new capabilities in the IAM space.

To support this program, we utilized these product teams to be able to do these deliveries in this agile context. 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. What you see there on the right is the I&O, the infrastructure product management team. On the left, you see the information risk management team product team, and then you see this little bar on top that says IAM Product Management One Team.

Really now, we function totally as one team. Although we report up through separate technology organization executives, we operate and we win and fail together. We're all very aligned. Even if things in the risk management space don't really impact the I&O IAM team, we feel the same set of responsibility and vice versa. We've got some excellent engagement between the teams. Overall, this dotted blue box is accountable for every piece of delivery within the IAM space, outside of our program, but all the other things, too, and I'll talk about that in a second.

In a company as big as Nationwide, I do have to acknowledge the box over to the left. Although a lot of the IAM capabilities do sit within the dotted blue box, we do have some federated capabilities that sit out in our application areas. That's okay. That's just kind of the way we've grown up, and we manage that by the first horizontal box on top called our IAM governance team. We pull everybody together to make sure we're aligned, and then on top of that, we have a steering committee who steers everything happening in the space. It was originally kicked off to steer just the program. But after about six months, we were able to convince them that delivery in this space is bigger than our program. It's specific to all the products. So now they steer all of our products for us. That's been super helpful.

You start off with your people, you start off with your organizations, and then you structure things around it. But really, when we talk about product model too, a big component of it is how do we deal with our finances? How do we unitize identity and access management? How do we manage all the work that's coming into the team? And how do we know where we're spending our money?

What we have here is a four-quadrant bucket of how we view work from the product model in the IAM team. At the top left in the light blue box, that's our external demand, specifically from the program, the multimillion-dollar program I mentioned. We've got a roadmap, capabilities, risk reduction work that's all flowing into this team over a three-year program that we're having to do.

In the top right, that's just other external demand. We've got other app teams, we've got other business areas who want to consume our products and services, and they have demand coming into our team, too, completely separate from the program. We have a bucket for managing that work.

In the bottom right, that's our product evolution work. That's where we see work like new product introduction, new capability introductions, major upgrades, things that actually evolve the products that we have on the team, 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. That's where we do all of our currency. 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. If we think about this in whole, that really covers every piece of work.

One thing that I want to really talk about or just call out from a product ownership model is previous to our product model, work was kind of like this, just not as organized. Our risk management folks, who drove a lot of demand into our team, really only focused on that top blue bucket. 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, 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. Now that they're product owners, they're accountable for prioritizing everything inside this circle. That has just made it tremendously easier for all the teams to be able to get things done.

If there's outages, although the risk management team isn't on outage calls, they feel the same amount of accountability as the actual hands-on-keyboard team does to do it. There are many times where we've looked at some of the risk management desires and prioritized either external demand or operational support activities over them because we know it's better for the product overall. That's not something that existed before. From an engagement perspective for our associates, it's been just a tremendous help for them to know what those priorities are and to have that one team that really helps us from end to end understand what they are.

Okay, so we've got our roles in place. We've got our organizational alignment in place. We've figured out how to manage our finances and unitize our products in the IAM space. We have all those foundational sort of pieces in place, all those building blocks. Now it's time really to have some fun and help to define our OKRs, help to inject our agile Lean practices and our DevOps capabilities throughout the whole team.

The first place we started here was with our flow capabilities. This was level setting the team on our common vocabulary, and really injecting the use of enterprise tools. We use Jira here at Nationwide 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.

My team has heard me say this ad nauseam now: by using and adopting these methodologies, work on our team doesn't exist if it doesn't exist in Jira. Outside of operational work or outages, no work exists unless it exists in Jira. Our drive-bys, our emails, our escalations all have to link to Jira cards, all have to be either active work or in our backlog. Other than that, it just doesn't exist anymore.

As we did these flow methodologies, we hired our TDPs who didn't know anything about agile and DevOps at the time. We had, as you could imagine, lots and lots and lots of iterations of figuring out what works best. We're probably dozens of iterations into boards by now on how we manage our work. But that's okay. That was the expectation we set with the team, that we're going to continuously evolve. In fact, I would fully expect the boards we have today 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 go was developing our product strategies for each of our product teams and really doing roadmaps, not only for our program, but also for our product evolution work, and bringing those things together to help define and really give us those headlights and guardrails into where we wanted to go. We took a few months. We've got some pretty strong product strategies developed now that we anchor to.

The next place we went was managing through metrics, and this was really huge. Once we got our flow mechanisms in place, got everything in Jira, were doing our daily stand-ups, and our TDPs were managing cards and pulling cards, and we started to see releases pick up and more workflow through our system with the same amount of people we had before, we started to say, "Okay, let's figure out how we determine velocity on this team. 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 biweekly releases? How many points are in our backlog? How is our backlog health?" It took us about six months to get there, but now we've got a pretty good view into the work that's happening and what it's going to take to get that work done.

Then we had to focus on our customer centricity. How do we get the feedback from our customers? We've started doing that through micro surveys, and then we're starting to work on net promoter scores that we're bringing back to our teams. We're also doing interview groups. We're doing group feedback sessions really to find out what capabilities, what integrations our consumers need for them to be more effective in serving our business.

Next was priority alignment. I've talked a lot about our backlog grooming and the real critical role our product owners play in there. It's funny, I look at each one of these dots and I could say how it's the most important. But priority alignment was really important for us. Before we went to this product model, nobody had any clear vision of priority. Like I'd said earlier, it was all squeaky wheel gets the grease. Whoever yelled the loudest was where we ended up working. Now with our product owners, we've got very clear priority through our backlog and everything that we're working on. And as you can see here, this is where we anchor to: if it doesn't exist in Jira, it doesn't exist for us.

Then injection of our Lean management systems as well. You can have all the boards in the world, you can have all the cards in the world, you can have great backlogs, but if you're not using Lean management practices to be able to manage the flow of work in and out of these teams, it's going to be very difficult.

Obviously, 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. At Nationwide, from a development center perspective, everybody in the office, lots of whiteboards, daily stand-ups where people are together, we had to really pivot that whole entire thing to be virtual. I think it was a little bit easier for our team because we didn't have that sort of conditioning like some of our app dev teams did. But using our Lean management practices, we were able to use that through using our virtual boards, virtual huddles, virtual stand-ups.

The one thing you'll see missing out of here right now is sort of the DevOps piece. There are some DevOps things that we've been starting to work on in terms of IAM specifically around our test automation. As we start to embrace our CI/CD pipelines in this space, we are using test automation and injecting test automation scripts into our releases to be able to do that test automation. But we're really kind of at the beginning touches of that, at least in the identity and access management space. That's going to be a big push for us coming up this year as well.

So we're 14 months into our product journey. What have we experienced? We have clear priority into all of our active and our backlog work. We use big room planning. We use quarterly big room planning sessions where we drive commitments on 30-, 60-, 90-day deliverables. We've had our fourth session now. Our first one was almost three days. Our last one was a half a day. So we're getting pretty good at doing our big room planning. 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. Our engineers come in, they pull in two, three cards a day. That's what they're working on. Context switching is minimal. I won't say it doesn't exist, because sometimes there are important issues that come up, but it's minimal to where previously we had tons of context switching, and essentially we couldn't get flow through our systems as fast.

We have transparency into our financials. If we think back into that circle, we know where all the money's spent. Not only do we know where all the money's spent, we know where we're spending the money on what types of things, between operations, between capabilities, between external demand, and we've been able to unitize identity and access management. For Nationwide, we picked cost per ID. So we have a cost per identity that we now manage to 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 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, and we can really manage the dials. In fact, last fall, one of the teams came back with a giant backlog and 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 has just been paramount.

So what are the key factors for success that we've seen in implementing the product model? I think it doesn't need to be said, but with any big transformational effort, you have to have executive sponsorship. I mentioned that we had leaders from our development team come over and take over the infrastructure area and help get this through. It's been awesome sponsorship from them. Obviously, 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.

The next one is really big, too: you have to have a team that's going to lean into the change. If you have folks who 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. On our side, it was pretty painful for a number of years. I think the team was really open to finding something that was going to help to make their lives better day in and day out. So that lean into change is really important.

This is probably the most important one out of all. You have to have a dynamic technology delivery professional. That TDP role who manages the flow of work, who pulls cards and does work, too, it's really a unique position, and it really takes a unique individual to be able to fulfill that position. Luckily, we've got a couple of great ones on our team who really dove in. They already had the technical skills. They dove into the agile side to be able to learn those practices and bring them on the team, and they've done a great job.

And 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. 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 in your teams, and we had that on our side. So it's really been a great journey.

One thing that I wanted to come to this group for is talk about help that we're looking for. For us, this is all a new journey. So experience with product ownership, and if there's teams who have used this sort of federated product ownership where you don't have clear product owners, how do you do that? Do you do it through groups? Do you do it through some sort of knowledge-sharing sessions? That's something that we're still trying to work through.

Then really the second one is implementing a TDP more broadly across the organization. Finding the perfect person with that mix of technical and agile skills is super important. On our team, it kind of evolved, but as we roll it out, we are struggling a little bit with other teams finding that right person who can fulfill the agile and the technical things all at the same time.

So I believe that's the end of my presentation. I just want to say thank you to everybody for listening. I really appreciate it. Please feel free to reach out to me if you have questions. I'm on LinkedIn. It is Tod Bickley, and I hope everyone has a great day.