Ep27 Interview with Chris Millar from Adobe

[00:00:00] Speaker A: In six months, we basically went from zero lines of code to an architecturally sustainable foundation that could power all of these sites. So, millions of pages. You're listening to Arbry Digital Experiences podcast where we're on a mission to simply explain the latest advancements in digital experience management. Today we're joined by special guest Chris Millar from Adobe Systems, architect of the Edge Delivery authoring solution formerly known as Dark Alley, and. And now onto today's episode. [00:00:31] Speaker B: Welcome to Arbor Digital Experiences. This is episode 27, today's super special. It's the day after Christmas and we. I'm joined today by Chris Millar, who is his friend and we've been working together for a little while now on, on. On the future of, of fun Adobe stuff and, and, and especially as it comes to content management systems. So thank you for, for this post Christmas episode, Chris. [00:01:00] Speaker A: Yeah, I'm excited. I think this is like almost a year in the making, right? We've been, we've been wanting this podcast for about a year and maybe, maybe 10 months if we're being a little. But, but yeah, this. [00:01:13] Speaker B: I think so too because, I mean, I wanted our first site to go live before, like, like, I wanted that to be successful before, you know, bringing it out into the opens. [00:01:21] Speaker A: But yeah, I'm in the same boat. Like, it was like, let's get you live. And then, and then let. And now I'm talking. That's right. [00:01:30] Speaker B: That's right. [00:01:30] Speaker A: Got a few more sites live along the way. [00:01:33] Speaker B: Just a couple. Just a couple. But, but before we get into that, why don't you just give me a quick intro on. On who you are and what you do. [00:01:41] Speaker A: Yeah. So my name is Chris Millar, as you said. Pronounce it like. Like you're a pirate. And so my official sort. So like, you work at a big company, you have all sorts of fun reporting structures. My official reporting structure is adobe.com, so I actually roll up to adobe.com leadership. Edge Delivery and adobe.com have always had like a very symbiotic relationship. So I've been building Edge delivery sites since 2018. Arguably, I'm probably the first Edge Delivery customer in the sense that, like, I have a GitHub repo that I made in 2018 that said Helix on it, because Edge Delivery was originally called Hel. And 2020, we. We essentially built blog.adobe.com in early 2020 as kind of like a joint venture between the Edge Delivery team and the adobe.com team. And then I think as. As we started to build DA that sort of symbiotic relationship and those, those lines blurred a lot. I'm probably considered the founder, if you will. I don't know what you would want to call it of da I started da as like a little skunk works project in 2023. And it's funny because somebody actually internally was asking who's the, who's the PM of Edge Delivery? And someone, someone with authority, quite a barrier with authority was like there's not really a pm. I, I think there is if, if you, if you need an adult in the room. But like it was like Lars and David went off and, and did Edge Delivery and then Chris went off and went into this dark alley and, and there's your answer. It was like a non answer answer. So, so yeah, I, it's kind of weird. I wear a lot of hats. Sometimes I'm. I'm putting my customer hat on and I'm like why are you doing, you doing this to me? Or even D.A. i'm, you know, and, and that's kind of, a lot of. Some of that is born out of lessons learned from, from building a. But yeah, so I sort of like one minute I'm. One minute I'm a DA customer and the next minute I'm a DA pm. The next minute I'm a DA architect. [00:04:13] Speaker B: So yeah, well I guess that's, that's, that's an interesting segue into like a, like a superhero origin story that I wanted to get into on you because you've got this kind of odd combination of being a customer and a producer of the product. But like previous to all this Edge Delivery time, you were essentially just a onboard AM customer. [00:04:40] Speaker A: Yeah. [00:04:40] Speaker B: Running. Running a really, really, really big AEM site. [00:04:44] Speaker A: Yeah. Yeah. So yeah. So adobe.com I mean it's no secret we kind of talk about this every, every summit or every couple of Summits. But yeah, Adobe.com has roughly 100 engineers, give or take, and then about 200 content creators. So what's really interesting though is that Adobe.com first of all it's a mammoth E commerce site, but most folks don't think of it as an E commerce site because you don't typically have like you. We do have a product list but we have got like 25 products that you can buy and it's, it's primarily like one or two that, that most people buy. [00:05:24] Speaker B: Right. [00:05:24] Speaker A: Um, so adobe.com is, is interesting in that it's an E commerce site that doesn't seem like an E commerce site and it's Also an application portal. Right. So if, if it. We're starting to blur these lines more and more, which is like when you, if you're logged in, you want to use your apps, you don't need tell you, like, how great Photoshop is. Right? You've already, you've already drank that Kool Aid. You're. You're just wanting to get to your content. So that I think is really interesting. But yeah, just. I don't remember where I was going with that, but basically, yeah, I, I do wear a lot of hats. And, and yeah, prior to Edge delivery, first and foremost, a customer, you know, working with the product team and, and, you know, having feature requests and daycare tickets and, and all of those things. Yeah, right. [00:06:15] Speaker B: But, but so I think the first time that I, I ran into you was at an Adobe summit and you were giving a talk on Dexter and, and you were talking about all the different customizations that had gone into trying to make AM really livable for your needs. And, and, and it wasn't insignificant the amount of the, the amount of work that, that had been put into making AEM really work for Adobe's needs internally. Yeah, and I guess I wanted to. [00:06:43] Speaker A: Yeah, so, so I think that that's kind of actually where I was going is like, adobe.com is weirdly simple in that, like, the cash. The cash hit ratio is like, really, really high. It's like 100%. Okay. We don't have a lot of like, content actually hitting our AEM published instances. Back when we had AEM published instances, it was mostly cached. And so like, you know, I would talk to customers like banks or something like that, and they're like, yeah, our publish instances are just constantly pegged because they have to deliver like, dynamic content. It's like, oh, we don't, we don't do that at all on adobe.com but yeah, so, so I think that's a, it's an interesting story of Pendulums because when we went into Dexter and that was like 2017, ish marketing, you know, in Adobe is arguably one of the most creative companies in the world. So, you know, we should have one of the most creative websites in the world. And so we treated, we wanted to treat every page like a special snowflake. And marketing was like, really felt burdened by us because they would say, hey, we want to change a logo or we want to move a logo a little bit more. Like, well, your original specs didn't have that feature, so now we have to go build that feature. And they're like, whoa, my gosh, that's like going to be a month. And so we did build Dexter, which was highly flexible. It was, to my knowledge, it was the most flexible AM authoring experience that I'm aware of. We did use all out of the box, like, we started off with all out of the box components, core components, of course, but we built in that level of flexibility. And what's, what's hilarious about that is like, it's a very like, be careful what you wish for type moment. Because marketing was asking for high flexibility, low engineering effort, etc. So we made like the foundation, like back when we were on traditional aem, the foundation of all of our aem. So we have, you know, roughly, I think on the creative cloud business, we have roughly 400,000 pages across 90 locales, I think 40 languages and then business. Adobe I think is like in the hundred thousand range. Helpex is in the 1.5 million range. And so what happened was, is like we had 15 component, 15 foundational components and they were highly flexible and you could just go build whatever. And marketing originally was like, this is great. And then what happened is over time they wanted to start making big, big, like far sweeping changes. And it was like, well, y' all asked for customers custom ability. That's not a word, but that's okay, we'll go with it. They asked for it. Yeah, you asked for it and we gave that to you. And our, the burden is off of us because you now can build whatever you want. And, and it actually had this. And I think this is what's interesting about software development is like, you make these hunches and you make these decisions based off of like the knowledge you have at the time and you, you sometimes overcorrect. And so our marketing folks did not fully appreciate that. Like, well, if we're not going to be doing the work, we're not moving around those logos. They're going to be moving around those logos, they're going to be moving around those components. And that was a lot of work. And they were like, whoa, this is a lot of work. And what's interesting is like, we moved the bottleneck. So engineering was no longer the bottleneck for, for most scenarios. But what happened was, is like the PMs who want to be creative and the designers that want to be creative, they would just go to the authors and be like, hey, I know you can change this and it's off by 4 pixels. This is off by 4 pixels on mobile and I know you can change this and so there's this like tediousness to it. And then we spent, we probably spent the next two years basically just trying to improve the authoring experience for our authors and make them to, to help them be more productive. It was like we, we created this mess at your request and then, and now you don't like it. And, and we see the pain that you're going through, like the tediousness because you have to build everything and you're building everything as if it's a snowflake, a special snowflake. So you can imagine you can't create, you know, 400, 000 pages like one off, right? And so, and so that's, that's kind of along the time that the Edge delivery came around and it was like this, this sort of lightning in a bottle moment because right around edge delivery kind of coming to maturity, at least from our lens. So this is like 2021ish. Our design team, our marketing team was sort of saying they were starting to drink like design system Kool Aid and starting to think like, ooh, you know what, maybe, maybe creating a consistent experience across Adobe.com would be a more worthy goal or a more lucrative goal even than having every single page be a bespoke snowflake. Because if we can create a consistent visitor journey then, then maybe it's going to be easier for folks to check out and less confusing. If the Illustrator page looks completely different than the Photoshop page and you're like trying to navigate between the two and check out the features, you're just getting lost and confused. So that's where we sort of started to say okay, if, if the marketing team is ready for a design system and edge delivery works really well with design systems, maybe it's time to actually pivot off of Dexter, off of AEM and traditional, you know, AEM sites, component based htl, that, all that fun stuff and, and move to Edge delivery. And so we did, we started that journey in 2022. [00:12:46] Speaker B: So I, I think one of the things that is, is interesting to me about this is that, is that so because you said you, you have like 100 engineers on adobe.com so even when you've got that, and these are not chumps either, these are like some of your guys are, I, I worked with some of them that you've got some pretty high quality individuals, right? So even with really quality individuals you're still running into, there's only a certain footprint in the product that you can reasonably affect on a day to day basis. Like if you say, I'm running into this problem and here's a product that we sell that is supposed to be able to do everything and we all know AM does just about everything, it's made for what kind of site? All of them. So that's what it's supposed to be able to do, right? So, but even still, even with a hundred very high quality engineers, you still are running into some things that you, that you still can't reasonably fix in the amount of time that it would take you. Like, like what, what sort of things ended up because you said you pivoted onto edge delivery? What kind of things would you have run into that you're like, I'm still not getting what I, what I need or I might be able to more efficiently achieve my goals with, with a different platform. [00:14:06] Speaker A: Yeah, I mean, so, so that one, you know, I, I famously say you need, you need five different languages to get a, to get a component out the door. So you need, you know, and, and it's not just the five languages, right? It's not just Java, HTL, CSS, JavaScript, X ray, JSON, all of those things. But you also have to know the, the underlying frameworks that AEM provides. So it's not just do you know JavaScript? But it's like do you know granite and core UI? Because you know, you want to. The author, some author is saying, hey, this is kind of weird. And it's like the only way to fix this is to do it inside, to do it inside the editor, right? So when, when you have that, you know, if, if you've ever looked at like how teams are constructed, you, if, if you have like true backend engineers and true front end engineers, you need two engineers to get something out the door, right? Like 99% of the time a front end engineer may be able to hack something together in, in HTL to avoid a Sling model or something like that, but it's not going to be architecturally sound, it's not going to be testable or, or very easily testable. So the moment you have two engineers is, is like kind of a sort of a, a point of, of failure or a potential point of failure because you now have to communicate and you probably have to communicate now, but instead of two people, it's actually three people. Because you have a pm and then, and then you have a front end developer and a backend developer. And then you could probably even argue like in our world, like you have a designer that's in the mix and then you have then you probably have the author as well. Because your customer, if you're a AEM engineer or even if you're, if you're any CMS engineer, it doesn't matter if you're WordPress, Drupal or whatever, your customer is actually your author. Right, right. You're trying to empower your creator to create something, a non technical person. [00:16:02] Speaker B: Right. [00:16:03] Speaker A: So we just couldn't get things out the door fast enough. And even, even with just really reducing how much, how much effort we had already started to put into it. So even though authoring was still like the main bottleneck, we were still like under this like three week release schedule cycle because we'd say, oh, we're agile capital A and, and we would go build something and we're like, yeah, it takes two weeks, we have two week sprints. And what would happen is like QA is like, well you just drop this on me after two weeks and now I have to QA it. There's five of you, there's one of me. We, we've got a problem here. So our sprint cycles went from like two weeks to three weeks or we would shorten dev cycles to hit that two week because we wanted to keep that capital A in, in Agile. And so it was just like the churn. It's like, okay, I need to push it up to a dev server and then I need the QA to check it and then can, can I get some UAT from an author? And, and okay, the back end's not done. Hey, front end or done. Oh, I can't do my job until you know, Joe is done or whatever. And so when there was just a velocity issue there and so looking at edge delivery, we're, we're, we're off looking, looking at these projects that are being spun up and, and they're just like run in circles. They're not battling build systems, they're, they're in a pure sort of ESM Modern JavaScript World. They're front end only. And so we had, you know, all hundred engineers, we had to, they had to pivot, they had to pivot from. If you were back in engineer it was like do you want to go more front end? Do you want to go like more data engineering front end of like, you know, maybe you're, maybe you're modeling some, some content and maybe you're not necessarily putting a pixel on it. So maybe you want to go that way or like work on localization or some, some like content automation tooling, content orchestration. Do you want to go that way we still need servers or at least like we need some kind of of server side services. Do you want to go, do you want to go that way? And so like I think out of the hundred it was sort of like 50, 50. And so our backend engineers definitely had the most of a pivot to do. And I would say 25% went to more like front end but more from like a data wrangling, data orchestration perspective. The other half, so about 25 went to more of a pure node or continue like working on our, our legacy systems. And then we in, in full transparency we had I think two, two or three engineers that said you know what, you're going into a world that I'm not necessarily a fan of and, and I'm going to go find a new role somewhere where I can keep writing Java. So we had, so if you, if we say you know, 100 per 100 engineers and two engineers said this isn't for me. So 2% of of our people decided to, to, to stay on traditional AEM and just move to a different team. But the, the you know, it, it's, it's sometimes hard to articulate how much velocity you do get where you're not pushing up to a fixed lane server, you're not pushing up to a dev server, stage server, QA server. It's like here's my branch that's named after my, my favorite pet and, or, or you know, or realistically, more realistically like some feature like oh, I'm building an accordion. Hey PM designer. Here's here's the branch and right you know, you effectively have your own domain for that and so like you can send that to them and it's not like you're waiting for a 50 minute build or anything like that. And so that between like having a single sort of, A single sort of Persona in that it's like a front end engineer, all right, Reduces that, that contact time. Us being able to push up code instantly, not battling build systems, all of that stuff led to us getting things out the door. Oh and also like it. We'll probably touch on this a lot but like also like we move to just for clarity we move to document based authoring, right. We move to SharePoint. And so again we weren't battling a WYSIWYG system and that was both good and bad because some author would be like hey, this feature in Word kind of sucks. And we're like well we'll take that up with Microsoft. And Microsoft is not exactly like, you know, Edge Delivery is not exactly, their number one most important customer. So there were, it, it was good in that, like, it sort of reduced our, our blast radius of the problems that we had to solve. Because now we did build authoring tools like we bid. Did build author productivity tools, but we built them in a very micro front end sort of way. And so you can't change the actual button inside word, but you can overlay little micro front ends on top and you know, you can still empower your authors but not having to do double the work like you, you get it all working on, on the delivery and it looks amazing. And then if you naively try to push that over to an author, the author's like, you expect me to use this? What are you, what are you talking about? And so then you have to go like, go fix it to make the WYSIWYG happy. Oh, the WYSIWYG has some quirks with Flexbox or CSS Grid. You're gonna go fix all that and you're like doing double the work. So yeah, that, that's kind of like the, the pendulum of how we got into like really deciding that Edge Delivery was, was going to allow us to scale our business. I mean, hopefully the, the, like, that's not marketing speak. That's like right through. [00:22:24] Speaker B: Well, the, the, the thing that really to me was that so, so Adobe's not a small company. And so, so even even though it's, you know, very progressive and likes to do new things and explore new technologies and so forth, it doesn't change the fact that it's a massive, massive company with lots of fiefdoms of people who are fans of various types of technology. Some of them are very legacy because they've, I mean, I mean, look at, look at how, how old Adobe is in terms of the, the, the, the technosphere. I mean, I was just looking at. What did I look up? [00:22:55] Speaker A: Oh, we were having some font issue. [00:22:57] Speaker B: Inside of Premiere and I was joking with my video editor, Frank. I'm like, well, I mean you would have thought that Adobe would have figured this out, you know, seeing as though they came up with the postscript spec. And I was like, when they come up with the postscript spec, I'm like, wow, that was 40 years ago. Yeah, that was a long time ago. So there's, there's been a, so it's a massive company, a really, you know, so it's not a tiny ship to turn around. And so if you've got this, this huge bunch of sites, this massive footprint not just you know, www.adobe.com it's all these other ones that you're talking about in terms of help X and experience League and so on and so forth. Right. Yeah. So the fact that in such a short period of time that there was so much uptake on the edge delivery side of things that so many sites said. I really dig the way this is going. When can we get on on board. And and we. And went from everything on AM with the exception with like rare exceptions of like your, like your blog that came from WordPress but like. Like that that with. With rare exceptions everything flipped over to the point where you've got almost everything on edge delivery like that to me speaks kind of to. To its. It's gotta. Even with weird things in Microsoft Word. [00:24:15] Speaker A: Yeah. [00:24:16] Speaker B: Like so many people would have had to live with that and see so much other value. [00:24:21] Speaker A: That's exactly it. We were not, we were not super emotional about it. Which is kind of interesting because like AM is obviously like it's claimed to fame is is sort of its WYSIWYG authoring environment and we are all of our telemetry and data JIRA tickets. Everything was like document. Everyone who's. Who's moving to document based authoring is like wildly faster across the board developer experience and author experience and everything. And not to say that it's flawless or anything, but we could not ignore that data. We could not ignore how much faster those folks were. And so even though we were not super in love with SharePoint and Word, it was still pretty great. And so we did, yeah, we, we did decide to pivot. We. I think we got the decision in. In really early 2022 where we said we're going to put our first, our first major site that's going to require localization. Like real big kid localization. We decided to do that in 2022 and we went from zero lines of code to the first 600 pages. And laying the foundation really we had to. It's not just like oh edge delivery. Sometimes I'm not a big fan of like somebody that says oh we got this edge delivery site out in two weeks. And I go well is it really architecturally sustainable and all those things? So we had to. In six months we basically went from zero lines of code to an architecturally sustainable foundation that that could power all of these sites. So millions of pages. We got to our first five or six hundred pages in like six months. Good. And that was when. When my team. So I'm a, I'm a recovering Engineering manager. But when my team. [00:26:24] Speaker B: I'm happy to hear you getting better. [00:26:27] Speaker A: Yeah, well, we'll see. I again I wear warehouse depending on the moment but when my team took over basically all of the edge delivery stuff. So again we were kind of like co ownership between the edge Delivery Team and Adobe.com and so the edge delivery team was like hey, it'd really be great if you all just like, you know, have, have Chris's team take over this and take over the existing sites. So we had to, our imperative was basically keep the live sites running. So we had about four sites that were already running on edge delivery so we had to keep that engine run. Meanwhile we had to build the new engine. It's like okay, so it's 2023. We've been building Edge delivery sites since 2018. Realistically for the last two years or oh sorry, 2022 we realistically like modern edge delivery. What I would call is like from 2022 and, or 2020 and beyond. So like two years of knowledge of like best practices. What do we like, what do we don't like? And so build the foundation. So built a foundation, kept those existing sites running, got those existing sites ported over so we could have this common, common foundation. And what's really interesting, so my team was, was about five engineers and so we did have that exact, like we had two, I think we had two historically Java engineers that moved over to more like Node, Microsoft, Graph, API, localization, content, orchestration type things. Everybody else was sort of front end engineering. So we built the foundation, kept those sites running, move them over, got localization up and running. At least our first poc. More on that later. And then. Yeah, so, so it was very apparent very fast that this was going to work. Um, and, and that's why like a lot of, we see a lot of sites right? These, these larger, these larger organizations, maybe they're in the Fortune 500 like, like Adobe and they're like we're going to do our blog first. And it's like. And, and I think some, some folks could naively be like well why aren't you putting your full site on it? And that's true. Like I feel a little, a little bit of a, that's kind of a bummer right, that, that you don't have the confidence yet. And that's fine. That's, that's for us to do. That's for us to, to get you that confidence. But we did the same thing, right? We in, in 2020 we were like we're not ready to put our, our mothership projects on this. Let's do blog, let's do long form content, see how it goes. And it turned out to go really well. So when we did do business, Adobe, which was our first big kid site on Edge delivery, with our sort of lessons learned foundation that we called Milo six months in, we were just like, we were like this is it. Like there's no perfect system but the velocity we're getting is, is just like we can't ignore it. So it was like, I think once we got that first site up and running it was like, it was the, the floodgates were open almost to a fault too because now we had roughly five engineers that knew Edge delivery really well and then we had to train another 95. Right. And, and so what happens is, is like you do have that sort of mythical man month where all of a sudden like leadership is like this is amazing. Let's, let's all hands on deck. Let's, let's get, let's get going, let's get going on the future. And so now you have these five engineers that have to go train everyone. And so it's like, well what about like we got to keep the lights, lights on for these sites and we got to keep our authors happy. So there was, there was a lot of cut teeth in that. We had to train 95 other engineers. I think that's why I'm so obsessive about support, whether it's slack or discord or whatever because we really want folks to be empowered to solve their own problems. And like we want to also know like where is the knowledge gaps and, and you know, where are our gaps? You know, whether it's documentation or, or whatever. [00:30:49] Speaker B: So yeah, and with shared services, feedback loops have to be fast too. You can't wait for something to percolate through a million tech support levels to, to be able to get. [00:30:58] Speaker A: Oh yeah, yeah, yeah. And, and, and similarly like I, you know, just from a customer perspective, like even though I, we had access to daycare or whatever, it was like we tried to avoid that at all costs because it's like it, it's just like a please get reproduction steps. Please get this, please get that right. Like oh my gosh, like can I just, can I just have a five minute phone call with somebody? [00:31:22] Speaker B: Like right, or so I already know who I'm slacking internally, so can I just do it? [00:31:28] Speaker A: Yeah, yeah, exactly, exactly. Right. So, and I think that's also born, I think the, the edge delivery team. We all sort of feel that way is like, hey, just, just slack us, right? You're gonna get, you're gonna get a fast, faster response than if you try to go through normal support channels. I'm in. And again, it, I should probably make sure I say this, if I haven't already. I don't think I did, but I meant to. But like Adobe is a very large company with a lot of different opinions. I, I have my own opinions and I will share them. So don't, don't consider my, my opinions. The, the voice of Adobe by, by my voice is, is for me. [00:32:11] Speaker B: I'm going to scroll like a massive EULA on the screen right now that everybody has to like accept before they go forward to know that they're, know what they're dealing with here. [00:32:19] Speaker A: I think I'm known to be a sort of opinionated person. So if, if I'm, if I pause for a second, it's like I'm, I'm doing my best not to say something controversial. [00:32:30] Speaker B: In the early days of us working on this whole DA project, the number of times that I was talking to somebody else from Adobe and I'd be like, oh yeah, I'm working with Chris on this thing. I'd be like. They'd be like, huh. [00:32:45] Speaker A: So yeah, I mean that, that probably, it probably dovetails into like how, how DA started because yeah, I wanted to. [00:32:53] Speaker B: Get into that because, like, why. So, okay, so, so SharePoint and Helix is a, is, is a, is a like one of these technical directions that you really can. It's like an acquired taste that once you acquire, you're like, oh my gosh, why does, why is not. Why aren't we all doing this? We're just going to do this right now. [00:33:07] Speaker A: Yeah. [00:33:07] Speaker B: Business being wildly successful. What drove you to do a project that you named after hiding in a dark alley, working on a secret project? Like, like that's. That, that's the big question then. [00:33:23] Speaker A: Yeah. So it was again, I'm a. I don't know why, but I really like. Of technology history. So I, I have these like dates burned into my, into my memory. But so it was 2023 and because I wear a lot of hats, there are, there are moments where I don't get to write code. Right. So I was actually flying to Summit. There was a pro. So we were doing our next gen localization. Our localization POC got us pretty far. We were like, it was like you could localize 20 pages for five languages at a time and we were sort of hobbling along and our next gen localization was a little bit behind schedule and it was a little bit of a black box in that we did have that traditional like backend front end engineering relationship. And so I was like, you know what an edge delivery mantra is? Do something client side first. And, and, and then if you have to move it into a server, move it into a server. So I was like well let's, let's, I'm flying to Vegas for Summit. How hard. Let, let's see what's going on. Why is this behind schedule? Let me write some code and get to the bottom myself. That was the most frustrating exercise of, of misery that I've ever had. I, I, and I think like it could all be wrapped up. Like I would not wish that experience upon my worst enemy. Trying to orchestrate content across SharePoint using Microsoft Graph APIs and Microsoft Word which is a glorified zip file and doing things reliably and predictably in a way that, that met our very high bar of how AEM worked. It. It was one of the most saddest moments of my life because I had never felt so defeated. Yeah. And so I, I start this and then I think I'm, I'm talking to David and Lars at, at Summit and just kind of shooting ideas around and, and whatnot. And then a week after I actually came up with this like really great. It was like a single file of functions of basically like you, you. It was very. What's funny about it is like it's kind of almost, it, it almost was da or AEM like where it was like okay, I have a function where I say from and to or, or source and destination and you provide a path and the document and it'll go do it. And it abstracted away all the like four 29s and four 23s and the, the oh, if somebody has it open you need to destroy it because you can't override it if somebody has it open. And, and all of these things. It was like this most like beautiful piece of code on top of this really horrible developer experience. And so, and at the time I think it's probably worth mentioning it wasn't like top of mind but I knew that Universal Editor had at least was either an idea or, or there were rumblings of, of Universal Editor which was like hey, let's bring WYSIWYG editing to Edge Delivery. Let's bring JCR to Edge Delivery. And for us the genie was already out of the bottle right. As far as like document based authoring productivity. So it was like WYSIWYG was not gonna, not gonna work for us. Which I'll touch on in a second. Like different authoring modalities and what. Right. Speaking of opinions. But so I just said as sort of a, a palette cleanser. It's like, okay, I've been, I've been, I don't know the right word. Handcuffed. I've been handcuffed to my BFF SharePoint the last year and, and now I'm really getting in, into the thick of it with, with these Microsoft Graph APIs. What would it look like? Would it be possible? This is an insane idea. This is literally what I said. This is an insane idea. But what if, what if we took some of these like document based authoring ideas and put them on something and it. Something that is not jcr. It is not. Not that it can't be jcr. Maybe it maybe eventually will be not jcr. Something that's like not AM and, and actually not Microsoft or not Google. [00:38:15] Speaker B: What. [00:38:15] Speaker A: What would that be? What would that look like? And it was really just a pallet cleanser. It was a pallet cleanser to say like, okay, there's nothing worse than feeling like something is out of your control when you're out near, oh yeah. And you're like, I cannot fix this. Like there's nothing I can do to fix this. We had calls with Microsoft and everything and they're like, you really shouldn't be using SharePoint this way. You know, it's not a CMS, guys. Yeah. And the thing is, is like it is and it's actually a really great cms and if, if you have a certain, like, if you don't have those sort of like enterprise Y web content management and I very specifically want to use the word web because we were super successful with our other projects, our other projects that didn't need all that content orchestration workflows, things like that, even workflows are pretty great on SharePoint. But it's like if you're moving around a lot of content, SharePoint just really doesn't want you to do that. It wants you to. It wants you to. It'll. It'll happily scoop up millions and millions of documents. And that was kind of where we were worried. We were like, oh no, is it going to support. And it's like, it's not that. It's more like I want to move a thousand documents and they all need to have the same Images. And so SharePoint's like, we're really not designed for this. So I Started research and it was like, okay, I want this to be serverless. I want something that is serverless. I want something that acts like a tree. Because that's how I work. That's why I fell in love with Apache Sling, that's why I fell in love with AEM is that I have this content tree. I don't have SQL or any of that garbage. I don't have a relational database. And so I went through the. So I know Sling very well. So I spun up a Sling and it's like, okay, how do I run Java serverless? And Java already felt like a. Not a great fit for containers, even so. And I know what we went through with cloud service and it's like, okay, Java is probably out, so that means I can't do Sling. Should I re. Implement the Sling APIs? No. What about Mongo? Mongo's kind of a. Mongo can give us a tree. We know because we have. Am backed by Mongo. Is. Is Mongo the right way? And we lean on those APIs. It's like, no, that's. I can't afford that because, because this was all. It's interesting. I actually didn't even know. I didn't know what this would look like. So I actually started building this all on a personal laptop just free and clear of. Of Adobe IT and whatnot and built it, was building it during weekends and whatnot as a hobby. So ultimately from. From like a pure. I have to, I have to fund this myself because this is not a blessed project from Adobe. This is a research project. This is Chris Millar's, you know, own crazy idea. So at first DA only worked on a file system. It only worked locally. Um, I actually used a file system because I didn't have anything else. It was like node fs, right? So then it was like, okay, gotta move it into a server. What does this look like? And so with enough research, and this is pre. LLMs with enough research, I realized that we could sort of kind of fake a tree with S3 prefixes. And so it was like, what's this? This proved to be like, just incredibly insightful in that we. I started saving into S3 and started to like really figure out like, okay, how do we, how do we show folders? How do we list, you know, just one level down so we're not just blowing out the whole, the whole tree. What does it look like to have a. Of an empty folder? Because for prefixes to show in S3 you have to have a file inside the folder. It's like, okay, so what does that look like? And so there was enough. So after doing the research and considering Sling and considering Mongo even, I think there was a point where I was like, would Dropbox be an answer? Because this, this idea, like we, we still believe this very strongly, which is like in edge delivery is like meet your authors where they are. Right? So I was like, ooh, maybe, maybe the idea of bringing some of your own service, your own content is a great idea. It's just like the, the fine print that is the problem. Like a. Docx file is not a very hospitable environment for the web. [00:42:55] Speaker B: Right. [00:42:55] Speaker A: At scale. Anyways. So ultimately decided, long story short, we're going to say flat HTML files in S3, the HTML file format will be edge delivery minus we will persist fully qualified image URLs. Which was great because then we could reference these, these little things that we didn't even think about at the time. We could reference other CMSs. So all of a sudden like when we went to build AM assets, it was like kind of laughable because it took like a week to build. It was like, do you have AM assets integration? Yeah, we, we like Adobe just do that together. Front end. Yeah, Adobe provides a micro front end. We, we had like a, a 50 line wrapper if that around it. And and so what was great is like as long as your image was published, we had it. And so it was like it really, actually that, that particular example was, was good because it really showed that like we could bring the power of AEM to document based authoring and edge delivery. And so that's when we just started to, or I guess I, I shouldn't say we at this point because like this is all research at this point. [00:44:19] Speaker B: Right. [00:44:20] Speaker A: And so started to research editors and then actually dropped the project for easily six months. I actually had to actually go solve that localization problem. This is one of those things where you're like almost like you're, you're bargaining with your parents, where you're like, no, I want to go play with my friends. And I was like, you have to do your homework. And so it was like my homework was y' all need to make localization scale on SharePoint like you, you got us. And to be fair, like, I had to do this because in a lot of ways I got us into this mess. I was the one that said SharePoint's gonna be fine. So we got, so I put all the research down and got scalable localization out the door and then sort of started to poke at this again, poke at this idea again and actually did a discord call. And it just. The Lars and I did a discord call and I had nothing to talk about or neither of us had nothing to, had anything to talk about. And it was like Halloween or something. And just serendipitously, Carl Paul's had joined the call and I was going through like, hey, here's web components on Edge Delivery. And I'm just showing DA at this point, right? And, and it was like, here I am just talking about like web components and Edge delivery and, and how you can bridge these worlds and stuff. And I'm clearly just showing like a full blown document based editor built by Adobe, like wired up to Edge delivery. So Carl was like, this is, this is kind of interesting. This is like none of us like SharePoint and all of us kind of really like document based on this is kind of an idea. Would you, would you want some help on this? I'm like, yeah, yeah, I'd love some help. So what's funny is like we, we all went to, we do these hackathons, we do these workshops. They're not really hackathons, they're more like. And so we did this workshop and, and Carl and I went to this workshop and we thought we were just going to work on DA and there were maybe like 25 other people at this workshop and they're all kind of working on different things. There were some folks working on Block Collection. There were some folks working on Helix 5. I almost said Helix 6 because I've been sitting Helix 6 lately. And so what's funny is like at that point David Neuschler, who's kind of considered the owner of, of Edge Delivery, I was really worried about showing it to him. And then eventually enough folks were like, no, you really got to show David this. This is pretty cool because again, we were all sort of drinking the same Kool Aid that he was drinking, which is like, look, go meet authors where they are. If the authors are, are a SharePoint shop, go meet them at SharePoint and, and deal. And so I was really reluctant because I'm like, this really goes against everything we tell our customers. This goes against everything we tell ourselves. This is everything. This, this goes against everything I, I have personally said, like, build your own, build your own editor. Like, this is, this is a fool's errand. So I was really worried that he was going to shut it down. And that's actually part of why I was building it on a personal computer because like I had invested in this and I was super excited about this and I'm like, what do I do if Adobe shuts this down and says, don't work on this? Like, and, and just again, in pure transparency, I was like, I'm going to build this all open source. I'm going to build this all on a personal laptop. And so if, if Adobe does say no, don't pursue this, I at least want to have the option to say, well, maybe I should take this and take it somewhere else. And luckily David was like, this is awesome. This is like, this is, this is a great plan B, Plan C. There's something to this. Gave me a big old laundry list. Like we had this quick meeting and, and it's funny because I told him, I was like, I have to show you something that I don't want to show you. And he's like, this is going to be fun because. And so I just set the stage. I'm like, I really don't want to, I, I really, I don't want you to tell me no, I don't want you to shut this down and say this is a bad idea because I think, I think I may disagree with you. And we usually tend to agree. And so he's like, you think I'm a big fan of SharePoint. And, and so he kind of had the same sentiment as us, which is like, we're not the biggest fans of SharePoint. It's that we're real big fans of, of the productivity and the low support and everything that comes with document based authoring. So it's like, hey, go research this. This is, this is a great research project. Keep plugging away. And btw, here's, here's five pet features I'd like to see. So that was kind of like a loose, loose blessing to keep going. So then fast forward four months and we're doing this hackathon and he says like up at the beginning of this workshop, Chris Millar is going to be, we have these tracks. One track is block collection 1. One track is helix 5. And then we have this other track which is da. And what's funny is like Carl and I just thought we were going to work on real time collaboration. I thought he was going to work on real time collaboration and I thought I was going to work on authentication. And what ended up happening is we had like five other engineers be like, well, we want to join your track. This, this looks cool. And so that's where that's, that's really where DA started. And that's where the, we came to da like all these incredible folks, Marcus Hack and, and Andre and Gosh, David Catalan and, and all sorts of Andreas from, from netcentric. We all just like started plugging away. And, and so that, that's, yeah, that's, that's sort of the genesis of da. And and so I think what, and that's really kind of where the challenges came internally. Like sort of where you do separate like opinions from, from facts and stuff. Because you know, everybody, everybody's sort of proud of their, their own work, right? [00:50:56] Speaker B: Oh yeah. [00:50:56] Speaker A: When, when you build a thing you're going to hear a lot of Chris Millard tropes but like usage is really the currency of engineering because like if you're an engineer and you build something and then nobody wants to use it, what, what was the point? And so if, if all of a sudden you're working on this really great editor, this next generation editor called Universal Editor, and then you hear rumblings that like some adobe.com edge delivery OG Chris Millar is, is deciding to not ask you about Universal Editor, but he's deciding to go build a document based editor. You're like, the first thing is like well why aren't you using our stuff? Why, why, why do you feel the need to, to build your own thing? And you know, I again the genie was, was, was out of the bottle for us. Like we knew we wanted document based authoring and, and we knew that they were sort of focused on WYSIWYG authoring and so it was like look, not gonna yuck on your yums or anything. Like that's great. We've kind of already moved on from jcr at least that's, that's kind of even with all the challenges we have on SharePoint where we don't think we want to go back to jcr, maybe we will. I mean, or never say, never say never. But we were like we want to go pursue this. And so a lot of folks were understandably hurt is, is probably putting words in their mouth, but they were like, why are you doing this? [00:52:34] Speaker B: Yeah, but we're confused. Or does it somehow invalidate the engineering work that was already previously done? But to me, what I think is kind of fascinating about this is that if you rewind it back to what you were saying earlier of you're working on a problem, it sucks to not feel like you can effectively handle something, but you can't, you can't actually contribute something which is going to solve the problem. [00:53:03] Speaker A: Right? [00:53:03] Speaker B: But then even back of that, like what, what is the whole engineering thing anyway? Like, I've tried to try to figure this out. Like my son has, he's a, he's a, he's got an engineering mind. And so I've been trying to work with him on like, I don't know what he's going to engineer in his life, but he likes, he likes fixing stuff. And so we talk a lot about like just the very basics of engineering of like what requirements do you have and what problems are you really trying to solve? Like what are, what are the things that you're trying to engineer your way around? And if you look at something as big as aem, right, what, what is the list of requirements that AEM solves? Like what are the list of things that it has to be good at actually trying to fit? Like if you were to list out everything that just the whole product, the storage mechanism and then the page editor and the customization patterns and the, everything that it's supposed to do and then you go, well, you, this new crazy thing that you're doing. Chris, how does it solve this content management problem? [00:54:01] Speaker A: Right? Yeah. [00:54:02] Speaker B: And which must have been like something that I can just imagine the fascination of being able to work on a content management problem with a blank slate. Like, I don't want to solve all those problems. What problems do I want to solve? What, what are the, what are the core things that I would like to solve in a cms? [00:54:22] Speaker A: Yeah, it's, it's really interesting because you do get. So there's, there's this term called Gall's Law, which is basically, I'm gonna, hopefully I'm not gonna botch this, but basically you cannot start building a complex system. You have to build complex systems that work started off as being simple systems, right? And so almost naively I said, what do I need to do? I need to list content, I need to be able to create content, I need to be able to delete content and basically crud. And I want an API that if you squint, kind of looks like Sling and kind of looks like edge delivery. And those were my, my sort of high level requirements. And again, very naively it was like, I just want to save a, I just want to save a text document. Okay, I got it. I got, I can save a text document. Okay, now I want to save a 20 megabyte PNG. Okay, now we can do that. Now I need to list those things. And so naively, DA has always been very simple and some of that is, is self preserving because we have one Full time engineer, that's me. And then we have, depending on the day, we have a revolving cast of part timers that can be anywhere from 5 to 10 people and part time meaning everything from like 90% time to 5% time. And so there's a self preservation thing to build something just ridiculously stupidly simple which is like, I have a file. Please save this in S3 at, at the path that I tell you to again which is very sling like resource resolution wise. Right? So yeah, that, that. And, and so like you, you do have to. And, and this goes back, this kind of almost leads into another, another thing which is like I was talking to a VP of engineering who's, who's a little bit of a mentor of, of mine and we were talking last December and he's like, hey, how's, how's da going? And he's been incredibly gracious with like letting us have room to breathe and not shutting us down. And he's like, how's, how's da going? And I'm like, you know, again, Adobe's big place, lots of opinions, you know, negative commentary, people not being terribly nice, et cetera. And I said, I just, I really just want to put my head down and build a great product. And he just sorts sort of laughs at that and he's like you, you naive little boy. Like, it doesn't work like that. Now what's really interesting is like as we did have our detractors, as we did have our sort of like, no use our stuff. Don't use, don't use da. This is, this is crazy. This is Adobe. Com. Crazy talk. We did have our detractors. And again, because those folks are proud of what they built and they should be, when we had those adversities, we did ultimately lean back to are we proud of what we're building? And so that was, that was sort of like the thing that helped push through those adversities and those opinions where it was like he was right in that it's way more than just putting your head down and building an exceptional product. But when we all that, all that like BS for, for lack of a better word, all the like gray matter of, of getting da out into customers hands. When we did have those adversities, we ultimately always fell back to are we proud of what we're building? Did we build a product? Is our product. And this is stealing another quote which is like we're in our infancy. Is our product stupid or is it simple? And so if, if it's stupid, you're on the wrong path. [00:58:35] Speaker B: Right. [00:58:36] Speaker A: And so like we just say no. It's just, it's simple. Can it, can it do. Because, because we always have that. I mean you're going to have that. It doesn't matter the industry. Well, does it do X? Well, does it do Y? And, and people that try to needle you or, or paint you in a corner and ultimately it was like no. But I, I have a path of how we can do this in a really elegant way. We just haven't prioritized it. So I can confidently tell you when you try to needle me, like it doesn't do. It's like I can confidently tell you like, no it doesn't. And, and that's okay. I have, we got two 400 sites where everything's just peachy for them. We have, we have 20 organizations, live organizations and, and they're super happy. So you, you know, you, you know, whether it's in the discord or, or whatever or internally, it's like when somebody challenges us or, or throws us a little shade which, which happens maybe directly or indirectly we just fall back to let's build a, let's build a great product we're, we're proud of and. Yeah. So. [00:59:52] Speaker B: Well, I think that's one of the, one of the luxuries that you almost have though with, with the fact that Adobe already has a system which is widely considered to be the best, if not one of the world's best content management systems that does almost everything. So you can almost afford to go from something that does everything and say we're going to build like it's almost, I feel like it's, it's quasi similar to, to the way DHH has been working on his Linux distro. Like it's like it's, you can almost afford to just say I'm going to build a really opinionated cms. This is, it's very opinionated and there's. We've got opinions about how this is going to go and things that aren't going to be in this thing. Nope. Servlets. I'm really, you know, or I. How do I, you know, add this to it? It doesn't do that. And we have an opinion as to why that is and we think it's a really good opinion. [01:00:48] Speaker A: It's a. It. That's a great call out because all of us have such a reverence for AM and everything that that AEM has represented over the years and we, we can hold both of these ideas together which is like we have A reverence for, for everything that AEM has done for us and how much fun we've had with aem. But we can also say, you know what, we'd like to, we'd like to do something a little bit differently. Um, and, and so I think, I mean, just transparently, this is probably where I, where I sit in the middle, which is like, in a lot of ways I think sometimes Edge delivery overcorrected with some of the things where it's like some of the simplicity is an over correction. And so I think DA brings a lot does in, in a small part, bring some of that back, which is like, you know, Edge delivery was like, we don't want you to have to learn Adobe's proprietary APIs or if you have, or if we have APIs, we want those API services to be extremely minimal. And so that was a, that was a correction in, in terms of like the API surface that lives inside a. Right. Am I using the, the resource, the Sling Resource API or the CQ Page API? Well, they both have overlap. Do I use the, the JCR Node API that has overlap with the Resource API and the CQ Page API? And all of a sudden if you overcorrect there, then all of a sudden you don't even have a single way to make a document. In the case of traditional edge delivery. And now DA brings back like, yes, you could make a document. So that, that can be, that can be a little bit of a challenge. But what's great is like AEM is an incredible escape hatch for us and they provide an incredible layer of air cover because the entire AEM ecosystem, which includes edge delivery. Edge delivery is a feature of aem. If you are dead set on like, I want to control the markup that my server creates. I know that edge delivery is giving me semantic HTML. It's both unopinionated and opinionated, and that you're going to get a div for this and you're going to get a, you know, a main tag. But it's like, well, I want a section tag for my sections. Oh, nope, you can't have that. So it's like both opinionated and not opinionated. And so if a customer comes to me and says the number one thing that I'm most concerned about is controlling my, my server side markup. We've got AEM here and we've got HTL and, and they're incredible technologies. I know because I use them for a very long time. And so AM is an incredible escape hatch to solve other Problems. There are things that, there are things at least today that are not fun to do in a serverless world or it at least in, in some ways. So a good example is like that, that section tag is a great example. I want, I want to have my server render a section tag. And can you technically run a worker between your CDN and Edge delivery? And so it'll convert that div into a section tag. Can you do that? Yes. Is that fun? No, it is not. Because what you're going to get is AM Live is giving you divs, which is like so all of your branches, all your developer, you know, experience everything. Div, div, div. And then in production you have sections like that. That's not going to be great. And so if you're dead set on like, no, I want to control the semantics of my server side markup, then I'm going to tell you to use traditional AEM and you're gonna, you're gonna have a great time. Well, that's one of the things though. [01:05:09] Speaker B: That, that I, that I. So five years ago when AAM as a cloud service first came out, I basically like self started my own like little cottage industry of pointing out all the things that AEM cloud service couldn't do. And one of the reasons for that though is I found myself when dealing with customers, I was checkmated by edge cases that it couldn't do. Where you'd say, well, can we move to this thing? And I'd say, well, can it do this? This only represents, you know, 3% of the traffic or some small percent of whatever this project is that I'm thinking of. But because it can't do this and I have to move the whole project, then that means I can't move the whole project because it can't do this thing. And if I have a list of four things that it can't do, then basically even if those, even that, that's such a small percentage of the overall job that site is doing, it means that I can't move the site whole hog and, and move it to a new city. You know, it's in a new location. When you turn that upside down, you say Edge Delivery accounts for 95, 96, 99% of everything except for these two like weird things. We've got this funny calculator thing, we've got this contact us thing which has to go through this wacky workflow. And then like, but Edge Delivery doesn't do my wacky workflow. Then you're like, good, Walt, let's Let's solve those problems individually as opposed to saying the entire platform is bunk because of the Edge case that it can't do. [01:06:46] Speaker A: Yeah, it's both a, it's both a blessing and a curse in that. I say this a lot, which is like, with Edge delivery, you're only limited by your own creativity, which is, is maybe a little easy to say because it's like, okay, well, my creativity is striking out here. I just paid Adobe a bunch of money. I feel like they should be solving this problem for me. I don't want to have to go now. I have a different perspective. Right. I'm internal to Adobe and I was excited. I was like, great. I've been downstream of, of some, some AEM decisions I'm not a big fan of. And you're telling me I get to own all the decisions here? Where do I sign? Because sometimes you try to make am do things that it's. That it's not meant to do and even Edge delivery suffers. All tools really suffer from this. So that is, that is the challenge is like, okay, yes, I can technically solve this in edge delivery, but is this in my heart of hearts, do I think that this is a good fit? And so you, you constantly have to, to like, question your own biases there on like, you know, whether it's like, I'm used to core components and you give me block collection and core components has a checkbox to show and hide dots for my carousel and block collections. Carousel doesn't have that. And so I guess you didn't give me that. So I'm, I'm out. I'm on cork and it's like, and if, if you knew the other side, you would know that it would take you five minutes to, to add dots and, and make that an authorable feature. But if you don't have that visibility, then maybe you do. You might be prematurely kicking yourself back to traditional A land. [01:08:41] Speaker B: So, so on. On Da. So da. [01:08:44] Speaker A: We've. We've. [01:08:45] Speaker B: We. I think we did the origin story and, and as well as the, the prequels on this pretty well. So, so now, so fast forward to today where today we're in this lovely world where we're, we're 10 months downstream from my first website launch, you know, full prod enterprise website launch on da. And, and that company remains very happy with it and we've had a couple occasions to, to, to. To look back and say, well, should we have gone a different way? Oh my gosh, I'm so glad we didn't go a different way because we were, you were going to go an entirely more complex manner and it would not have, it would not have ended very well. So, so now given what it is and what it's become, how would you basically describe this product in what it, what, what it. What. How it exists now and where does it fit? [01:09:43] Speaker A: Yeah, that's a good question. So yeah, just, just a quick call out and, and props to you and the entire Arbery team because you all did launch the first, the first customer on it. You. You all on. So I think we had parts of business.adobe.com in January, so we're coming up upon a year of live sites. But you all were the first external customer and partner to launch a live site. And getting live is the real metric. Anybody can spin up a sandbox project or maybe even a friends and family blog or something, but like getting an actual customer, especially like the relationship between Adobe partners and customers, getting a customer live and the first one at that is, is huge. So probably my, my most favorite accomplishment of, of 2025, even though it, it was your accomplishment, not ours, it was. [01:10:49] Speaker B: It this, this was a super team. And so yeah, this was, it was, it was, it was all of us. [01:10:54] Speaker A: It. It's interesting because so DA started out, we had to frame DA in a way. So we always frame DA as an alternative to SharePoint for edge delivery. And as, as your product grows and matures, you have to change that narrative because like if, if all of a sudden you're now talking to customers that have never used edge delivery with SharePoint, they have no reference point of what you're talking about, like why it could be better or anything like that. So the first year of like internal sales and external sales, it was really about like taking existing Edge delivery customers and educating them of like, why DA would, would be a better fit for them or how DA could solve some of their pain points that they had on SharePoint or Google Drive. And now you, you fast forward and DA is just this freestanding thing and it's sort of like the default, it literally is the default in that if you go to AM Live Forward slash tutorial, it's going to tell you to build a DA site. And so DA is Edge Delivery Author. It's your authoring surface for Edge Delivery. It's, it's, you know, if, if you're trying to get a site live or a project live, you need to deliver it and that's Edge Delivery. And then you can choose other, other, you know, content repositories or editing services to wire up to Edge Delivery and DA is. DA is the, the default now. So it's just. It. It's kind of weird to just say like what is da? DA is an authoring environment for Edge Delivery. It is the authoring environment. It's the, the. The sort of I would say premiere. But like again if you're looking for, if you're looking to bring over servlets and, and things and you have developers that are maybe more comfortable in jcr, you know, AM is. Is really great for that. So yeah, it, which is funny because like we constantly talk about branding and whatnot and like I'm. We don't get to choose. I hope we're. We're not going to get this like next gen composability thing. I hope we don't have that moment. But you know, I in. In fact I think if you, you look at our GitHub repo now it's just called Edge Delivery Authority. Okay. Because when, when Cedric made the decision to and and sort of like he, I don't know if I would say this is a decision, but he certainly gave us, gave us the idea and he certainly championed the idea of like well UE can work on top of anything and, and yeah, it sort of heavily flavors jcr. Those aren't his birds, those are mine that seen what I've seen. But you can like, you can wire it up to any cms and so if we can technically wire it up to any cms. The commerce folks at the time, it was January of this year. The commerce folks are like well, we really want ue and the AM team is like well the, the cloud manager and, and from a licensing perspective and the, the headroom from a licensing perspective, we don't really want to give them a JCR thing. Maybe we should see what UE on top of DA looks like. And so that, that sort of like direction happened in, in January and so we were off to the races like January. [01:14:37] Speaker B: We. [01:14:37] Speaker A: We had a poc. I think Marcus had a POC in like less than a week. Right. And and so that at that moment, you know, we went from Dark Alley to da, which was document authoring. And so at that point we, we actually dropped it used to say, I think first it said Dark Alley in our, in the top like where the logo is. The little logo lockup. It said Dark Alley Project, Dark Alley or something like that. And customers, I think you all were the ones that was, it was, it was. Yeah, we're showing what was it. It was like we're showing some, some other companies this and, and they're, they're, they see the word dark alley and it doesn't inspire confidence. So we changed it. Right? Yep. So then it was lunch. So DA is just a edge delivery project itself. So just at lunch David and I were like delete, delete, delete on document authoring and called it author. And just in, in service of, we're well beyond document based authoring now because you can, you can throw UE on top of it. [01:15:46] Speaker B: That's right. [01:15:48] Speaker A: So yeah, that's, that's. I'm sort of like hoping to plant seeds that, that DA just ultimately is, is called Edge Delivery Author. And what are you doing? I'm authoring content for edge delivery. That's right. We'll, we'll see. We'll see if the, the branding gods and goddesses are kind to us. We'll see. [01:16:09] Speaker B: The target, the destination is what matters in this case and where you're getting the content from shouldn't. And I mean that's what all this craziness that I've got on my screen here is a AM Forms Linux box that I'm missed. This is one of our next fun things to talk about. But yeah, it's still, the destination is still edge delivery. [01:16:36] Speaker A: Yeah. So it, it, it's been really fun. I think getting DA has, has gotten way more support from folks and, and some of those adversities that I was talking about before have, have largely gone by the wayside. It's incredible that I think John Madden said success is a really great deodorant and like when to put that in like engineering terms, it's like shipping is a, is, is a great settler of arguments. And so you know, you all were the first. So like if you think about it, January 1st we had two CUs. Two external customers that were fully, maybe two to five customers that were fully committed to building a site or a site or many sites. So about five different orgs. And then Lars kind of pontificated we want to have. I don't remember if he, I. We didn't differentiate at this point but I think he said we want to have 50 live sites on, on DA by the end of the year. And I was like oh my gosh, you're, you're, you're cuckoo pants. We don't, we don't even have a single site live. When, when he said that he was like, and again for me shipping is what matters. Right? So now we have roughly 20 organizations live. I think we just hit that mark Last week. And then we have about 2200, 22 or 2400 sites actual sites live. It's a little bit of a cheat because we have a school system that is roughly 2,000 of those I think. So it's one organization with, with over a thousand different sites because they have a site for every school. But it's also the, the complexity in there is, is like, should not be dismissed because they were like, they would launch like 200 sites a day. It was pretty fun to watch. They're just like we shipped another 200 sites today. And so if you think about the coordination of like the school teachers, the, the principals that are like authoring the content in DA just, just like it, they're like my poster child of, of implementations in a lot of ways because they're non technical users. They, they kind of drank the same Kool Aid that we did because they did come from a component based world and they actually had, they only had a few people that could author in a component based world. And then now every single teacher, every single principal, totally easy, they, they got it, they self service everything. It's, it's really great. So they're kind of our poster child. So, so yeah, it's, it's, it's great. [01:19:29] Speaker B: And something like that should be a poster child though. Like I recently had to, I went on somebody else's podcast and I said oh yeah, I, I, I, I do platforms for content management systems there and, and they're like oh but so what is that, is that, is that like what, what is that content? Is that like content creators like TikTok or something? And I actually had to explain what a CMS is for the first time and when you bring it down to brass tacks, it, A CMS is that system that enables a non technical user to be able to create content and reliably get it out onto the Internet. So a school principal or an assistant principal who's supposed to be updating today's menu for some school that is just so many joints removed from where you sit as a, as a, as a technical architect for a platform. You know what I mean? Like that is the goal. [01:20:23] Speaker A: Yeah, yeah it is. And, and actually I mean to just to also to, to further that point, you know, you all needed a lot of help from us because we had a, we had a, we were building a product while you were trying to use the product and there were, there were a lot of paper cuts, the foundations were there, but it was like oh, there's this paper cut, there's that paper cut. And so one of the, one of the highest compliments we can get is when we find out that somebody went live like weeks ago and we didn't know about it because it means they didn't need us. It means that the product worked the way it should. And so, I mean, gosh, you and I, like last year, like 20, 24, you and I were on calls like every week of like, hey, this is weird, like, what, what are you going to do about this? You know, or, you know, you say it does this, but it does something slightly different. And what about like. And so like, you and I were on calls all the time trying to get that first customer live, and very much Rising Tide lifts all boats. Right? So, you know, when, when you all were giving us feedback and your customer was giving us feedback, I'm like, oh yeah, Adobe.com is going to come upon this pretty soon and boy, am I glad you're calling this out. So I have a reason to prioritize this and elevate it and get it fixed. So yeah, that, that, that's one of the things is, you know, if, if we can get folks live without a lot of hand holding it, it means that everything is sort of working. And then there's times, you know, there's, there's times where had this a couple of times where customers went live with something and then we hear rumblings of like, dissatisfaction and they might be on, they might be on something else, they might be on SharePoint, they might be on Crosswalk, something like that. So we'll, we'll hear rumblings and, and maybe even trying to think if we had complaints post, post DA. I think we had complaints in, in a post DA sense of like, y' all told us to use SharePoint and, and I felt this too internally with Adobe, Adobe.com but like, okay, Adobe, y' all told us to use SharePoint. When we started complaining that SharePoint was not working, you told us to use DA. Now we're trying to implement DA and like, it's clearly in development, like, what should we do here? Like, SharePoint doesn't work real great. DA works great. But we have these paper cuts, like, what, what should we do? And so we really did have to come in and be like, like, get really sort of rigorous about, like, what are we going to fix? What are we not going to fix? What are we going to prioritize? All those things. And then, you know, luckily I, in, in that customer's particular case, you know, they're, they're quite Happy now. And they're, they're also kind of in the same boat as your original customer. Which is like, it's funny because like some of the, some of the decision makers are sort of ue curious Universal Editor curious, which I get. It's like, you know, you see a shiny thing and whatnot, and the engineers are like, well, if, if we do this, if, if you want to use ue, we can do that. We just have to add component definitions, component models, you know, make sure the WYSIWYG is happy. So any little tweaks, like we did in Page Editor, so we had engineers like being like, almost like doing their own pushback of saying like, hey, this will, this will slow our velocity down. Which just to be clear, like sometimes that's, you want that, you know, and, and so like that, that's another really important take. And, and this is my opinion. So again, Adobe is a big place, but you know, our three, our three core pillars of edge delivery are it's, it's faster to create content for, it's faster to, to develop for, and you get better site speed when, if, if you're a customer and you, you choose to use Universal Editor or any WYSIWYG environment. I actually saw a customer that built their own WYSIWYG environment which was like, whoa, you are really signing up for a lot of work, because I've been there. But when you sign up for a wysiwyg, you are signing up for more work. You are signing up like your developer velocity does go down. You have more work to do, like reponent models, component definitions, those things. You, you do have more work to do. You do now you as a company, you might say that investment is worth it to me. Yes, it's no longer the fastest to develop for, but I want my authors on Rails. I want them to have a drop down that, that, you know, turns red if they don't select something. So you may want those things and we lose, like, we don't want to oversell you something. So if you use Universal Editor, you know, there's a lot more clicking you have to do because we've created a UI that, that in all WYSIWYG is like this. It's not specific to ue, but like you're asking for more ui, right? You're asking for more modals to pop up and switching contexts of like, oh, now I'm editing this and now I want to move and now I want to drag. You're signing up for that and and that's, that's fine. But will, you know, you as a customer have to make those decisions? [01:26:26] Speaker B: Yep. One of the things too that, that, that set. Because it's not that those requirements, those, those I need it to turn red or I need, I need, I need that level of Rails. It's not that those customers don't exist. I mean there's, there's plenty of AM customers that are out there that I, I literally cannot have anybody editing something that's outside of these bounds because if they do, it's a legal risk for us and, and the legal risk is significant. So. And I needed to go through this workflow before it ends up on the Internet and, and so forth. Those do exist. But yeah, now, so, so in terms of where you ended up landing with, with DA in terms of a feature set? Because right now you've got, I mean, yes, you started out with a, with a super basic like set of requirements of like, I need a tree. I need to be able to edit stuff. It should be fast when I save stuff. I need a flexible way of presenting images. I do need localization. So, so you've got a couple of these things, but then you've, you, you started out with a super basic set of, of features, but then you add, you end up needing to. This is again, it's kind of like this whole like, does it reimplement everything that AEM ever was and, and is. And how much of that kind of opinionated set of requirements do you, do you then bring into this? Because you, because we, when, when all this started out, there wasn't really a, a framework for like author customization because there's like in any, in any major org there sometimes they have more authoring releases than they do publication side code releases in terms of really customizing the author experience taxonomy and all these other, you know, you know, I need people to be able to add these properties or I need them to have this thing. So, so there, so there was, so there were things that were added. Do you want to speak to that at all in terms of like, what, what decisions did you make on, on what level of author customization options did you want to give to folks? [01:28:33] Speaker A: Yeah, that's a good one. This is, ooh, this is a really good one. I wasn't expecting this because I think there's, there's two angles here. So the first one is you all needed a date picker and it was like, you have no idea. Like we have no, we have no path to give you a date picker. [01:28:53] Speaker B: Right. [01:28:54] Speaker A: And we had, Speaking for myself, I had a little bit of PTSD with the amount of abstractions to, to add simple stuff to the authoring UI of, of traditional aem, especially like admin screens. Actually wrote a blog. One of my very first blog posts was like how to, how to work. [01:29:13] Speaker B: With. [01:29:15] Speaker A: Like how to build an admin screen in. In a. And it's like all sorts of like overlays and all sorts of like you're like reverse engineering the everything the JCR in CRX de knowing what you know about Sling and extending and resource super types and all all sorts of things like that. So it was like, okay, got a customer, they need to be able to, they need to be able to have a date picker. They need to be, they need to be able to own it. We kind of had. It's funny because like we kind of between Rafi and, and me, I think we originally started off with this sidekick idea of like what if we could, what if we could have an iframe living on top of Word and then you can kind of. And then started to look at like clipboard APIs and good things like that. So that was kind of the, the, the sort of alpha of what we wanted to do with ea. And so I knew that I wanted something like that, but I wanted it to be a little more predictable and a little bit more structured. And, and I don't know it. Predictable is probably the right word. And, and so it was like, okay, let's take the iframe concept from, from Edge Delivery, but let's make it a little bit more, let's make it a little more structured. So it's like, okay, you're going to add these two properties and then it's going to populate into the library. And so your library, your library has all sorts of fun stuff. It's got your blocks, it's got your templates, it's got icons, it's got placeholder values, it's got fragments, it's got plugins. So it's a library of all these different things. Just like you can check out a DVD from your library or you can check out a book. So doing that. And so what was really nice about this is the front end community has. This has been having these challenges of like, especially when you're a platform provider, the front end community, you don't want to be executing customer code inside your own code base. Just hard, hard Stop. So we were. And, and to be fair, like if you're on am, you are running, you're Running your code literally alongside now you've hopefully deployed it and everything. So we basically standardized on micro front ends for all of that, for all of the extensibility and what made sense from an extensibility perspective. We didn't want to have like a thousand different places and then all of a sudden you're back to AEM with like analysis paralysis of like, where do I do this? How do I do this? It's like, nope, you got one spot. And then yeah, the, the other piece was like. I didn't want folks to have to go through what I went through as far as like learning new technologies. If you want to use React, go for it. If you want to use Angular, go for it. So not only did iframing basically iframing your own site and so you make a little HTML page in your GitHub repo for your edge delivery project and, and then you bring whatever frameworks you want. So if you want a build system or anything like that, you can go for it. And then we will, we will one up Word in that we will give you a couple of functions that will allow you to push content into the editor. So you, you can, I think right now we have like four functions which is like you can get the current selection, you can insert text, you can insert HTML. And then I think there's one more. I don't, I don't remember what it is. And so again it's, it's, it's self serving but it's also nice in that we have a very small API surface so you don't have a thousand different ways to do something. But also you don't have to, which means you don't have to learn a ton of stuff like in, in five minutes. I think the lab is actually the, the, the lab we did at Adobe Developers Live is, is like my canonical happy place I guess for, for like da ext. I was going to try and not talk about AI because I feel like folks can, could use a break. But I will say this, the lab was great from an extensibility perspective because it was like here's how you build a plugin. Have your AI do the, the lab was. The AI is going to read your page and it's going to give you back 5 to 10 keywords for, for tags for your page and then we'll, we'll stuff it into the page and so you can do that like you can do that in 15 minutes. I spent weeks on AM extensibility like just reverse engineering like all the JCR nodes And, and everything of like how to get a button, how to get it deployed, what, what vault filters to, to run that aren't going to like wreck havoc and, and all of that. And like you just, all of that was, was not fun. So I didn't want folks to have to go through that. But you know, and, and that's, it's important for folks to know though is like if you have a need, let us know. You know, we have some, we have some other places where we kind of want to do some extensibility things in a safe way. That's another thing is like sometimes user experiences are less ideal when sometimes user experiences are less ideal in, in for the sake of security. So it's like, ooh, you build this thing and you're like, oh, this is awesome. Why didn't anyone else ever think of this? And then all of a sudden security comes down and goes boom. Here's, here's why no one has ever done this. You know, ooh, we have to fix this. But yeah, but I think it's been a success. I think I've seen some really incredible things that folks have built on top of DA and that, that lab, you know, you have the AI generate your tags and pause. You have your AI generate tags and then you as a human that's obviously non deterministic and LLM's just going to go wild. And then you as a human, you should bring in the governance piece which is like, okay, now let me, let me get a holistic view of all my content and let's see, like did the LLM do an underscore here and then a dash over and a hyphen over here? You could spend weeks trying to get the LLM to like be consistent. And, and we've, we've all done that. The whole like prompt and pray, right? It's like please just, and, or you can, you can say, okay, LLM is not going to be great from, for this governance perspective. So we're going to make an app and DA gives you the, the affordances to make a full blown app almost nearly identical to, to the DA ops themselves. And I will, I will bring in the governance. So that's, that, that's, that's something that's, that's been really exciting and really fun to see. [01:36:51] Speaker B: Well, that, the fact that it is simple and predictable and, and, and I also didn't want to bring too much AI into this because I feel like there's a certain subset of the population that like tunes out when you start mentioning it, but, but the, the fact that because of how simple that surfaces that you're working on, you end up kind of turning into. With. With da and with Edge delivery as a platform, you kind of end up turning into. It's a little bit, it's a little bit Green Lantern esque where you're mostly limited by like can you, can you imagine it clearly? Can you think about it clearly? And, but if you can imagine it then you can, you can get it put together pretty fast. And some of that stuff is, is, is complicated and well thought out. Also like, like this like our, our, our main engineer for, for the customer we brought live. I mean she's got stuff that she's put together for AM Rockstar as a result of this. That's if you, if you were like, if you rewind to any of my enterprise customers in like you know, say like 2017, like I remember clearly a financial services customer that we spent the entire year doing a 6.2 to 6.3 upgrade on AEM. There was not a ton of like great features that we implemented. There wasn't a lot of like real author enablement, developer enablement. You know, fun new, really nice stuff. It was, it was all guts and guts and, and, and, and a lot of work and, and to have talented engineers kind of drowned in that sort of non creative work for, for not that much output to see what one engineer can do right now is really, it's special I think. [01:38:44] Speaker A: Yeah. And you know you can, you can get into this trap. I certainly did when we built Dexter, which is like, you know, if, if you are too high on your own, on your own needs or, or you let your own biases sometimes you can, you can lose sight of things. And so you know, when, when we built Dexter, I would say like I've fallen on both sides of this. When, when we built Dexter it was like well what, what authoring. If I wanted, you know, omnipotent powers as an author, how what would it look like? And I, I built that and, and then all we had these, these, some of our technical authors loved it. And then some of our less technical authors are like just needed support every single day. And even as obsessive as we were about the authoring experience and so we let our own biases of like what would we want? We, we, we maybe over over corrected on what would we want. And then where, where that worked out really well was when we were working on the extensibility like David Boshart, he was, he was like I want to build this date picker for them. And I said, okay, I love your energy. This is great. I, I have kind of a loose vision of how I want a plugin system to work. So you, I need you to be my customer and you give me feedback. And so like, I'm gonna give you this. And then it turned out really great. And, and so it was like, okay, I don't want this like convoluted mess. I just want to be able to, like, I want to be able to work locally with my plugin. So I, yes. Refresh and, and, and it just works. And I don't have to do a deployment just to see my thing working and how do I do that in a secure way and like all those things. So that's just to say that like nuance and context is everything, maybe, which is maybe cheap. But you know, sometimes you have to like, you really, you can't go one way or another where it's like if you're too high on your own, on your own sort of biases and you have to be honest with yourself of saying, like, what are other folks going to want too? And so I've seen it go both ways, but I think we did a pretty good job on the extensibility. And like when we had the, when we had the school, it. This is also a really fun one. Like when we had the school system, they're like, we need to make a lot of schools really fast and we need non technical people to be able to make a school. And so Hannes, who's also on the DA team, Hannes and I built this little like site creator. And so we put on our customer hat and we're like, all right, we're going to build a site creator and we're going to use all the DA APIs and edge delivery APIs and we're going to be our own customer here. And so it was cool. You filled out the name, you filled out the principal's name and whatnot and you clicked a button and 50 seconds later you had a site, an entire site. And so we were our own customer. And what's nice about that is it validates like, ooh, this was. We had a lot of fun and we did this really fast. So I guess we're on to something. You know, it wasn't like, oh, this works for me, but not for you. No, it's like, no, it works for everybody. It seems like it's working out well for everyone. [01:42:17] Speaker B: I think that's an underestimated side benefit of the fact that Because I think some folks miss the fact that this so DA is an edge delivery project. And one of the, one of the core things that I think again is underappreciated but is huge on edge delivery projects is this idea that you are, there's no, there's no fixed environments and as a result of there being no fixed environments, you also have this, this, this ideal that you're always working toward of your local development experience develops with the full load of production content. So there's basically nothing. There's, there's a super limited set of things that you can't test when you're doing local development and an even smaller list of things that you can't test when you're, you've published to a branch for review. And so when you have that same exact philosophy toward your authoring experience, you have the same thing because a local, a local author, like take a, a local author, you have no, you have no access to production content. [01:43:24] Speaker A: You have no. [01:43:26] Speaker B: Unless you packaged up, you know, all, you know, 10 terabytes of your production content and somehow have them on your laptop, which is not going to happen. So you, there's all these things, all these things that you can't test then you won't test until, until you move them up and you've got the same thing now basically where your cms, the actual CMS itself is edge delivery. Therefore you've got a local development experience. That, that's, that's, that's just as good as it is on, on edge delivery for published sites. [01:43:55] Speaker A: It's funny you, you say that because like we, we kind of like. And again, this is sort of in the interest of, of security but like we actually made local development a little bit harder to solve some security challenges because you could, I mean you can still do this right now but like you go, you would do a up and if you didn't put like you have a throwaway sandbox or whatever, if you didn't put off on, on your project, you could just, you could just work. So if you have some throwaway content like go nuts and we. So local development was for building DA itself was as easy as AEM up and, and you worked against your production content. And, and so like if it's really important production content, you have it locked down, right? But what was nice is like if you had that sort of sandbox app, if you had that sort of sandbox project, you could work on your stuff and then when, when you would push up a branch for, to, you know, have Hannes or triple Chris check something. We we did just send them. So it was like how we build DA is exactly how we build edge delivery only recently. So which this is a whole dovetail into like product LED growth and PLG and all that. But recently a very well intentioned sort of white hat hacker, if you will, started to quote unquote, vandalize these open sandboxes. And we, we always wanted like from a, from a product LED growth. And the idea is like don't go like don't go put all your eggs in this product until you know people actually want to use it. And so when we were in this sort of PLG mindset, this sort of product LED growth mindset, we were like if you want to go like kick the tires on a sandbox project, you shouldn't have to sign up. Like signing up it, it's, it's almost, it's the cousin to if you don't see a price, you can't afford it, right? So we said like hey everybody, you know, just go make your content. If, when and when you care about your content, go set up authorization. Here's the docs. Some, some developers started to realize like, hey, there's a bunch of like open projects kicking around and again all sandbox throwaway stuff. But it's not a good look, right? It's, it's not a it. So we had to basically all of a sudden we're, we're no longer in plg, right? We've got plenty of customers. DA is going to survive like this is all, this is all great. And it's like okay, we need to start locking things down. So yes, while DA is very much first and foremost a edge delivery project, go run AEM up. Every once in a while you have to do something for, for security reasons or, or just like even, even, just not even security necessarily but like what's the right thing to do? And so you can still do am up. You just have to log into stage IMs. So sorry folks that want to go poke around DA like you're going to have to log into stage IMs. And that comes with some like how, how does stage IMS work and all that. But. [01:47:25] Speaker B: Anyway, well, I guess that, so that's a decent segue to, to another question I want to get into which is, which is so all, all of this is new to a lot of folks and so if you've been running your, your, your current CMS and you just really haven't had any reason to to dive into the edge delivery world, there's been, there's been, we, we've already talked through like three different evolutions of edge delivery over the last like three years. Right. And might have. But if you've been on running on prem gear and you just had no real reason to check into this, it'd be, it'd almost be like if somebody hasn't heard about LLMs over the last two years and suddenly you realize that there's a new world. So if you were trying to explain to somebody who is used to CMS requirements as they existed in, you know, 2020 or whatever, how would you, what, what, what are ways that, that you think that people need to just think differently about cmss? Because, because there's, there's all these. And I, I wanted to get into this like, kind of like Mythbusters kind of section of all this of like, you know, like, oh yeah, but. Oh yeah, yeah, but it doesn't do this. [01:48:38] Speaker A: Right? [01:48:38] Speaker B: Like, but is that even a requirement? Like, is that even a thing? So what, what, what, what, what different ways have you found that people need to start thinking differently about the way they're approaching content management? [01:48:53] Speaker A: Yeah, you know, the, the thing that I see that, that I'm seeing, especially from an AEM world, is developers. So we have these three pillars, right? Faster develop, faster site speed and, and faster authoring time. So. When you, you, you can't appreciate that until you're on the other side. And, and so the other. So, so not only is it like, you know, it's off in the distance somewhere and like, I can tell you that you're faster, but like it's, it's just gonna sound like Adobe's just usual old talking points or maybe some, some partner gets a project out the door and had a really fun time and came under budget or whatever. And so it's like, oh yeah, you're just, you're also just drinking the, the Adobe Kool Aid, of course, you know, and it's kind of like this is going to be a really weird tangent, but, but it's kind of important. So I, I don't drink alcohol. I, I used to. And then I stopped and when I decided it was like, hey, I like mental health and all of this. And it was like, oh, I want to, I want to live a life of, with without drinking. I would see people on the other side and they're having all sorts of fun and I'm like, I don't, I don't understand how I can go to a party and not have a beer. Like, it just like my brain could not wrap my head around it. And so, but they're all having fun and I, I can't, I, I don't know how to get over there. And so delivery is kind of the same way which is like they all look like they're having fun. I'm seeing smiles, I'm, I'm seeing like and I'm seeing problems getting solved and, and I'm seeing go lives and, and, and I'm not so I don't know how to get over there. And the thing that I always like, I think there's nothing wrong with starting with a small project. There's nothing wrong starting with a small subset of your, of your sites. Let edge delivery prove itself to you. Make sure you're set up for success. The big one that I see is that we get AM engineers that kind of like, like I know what I'm doing and I'm gonna go spin up my dev server and my, my QA server and how do I spin up a QA server and how do I spin up server? And I'm going to make the, oh, it's branches. Okay. I'm going to make a branch called Stage and I'm going to make a branch called qa. And it's like you're, you're destroying the value proposition of DA here. If, if all of a sudden you have to take your code from your local and then get it on this dev and you already have this branch here which you could send to get, to get any sort of sign offs that you need. But you're, you've decided that no, it's got to go into the dev branch. You've just, you're signing yourself up for overhead. You're, you're signing yourself. Another good example is like I, I saw folks, they start off with a brand new project and they're like we're gonna go live in six months and they make their, their dev environment. I'm like so you're not live, you're not planning on being live for six months. I get like wanting to have backups of copies or, or whatever. But like here's what's gonna happen. You're gonna, you're gonna do all this development work. You're going to get into like some QA or Stage server ish thing. It's not a server, right? I mean it's a serverless server tied to a branch name, right? You're going to get all this ready to go and then you're going to be like we need to go Live and you're going to have to do all of that QA and UAT all over again because you decided to put yourself into your own box, right? And so the challenge that we have is like, how do we convince you that this side is easier if you're like, no, I need to have a, I need to have a QA server. Even though there's nothing that can go wrong on a non production site. I need to have a QA server and a dev server and all this stuff. And it's like just, just make your live production site because once you validate that this page is great, you're done, problem solved, you just move on. If you do that in the, in a QA or stage context, that page is great. Now you gotta, now you gotta move it to your prod ins quote unquote prod instance which is just a folder in DA and a branch in GitHub in A, in a config bus entry. All of a sudden you're signing up for more work and so all of a sudden you, you go into this and you're like, I know what I'm doing. Edge delivery is easy. I hear it's easy. Why is it not that much better? And it's like, well, I got, I got bad news for you. You just brought along a lot of your, your sort of traditional AEM biases. And so that, that is like kind of a two prong issue. Is like how do we, how do we convince folks that this isn't just for baby sites? We need to give you examples, we need to prove to you. Because if all, if all of our marketing is like, look at, look at XYZ Blog. Look at, you know, it's like that, that ain't, that ain't gonna fly, that ain't gonna do. In fact that's, that's a, it's been a huge point of, of work on our, on our side and even going into 2026. So that, that's the thing is like so Edge Delivery can power adobe.com and I've seen edge delivery and, and adobe.com is still arguably one of the most especially for its size. Pound for pound, it's one of the most creative websites in the world. If you go to the Firefly product page, it's an incredible page built with document based authoring, highly interactive, all this stuff. And so it's like, you really have to, if you're like edge delivery can't do X, I think you really need to look at your own biases because I'VE seen every single type of site. I, I heard it was funny. I was on a call showing DA and somebody's like, you can't do single page applications with edge delivery services. And I'm like, what, what is, what is da? Is, is DA not a single page application? Because in, in many, many, many ways it, it is. And so it was funny. It was very, it was like, okay, sure. And, and that's another thing is like if you're not convinced, I'm kind of, I'm, I'm also a little past the point of like trying to convince folks spent a good year where if you say something, it's like what I tell my kid if she says something can't be done, well, her mind is already made up. [01:55:48] Speaker B: Oh yeah. [01:55:50] Speaker A: And so like if you say you can't, you can't. You're right, I'm not here. You know, I'm. If, if you're not sort of interested in having a good conversation about this. I, I think a mutual friend of ours had a really good take. Brett from rxd. [01:56:10] Speaker B: Dxri. [01:56:11] Speaker A: Yeah, yeah. You know, and he's, he's, I think he's kind of on record of being, I'm going to put words in under his mouth a little bit. Brett, I'm sorry, but a little bit of a Edge delivery skeptic. And we had some really great conversations and I was like, let's just have, let me just show you. Like you've, you've seen a lot of stuff from the peripheral. Let me show you a bunch of things in, in DA and he's like, he seemed to turn a little bit and, and I think his insight was really good. Which is like, look, at the end of the day we're just, these are just trade offs. AM is going to be better at one thing and edge delivery is going to be better at one thing. And so like for, for him, he was like, it's just a matter of trade offs. Like would I like if, if I have this paper cut on AM and I don't have it on edge delivery? Well, is my project better off with edge delivery? And it's sort of flavors of paper cuts versus like the paper cuts of aem. And I think your customer is a good example of that where I think they have an internal, they have an internal engineering team of like one or two engineers. And so like the complexity of AEM is the paper cut. Yes, they, the, the, the deployment and the, the Java HTL xml like all of that. Like one engineer can't necessarily support that. And so that was the paper cut for them. And so they said, oh, edge delivery is actually better fit because we can, we can do everything we need to do. Now again, paper cut on the edge delivery site. I need to be able to control server side markup. That is a hard requirement. I, there's nothing you can tell me that will ever change my mind. I need server side markup and edge delivery doesn't really support next JS very well. And am. I can do whatever I want. So I'm going to use AM and, and totally, totally fine. But I will say and this is a key area like 2025. If, if I was to roll up like my, my number one goal in 2025 was make sure DA survives. That was the number one goal because it was still in the card. It was early access technology. Again, January 1st didn't have a single live customer. So my number one goal was make sure DA survives. And, and that was like we did things just for pure sales reasons that we would not have maybe done. We did that so we could, we could get a close a deal or something. There was some pet feature or whatever. They're. And, and so like we're good now. Like DA is going to survive. [01:58:59] Speaker B: Yeah, yeah, yeah, we're well into that now. [01:59:01] Speaker A: Well, well yeah. Like DA is going to survive way past the point of early access technology. And so my number one goal for 2026 is to remove any reasonable reason why someone would not choose edge delivery. That's my number one goal is like remove any sort of reasonable reason why someone would not choose edge delivery. And so we have two very big tent pole features we're researching right now. So in going into 2026 and so because there are still reasonable reasons. What, what's funny is like one of those, I, I won't beat around the bush. Like one of those is structured content. We're looking at structured content. [01:59:59] Speaker B: Okay. [02:00:00] Speaker A: And I think it's called content fragments in the, in the AEM world. And this is another one of those like, you know, check your biases at the door. I don't necessarily have any use for structured content. If I do, I, I don't know about it. Or it's like 0.1% of. [02:00:26] Speaker B: Or you solve. You've already solved it in a different way. [02:00:28] Speaker A: Solved it a different way. Yep. And, and accepted the trade offs or whatever. Right, Touch on that actually. So structured content. And so it's like, you know, we have customers that are like hey, we want to use structured content and just from like, again, we do things for, for sales or at least to prove a point. Like if, if somebody comes in and says, well, can you do X or, or I hear edge delivery cannot do X. And that's, that's true. And so even if it's just a research project where I can pull it up, even if we're not shipping it, or it's an early access thing, it's like, here's our path to do this and, and here's all the research we've done around, around it. [02:01:06] Speaker B: We could make this prod ready. This isn't necessarily prod ready, but you're not checkmated. [02:01:12] Speaker A: Yeah, exactly. And so that, that's kind of, that kind of is, is sort of how I solve sort of the edge delivery skeptics, if you will. [02:01:26] Speaker B: Well then, then let me, let me, I'm going to skip right into a couple of my other Mythbusters ones because I hear this all the time when I'm trying to convince the unconvinced. So one of the other ones, and this is, this is going to get right into like, this is almost like a, somebody cussing at you. But this is folks saying that edge delivery is just a hack for hacking Google Lighthouse scores. And, and it's, and it's built around the whole eager delayed phases and so forth are all just a hack for, for an arbitrary target. It's a little, that's a little mean spirited when I, when, when one hears that. But, but what, what would, what would, what would be your response to something like that? [02:02:23] Speaker A: So. I think it's important to know and this is maybe a dirty secret or a not so dirty and not so secret comment. Lighthouse does not matter. Yep, Lighthouse, Lighthouse is developer bragging rights and maybe even executive bragging rights. The thing that matters is core web vitals. So you can pass Lighthouse and fail core web vitals. You can, you can pass core web vitals and fail Lighthouse. Lighthouse does not matter in any sort of material way. Lighthouse is useful to give you as a developer metrics on synthetic metrics to help you get to a good core web vital score. But ultimately a 100 lighthouse score means absolutely nothing aside from bragging rights. And it also tells you that somebody framed this really well on, on Lighthouse, which is like or on LinkedIn, which is if you have a 100 lighthouse score, it means that Lighthouse can no longer help you. Right? It doesn't mean that you don't have more work to do. It's just that like you've, you've exhausted what Lighthouse can do for you. You can gain. Now I think there's, there's, there's two parts of this. So you can, there, there's a, there's also a guy on LinkedIn that has this like the, the Homer Simpson meme of like he's looking all trim and then he's got like all of his, his extra parts like rubber banded behind him and. Right. Somebody, somebody talked about like deferring JavaScript and whatnot to that. You can totally do that. And Edge delivery, what I would say is the way Edge delivery loads content is. And actually the content is already there. Right. Unless you pull in a fragment or something. But the content's already there. It's already in the HTML for, for the majority of the content. So edge delivery is basically accepting the realities in which we work and it's giving you proven patterns that we're not doing any. Like there's no, I've seen plenty of questionable and I've even tried doing some of them. Like you can do questionable lighthouse hacks and everything that is in Edge Delivery and is in boilerplate and Author Kit and all of those. It's basically saying like, we're only going to give you what you need when you need it. Right. And to me that's not hacky. That's like just like if you're on a 4G connection in the middle of nowhere, a low end 4G connection in the middle of nowhere, you don't need to load the footer, you don't need to load the header. Those are not the most important parts. You did a Google search, you saw an answer and, or you saw something in the search results page, you clicked on it and you clicked on it not for the header content but for the actual content of the page. And so all we're doing is basically agreeing with Google and agreeing with the user that this other stuff is less important. And so, and we, we architected all of boilerplate and AMJs to do exactly that. And so it's like we will like is it a hack to say, hey, if I'm not using a block, don't load its JavaScript? That's not a hack. That's smart. That's intentional. [02:06:26] Speaker B: Yeah, yeah. [02:06:27] Speaker A: So it's important to know. But, but yeah, so I, I, it, I wouldn't call those hacks. And, and if you put, if, if you break down the abstractions enough of, of anything, literally anything, whether it's an organic bean or, or code or whatever. But like if you break down the abstractions enough, you can say well, that's just a hack. Like you're, you're writing in C plus plus, but the machine actually wants zeros and ones. You're just hacking your way to zeros and ones. Like, okay, that's true. [02:07:03] Speaker B: I don't speak binary. [02:07:04] Speaker A: Yeah. And, and so it's like it, is it less of a, an application to say like, you know, I'm using this abstraction. So. Yeah, I, but, but again, Lighthouse doesn't matter. Lighthouse will constantly give you misleading things. You can, you can totally gamify it. All of the AEM projects that you see, like, at least coming from Adobe, you're, you're not going to see any gamification. You're not going to see any shady. Like if it has this Google, you know, user agent, do X, otherwise do Y. Like, we're not going to, you're not going to see any of that. It's very foundational. Just load JavaScript when you need it, show content when you need it, don't prioritize the wrong things. This, this, to me this is just common sense stuff. [02:07:54] Speaker B: Well, I know. And on a, any site that is, it has a business purpose, the gamifications don't tend to survive because if they don't support the business, then, then they were there for exactly one iteration until you needed a feature. And then, then you're gonna get, you're gonna get practical again. [02:08:13] Speaker A: Yeah. And, and that's where I get back to like architecturally sustainable practices. It's, it's kind of like the, the LLM stuff, which Frank's blog post is, is awesome. I wish more people would write posts like his, which is basically like, let the LLM go take a first crack at it. But then like, you need to oversee it and you need to like an LLM is going to have nuggets of really great stuff, like really, really great stuff, but it can also make architecturally unsustainable code. And, and so it's like great. Like you see it everywhere. It's like, I made a thing in two days. And you're like, okay, well is that an architecturally sustainable two days? Like, is that still going to work in two years? So that's everything you see is, is very architecturally sound from, from us. We almost over, like over over index on that sometimes. [02:09:18] Speaker B: Right, well, so, so that's, that was another one of myths that. So I had somebody run into me at Adobe Developer Live in November. We were talking edge delivery and he was like, yeah, I'm, you know, one, one day I might go, that way. But honestly, like, all the Helix stuff, man, I could vibe code that in a weekend, like, I could just. I could just bust that out. I'm like, I. I know enough of the Helix team to know that that's super extra not true. But. But also just the number of intentional decisions there, to me, it's kind of like, you know, why didn't anybody, you know, vibe design The. The. The iPhone 4 when the iPhone 4 was released? Like, there's so many intentional surfaces and features to that. It might look simple, but, like, what. What. What's your. What's your take on. On the relative simplicity of Helix? [02:10:10] Speaker A: So there. There's two parts to this. Or. Or I'll give you two. Two analogies. So the first one is like, I. I really like. Oh, you know this. I really like espresso. I really like nice coffee. [02:10:27] Speaker B: Yep. [02:10:28] Speaker A: And there's a. There's a common phrase which is, espresso is an afternoon to learn and a lifetime to master Edge delivery. Very much is that you can learn. You can start building a block in less than an hour. You're. [02:10:44] Speaker B: You're. [02:10:45] Speaker A: You go through the tutorial that's going to be 15 minutes. Then you start reading some documentation. You're like, I want to get some pixels on a page. You're. You're going to be yelling real fast. Especially with all the new agent stuff that we released on AM Live. The. The next sort of analogy. And, and the challenge is, is that you will now spend the rest of your career making that. Great. You learned the basics. Okay, I know how to make a block. Okay, cool. I. I'm. I'm ready to go. I'm. Everything's a block now. And you're like, ooh, maybe. Maybe everything is not a block. And how do you know that? The other. The other analogy I would give, or the other quote, which I believe is a Mark Twain quote, which is basically. I'm. I'm sorry, this letter is long. I didn't have enough time to write a shorter letter. So you get up and running real fast, and. And maybe you're even vibe coding and everything. And then all of a sudden you have a block that probably only needed a hundred lines. And if you let the LLM run amok without too much oversight, you have something that's like 400 lines. And so all of a sudden you're like, okay, so the LLM kind of did you dirty there? Does it work and everything? And maybe that block is throwaway. Maybe. Maybe it's only for this one simple campaign vibe Code the crap out of that. Like do it. Yeah, but if, if you have this ultra precious hero block that you need, you, you do have a hundred engineer, a hundred humans that are going to work on it with their LLM buddy. You know along the like you are probably going to want to, to like write that shorter letter. You're going to want to spend the time to write that shorter letter. The other thing is like, you know there's kind of, speaking of blocks, there's, there's kind of these three, three different approaches to blocks. And I think especially if folks are coming from aem, they're sort of used to the JCR is very key value pair, right? It's like give me what are my properties, what are my JCR properties? And so, and also react and those things have kind of lend themselves to give me my props object or whatever and get out of my way. You tell me the key, tell me the value, get out of my way. I think engineers can naively go into block building with like, just like. And so all of a sudden you get like taking a button for example. If, if you do take this key value style approach you're like button text and it's camel case. So that's not going to be very author friendly. Author, author's going to mess that up and then button style and then you have button link and then you have, and all of a sudden you have like five in this like little key value block. When in reality what you want is just link, right? You want, you want to link with some semantics. And so I break blocks down for edge delivery into, into sort of three categories which is like you have your, your blocks that are defined by their semantics. This has a heading in it, this has a heading 2 in it. If, if I have text above a heading that means it's detail or eyebrow text. If I have an image in this particular cell, that means this particular block has a foreground image. If this, if this block has a image in this particular cell then I know it's a background image. So you lean on the semantics of the block. Overwhelmingly we prefer that blocks are built with like defined by their semantics. There are times and, and, and, but that is challenging if you're not used to that. If you're not used to thinking like okay, my author is going to give me an H1 with a link. How should that link behave? Like, do I want, do I want this link to automatically light up in as a button if it's in here or do I want to give my authors like if they bold it, they're going to get an accent. If they're, if they italicize it, they're going to get a secondary color. You know, things like that. So there's, there's the, the blocks that are defined by their semantics. And then you have your blocks that are, that are truly key value pair blocks. Like a forms block is a really great example. It's like just, you know, let me, let me define the little. These are or metadata blocks almost. They're, they're writing metadata blocks. Like section metadata is very key value pair like style. Give me my list of styles grid. [02:15:30] Speaker B: Which here's, here's the form I want you to use. Here's the place I want it to go. Here's the campaign that it's associated with. All that kind of stuff. [02:15:37] Speaker A: Exactly. The, the redirect URI like semantics don't really apply there. And then last but not least, you have link blocks, right? These are like, hey, edge delivery doesn't support nesting because they saw the mess that, that parses and responsive grid created from over nesting and, and misuse. So edge delivery doesn't support nesting. And so you're telling me I have a page, I have sections and then I have blocks inside the sections but I need like one extra level or something. And so it's like okay, what if we said this block is actually a link and so if it follows a particular pattern you. YouTube.com if I see a link with YouTube.com I want to have like images or my video next to some text. I can do that. I can throw the link in, it's going to hydrate into a YouTube block and then I have my text and they're both inside a columns block. So you have that third and final block style which is like a link based block or an auto block. So the, that's, that's sort of like, That's where I see, I'm trying to think of the, the right way to close this out. But the, the, the challenge is like you may come into this thinking that it's like super easy and it is super easy but like building something that's like world class, author friendly, it can take a little bit of time. And you're not just gonna like, if you want a really, truly exceptional like author experience and cohesive website, you're, you're probably looking at depending on the thing like you know, either and, and it really kind of depends on like how important is it. Back to the whole like hero hero block versus like vibe coded promotion. That's only going to run for like two weeks. And I think that's another fun thing that's about Edge delivery is like, at least on Adobe.com the, the Firefly product page is actually just such a great example because we would have. Marketing would come in and be like, hey, we want to make something really splashy. And we're like, well, it needs to be really splashy. Okay, what did you think about localization? Did you think about this? Did you think about that? And they're like, ooh, we didn't think about all of those things. And you're, you're quoting us like two months to build us. And we're like, yeah, because I know it's just throwaway, but we gotta have a Sling model and we've got to have a. We, we gotta make sure it's localizable and all this stuff. And, and so now, because blocks are so cheap from, especially with vibe coding, you know, the Firefly really just can't, can't say enough about this. Like, everyone should go look at it because it was like, it was like, yeah, we can, we can knock this out in, in two weeks. We have Adobe Max coming up. We want to make a really splashy page. Your design is ready. We're going to point the LLM at your design. We're going to have, you know, a hand over the wheel, so to speak. But we don't have to be too precious about the code. There's not a deployment life cycle that we have to worry about or anything. So go, go make that. And so all of a sudden marketing can be a lot more nimble and not feel like they're beholden to, to, to engineering. But again, there will be times where you're like, no, this is super important. Let's write tests. Let's, you know, whatever your criteria of really important is. [02:19:19] Speaker B: Well, I think though, so, and this is one of the things in that the simplicity of the design, or the apparent simplicity of the design that had so much thought put into it, obviously, and I don't think that we talked about too much is with, with a, with a wysiwyg, you are assuming that the, you're trying to edit the final product and assuming that the author knows the elements that the final product was comprised of, which is that's, that's, that's, that's in some cases very difficult to assume that they know that this was a form and this was a background and this is of this and this is of that. Right? So, so you have that assumption. You're trying to though tell still tell them to edit the final product. Whereas the reality of most content driven sites are is that the author starts from something that looks nothing like the final product. And, and, and it's the content creators or the content is that CMS user's job to somehow take the source of and make it look like the final product. And, and, and the, the, the, the, the speed and simplicity to which this type of document type document based authoring setup bridges the gap between the source information and, and, and the final and allows and allows that bridge to flow is to me the, the honest power of that is. What, where, where are you coming from? So you got this crazy thing. Oh, you want nesting? You want this crazy thing. I get it, I get it. Cool. Where where did you start? Where like where how does the data arrive to you? And the fact that the, the editing looks remarkably like the data that you started with? To me, I, I, that's an understated amount of power right there. [02:21:15] Speaker A: Yeah, I mean that's the whole thing right? Is, is, you know, back in 2020 it was really, I guess it was 2019, the lightning in the bottom moment of document based authoring. It was like it really came to just serving users or, or not even users but like business people. And, and it was like how do, how do you, let's, let's, let's go back to, to basics here. How do you get your content? Well, I get a Word document and then I pay a vendor $80,000 a year to take that Word document and put it into WordPress. What what? Or, and, and like a lot of like smaller sites. Right? So this was a lot of like helping friends and family. It's like hey, I'm doing research for a new CMS and you have a restaurant or you have an ice cream shop or whatever. And you like how, how do you use Squarespace today? Oh, I have a, I have a Google Doc and I just select my text and then I put it into my, into my Squarespace editor field by field. And it was like whoa, whoa, whoa, whoa whoa. What if we just got rid of that? And it was like maybe. And so now if, if I have some, let's say some C level person gives me a Word document. Now can we paste that directly into DA with without modifying anything? Yeah, you actually can. Now you're not going to get all of the fun features that you've had your developers build for your website. You know, carousels and things like that. You don't expect your C level person they don't need to know that stuff. They just. It's like make your content wherever you want. Give it to us. And we have a lot less work to do because it's already in a document guess. And that's what's kind of funny is like, especially like we, we definitely overly in. We over index on. On web pages, but within the, the sort of edge delivery Kool Aid drinking team. But it's like okay, you want a document, you want a homepage, your homepage is a document document. We're going to give you, we're going to have you create in a document and then you're going to be supplied a document. So it's like document, document, document. And they all have their, their sort of different, different flavors if you will. So the exec may come up with their own like bespoke how they do their tables to denote. Oh you know, put a, put a. I want to see a tabs block here. And you know, you don't have to necessarily train them but at least they, you. You have a fighting chance. You're not tediously you know, pulling out pieces. Oh, I accidentally didn't select that period or whatever. It's like command A, command C command V and then. Oh, let me go to my block library. Okay, recording. Click click, click click click. Done. Massage the content and, and you're you know, you're not in this like open dialogue hell. That's my. [02:24:24] Speaker B: So yeah, so okay, so I think I want to, I want to wrap up our, our, our marathon session, but I want to wrap it up on a, on a, on a. Something that was said. I didn't want to get into AI, but the AI is, is, is inescapable and how it, how. How the. The approach to pages and approach to the. This goal of all websites being page views and so forth and, and how this is. We're on the cusp of having something completely upend the entire web framework that we've been working with really the last 25 years. And like in terms of even the goal of what we're trying to make a website for, we've been trying to optimize for a thing which we may not be optimizing for. So this is. So if you're going to net new make a website a big one, a big thing for a big company, the thing that we're actually making a website for may be potentially totally different. Yeah, how, how do you see the, the, the job of the CMS and the, and the things that you're making the CMS for enabling any, I guess like the future that you're kind of envisioning or that you see, you see the web traveling in. This is super open ended but, but it's like, you know, you can't see. [02:25:49] Speaker A: There, there's two sides to this. So what's really interesting for me is that I think we're going to, we, we should, if, if, if, if we do things the right way, even if we do things the wrong way, we should encourage an explosion of more content creation where, where the conventional wisdom and I think Cedric touched a little bit on this at, at Adobe Developers Live or somebody. The conventional wisdom was like keep your pages short, keep them, keep them really digestible. If you, if you write a wall of text, no one's going to read it. Don't be overly verbose all those things and that's great for humans, but if, if a human is moving all of their search queries really questions to an LLM and LLM is going to scoop that up and it's like the more the, the, the more, the merrier, the more content and the more context that the LLM has, the better off it is. So you, you were almost pivoting to a world of more content. Now I would, I would strongly. And I am neither, I am neither skeptic nor like AI is fanboy is. Yeah, I'm not an AI fanboy. I'm kind of in the middle. But you can't, that has to be really high quality content. It can't be. We've all been there where we've asked an alarm to do something relatively creative and it just like, it's like a little too high on its own supply where it's like overly, overly like friendly or, or like over this or over that. And you're like, yeah, this, this, you're, you're just saying words to say words. You're not actually saying anything meaningful. So the, the trick will be how do we create meaningful content? We know, we know. I was looking at like GPUs that, that work great on Linux and like weighing the trade offs and everything. And this was all pure LLM. I did no, no traditional search engine stuff. And so like if I'm, if I'm weighing that and it's like okay, Nvidia has a proprietary driver so it's going HDMI 2.1 ATI or I guess AMD. AMDs have open source drivers so they're going to perform really well. But they, the HDMI consortium doesn't. This is all stuff I Learned from AN LLM like HDMI consortium doesn't allow the 2.1 spec to be in open source drivers. Weighing the trade offs like what can I do? So like the LLM had to consume a ton of like nerd blog posts highly detailed to help me make an informed decision. And if, if we are approaching content from like a. That really lends itself to I. The LM can give me better answers if it has more content to work with. So the trick is so that's more on the, the delivery side, right? It's like we, we. It's in your best interest to, to create more content but it has to be meaningful content. It has to be very sense. And and then on, on the flip side is as a, as a platform provider of a cms we have to. And I think we, we've seen this in other, in other areas. Like Apple famously was not able to ship all of their AI promises, right? And so what we have to do is we cannot set the LLM up for failure. So if you ask an LLM to do something that it's not good at, well you can't blame the LLM. If I ask the apple to taste like a banana, I should not get mad at the apple for not tasting like a banana. So if I'm asking an LLM to give me a determine like I'm expecting the LLM to do something very deterministic and if it, if it messes it up, I can't get mad at the LLM because it's like the LLM is very non deterministic. So we have a responsibility to, to give to, to set folks up for success. We have a responsibility to not over over prosthesize the the merits of of AI. Again that's my, my opinion of this is probably born out in, into that lab. It's like yeah, I'm gonna have an LLM generate tags but I'm gonna give a human the governance abilities to to help it along. So that, that's for me that's the big one is like my, my again my poster child customer the school system, they had like a three hour AI pitch and, and they were just kind of like they were kind of a little underwhelmed because they're like all this AI stuff is kind of interesting but like we don't see how it applies to us. And they actually were like hey, can you, you know we're your biggest customer. Can you give us like a one hour like roadmap session? And part of that roadmap session was like practical. The the. The title was like practical AI you can use today. So things like Smart Crop and and like our new focal point detection with the machine learning models and. And whatnot. And I think for me that's where like I want us to be is like how do we not over promise and under deliver and so how do we take like a very. Again this is another Chris Malar trope but like very crawl walk run in in terms of like how do we. How do we enable you? I think like things like LLM Optimizer and what we're doing as far as like stitching content together for LLM crawlers is really interesting because like that's not even an LLM thing but it helps you on the delivery side and things like Sites Optimizer not to get too like sales pitchy but like Sites Optimizer is another good one where it's like on the, on the box like hey, we're gonna auto fix this stuff for you and, and all of that. But like as you use it it's like we're gonna. Yes, the, the AI system will give you recommendations and you as a human you need to decide if that works for you. So a great example of that is like it might say like hey you. You need to. If you add. If you remove the phone number field from your. From your form sign up our data suggests that you will get X number more signups if you remove the phone number field. And it's like great LLM, thank you for that recommendation. But our salespeople need a phone number to call somebody or we are mandated to. And so you just like nope, goodbye. And so and, and other times the LLM is going to say hey, we noticed something because it can do things that scale that. That humans just can't. So it's like let's, let's set the. The LLM up for success and let's pick those tasks where it will be successful. The other piece I would say which I think is really interesting is like do if. If you remember the. The LLM the. This is both sad and, and also good in a way where in the the Web 2.0 era. So the sort of like flicker heyday area era. [02:34:09] Speaker B: I still have my Flickr account by the way. It's like 20 years old but yeah, of course. Yeah. [02:34:15] Speaker A: Everyone we. [02:34:17] Speaker B: We. [02:34:17] Speaker A: We realized that rest APIs were. Were like the, the amazing interoperability layer. And so you had everything from like blog roles so you could link out to your friends to you know, a lot of Social media at the time, again, early, early 2000s, mid, mid to early 2000s, a lot of social media had had rest APIs. And then all of a sudden this idea of these, these like closed walled gardens came in. And so the Web 2.0 kind of like, kind of went away. It was like, hey, Instagram came out. I want to be able to post an image. Like, I can Flickr with an API. And Instagram's like, no, you're not doing that. And that's even pre, pre Facebook buyout. So what's really interesting is that with LLMs, folks are starting to relearn that lesson that like, interoperability is actually a good thing if you have a. And it's kind of sad because, like, we lost that. I think, like having really great restful APIs, we. We lost that. That from the public web. And MCP has a chance where it's like, if I do a search in Gemini for a product, I want to be able to see those products. Well, I, I want to be able to like, buy, buy. Now, like, when I say another, another example, I, I did a search for. I was comparing mattresses. I was like, we have this old mattress. I guess it's discontinued. Can you tell me what's the, the closest one? I'm not going to try and figure out, like Reddit posts and all that. Just Gemini, just tell me which, which is the newer version of this mattress. So I would love to be able to just check out. And so MCP has the potential of solving that and some of the, even the. I'm not the biggest Chat GPT fan, but even, even like the app stuff that Chat GPT is doing, which is like just loosely disguised MCP servers. [02:36:30] Speaker B: Right. [02:36:31] Speaker A: At least that's my understanding. All of a sudden having an open ecosystem is, is becoming important again in like an open platform. So that will be really interesting being able to like, getting back to like. It's so weird that we're backing ourselves into Web 2.0 again with, through MCP. And luckily we have the, we have all the PMs that are on board with this now instead of the nerds trying to push restful APIs because we all wanted to talk to each other. Right? [02:37:07] Speaker B: Because now, now suddenly we need to be able to have a website that has its capabilities, its core capabilities exposed in a predictable way to a machine. [02:37:17] Speaker A: Yeah. And, and the research that we're doing around MCPS in the edge. Edge delivery space is really interesting. So again, right. As I sort of close or as I sort of Said like we chose certain technologies as sort of self preservation because we were a small team. One of the things that we, we sort of kicked down the road was searching. We have like. It's funny because our search is really just a filter, right? You pull down every single document and then we search it and we say does the string exist or not? You're, you're searching the raw HTML. The crazy thing is, is I was just waiting, I just, I've. I've just been waiting for someone to say like your search is not fancy like Google or, or elasticsearch or any of those Algolia. I've just been waiting for someone to say like technically speaking our search is like the dumbest thing in the world. Hold down every single document in a tree, see if the text exists or not. And not a single non technical person has said a thing. They do a search, they find exactly what they want. And it is, it is very terse. A MALD actually just added case sensitivity or turning off case sensitivity could because oh my gosh, like what you search is what you search. And so technically speaking it was just one of those things where I'm like, oh man, we're gonna have to, we're gonna have to pay that off some. At some point some, some customer is going to come along and say your search is not good enough stuff. And the hilarious thing is is no one has, no one has said anything. We've had some like interesting feature requests of like decorating the search better. Of like allow me to scope my search to a block. Allow my, allow my search to scope to a value. But we've never had anyone say this is not using, like no, no one has ever said this is not using elasticsearch or anything like that. That. So what's interesting is that we have an McP for, for DA and just, just playing around with it. And again it's all research. It's. We have, we don't have any announcements to make as far as shipping or anything. So I was just playing with it in general and so I said my canonical example of, of testing things in in DA is the Am Sites page. So it, I always for some reason like if somebody wants to see a demo or something, I'm like let's go look at the Am Sites page. Because it's a good metaphor of like I'm on a call, some partner is like edge delivery can't handle big sites. And I'm like our literal AM Sites pages in DA being hosted on delivery. So it kills a lot of People. But what's fun about it is so I'm on, on the MCP and I add my, my bearer token and, and I go find me, find me the Am Sites page. And it's like, okay, I'm, I'm in business. I'm in the tree of business. I, I think I gave it a little more help. It was like find me, find me the AM Sites page in the, the, the Adobe com bacom project. And it's like, okay, it listed the first, the first list and it says hey, I know I, in my world knowledge, I know that Am Sites is a Adobe product. So. And I see a folder called Products. Okay, I'm, I'm gonna go now I'm gonna go list the products page. Oh, I see a folder called Experience Manager. Am Sites is associated with, with Experience Manager. I'm going to go list that and then I'm going to list. I think it was called. There's like one other level I think maybe. And so what's crazy is like in, in our current search again which is a glorified filter, it just, it lists everything and then you, it goes until you're happy and you, you stop the search. But this was intelligent enough. And so now I'm thinking like, okay, so if I take, if I take that no one has really complained that they can't do like multi word searches or like and searches or, or searches. No one, not a single person has asked for this. It's really wild. If I take that and then we have this really great MCP server and if we put an McP in the UI, does this pass our, our, our test of like setting it up for success or are we setting it up for failure? And that's what, what all this research is is like do we like this ourselves because we're, we're a customer ourselves. And so that's. The other piece is like I think MCP is going to be really interesting. And the, the other and maybe last piece to, to this is that AI has fundamentally shifted how we build DA. It is 2025 has been such a success story for AI and DA in how we build and how we build DA. So early on when I went through all the research of what, what actual text editor to use, like the underlying thing and I even tried rolling our own and it was like there's too many weird browser quirks with, with editing text. So we standardized on this thing called prosemere. And I always knew that Prose Mirror was incredibly powerful, incredibly flexible, but the, the API documentation was, was real. Rough. And so the first year and a half or I guess like two years of DA building, building anything into the editor, it was like kiss, kiss two weeks goodbye to like make like if I paste in HTTPs www google.com like I want you to automatically convert this into a link and it's like okay, I need to know where your selection is. I need to know where you paste it. I need to know like all these like building a plugin for that like originally took to do like auto paste links took like a week of of traditional research and everything, right? This year we have made such incredible strides to the author experience inside DA for the document because of AI, because we can say let's build a working example of any sort of feature there. There's both good and bad to this. So the good is like some of our more seasoned like people that have used LLMs a lot and know like what is good at what it's not have the, the sort of oversight, right? You have this really eager junior level engineer right now and sometimes that junior engineer is really great and sometimes it's really bad, right? And, and your, your feedback loop is way faster. It's not like you go send a junior engineer off and they go, you'll spend two weeks and then you get, you come back and it's like oh my gosh, we just wasted two weeks on all of this. [02:44:48] Speaker B: They may have been developing, they may have been playing Call of Duty. [02:44:51] Speaker A: Yeah, yeah, exactly. So that's been one thing that's like fundamentally changed. And so we have to, it has accelerated DA's development. But then just for as many times as is an engineer says whoa, AI saved me a ton of time. And here's a really great looking PR that's like really concise and really well thought out and all of this. We also have other engineers that are like hey, I just vibe coded this, of course you want it. And it's like just because you can doesn't mean you should. And so we, that's, that's the one thing is like and, and you know, I'm all about vibe coding and I'm all about PMs, especially vibe coding. It's like, like go, go iterate with your junior level engineer. Figure out all the things you forgot to to think about. Like if you would have come to me in a different day, like a different age, you would come to me with your half baked ideas. Like go, go get that all sorted out with junior level engineer. Then let's go have like you can save both of us a Crap. Ton of time. You vibe coding with your junior level engineer and then you come to me with like a fully baked idea that it, where you know all the edge cases. I don't have to come and figure out all the edge cases for you. Your, your junior LLM engineer did. So I'm a huge fan of that. And again it's, it's pick your poison, right? So as we're doing research on, on the structure content, this incredible engineer, he, he went and vibe coded this thing and it was like, okay, there's something to this idea. Let's, let's go like maybe try to start making it real so we can put it in front of customers because I do not want to have a customer support ticket on top of all this LLM generated code. But we got the idea and it's like, okay, there's something to this. So that's, that's another piece is like LLM has, AI has really impacted in a, in a mostly positive way. I would say like 80% positive. LLM has really accelerated how, how quickly we can build things in da. And again it, the, the, the responsibility is ours to make sure it's architecturally sustainable. Sometimes that junior engineer knocks it out of the park and sometimes it doesn't. And so you hope that when the person hits submit on that PR that they've already done all of this sort of mentorship to get it into a good working state. But from a content creation perspective, again, more, more thoughtful content is going to be key. And then you know, mcp, don't sleep on mcp even for your, for your regular site. Go read Frank's post again. I, I couldn't recommend that post enough. So. [02:47:47] Speaker B: Yeah, sweet. Well, I think that this is going to be, we got like what, four months now or something like that, or three months. [02:47:56] Speaker A: Three. [02:47:56] Speaker B: Three months and change until Adobe Summit. Yeah, traditionally in the ye olde days of shrink wrap product versions and stuff like that, we'd all be like waiting for what is the new thing that you're going to come out with by Adobe Summit. I almost feel like right now like there's such a velocity of advancement month after month. Personally, I'm looking forward to folks getting a, a, a, a congealed set of understanding around what is the state of product categories now? You know, because there's, there's so many of these established product categories that you were assuming we're going to perform a function and is that function even needed anymore? Or if it is needed, what, what should it do in, in my job of creating content. So this is, this is a, it's a wild time to be alive. [02:48:54] Speaker A: Yeah, I, it, it, you know, it's funny, some folks I think have, have been a little nervous about, about AI and, and what it means. You know, like can can a customer go vibe code a cms? Yeah, sure, they'll be back. I don't, I don't know of a single customer that has ever built a homegrown CMS and been happy with it beyond like the first six months where everything's rosy and so like the, I think we have some really incredible technologies and we made some really good foundational decisions that, that have turned out to be really smart in a, in a post LLM world. And you know our, our goal is always especially my goal anyways is how do we empower people to, to make what they want to make. And you know, if you are an enterprising entrepreneur and you have a little five page site and you look at DA and you're like I don't understand document based authoring when I have webflow or whatever. If, if you have five pages having, having done something like this like yeah, like maybe, maybe the, the productivity gains and the author experience and the developer experience. Maybe all of that is because if you only have five pages, well that's what's the difference between you know, five minutes and five hours. Right? So you know, but if you have content scalability issues like I don't know that you have a better, you certainly don't have a better option. Especially like as, as commerce has come together. That's another one like really high SKU count. How do you manage this stuff? How do you create like really bespoke destination style sites that, because we are living in a post LLM world. So yeah, I think Summit's going to be really, really fun. You're seeing like we talked about Storefront last year. Last year was kind of like the coming out party of DA and Edge Delivery and, and Adobe Commerce altogether. I'm really excited to see what, what sort of the, the sort of like polishing down and refinements of those things look like. And yeah, Adobe Summit is, is by far my, my favorite time of the year. [02:51:52] Speaker B: Well, I'll be there. All right, well this was a marathon man. This. But I think that, I don't think there's any way that we could have slimmed this down. This is this. If you missed the Edge like we were saying earlier, if you missed the Edge delivery, you know, introduction, then this is this. There's no way to shortcut the amount of change that this has afforded to a traditional enterprise to a traditional, you know, flow of creating product. But here we are. [02:52:25] Speaker A: Yep. Yeah. Cool. Well, thanks for your time, Ted. I'm glad we finally were able to do this. [02:52:31] Speaker B: Yeah, exactly. And I guess. I guess we'll. We'll cut there. Okay. All right. See you.