George Kraniotis

All right. It was May 2021 when my group rolled out our product structure to the organization. We had spent the previous five months trying to figure out what this would look like, working with the business and technology, understanding all the customer journeys that we support and the systems to get to that point in May.

My name is George Kraniotis. I am a director of software engineering at Discover, and today I will tell you a story about what we went through as part of the product transformation and the things that did not cleanly align in our new product structure.

First, just real quick about Discover in case you do not know: we are a bank and payment services group, and you can read the slides. The slides will be available to you at the end. You can read this at your leisure, but you can also take pictures, so feel free if that works for you.

Just real quick, our mission, what it comes down to, is to help others achieve a brighter financial future. That is what it distills to if you just boil it down. We are recognized for a variety of different things from a customer perspective, from a workforce perspective, as well as with our technology. Our technology starts with our small autonomous teams and how they work. They work on meaningful activities that ultimately make an impact. The engineers on those teams have a focus on innovation and learning, with access to leadership at all levels.

Enough about Discover. Let us talk about the story and why you are all here.

A bit about our group and what we do. My area, we call ourselves Portfolio. We support our Discover card members. Raise your hand if you have a Discover card. All right, awesome. If you do not have one, feel free to see me. We can get you signed up.

We support anything that a card member can do: submitting a balance transfer, viewing your statement, adding your Discover card to Apple Pay, and everything in between. But this is where we started: a feature factory, where teams moved to the work. Over 300 developers, 200 applications, three platforms, of course we have mainframe, and using scaled agile and quarterly program increment planning, where we got a couple hundred people together in a room and we spent a whole day, sometimes two, trying to plan the next quarter's worth of work. Hopefully, at the end, nothing changed, but it always did.

One of the things that we uncovered when we started in January to plan that product structure was pretty shocking. We found out that over 50% of our applications that were managed by technology, meaning they were running in production and if they went down we were paged out, did not have a defined business owner. No one owned the customer journey. No one owned the business logic that was associated with that. So, over half.

This all started with our new CIO that came in, Amir Arooni, and he had this vision: we need to make a shift from project to product. We had to use smaller autonomous teams that were product-focused because we had to get things out to customers faster and simplify how we work.

The caveat I will say for all of you, if you are either starting, have started, or are thinking about starting, is that this journey is not a technology one, and it is not a business one. It is a company-wide one. If you are going to start on this, you need to have the partnership there from day one. Otherwise, you will not be successful. That is one thing that we did have with our CIO. There was partnership across our entire C-suite in terms of what we were going to do, and so it made the conversations from my perspective with my peers on the business side much easier. They are still tough, but they are easier.

Just a plug: you could scan this QR code. It will take you to the IT Revolution site of a talk from 2021 where Angel Diaz and Sheila Lodi, if you want to go deeper on what we did and what we are doing from an engineering perspective on the craft itself, presented and had an awesome talk around the nitty-gritty details: exactly how are we doing it from an engineering perspective and transforming how they work. Again, the slides will be available, so if you miss it, you can scan it or just go look at the IT Revolution site for 2021 videos.

01The New Landscape

So the new landscape, what does it look like for us now? The first thing we had to do was define what in the world is product. We looked at definitions and Wikipedia and all these other blogs and insights, trying to figure out what the hell is a product, and we distilled it down to two things.

It was either a customer journey, something that a customer interacts with, whether it is the mobile app, the website, or calling in, because people still do that, they call into our call centers. Or it was a platform capability, something that more than one customer journey relies on to deliver to customers. The customer journeys relied on the platform capability. That is what we boiled it down to. It was fairly straightforward for us.

This new landscape had dedicated, persistent teams. They had end-to-end ownership, and they used continuous planning. It was up to them what they wanted to do. Their backlog was their own. There was no top-down, we are going to do quarterly planning and all that stuff. It was up to them as to what made sense given what they were supporting.

We spent this time and we were thinking about rolling it out. At this point it was not quite May yet, but we were like, okay, cool, what is this going to look like now that we spent all this time? This is what we came up with initially. We had product families, which is just a logical grouping of products. The top in orange are all the customer journeys, and underneath it were the platforms.

The customer journey we worked from the customer back. If you notice, as a Discover card member, setting up your account is one of the first things you do, so that is on the left-hand side. If someone maybe starts to not use it, that is re-engage with my card, so we want that customer to get re-engaged. It is sort of the end. Transfer a balance, you could balance transfer at any point in time, and so on and so forth. We had the customer in mind when we built these out.

Portfolio enablement: that was what our platform team was now. There is more than one team in each one of these. Some of them have a couple, some of them have 10-plus. It just depends on what we had to support.

02The Leftovers

Now, The Leftovers. I have talked about why in the world this talk is called The Leftovers. It is not about the TV show The Leftovers. It is not about the food that you did not eat from takeout. It is not about the players that are not good enough to be on the field, so they are on the sidelines.

In fact, when we started digging into it and looking at these leftovers from our perspective, the things that did not cleanly align to one of those product families, we found out that one of them was a monolith aggregator that sent back hundreds of data points that everyone needed so that a customer can log into the mobile or web app. It is not something you could just turn off.

Sending servicing notifications, or even allowing you to change your card, were another monolith that spanned eight different customer journeys and three different product families, and a partridge in a pear tree at that point too.

This is what we initially came up with. But we had 130 people, seven teams, that did not fit. So what in the world were we going to do?

This is a little bit of what they did. We are talking about monoliths. We are talking about on-behalf-of functions that, for decades, were small groups of contractors that did stuff for others in the organization. Again, they did not cleanly align somewhere. So let us look at them as the leftovers right now.

That is when we created a new temporary product family called The Leftovers. We had a hypothesis as part of shifting to this product model: teams needed to own what they did. Our hypothesis up front, and we did not know everything about what was in this leftovers category, was that everything should be moved back into the product teams. This family should not exist anymore, nor should everything inside of it.

03The Approach

The approach I will talk to you a little bit about: how we did it. Pretty straightforward: centralize and then start to shift.

Centralize: we talked about bringing them together in a group. That is The Leftovers. We did not call it that internally; there are people here, and you cannot call people the leftovers. But supporting them with strong leadership. Oftentimes these functions, you just kind of put someone in charge of and say, hey, go run this thing. But we knew there was going to be a big task at hand in terms of trying to prove this hypothesis.

For myself and my engineering manager who took it on, we had no idea what these groups did. We knew about them, but we did not know what they did. So we had overview sessions: what do they do, who do they support, what does success look like? Because we wanted to define some preliminary objectives and key results. Where in the world do we start? This very much felt like we were going to be boiling the ocean, and we wanted to start with something.

That is what it comes down to: shift.

When you are shifting things and trying to give work to other teams, even though it might be good for them because it is a product way, they are not going to want to take it. We knew we had that to deal with. The approach we were thinking about was either we are going to move that function completely because it made sense, we are going to federate it, so break it apart in terms of who is doing it, or simplify it: breaking apart, think about like monolith into more domain-driven APIs.

For us, we started with something small. We had a small team that did lightweight front-end development on behalf of other groups. There is no reason why other teams could not do it. In fact, they were actually making changes in the GitHub code that the product teams owned, and they were the ones doing testing, and the product team did not really know what the hell they were doing. We actually had issues over the past couple of years that impacted our customers, and so this just made sense. That is something pretty straightforward, pretty small. Let us go with that.

We wanted to link it to the broader business effort. That is where, again, the customer impact and the issues we had, we wanted to link it to that so that it could resonate with our business partners. And we wanted to be transparent along the way.

For us, we just used a simple business case. This is a template that we put together, nothing crazy, but we wanted to answer the so what, why is it important, what if we did not do anything? We tried being our own devil's advocate when it came to this stuff because we knew we had to get buy-in from senior vice presidents, from vice presidents, from our peers, from managers, down to engineers and product owners. We are talking across the organization. We wanted to be able to answer this and get support along the way.

04The Results So Far

The results so far, by no means are we done. This is going to be a journey for some time, and we have learned a lot since rolling this out in May 2021 to the organization.

Just a couple things to highlight. The first thing is we have reduced the size of the family by 59%. We were able to reallocate that capacity elsewhere in the organization where it made sense. This was just an operational efficiency from our perspective.

Part of the product ownership is now teams are getting paged out, not some offshore first-level team that is getting paged out and, in this case, was not doing anything. They were just clearing these false positives that are out there. Very quickly, we saw a benefit there within the first couple of weeks.

The thing that was most eye-opening to me was these deficiencies in architecture that have existed because we were a feature factory. Who is going to invest time to work on and address the refactoring that had to be done in a quarter when they knew the next quarter they were going to be working on something else? It just has built up over time.

There are still problems out there. Of course, simplification is easier said than done. You are talking about reverse engineering code that has been out there for decades, trying to figure out what the hell it is doing, then gaining product team buy-in for them to take it on themselves.

For us, we were like, how are we going to do this? We had a team actually come to us saying, you know what, we need to pull our stuff out of this monolith. We were like, great, let us start. We are starting with them to build a white paper that we can go and showcase around the organization around the benefit that it is for that product team.

Then, what is good enough? This is the one thing that is like, how much time are we going to be putting into this going forward? We are looking at some of these components that we are breaking apart, and we are probably going to be able to get 80% of the way there, and the last 20% maybe sits with one product team. That is where we are going to start having conversations with that product team saying, hey, look, is this on your roadmap to take care of it? If not, it is probably going to come to you. Having those conversations about it.

Our hypothesis that we had up front was: this family is going to be gone, everything in the family is going to be gone. Now that we look at it more and we have learned a lot, we know some of those areas where we have those functions are probably not going to go away completely. Maybe they are going to have to live in some other different way within a platform team like the portfolio enablement group that we had. Again, there is a lot of rigor that went through that to test it out.

05Takeaways

Takeaways: when shifting to a product operating model, you are going to have areas that do not fit. It is just going to happen. It is the bits that everyone cares about but no one wants to own. As soon as we said, you know what, we are just going to shut this thing down, we had eight teams that came up and said, wait a second, we still use that.

The thing that works for us is define that hypothesis up front. For us, it was pretty shocking: we are going to basically retire this product family that we set up. That is what we thought initially, and so what needs to be true in order for that to happen? That is what we did in terms of centralizing and then starting the shift and starting small.

Appreciate it. That is my LinkedIn QR code. My last name is hard to spell, so I figured that would be easier. I do have nine and a half minutes that I want to leave for questions from all of you.