 It's time for the panel and to moderate the panel today I'd like to introduce my my my colleague Dave Lansbury, who after many years as CTO is now the chief digital officer for the open group. Dave oversees the development delivery and implementation of digital independently use standards and this of course is key is digital standards can be best used together to accelerate the adoption of digital practices across an organization. Facilitating sustainable and enduring value. You've seen our speakers so far and we're running a little behind. So I'm just going to stop there and hand over to you a warm welcome please for Dave Lansbury chief digital officer. Welcome Dave. Great. Thank you Steve. And if I could ask all the panelists to turn their video on and unmute. We'll get started with the questions. I will also note that some of our panelists have answered their questions in the Q and a will will skip those answers, but please take a look there. While we're doing this and we'll try to get to as many of the questions as we can. So I think our first question. Relates to the skills needed and how people move into some of these new roles that have been described. So do you think that product management methodologies like agile and strong and maybe even PMP are evolving fast enough to Continue to be relevant alongside the product management teams, even today's volatile uncertain and challenging environments. I can go first maybe having There's still big separation between product management acumen and what would be considered in regular IT all these roles that you have. I've had the benefit of working in both roles, you know, a true product manager and a true person of some sort. But I still see a lot of disconnects when you go to, you know, these, these IT frameworks and practices, you don't see a lot of product thinking and I think we have a ways to go on both sides Frank and but but the good thing is. We're aware of it. We're here to help shape the future of how we bring these roles and acumen together and simplify things to be honest. I think we can scale and do this better if we are simplified and product centricity is going to do that. Any other thoughts on these skills. Yeah, maybe I can respond to that. So if I look at frameworks in the market, they might not evolve that fast as we would expect it. For example, a lot of frameworks are not that product centric. A lot of them are like Scrum and DevOps, they look at the product, but then they don't look at the product at scale. So they say at the same with the skilled agile framework, they have good ingredients, but they don't look at the portfolio of your services and products. So, so I think that there's always some lagging behind because it's it's probably a combination of the people just take part of the best practices and implement and then figure out what's best for them. And based on that feedback, maybe the practices will change again. But I think the most important challenge I think still is that we got so many product owners or managers we need. And we probably has difficulty to find the right person because a lot of times agile and DevOps teams, they believe that have the kind of a superman or a superwoman kind of a product manager, which in reality, that's not always easy to find those with all the skills combined. So hopefully it fits in the DevOps team as a whole because the product manager does one person in a team. So it's also important to understand the role of the whole team with all the combined skills and maybe that's even more important than just a product manager role. Right. It's having the right skills in that team or in the in the cluster. Yeah. Yeah, definitely all of these new capabilities that are needed new competencies and really stretch our traditional set of skills that we've hired for four years. So, next question I think, and this was targeted Charlie, but I'll open it to everybody. You comment on how to include the development of business and business architecture like new processes and new organization capabilities in the presentation approach based on that was focused on DevOps and product teams. How do you how do you see that transition? Well, since it was directed me, I'll take it. I mean, certainly, you know, former E a practitioner here and I've thought quite a bit about this. I think that Rob, what I saw Rob's presentation. There is definitely an analog between business architecture and the overall product value stream conversation. And I think that the skills are readily transferable. I think that it's going to be a challenge for some architects to maybe adopt a bit more of a market facing stance, but there is still internal challenges that might be reframed as product management. But at the end of the day, it's still the whole question of, well, are we doing this in an effective way in an efficient way? Are we managing risk appropriately? Are we redundant in our offerings? Is there a opportunity to factor out shared services or a common capabilities, common platforms? Are we overextending ourselves? Do we have too broad of a, is the security perimeter getting unmanageable because we've allowed too much proliferation? I mean, right now there's a lot of focus on independence and autonomy, but this is a pendulum and there's no way that you can allow infinite autonomy amongst the product teams. Sooner or later, you will have the very well understood problem of too many, essentially too many suppliers. And so I think that there is, you know, absolutely a lot of commonality here. I think that for the average enterprise architect or business architect, there is a rich, rich motherload of thinking to be found in product management. And if you have not explored product management, you need today to go out and acquire some of the material by, say, Melissa Perry, Steve Blank, Marty Kagan, Jeff Goff Elf, Eric Reese. And these names aren't, you know, they're not the usual suspects in the EA space. And yet for my money, you know, the intellectual leadership has really passed over there in many cases. And so it's super important for the practicing architect to be very well versed in the product management discourse today. Any other thoughts on this? Justin, you're looking thoughtful. I'll pass on this one for now. He hit everything I was thinking about. Okay, good. So we have a question here. We talk about agile quite a bit and agility and having that learning organization. So innovation and being able to test and deliver hypotheses about new potential digital products and how you need to shape those to address market problems is a key capability. How would you relate this innovation and testing and learning to the digital product management profession? Yeah, just from a product management point of view, I think what happens today is you can, you know, be in a large organization and get an idea for a product. You have to convince, you know, leadership to invest or try that product out. And we're seeing more of a sharp tank approach to that even internally to say, okay, let's give you a little team. Let's go try this idea out and see what happens. But they also have to kill the product if it doesn't work out for whatever reason. If you find that the market is too entrenched with other players that you're not, you know, familiar with or you find that there's some limitation in what you're starting with, right? From a platform perspective, from a skill set perspective, most people can start a product company in the garage and that's really where a lot of these big companies have come from. I've worked for one Dell down the road here in Austin, literally started in Michael Dell's garage. But the point is, you know, you could start with an idea and develop it on your own or outside your company or leverage resources internally. But I think that that scale, as you start to grow, you have to figure out what, you know, you've got new players, you've got to answer to customers, but investors. But we're willing to kill those products if they don't work out and be, you know, apply those agile principles of trying things iteratively. If it doesn't work, change course. If it does work, you know, continue down that course. But that's really the print. I would say the key to digital products that we didn't have that in physical products alone. Yeah, no, I would just. Okay, I'll just quickly add something to that is the digital product lines give you an opportunity to kind of foster that little bit of competition so that you can see who your digital Wildcats are. They're going to step up and really make the best case. So the product line manager can foster and drive a lot of that competitive thinking internal to the product line, trickle that up and start, you know, really being a little bit competitive to see who can make the biggest, most impactful value case and pull that next round of capital investment and then execute successfully on that. So it's having that multiple layers of, you know, creating, you know, driving innovative thinking, but also having some control around it at different levels to say, yeah, this wasn't quite hitting what we wanted it to. Yeah, just, yeah, similar. So innovation can be on different levels, even within one product team, but if it's a new product, of course, there is not yet a product team. And then you come to the product line, indeed, as Justin was saying, in some cases, maybe it's outside of the product line goal because each line has a kind of purpose in life. And so that maybe you need, and then I think it's a good question, whether you do new things, startup models, so that you can accelerate, like quickly assemble a team, they create a prototype, put it in the market, but at the same time you want to make sure, and that doesn't sound maybe very agile, but you want to see how does it fit in my overall product portfolio. And because my other customer needs to recognize this as well, does it fit in your portfolio and does it fit in my customer journeys or not, but those kind of trade-off you make. And I see that a lot of organizations that it's not about how fast you can deliver, but how fast you can decide, because typically you have a nice DevOps team that can deliver fast, but maybe it takes you three months to get funding and even have agreement to start on this. So I think it's good to investigate that as well. How do you make that kind of early, like lean startup model in your own organization, some areas, to make sure that you can do that quickly if needed. I want to pick up on a theme that I've seen in pretty much everybody's presentation about the interaction between teams and the need to recognize that the economists and agile teams are kind of the building block of productivity in these organizations. And this is a way we see a lot of organizations struggling to get this right. You know, how do we standardize the ways of working and the tools that support those ways of working so that there is the ability to develop the organizational capabilities, or do we just let every team, you know, decide for themselves, how do we balance that. And Charlie, you mentioned this idea of the skilled resource, how to manage a skilled resource that has many touch points. How does that fit into this? It's an enormous problem, Dave. And I would absolutely say that, I mean, one of my favorite quotes from the Spotify retrospectives that are out there is that the, you know, there's a former Spotify employee. I can't remember his name who's got a fairly well, well, well read critique of Spotify out there. And he said, one of the problems was that every team at Spotify invented its own coordination protocols. You know, whenever there was a need for two teams to interact, they reinvented and reinvented because hey agile. You know, that's dumb. And it's ineffective and it's inefficient, and you're going to lead to drop balls. It's going to lead to all kinds of things. It's why we have a whole section in the digital, digital practitioner body of knowledge on work management and a section on coordination. You've got to look at the coordination channels and you've got to look systematically at them as I talked about in my presentation. We know that when coordination implies a queue, a wait state that this is when pain arises. Well, we need to be honest and direct about this. And this is when, you know, the agile folks in the room will start pounding the table and say, we can't afford the cost of delay. And in many cases, they may be right. But then we need to say, well, that doesn't mean that it's simply carte blanche and everybody just goes back to, you know, reinventing the wheels. We need to look more systematically at this as an organizational problem. And there's a wide variety of options that I think we need to empower service owners with and I talked about those in my presentation. I won't recap that here. But I definitely think that coordination remains one of the outstanding issues in the modern digitally transforming organization. Yeah, Charles, you're absolutely right. But I see organizations that have done a DevOps journey for, let's say, four or five years, they start with the model, the teams figure it out themselves and they implement their own ways of working. And after four or five years, they suddenly realize that to gain the speed for the whole enterprise, they need to scale also the standard ways of working. It doesn't sound very baby agile, but the standard ways of working, it can be considered like platforms because they enable teams to deliver faster, but it depends on the maturity of the enabling teams, right? So for example, if I want to deploy something quickly, then maybe if there are standard patterns, I as a team don't need to figure out how do I get security access firewall to change is getting access to infrastructure. It's all standardized, but I need to comply with some compliance issues, potentially. If you want to develop a new product on Azure as themselves, if you want to develop a new product on Azure, at least they need to make sure it can be put in the catalog. It can be charged for it can be built. So there's a lot of standard reusable components where you as a team should use, but if you use it, you can also accelerate your delivery into the market faster. So it basically having a standard platform enabling which I see as a standard ways of working as well, right? They deliver kind of standard ways of working that enables the team to deliver faster and better. And I'm assuming they are the right platforms. And that's what people don't believe, right? The team start. It's about trust as well. How good is the because they don't have a good experience with in the past when you had to create an API. You go to an API platform team that's a typical team. You have to wait three months to get your API implemented. That's not how people want to work, right? So that's probably where if it self serves a self help, it will work. Well, I'm afraid that we've kind of run out of time for our Q and I would invite all our panelists. So thank you. Invite our panelists we can leave these questions up and if you want to answer them in the Q and a please do so. I just want to thank my panelists, you know, Justin, Charlie, Rob and Mark for this.