[Music] [Katie Brady] Hi, folks. We're going to go ahead and get started. Welcome to Best Practices to Build a Unified, Collaborative Experience Platform Team, which is a mouthful, but we really are here to talk to you about how you create really good teams to implement, deploy, and run your Adobe Experience Platform.
Really quick introduction. Katie Brady. I'm an Enterprise Architect with Adobe. Been with Adobe for nine years as an Enterprise Architect. And as it says, I like to really build cool things with tech. And one of the things that I've learned over the years is that it's not enough just to build. You also want to have really great teams to help you build.
[Graham Sensing] Yeah. And good morning. Good afternoon, Adobe Summit. My name is Graham Sensing. I'm a Principal Program Manager. It's super cool to be in a room where I can say my title and you guys at least can textually know what that means versus I'm sure there are dinner tables and campfires. Like what do you do? What does that mean? So yeah, I'm a delivery lead for AEP projects specifically. I live in Abilene, Texas. And when I'm not on Zoom calls or Slacking coworkers, I'm usually trying to coach my son's little league teams. I've tried to descend my daughter, but instead, she just asked me to be on stage with her in ballet.
This is not the biggest crowd I've been in front of recently. I was a flyer for her in The Nutcracker this past Christmas. Thankfully, it was also not recorded.
But yeah, so team and again, I share that with you to show, but the passion that I have for teams and working as a team, and I try to do that with my son.
Is there music playing? Totally like a party going on in the room behind us. I thought something was wrong with my mic. - Our session just got lit. All right. - All right. I was like, "That's not me, is it?" But so team is really important to me, and therefore, I love being around the sporting events I do with my kids and share that team leadership and coaching mentality. And we share that across into work too. That's one thing I love about being a project manager is that you really get to spend time, coaching, and mentoring, and teaching leadership skills, and growing our teams. And that's what we're here to talk about today.
Really with Adobe Experience Platform, or you'll hear us say AEP because acronyms are fun...
It is a very, very complex ecosystem, as I'm sure you know, no matter where you are in your journey. And it's hard, to be honest. The technology is great. It's super, super cool. But customer experience marketing at scale across enterprise organizations is tough. And that's okay, right? We're here trying to solve problems, trying to figure it out. And so Katie and I have done a lot of projects, some together, some apart for very large enterprise organizations. And we've tried lots of different types of methodologies to deliver projects. We've tried traditional waterfall start to finish. We've tried agile. We've tried all of the funny agile falls and things you can mix up. And really where we've landed across lots of years of different enterprise AEP products together is that landing on the model, a Tiger team model, has been really, really successful for us. And we've seen a lot more value recognized by customers using Adobe Experience Platform.
And so today we hope that you walk away not necessarily understanding the technology better. Although, when Katie talks, listen because she's an amazing enterprise architect and she goes very deep on how the technology and the tool works. We want you to walk away understanding and be thoughtful of, what could I take away to apply to my AEP organization? Where am I at in the lifecycle and the maturity curve of my team's AEP adoption? And what fits my organization best? So why Tiger teams? I'm glad you asked.
So marketing as we see it, is really staffed and organized in columns. We have your outbound marketing channels. You have your now AI/ML marketing teams. You have web content, app content. And all of these teams, typically in enterprise organization is very siloed and organized. You have different VPs, different budgets, different agendas. And so naturally, human organization we organize in these column structures.
Now MarTech is also in these columns, right? So we follow what worked before in traditional marketing organizations hasn't really changed over time. And so we have development teams and QA teams, architectural teams, engineering teams. And so that's the natural evolution. And that's not a bad thing, right? That's how these enterprises have scaled. That's why they're big. We've made acquisitions. Your company may have multiple different dispersed marketing teams coming together through acquisitions and things of that nature. And that's normal. However, our customers as we know, experience us in rows.
They experience us on the app. They experience us from the push notification that we receive. They experience us when they call in the call center. They experience us when they are driving down the highway and see our billboard or watching the Super Bowl and seeing your commercial. And so our customers experience us left to right in these rows.
Obviously, the Adobe Experience Platform is built with that in mind, trying to also expand across said rows, right? And we see the technology, honestly, being ahead of people and processes and organizations. The technology can have that unified profile.
And I said this yesterday, too. I get royalties every time I say unified profile. So I'm going to say that a lot over here. But that unified profile it brings people together. We have a central view of the customer.
We can activate and reach out to our customer across all of these channels, whether you're integrating with VA or you're pushing out and creating segments in RTCDP and trying to push out on experiences on Target or an AJO decisioning, what have you. The technology's there, but people were still in these columns. Our organizations are still very column-centric and siloed. So we want to talk about how we can meet our customers and their experiences in rows. So that's the biggest takeaway, is how are we as team leaders, project leaders, AEP practitioners, how are we supposed to think and execute and build teams that can meet our customers to experience our brands in these rows and not in columns.
So I'm going to turn over to Katie for a second and talk about who's included in Tiger teams and that initial baseline staffing model. Sure thing. So when we think about teams and what it takes to deploy experiences at scale, especially with a platform like AEP, its marketing teams and it's your technology teams. And they're teams that need to integrate together now and not work in separate silos or columns. But you're looking at enterprise architects, data architects, product owners, things like that that own the tech and have the typical technology, responsibilities around SLAs and uptime and creating capabilities for people to use and then marketing teams that want to use those capabilities in creating messages and experiences and creating those really compelling customer events that bring them to your brand.
But what we're asking people to start thinking about is looking at it across as an experience and looking at experience owners across both of these types of organizations. And really thinking through the entire start-to-finish customer experience as they experience the different parts of these channels. And that includes an Experience Champion, which we'll talk about in a second, enterprise architects, project managers, people that are able to look across and drive that from a leadership and a vision perspective.
So I'm super passionate about this. I think this is an emerging role. It is this concept of an Experience Champion. And this is the person that will own almost like a product and experience. So that could be, I own new customer experience. I own loyalty customer experience in the sense of I understand how I acquire and talk to that person outside of my channel, I understand what the conversations I am having with that person when they are in our channel whether digitally or physically, and I understand how to help them get the things done that they need to do so that they can enjoy our product and grow with us, right? That is an Experience Champion. That somebody is passionate about that experience that person's having and understands how they interact with email, how they interact with SMS, how they interact with all of the different ways that you can touch with them. That's a champion.
That role doesn't really exist. We might have-- I'm a champion of homepage experience column. I'm a champion of email marketing column. I'm a champion of A/B testing column.
So we need to talk all the way through that and understand the tech and the customer experience to really understand how to drive that to a really great outcome.
Yeah. So how do we structure these Tiger teams? And we talked about the Experience Champion being a key component there. There's also all parts of the ecosystem. Really to start talking a bit more on the technical talent, we'll go to the maturity curve here in a minute, he'll walk us through. But I wanted to emphasize as well that the Experience Champion, as Katie mentioned in the columns, it's a role that is-- We're used to product owners and product backlogs, and we use the word owner a lot in a PO role. Maybe it's a scrum team. So it is a very different-- It's a similar skill set, but it's a unique skill set that understands the marketing, and the outcome that the business wants to make with marketing, but needs to understand the technology too. So it does require a bit of homework to have that skill set come to life.
Yeah. And so to get there, you're going to go through a bit of maturity curve. And so for those of you that have been with our products for a very long time...
Pre-AEP, you probably had put a piece of JavaScript on a page, and then you could go do what you wanted to do with Target. Some more JavaScript on a page, you could do what you want to do with Analytics that sort of thing. And then you might have some connections between the two. But our products actually also organized you into columns, intentionally or not, but that was the outcome. But over the years, we got asked, "Hey, I need these products to talk to each other. I don't want to replicate things through them." We've had these conversations as in the pre-days. And that's became the evolution of Experience Platform. So now we have organized across-channels and across data, across experiences, and it's time to move people into that next phase of how you organize with that too. Initially, when you start to build with AEP, it may make sense to stay in what we call the squad mode because you're trying to translate what you have been doing into a new piece of technology and stand up some very foundational capabilities. But when it comes time to actually deploy at scale, that's when you come up the curve and you start working across those columns as a team.
So you might see in squads as you start to deploy a data squad, a messaging squad, something maybe some technical folks on your SDK, analytics, decisioning, your audiences, or Real-Time CDP. And those are the folks that are going to grow in there and turn those things on, move from existing platforms that you have into the new platform. They're the folks that are going to really think about how they take what you're doing today into the technology stack. Yep. And I would say real feature and capability focused. Not a lot of use case driven. There may be use case foundations. LA is a Central North Star where you have your MVP use case building up the architecture. It's important to know we're doing our first use case or MVP use case may be an abandoned car experience. And so that helps you have a unified profile, that helps you think through some of that MVP use cases. But really, this team, when you're at inception, is really product and capability focused if we're being honest with ourselves. Yep. All right. But then we get into a place where we're trying to run and operate that, right? You should have a full catalog of capabilities, that choice of people coming in and being like, "This is the thing I need to do, and this is what it maps to from a capability perspective." And that's where you'll see individuals from these different squads that fit into these teams to go solve a activation use case. And then, you'll have your leaders of program managers, enterprise architects, Experience Champions as part of that overall umbrella looking across everything. And this is really important because that helps you also scale. If you have somebody that's in a squad all day and they're waiting for that Jira ticket to come in and they're going to answer that thing in the Jira ticket and they're going to pop it over the fence. And they're going to answer that next Jira ticket and they're going to pop it over the fence. They're not thinking holistically about the whole thing that they're trying to build, but when you have five people that are just really trying to get into there and build an experience together and they're interacting and talking, they're going to get ahead of those problems. They're going to understand the experience, and they're going to build faster, iterate faster, and get to production faster. That's right. That's right. So we're going to play a little game here with Katie. And we're going to talk through some example experiences that you might can implement within your AEP stack and talk through some of the staffing that may be included so you can think through who's needing it for what type of skill sets we need for these use cases. So we know we have the product squads. We've already talked about the foundational capabilities. And so you still have those product owners. You still have maybe a lead data architect, a lead campaign or AJO consult, sorry, practitioner. But you also then have the design leads. And this is where actually Katie and I have sat in most of the programs we've led and a partnership from a lead EA and a lead program manager that's working through the staffing of each of these components to make sure that we're all following the North Star architecture. We know who's doing what. There is a leadership vision there. But yeah, we have these three experiences that we can talk about. So from an A/B test experience, Katie, we see here that we have fit staff with the various headcount for these various skill sets. Who do you see staffed in the A/B experience and why? So when you think about A/B experiences, if you're trying to say, "Hey, as part of this customer's journey, we're trying to really understand what the right path for them to be on because we're trying to learn things or we're trying to understand what the type of content that they're responding to across that experience we want to do." So you're looking at people, "Hey, I need to pull data in either from data to qualify people for that experience or data to collect and understand how the performance is going to work from that." SDK to make sure that you can actually do the testing on those pages or in the app screens and go make sure that that's working. Customer Journey Analytics to make sure that you can do performance reporting. You can deploy experimentation panel. You can really get in there and do some really neat attribution.
Decisioning squad to make sure that you are creating whatever AI models that you need to do for optimization, Auto-Target, depending on the toolset that you're using, and then Real-Time CDP to really understand the audiences overall that you're going to work with. And so this-- And I want to be really clear about this too. Those aren't necessarily individual people. Those are skill sets. So be really clear about that too because I don't want you to think that you have to go hire 100 people to staff all of your different teams. It's really about who do you have that has a skill set to go and deploy on that experience with those capabilities. That's right. Okay. Next one, real-time triggered push notification journey.
So again, it gets really similar, but this shows how we can swap people in and out based off of what we're trying to do. And so what you're really taking in is real-time push. So it's your messaging, right? It's how do I message people with the right experience at the right time based off of what they're doing and the qualification of it? So you're still looking at data. FYI, you're probably always going to have somebody from data. It's super, super important. It's a really great skill to invest in. Your messaging squad to think out not only does this message from a creative standpoint meet the objective of what we are trying to communicate, but also looking at things like your overall metrics and messaging deliverability, things like that, and making sure that that's working really well. And then you have analysis. You should always, always, always think about how you're measuring performance and building that into whatever you're doing. And then your Real-Time CDP again for audiences.
Okay. So this one is-- I'm going to ask you actually to find cross-channel experience. Was a cross-channel experience to you? Because when I hear cross-channel experiences we see it on Keynotes. That is the end goal, right? What is a cross-channel experience, and how is that team different, or what's the goal there? So to everybody.
That's what we're all trying to get to, right? This has been the vision, and we've all achieved it in pockets with varying levels of success either on channels or across certain customer groups and different combinations of that. But it's really of meeting the customer where they are, when we're supposed to meet them with the right message, right? Whether that is first they come to us on a nap, and then they come to us in a store, or they call into a care center, or they come on through digital channels and come back around. That's cross-channel with the right message, orchestration, getting them through a journey. That's how you do it with cross-channel. That's probably going to take roles across every one of these products to go do that very, very well. This is where your Experience Champion shines. This is the person that's really going to come in there and drive that experience and those interactions and give you what you want as far as that overall cross-channel experience. And they are also going to understand all of the places of fallout, all of the places of reacquisition, bring them in and talk to those teams, and talk through all of those scenarios. But you're going to see that every one of these roles becomes very important as part of that. Yep. And you'll notice here we added actually the Experience Champion and a project manager to each of these Tiger teams because that's how these teams are going to move across. Yes, you can have stories and Jiras and epics that systemically move things across, but we'll get to the communication strategy here in a minute. But it really is that at kickoff, at inception of this Tiger team, don't think my data architect is a data person and they just want requirements, and they can be a really expensive keyboard to build the data scheme like I want it.
I'm picking up data architects as an example. But that skill set should be at the kickoff and at the inception of discovery. You need that voice in the room because they're going to ask different questions than maybe your business requirement...
Your BA may capture. Same for the person who's building the audiences. They need to understand what's the business use case. They can probably provide some insights and practitioner consulting to your discovery session or your kickoff session. And it needs to be done as sharing is caring, right? It needs to be done together. So this is the team staffing model that I think you want to have actually at inception and kickoff of the Tiger team meeting because you're going to need to have that continuity as you move left to right throughout the project.
So how do we operate and communicate effectively as Tiger teams? We're in these big organizations. Again, we're structured in columns. We're trying to talk through rows. So let me ask you a question. If you were to pull out your phone right now, you may already have your phone out. But if you're pulling your phone right now, is this your calendar? Does it give you hives? Do you have to take some Benadryl on Sunday night because Monday just looks like it's going to be miserable? Because as a project manager, nothing gives me more anxiety than seeing this on Sunday. You're double booked. You don't really have a rhyme or reason. Your priorities are driven by your calendar. So if you think through a Tiger team structure, if you're having your team being driven by experiences and not working just in our silos, you can have a bit more sanity.
I have worked in project teams where we've had months of high velocity output and success being structured in a very rhythmic and drumbeat cadence because we knew who was meeting on Mondays, who was meeting on Tuesdays. And it's very operational and rhythmic of, "Hey, I don't even have to go schedule this ad hoc meeting with that person because this thing's on fire because I know every Tuesday and every Wednesday, I meet with this skill set or this team." We have this session. I can get the update there. We can have our priorities drive our calendars. And better than that, we can have our customer experiences and our brand priorities drive our calendars, then our calendar's driving our focus. That's just one of the fires. And I just want to-- That first calendar was I'm pretty sure he screenshotted my calendar to bring that up. And I'm an architect. Like that's ridiculous, right? Most of my time is supposed to be around thought leadership and design and thinking through how to solve really big problems, but it was meeting, meeting, meeting, meeting, meeting, meeting. And we have seen this too with our other customers, as they go through different industries. This comes up again and again and again. It's too much. We don't know how to manage it. There's pulled into too many places. And when we start helping them organize around these Tiger teams, it starts getting more meaningful. They have better prioritization. They know how to think about things. They know how to address when problems are going to come up. And they're also using offline communication channels a little more effectively as well. Yep. So we see people being able to breathe again, which is just super important because you're going to come up with better solutions and better experiences. And if you're in meetings 8 hours a day, 9 hours a day, 10 hours a day, when does the work get done? When does that experience actually get built and deployed? So this also frees up your teams to be able to know that this is when I report in, this is when we collaborate so that I can go do the work that I need to do. Yep. And if you're in the room and you're more maybe in the director level or executive level and leading the entire MarTech stack, it also lets you know how to prioritize where and when you can lean in, right? You can know, hey, I know on Tuesdays-- I don't know? You can base your priorities around the agenda that's already set. You know where to go to when. So how do you do that, right? This is just a screenshot of a fake calendar. It's not really super helpful. And so there's an expectations framework for each of the parts of the Tiger team ecosystem. So again, I'll pull up the org chart there just for reference because I'm sure you memorized it.
So from the Experience Platform team, the holistic all in the entire box, we do want to have community together. Sharing is caring. Tiger team A needs to know what Tiger team B needs to know what Tiger team D is doing. There may be common risks, common issues, common needs for capabilities and features that are backlogged. And so there is a scrum of scrums, what we're working on, who's doing what. That brings the whole team together. And so I found a cadence of two times per month was successful for products we've worked on together at that level, right? There's also that can give you a chance as team leaders to push information down to the team at whole all hands, if you will.
And you can manage risk, and you can also from a manage program reporting. And so from that perspective, maybe as the MarTech director or the marketing director, you want to know the roll up of all the things that are going on in the ecosystem. And so that's going to be reported on at the experience level. So when we talk about status reporting, I no longer have statuses that are going out into the organizational leadership of, "Hey, here's all my Adobe Journey Optimizer backlogs and status and risk and issues." I no longer have the data ingestion team reporting off a project status of we're in yellow because these data elements we can't get, and here's blockers in the ecosystem preventing us from loading this data at the velocity we want. We're no longer reporting projects based off the capability in these columns. We're reporting projects based off the experiences. So experience A is your project. So a risk there may be the data that's unavailable, or the staffing that may be limited or a requirement you may be missing. But you're reporting your projects at the Tiger team level, and that's rolling up to your program, right? From the design teams so again, that's the chair that Katie and I sat on. We're a bit more agile because we're team leadership. So we need to know the North Star architecture. We're governing all of the priorities of the entire ecosystem. And so some expectations that we have are...
If you feel the word RMO, like resource management office, but there's some staffing that we need to be involved in, like the exercise that we prebuilt a few slides back where, "Okay, this new experience is coming in." Who do I need on that project at the kickoff? Do I need a data architect? Do I need maybe a few data architects or a data engineer because we need to integrate something new? Or do I need somebody who can build V8 campaigns because it's going to be something that's going to go out in batch to end users, right? So if you think through with an architect's perspective, understanding the requirements and the Experience Champion, you are defining together what's the staffing model and for each of the Tiger teams. And that also allows you to know what's your capacity. How many experiences can I do at one time, right? You can look at it from a whole program view. And I just want to add to this too. It really does scale really lovely because at one point, I think you and I had over 90 people that were deployed across different teams that we knew what was happening at any point in time, and we deploy this into another place. At one point, I had over 100 architects across multiple Tiger teams that I had to know when I could go in there and help and when I did need to help. And this structure, from a leadership perspective, really helps you understand what's happening and set expectations instead of having to go and read all of these individual reports and figure out how they all tie together and connect together. So it was very nice.
From the platform teams-- Sorry, from the experience Tiger team perspective, you're going to manage that more as a traditional waterfall project, to be honest. And that's because, again, we're reporting our projects based off the Tiger team, based off the experience. And so you are going to have standard kickoffs, and we'll get to that in a minute, like what's the ground zero expectation framework you should have for a project, right? When I say SDLC, software development life cycle, and so or SLDC here, as that typo kindly points out. So you're really thinking through more of a traditional waterfall project. And so you do have your project manager and your Experience Champion and that assigned resources that your design leads have pointed towards you to walk through that project from kickoff through build, testing, and launch.
Something else that we found really fruitful, again, working with global teams and maybe it's Slack, maybe it's Microsoft Teams, whatever your messaging medium may be we defined for each experience a singular channel. Yes, your developers may break off and want to talk something very code friendly or the marketers may have a different objective to talk over here about KPIs. But holistically, we have one channel because there is messaging fatigue. Just like our calendars may be everywhere, your notifications are probably also going bananas, right? My mom does not understand why I don't always answer her texts all of the time. It's like, well, because you're one of probably 200 notifications I may have gotten the business day, right? It's overwhelming. And so by having one channel, it does a few things. For your project leaders and your team leaders, I know that I can go look on one channel and catch up on the coffee conversation or the issues that may be happening, but also reduces the need for follow-up conversations about follow-up conversations or, again, meetings about meetings and having a meeting because I wasn't in a meeting. And so, honestly, the discipline of one channel and you may see a channel break out. No, no, no, no, no. That's had this conversation. This is interesting. Let's move it to the project channel. It sounds so simple and elementary, but it reduces communication cycles. And so it's an expectation that you can set for your team that we've seen have a lot of value on communication.
And so your product squads here in the far right don't go away per se, right? You still have practitioners who are very good at learning their products and going deep on data architecture or audiences and taxonomy or campaign building. And that's okay. And that's how you have to staff our teams. We do have to respect the columns from which we came, right? So we're not going to be able to change the whole organization, but it's more changing how we think and work together.
So I won't dive into this eye chart here, but here's a little artifact you can take away with you of a traditional project communication plan that has been very effective. And so here, we do mention things like the Tiger teams. We do talk about offline messaging channels. We do talk about the Tiger teams are working as standard projects. But then we also talk about how that rolls up to the design level and the program leadership and the overall experience view, that you get with AEP.
So going further into the expectations framework and how your Tiger teams and your experienced projects should think and work together. And so, again, I mentioned the software development life cycle. So you do have traditional project management gates here. And there's nothing more boring than to talk about project management gates. But being one, I couldn't help but resist not to do it. So there are initiate and design phases. There are build phases, test and deploy phases. And so when you're in initiation phase, you have to have the use case defined, right? There are some capabilities and features you may know that you need that are ground zero. But don't have that experience kickoff until you have an Experience Champion identified and the requirements centralized. And so you do not come out of that initiate phase until you have that set up. If you're trying to kick off, we want to do this A/B test here, and so we start building something together, but we don't have that Experience Champion who understands the business value and the KPIs, and also the requirements of how that experience, what it looks like not only on this channel but across all of the channels, then you'll never receive the return on investment that you're hoping to get.
And then also in the project manager to set up the communication plan and then expectations that we walk through. In the define and design phase, similarly, you can double-click on that. So again, at your kickoff and through your discovery sessions, you have the data architect there. You have the audience management team there. You have your campaign builders there. And so they're all there at the define and design session to double-click on the experience that that experience owner wants. So the experience owner isn't a technical SME. They don't know how to do all of the tricks of the trade, but they know what they want to see on screen at the end of the day. And so the BRD is a lot level deeper that allows your team to know what they're building, how it's building, and can be blessed by an enterprise architect to know how it's going to work together.
And I'm going to just get through these very quickly.
Everybody knows what building and testing and deploying is of getting to the place where you can actually go into production.
What I want to say is, though, these are not separate things the way that a lot of people handle them. I don't want somebody to initiate and write some requirements and then put it in an email that another team comes together. I want the same people across everything. I want them to all be very clear on what success is and isn't...
And everything gets filtered through that criteria of what we decide to design and what we build. Because when you build, things come up, right? And you have to make decisions. Is this something that's going to prevent us from shipping or not? Can we still get to what we're trying to do in objective or not? When you go into testing and deploying, is this a critical thing that breaks an experience? Or is it just we can get there, and then two weeks later, we can follow-up and get to where we wanted to be, right? So if you understand from the start what the goal was and you really get it and you have that champion that's championing it all the way through, you can speed through those because you spent so much time really understanding upfront how you get to success at the end. And the selfish goal of reducing meetings about follow-up meetings and right. Yep. There's just and I have people will send in meetings to me all the time, and I was like, "What is the success?" And everything else I don't care about. What are we trying to get to? And then we'll figure everything else. But if that's really clearly defined of what that looks like, then we can get there very fast. But you have to have a champion that really understands that and holds on to that all the way through these stages. Okay. So that's how you run-- That is an example of how Katie and I have had success running Tiger teams and building AEP programs at different states of maturity curve and getting value back to not only our internal stakeholders, but also to our customers who have a better opportunity to experience our brands. But there's something else too we wanted to cover here, and that's a huge key to success. And if I can say something about the team that I've had the opportunity to work with, or who I'm sharing the stage with today, there is something to be said about knowing your neighbor. So again, our human nature is to be very column-centric. I'm a messaging person. I build emails all day. I can build campaigns until the cows come home.
I don't have any cows. But the point is, if you actually know your neighbor, if you can look over the fence, "Okay, I'm a messaging person. I build campaigns." But how do the segments, how do the audiences built that I'm ingesting? What if I understood that a little bit better? What risk could I mitigate? Or how is the push notification that I'm triggering, how is that integrated with the app? What if I knew that a little bit better and could understand the architecture a little bit better? I don't have to be a deep practitioner in that skill set, but I understand how my neighbor's receiving the campaign that I'm sending their way. Or if I'm the data architect, how do I understand how the campaign's going to be activated? Does this need to be real time? Well, why? Is it going to be activated through AJO? Is it going to be activated through a target campaign? If I understand those intricacies and understand how target works a little bit, or how AJO works a little bit as a data architect, I can be more effective on how I am thoughtful of what questions I ask, the schema I build, etcetera.
And so I've worked with a lot of-- So being part of Adobe Professional Services, obviously, we have a lot of people who are very close to the product. And our clients always ask of, like, "Hey, when we have an issue, your team can debug the issue and get to the root cause of the problem really, really fast. But then when I have my team, I'm trying to train my team to do that, you know? They may can build campaigns all day long, but how are they understanding the issue?" It's like, well, because and we're training our team members to know your neighbor and to understand, well, that campaign consultant who's going to be working with Adobe Professional Services, they're looking across and understanding how the audience was built or how the data is impacting that. And so there's a velocity that you might be experiencing with your partners, but you're having trouble getting that adoption within your own organization. And it's because you really need to spend time as department leaders encouraging your team to cross-train.
I'm a huge basketball fan. It's my favorite sport, my favorite hobby. I love everything about basketball. And I was reading this book called How Basketball Can Save the World by David Hollander. And in there, he talks about something that really resonated with me with this takeaway here, which is now in the modern NBA I know you shouldn't use sports metaphors, but I'm going to throw the Hail Mary and go for the green here.
So I don't want to isolate anybody. But in the modern NBA, where I know that the best players, LeBron James, Nikola Jokić, Giannis Antetokounmpo, which that was the biggest risk I took on stage was saying his name.
These guys are positionless players. They're no longer just playing center, playing power forward, playing the shooting guard. I'm just a shooter. That's all I do. The best players with the best teams, they're all positionless. They're all rotating. There's no longer five positions on the floor. They're playing all five positions, and that's with the teams that you're seeing rise to the top and players that you're seeing rise to the top. And that cannot be more true as is with Adobe Experience Club. I'm going to add on to that. So I lead a small team of enterprise architects, and one of my requirements is you should be able to build something in every one of the products and platform. Any one of the people that report to me can build an audience, can build a campaign, can load data, understand we're not going to build great content. Sorry, we're architects. But we understand how to go build that within the solutions and deploy it. We can hands-on keyboard to get there. And that's really important because then we understand the implications of the decisions that we're making as part of that. Yeah. So to wrap things up...
The important part that the things we want you to walk away with, to takeaway from here is, we know our organizations, these big enterprise-level organizations are organized in columns. We must work in rows. We must think through experiences and not just capabilities. So therefore, we have Experience Champions. We know that we are going to organize our technology groups in Tiger teams that support these Experience Champions that are based off rows and not columns. And then again, knowing your neighbor, being positionless as department leaders. If you can encourage your team and invest your time and money, you'll see a huge ROI and velocity of output from your team by understanding the entire stack there. So by doing these things, we've seen customers, we've participated in it, we've watched customers go to maturity, and they've actually received the value for themselves, their stakeholders, and their customers. - Thank you. - All right.
With that, we do have time for questions. Yep. Thanks. Thank you. [Music]
