Episode 36: Reorganizing IT to Create and Support Products, Feat. Brian Hart

Jim VanderMey: I’m Jim VanderMey. I’m the Chief Innovation Officer and Co-founder of OST, and today I am pleased to introduce you to Brian Hart, and Brian Hart has worked with us for a number of years, and Brian, I’ll just let you speak. What is your role and who are you with?

Brian Hart: Sure. Yeah. Hi, and thanks for having me, Jim. My name is Brian Hart. I work for Amway and I’m responsible for our external facing technology, things that our customers and business owners use, specifically in North Central and South America, and then a lot of the applications that are used globally. So a lot of heavy engineering software development on my team and making sure that we’re building things that valuable.

So the thing that attracted me to this conversation, the one that Brian and I have had a number of times, is around how IT at Amway has been oriented from what I would call a traditional IT role to one that is oriented around product teams and product development. And a lot of our customers struggle with this idea of I’m building custom software, and I can understand the build process, but once I have to support it, it becomes really, really hard. And I think that Amway has done a better job than any of our other customers in organizing around that, that would it takes to run and maintain the software in addition to just build it. So what transition did you have to go through, Brian, to get you to where you are today?

Brian Hart: Yeah, I can share a little bit of that. You know, first of all, I don’t know that we’re in a better state than anyone else at Amway, but we are in the constant process of trying to get better, and I think that’s kind of a key tenant of the transformation that we’ve gone through is a lot of continuous improvement, you know, retrospect there’s looking back at what’s worked and what hasn’t worked and just introducing that as part of our culture day to day. But, you know, going back to where we started, we definitely were an IT organization that was oriented around projects and projects that spun up and then spun down with a product that came out some type of software, and then not really an effective model for continuing to advance that software, and continuing to invest in it while it was kind of live and being used. And so we had, you know, very much a project oriented organization and structure, and probably about five years ago, we started to make a transition to Agile, and that was what started our transition from projects to products, and that started with kind of cross-functional product teams, different resources with different scale sets. It also required us to engage differently with areas of the business that we were partnering with on building software, and we started out with, you know, we started small with kind of one or two teams in a focused area that was a priority to us and an area that we had, I think, less resistance. We had a willing business partner to start that journey with us, and then over the course of time we’ve, you know, after we had a few successes with that and some other teams saw it, they started to ask questions, and there was almost poll in the organization to go through a similar transformation with other teams in other business areas, and I think that got to a tipping point where most of our teams were then operating, following Agile and very much oriented toward products and [inaudible][00:04:14], and we still have a ways to go, you know, we don’t—I wouldn’t claim that we’re in a spot or we’re done, but we’ve definitely made that transition in where we’re organized and oriented around products now as our value that we deliver and optimizing those with the way that we’re structured.

Jim VanderMey: So you describe the orientation from projects to products, do you still have projects that are in the IT ecosystem at Amway?

Brian Hart: We do, I’d say in two different ways. I think that there is still some work that is best oriented in IT as a project, and by definition, a project is really something that has a defined start and a defined end, and there’s work that IT does that has a defined start and defined end. We need to replace all of the switches in our data center. When those switches are replaced, that project is over. We need to migrate something to the clode. When that migration is done, that project is over. So there is work in IT that’s still oriented around projects, but when it comes to software and building software and deploying software and continuing to advance it, there’s very little work that looks like a project in that space, because once the software is being used, that’s the start of the project, that’s the start of the product when we have, you know, continued investments to make in that, so there’s definitely still project oriented work. And then the other place I would see that we have a kind of a project mindset would be—and it’s not a bad thing—but we have larger initiatives that oftentimes are things that we want to get done as the business, but they require multiple products changing to go through that transformation or to go through that change in something that we’re implementing. And some of those still have some project-like orientation, where we have someone who’s working and coordinating work across multiple product teams, so we still have some things that are structured, like tracks of work that do have a defined start and defined end. That work gets injected into different product teams and their backlogs, and then that work is coordinated, because there are so many dependencies that all have to be met by these different teams. So that takes more of a, I’d say, more of a project flavor in the way that some of that work is managed, but the way that the work is delivered and done is through our product teams.

Jim VanderMey: And so you’re describing a coordination activity that has to occur when you’re dealing with projects that have or programs, really, at an enterprise scale when multiple product teams, project teams have all had to be coordinated at the same time.

Brian Hart: Exactly.

Jim VanderMey: You mentioned your Agile transformation. Did this really come alongside of your Agile process or was it a natural outcome of going to an Agile process? How do you say those two are related?

Brian Hart: You’re talking about the product, you know, kind of moving more towards a product orientation. Yeah. I think we started with Agile without, you know, we started with Agile defining, you know, the first product. Here’s a product we’re going to dedicate resources to it. So there were some prerequisites to getting that team set up, and some of those prerequisites were we have to have a defined product owner, brand new role in our organization. We didn’t have a product owner. We had people who had product owner-like responsibilities, but we didn’t have a clear product owner that was going to prioritize for a product, so we had to have that, that was a prerequisite. We worked with, you know, some coaching and we realized that we needed to have a stable team. We couldn’t have resources that were part-time on a product team, because then there wasn’t predictable capacity. We didn’t know how much we could get done, and we certainly couldn’t promise what we were going to get done for that product and kind of promise an outcome. So we needed a product owner. We needed stable capacity, obviously, the right skillsets on that product team for the product, and those skillsets spanned, you know, people who understood software development testing, you know, design work architecture, so we had to have the right skillsets on that team. And those were all prerequisites for us getting started with our first sprint. And then I think that that really took us forward into once we had that unit, that team assembled, the first team assembled, recognizing that that was actually a better way to organize rather than having, you know, a Software Developer from the software development team and a Scrum Master from the scrum master team, and kind of these independent resource pools that were working on this team, we recognize that putting that team together, organizationally, around the product, rather than just having resources identify themselves as being part of that product, it made a lot more sense. And so it did take some time to evolve to that from just resources on a product to that product team is now distinct and recognizable in our org structure. So that was a transition that we went through, but it’s definitely been valuable for us to, you know, looking back on it now, it was definitely a valuable change for us to make sure the product teams had the right capacity and capability and stability to them.

Jim VanderMey: I know that one of the early projects that we worked on together was the sky air filtration system, the home air quality system, and it was interesting watching the product team evolve through that process. And one of the most interesting things to watch was how IT had to move from being a supporter of the business, to being a co-developer of a product with the business. What was some of that transition like?

Brian Hart: Yeah. That, you know, that project alone, I think, was quite fascinating, because we never really have thought of our IT product being part of a physical product that we sell or being a material component of that, and, you know, any connected product that exists in the market, you know, there’s a value proposition for the physical product and what it provides, in this case clean water, and there’s a value proposition for consumers around that. But the connected nature of that product was a whole another value proposition that was part of the value of that product, and we hadn’t really worked on IT projects that fit that profile, where they were really integrated, and part of the claims around that product about what it could do that it could be connected and controlled and monitored, and we could guarantee that people would always have their filter replaced at the right time so it would continue to produce clean water. So that was a fantastic blend within our organization of not just—not just IT people doing software development, but we had to develop hardware and firmware and things that our IT team traditionally was not involved in. And all of that had to work together seamlessly. So our product team, in that case, took a different shape than some of our other teams, because it included more cross-functional resources, you know, where design and development, which we don’t typically do in IT, but that all had to come together, and, yeah, that was—I think everyone who was on that project loved it, because it was a very focused and dedicated effort, and everyone understood the outcome they needed to achieve, and we had people from various parts of the organization that came together incredibly well on that product overall—both the physical product and the digital components that went along with that.

Jim VanderMey: And the level of complexity that was being undertaken by Amway IT in that moment, when there was a mobile app that was being developed, there was a cloud architecture in AWS that was being developed there, and then also having to work with firmware developers and QA processes and marketing and the design teams. It was really fun to watch, and fun to participate in. And then all of a sudden, the product was launched and you had to support it. Was that— and the IT team continues to support it to this day, right? So how does that get funded then, if I may ask, because that’s always one of the interesting questions is, IT is used to funding projects, but now you’re funding the ongoing maintenance and support of a product. How does that work differently?

Brian Hart: Yeah, so it definitely works differently, again, in a project orientation, you’re funding something, but when you’re done building it, you’re done funding it, in a product orientation, there’s ongoing investment as long as that product is kind of in the wild is being used by people. So we definitely had to make that transition, and you know, we went through our first market launch and then we still had additional development work to do for subsequent market launches, so we kept that team together and they’re still together today supporting the product. And I think, you know, the change in our organization was to look at that kind of funding model for that product and understand it, and be transparent about it. This is what it takes to manage or maintain this product, and there are always new features as well that are being launched, and so the consumers, the people who purchase that product, they’re getting ongoing new value with that product, which is something we could have—there’s no way we could have done that without that product being connected, so in that case, it probably is a little bit easier in that we have active users, they’re getting new features, so they’re happier. There’s increased value to that product over time, because our product team stays in place and continues to advance and evolve that product. So you know, we still have that product team in place. They’re still supporting and sustaining that product and the architecture that’s around it, all of the data that’s around it, and they’re still introducing new features to that based on feedback from our users.

Jim VanderMey: So that’s a persistent product team that’s developing new features and maintaining. Do you have some product teams that are only maintaining, as opposed to developing new or are all product teams doing new work and maintenance work?

Brian Hart: I think I would say all product teams are doing maintenance and new development, and I think it’s based on the nature of technology that is kind of a fact with all of our teams, even teams that are not actively adding new features to their product oftentimes have technology upgrades or, you know, something changes that’s not in their control that they have to react to for their product to still remain viable, and that’s new development work off, and, you know, making changes to the product. There really is no true maintenance mode, you know, stand back and everyone watch the product run, that doesn’t exist in a technology environment. Nothing is ever standing still, and there are things in motion that affect your product, and there are always new things that need to be done as long as the product continues to be used and continues to be available to consumers, there’s always some element of development that teams have to do.

Jim VanderMey: And I think that’s a really important point that you bring up, because you have responsibility for the customer facing application sets and the, what would be considered the outward look. And a lot of traditional IT has been built around what I’d call persistent infrastructures. So we put servers in the infrastructure, we layered on an operating system, we loaded an application, and it could be a fairly static process to operate that environment, but you’re talking about environments that are having to be responsive to something as rudimentary as a browser upgrade or a mobile app, you know, a new release of iOS from apple or some outside interaction in the cloud that you don’t have control over, and so you’re constantly reacting to the technology ecosystem changing around you.

Brian Hart: Yeah, absolutely. New browsers, the way cookies are handled on websites, the way that things are tracked, you know, usage is tracked in different tools associated with that, all of those things are changing. Security standards, data privacy rules are changing, so there’s a lot of change in, you know, in technology in general, so you know, as long as the product is available, it doesn’t feel like that ever settles down to where we have a true maintenance mode. We definitely have periods of higher investment and lower investment, you know, higher investment during an initial build or higher investment when we’re working on some large new set of features, or possibly some, you know, replatforming, rearchitecting. So there are periods of higher and lower investment, but it doesn’t ever get to a point of zero where there is no new investment, no new development happening, and we’re just in a maintenance mode. I think that, you know, if you intend for a product to die quickly, you put it in maintenance mode and it won’t take long, because it will just stop working eventually based on things that are outside of your control.

Jim VanderMey: So you are making a willful choice to end of life of product if you stop maintaining it.

Brian Hart: Absolutely. Yeah.

Jim VanderMey: What’s the smallest product team from a number of people standpoint?

Brian Hart: On product team size, you know, we have this discussion internally, but I would say we have product teams that consist of just one person. Sometimes it’s one person with some, you know, heavier support from a vendor that may have built a product, and so we’re sustaining that product and continuing to make advancements on it, but you know, our products, if I think of a product, they expand from very small teams, and it’s scaled based on the amount of work or demand that those teams are required to deliver. So we have smaller products where it’s one person, they know the product incredibly well, they have the contacts if they need to reach out and get some help with something, they have an ability to scale up capacity if they need to and get additional help, but it’s really one person on our team all the way up to products that have multiple delivery teams, so multiple teams delivering code or doing development on a larger product. We try to keep our teams kind of, you know, min size obviously as one, max size we use the two pizza rule, the two pizza size team rule, which is, you know, we need to be able to buy two pizzas for the team and be able to feed the whole team, so there’s a maximum size to our teams. When those teams hit that maximum size, they start to become inefficient. It takes too much to communicate across the team, all of the work that’s happening, and then there typically are some natural break points in that team, and we end up taking one team that grows and splitting it into two or three or four for a given product to keep those teams nimble and able to react quickly, and not have the overhead of needing to communicate to a large audience with everything that happens with a large team. So that’s kind of how we do product team sizes, you know, it varies all the way from very small one person up to, you know, a lot of people on a very large product split into separate delivery teams.

Jim VanderMey: So in the composition of a team, would you have a combination of designers, engineers, architects, delivery leads, or Agile coaches, or scrum masters? What would be the composition of a large team?

Brian Hart: Yeah. So the composition of a large team, every team has a scrum master, and then kind of the delivery team structure, every team has a scrum master, and then the team members that we have within that team, we look at the skillset that’s needed to deliver that product, whether it’s a certain technology or language, in some cases it’s an architecture, maybe it’s AWS as a cloud architecture, so we look at the types of skills that would be needed, and then we try to create a team that has all of the skills necessary to produce and maintain that product. And our goal in that is minimizing external dependencies, minimizing people that team needs to rely on to get their work done, to the extent that they can be self-contained that they have all of the skills needed to get their work done, and they don’t rely on anything external to their team. They can make decisions within their team that affect only their team, and they can move very, very quickly and pivot and change as they learn new information through their development cycle.

So a typical makeup of a team, you know, we have a scrum master that helps drive the sprint cadence, and works to make sure that the team, you know, they’re doing the daily stand-ups that they understand the work that needs to be delivered, they’re helping remove blockers, and other things within the team, so we have a scrum master that’s part of that team. And then the rest of that team, I would describe as largely software engineers that may have specific expertise in some areas that are valuable to that product, so it may be a software engineer that has a background in testing, automation testing, maybe some of the dev ops deployment processes. We may have someone else who is—knows the language that we need to code in very, very well, they have deep expertise in that, but most of the people that we put on those teams, we want them to have some deep expertise that they bring to the team. We talk about T-shaped Engineers, which means they have some depth in one area, but we could bring almost any work related to that product to any team member, and we’d like them to be able to take that on. That gives them flexibility as the product is developed and goes through different phases. There may be more testing work, one sprint, more automation that needs to be written. There may be some data set up that needs to be done, and we want all team members to be able to be fluent working with data and databases.

So we talk about T-shaped skillsets, so beyond to the scrum master role, which I do think is a unique role within the team, or at least a unique designation for one of the team members, the rest of those roles are people with kind of a T-shaped skillset, some expertise that’s valuable to the product, and then, you know, it scales based on the size of that team, the different skillsets in different areas that we need.

Jim VanderMey: So you mentioned the scrum master and what a scrum master have responsibility for multiple product teams potentially, or would it just be for one?

Brian Hart: In our model, we have dedicated resource on the teams, which means the scrum master is dedicated to a team. Now let’s go through a couple of examples. If you have a team of only one person, who’s the scrum master?

Jim VanderMey: Right.

Brian Hart: Well, you probably have someone who’s running their own sprint cadence, doing some work to maintain their backlog, and actually delivering some of the wor all wrapped up in one person, so the person is playing multiple roles. As soon as you scale beyond that, you get to the point where the scrum master is either a full-time role or nearly a full-time role. And we do expect scrum masters also to participate in some of the work of the team, so there’s no reason why if the scrum master that’s dedicated to the team, you know, they’re managing the sprint cadence, they’re managing their scrum master responsibilities, but they may also participate in helping the team advance other work. So in our model, our scrum masters are dedicated members of our teams. There are some unique circumstances where we may have one scrum master for maybe two teams, maybe three teams at the most, but by design, we try not to do that. The reason why is as soon as you have shared resources across teams, you’ve created an external dependency for that team, and to the extent that the team depends on that scrum master, if they’re busy with two other teams, you’ve created a dependency. Now the team is in a wait state waiting for something that’s outside of their control. They’re waiting for some other external team to release that person to come help them with their sprint or with something that they’re blocked on. So if we have shared resources across teams, it creates external dependencies that create wait states and waste for a team that are unnecessary. If you have dedicated resources on the team, the team has much more control of its own destiny. They can control what different team members work on or how they shift resources around, and you eliminate one external dependency.

Jim VanderMey: I think that’s a really important consideration as people move from a project mindset to a product mindset, because I see a lot of our clients trying to timeshare critical resources, and then it turns into the classic situation where the business says, I can’t depend on IT to deliver on their commitments, and if you’re supporting products now that are part of the, you know, externally facing value, those commitments are not commitments to your customers as opposed to internal commitments only. So I think that’s a—so sounds like one of the outcomes you’ve been able to achieve is creating predictable results for your business customers.

Brian Hart: Yeah, definitely. And that starts with predictable capacity. If you don’t have predictable capacity within a team, it’s very difficult to have predictable output. So absolutely predictable capacity or what we would call a stable team. A stable key team is a key tenant, and it’s not just about having capacity in kind of a person hours available to the team, it’s also having the right skillset, the right people. It’s not true that all people are interchangeable. You can’t plug someone new in on a team and expect them to immediately be at the same capacity as all of the other team members who have years of experience on that product. So people are not completely interchangeable, so stability is the key with those resources. So you have stable capacity and stable skillsets and a stable knowledge base within the team, now you can produce a predictable output. If there’s constant churn where resources are getting swapped in and out who don’t have the right skillset or don’t have the history with the product or don’t understand the architecture of the product, even if you have the same capacity in like person hours or person days of work that can be dedicated to the team, if you don’t have people with the right knowledge, they’re not going to produce the same output, so stability, I think, is key. Without stability, you can’t predictably produce something.

Jim VanderMey: Well, I think we could talk more about the organization of Amway IT, but if you were to—and around product teams—but if you had one piece of advice to give to an organization that was, maybe, looking like Amway, a large enterprise, hundreds of people in IT, and they’re, you know, five years behind you, what advice would you give to one of your peers as how to get started?

Brian Hart: Yeah, that’s a great, great question, and, you know, I’ll probably, you know, I won’t take credit for this advice, because this is the advice that we had, and I think it was effective, so I would simply pass along this advice, but the advice I would give is start small. Don’t try to take on everything in the organization at one time, so start small. Start in an area where there’s the lowest amount of resistance, but also a high probability of being successful. Something that’s strategic that’s important to the organization, and low resistance means you have all of the people that need to deliver something aligned to try something new. You have the right mindset within the team and they’re willing to change and adapt. So start small, pick an area that has low resistance, but also has importance, and then iterate. Make sure that continuous improvement is part of your process. You won’t get it right the first time. I don’t think any team that we have would say, “Hey, we’re done. We’ve really done a great job, and we don’t have any more improvement to make.” That mindset of continuous improvement, of repeating retrospectives, and learning as a team, that is incredibly important for the teams to continue to develop. So start small, focus on an area where there’s low resistance to change and to trying new things. I think that would be some of the advice that I would give to someone who’s starting up or trying to go through some of this transformation.

Jim VanderMey: Good. Well, and I saw work at Amway, and I remember sitting in on product team demos when there was three or four Vice Presidents around watching those demos, and it was clear to the team that it had importance, that they had permission, that they had the ability to try new things, and they had the ability to fail, and then iterate upon that, and learn. I saw it happen and, you know, kudos to you for being able to scale that beyond that first team, and then make it a way of life for Amway IT.

So thank you for joining us today, and I have always learned something from you, Brian, and I think that the lessons that we heard today are broadly applicable inside of a lot of IT organizations. I look forward to hearing more from this in the future, so thank you.

Brian Hart: Yeah, and thank you, Jim, for having me, and I look forward to continued engagements with you as well. We’ve had a number of great discussions about this exact same topic many, many times, and, you know, your teams have been there to help us along the way with a lot of these transformations as well, so thank you, Jim.

Lizzie Williams: OST, changing how the world connects together.