I am absolutely delighted to be here. I'm delighted to be in London. I'm delighted to be here discussing the electric city because I actually love this phrase. It seems to capture the very heart of the dance between technology and the very human magic that actually makes cities work. It captures the connection between the ever changing nature of how we communicate over space, of how we travel, of how we buy and sell, and the most common, the most basic of urban interactions of sharing a meal or a smile of connecting with one another. Let me start, and in this room that I know has so many people who actually do have aesthetic sense, let me start by calling the support of America to make it clear that I have absolutely no aesthetic sense whatsoever, but this is in a sense a portrait of America. What I've done is I've taken the 3,000 odd counties in the United States and I've ordered them. I've ranked them on the basis of density. For cities are at their heart the absence of space between people and companies. Cities are density, proximity, closeness. The bottom line shows the relationship between median family income and density. And what you can see is that the densest 10th of America's counties have incomes that are on average 50% higher than the least dense half of America's counties. This is a common fact economists referred to it as the economics of agglomeration, which Alfred Marshall talked about 120 years ago when he noted that the mysteries of the trade become no mystery but are as it were in the air in dense clusters. In the United States, the three largest metropolitan areas in the country produce 18% of America's GDP, while including only 13% of America's population. The top line shows something that is somewhat more surprising which is the relationship between population growth between the years 2000 and 2010 and initial population density. As you can see, the denser the place was in 2000, the faster it grew until you get to the top 10th. Whereas at the start of the 19th century, Americans were leaving their dense enclaves on the eastern seaboard to populate the empty spaces of the American interior. At the start of the 21st century, instead of spreading out, we're clustering in. Now, the urbanization, the re-urbanization, the revitalization of urban spaces in America, in London, in Paris, in the developed world is nothing relative to what's happening in the cities of the developing world. Gandhi famously said the growth of the nation depends not on cities, but on its villages, talking about India. But with all due respect to the great man on this one, he was completely and utterly wrong. Because in fact, the future of India does not depend on its villages, it depends on cities. It depends on Kolkata, it depends on Mumbai, it depends upon Delhi, it depends on Gargan. It depends upon the places that are providing pathways out of poverty into prosperity, places that are connecting India with the larger world. For indeed, the relationship, and this shows the relationship between urbanization and income in the US, India and China. Again, one refers to the least dense areas, five refers to the most dense areas. As you can see, that positive relationship that I showed in the US is actually much weaker than the relationship between urbanization and prosperity in India and China. These are places that in fact urbanization, being in a city is even more vital for being part of the global economy for succeeding. Now, it is tempting to look at the traumas, the very real difficulties that cities face. And to think that in fact, wouldn't we be better off, despite all this prosperity, if people lived in farms. Sure, it's true that the more urbanized countries, the countries that have more than 50% of their population have on average incomes that are five times higher, but aren't they losing something by all this urbanization? And while certainly it is true that there are demons that also come from density, and we must battle those demons. On net, the right answer is cities. This is self-reported life satisfaction, ranked across the countries of the world on the basis of urbanization. What you can see is that people actually say that they are happier when they're living in urbanized countries. It is not true in the United States that people who live in big cities say that they're happier.  On the other hand, when you look in the developing world, people who live in cities do typically say that they're happier. And it's not just that more urbanized countries are five times richer on average, they also have infant mortality levels that are less than a third. Now, the success of cities in our age is something of a paradox. At one point in time, 30 years ago, all of our older, colder cities, London as well as New York, Buffalo as well as Boston, looked as if they were headed for the trash heap of history. Because indeed, it looked as if the trends of history were going to make urban density obsolete. After all, we live in an age in which it is effortless to telecommute across the planet, in which we could all just occupy whatever a silvan spot appealed to our biophilia and just dial it in. And yet, somehow or other, we've managed to come back to cities. But that wasn't obvious in the 1970s. These are two iconic images from Manhattan and my youth. The lower images, President Ford, New York had been hemorrhaging manufacturing jobs in the 60s and early 70s. The largest industrial cluster in the United States in the 1950s was not automobile production in Detroit, it was garment production in New York. And it was hammered by globalization, accompanying that with social distress, crime, economic chaos. And Ford was telling the city to get its fiscal house in order. The top image shows Jimmy Carter wandering through the wasteland that the South Bronx had become, where it really seemed as if cities were headed back to some sort of a rural past where the weeds would come out of the ground and reclaim the once tall towers of urban areas. It really seemed possible to imagine that that last scene in Planet of the Apes where the Statue of Liberty comes poking up out of the sand that that actually was a real possibility. And yet that's not how history happened, at least not in all cities. And I submit to you that the success of cities in an age in which distance is dead is not an accident because what globalization and new technologies have done is they've increased the returns to being smart. They've increased the returns to new ideas and innovation. This is what electricity has done by enabling us to connect across the world by making the world a more complicated place. And the more complicated an idea is, the easier it is for it to get lost in translation. The more valuable it is to rely on that most basic, most primal, most effective means of communication being in the same room with each other. Because we as a species have evolved over millions of years for having these wonderful cues for communicating comprehension or confusion that are lost when we're not together. And electricity isn't going to rewrite that. It's just going to make those ideas more valuable. It's just going to make the sense of being, the reasons for being in one dense area more important. This reminds us, though, of a central fact. It's not that all cities have come back. This looks at the population growth by the share of the population with a college degree as of the year 2000. It's a subsequent population growth across America's counties. Skilled places succeed, less skilled places don't. That's why the LSE is such an important part of London's fabric. That's why those American cities that had land grant colleges prior to 1940 have done so remarkably better than other cities have in the last 30 years. Boston's land grant colleges, of course, MIT. That's why on average, holding your years of schooling constant as the share of adults in your metropolitan area with a college degree increases by 10%.  Having skilled neighbors really matters, and it matters today more than ever. And that's what you're looking at here is the relationship between Perk Avenue GDP across metropolitan areas and the share of the population with a college degree. This is the relationship between skill area level skills and earnings in India, China, and the US. All of these things, again, the US has the weakest relationship with these countries. Skills and density, the power of connection to bring new ideas to fuel knowledge is really the future of the world and cities. Now, of course, cities are not just about the skills that are learned at the LSC or at Harvard. They're about the skills that are learned on the street. And there's no skills that are more important to urban success than the talent and inclination to be an entrepreneur. 50 years ago, the economist Ben Chinnitz compared New York and Pittsburgh and noted that New York appeared to be more resilient than Pittsburgh even then. He argued that this was a result of the industrial legacy of the two cities, of New York's great industry, the garment trade, born of the port, which had no effective economies of scale, that any person with a good idea and a couple of sewing machines could get started and see if their future was bright.  By contrast, Pittsburgh, city of coal, and the Three Rivers, Pittsburgh had steel, US steel, an industry based on economies of scale that no one would venture in if they were remotely sane and tried competing with US steel in this business. Great bread company men. And for the resilience of a city, the well of entrepreneurial human capital, the well of skills that are not just about coming up with a good essay to write, but about seeing new opportunities are really central. And it is remarkable, given how mediocre our measures of entrepreneurship are, that they do such a remarkable job of explaining which cities have managed to be resilient and which ones haven't. This is the relationship between average establishment size, small average establishments are typically thought to be an index of entrepreneurship and subsequent employment growth across metropolitan areas. Small firms, big cities. And of course, how do you engender entrepreneurship? Certainly the government has a major role with infrastructure, but above all, it's about making cities attractive for smart people to come and try their future. It's about having consumer cities that are places that are livable. And indeed, making cities livable is the great challenge of the 21st century, particularly in the developing world. Luckily, the cities of the West have indeed some experience in this. This is the evolution of death rates in New York City. A boy born in New York in 1900 could expect to live seven years less than the national average. Today, life expectancies in New York are almost three years higher than the national average. That didn't happen by accident. The current healthiness of New York reflects a great deal about what's good about cities. Lower level of suicide rates among the young. Lower levels of motor vehicle accidents among the young. But that didn't happen by accident. You needed to battle the demons of density. You need to create clean water. America's cities and towns were spending as much on water at the start of the 20th century as the federal government was spending on everything, except for the post office and the army. Now, of course, cities also need to make themselves affordable. And one of the trends that's perhaps not so beneficial is the relationship between density level and price increases. And we've seen this among a number of different dimensions. This is the relationship between price growth between 1996 and 2012 and initial density levels. The places that had a lot of people per square mile have just gotten more expensive. The challenge of creating affordability of making cities livable not just to the very rich but to middle and lower income people, that's fundamentally a challenge of housing supply. And this is actually the area that Jane Jacobs got it wrong. While in so many ways she was a peerless observer of urban life, she sometimes took her ground level observations too seriously. She looked at old housing and noticed it was cheap and new housing and noticed that it was expensive, which led her to conclude that the way to promote affordable housing was to make sure that no one built any new housing on top of old housing. And yet, of course, that's not how supply and demand works. You need to actually supply new homes in order to our city to become livable. But you need to build, and you need to build up. And indeed, you don't need to look further than Jacobs' own home district of the Greenwich Village Preservation District that she worked so hard to create to see the pernicious effects that can be created by freezing a city in amber. Her own home area, which was affordable to middle income people like herself and her husband in the 1950s when she lived there, now is a place where row houses start at $5 million and hedge fund managers only need apply. This is what freezing a city can do. One of the reasons, one of the many reasons why having an electric city conference is so important is it reminds us of the interplay between cities and the environment. And it reminds us that all those cities run on electricity. They can actually be places to minimize our energy use and actually reduce the harm that we do to the environment. After all, Henry David Thoreau, who was such a great advocate of living around the woods, managed to burn down more than 300 acres of prime Massachusetts woodland by starting a fire while it was out cooking chowders. We are a destructive species. Often the best way to take care of nature is to stay away from it. And indeed, that's exactly what our cities show us. This is from work with Matthew Kahn, where we've cataloged carbon emissions associated with living in different parts of the US, holding income and family size constant. And what you find is dramatically lower levels of energy use from living in dense areas, primarily because of smaller houses and less driving. One way to think about this is if the great growing cities of India and China see their carbon emissions rise to the level seen in the sprawling United States, global carbon emissions go up by 130%. If they stop at the level seen in wealthy but hyperdense Hong Kong, global carbon emissions go up by less than 30%. The Lorax is not a true fable. It's a myth. Building up cities is not damaging to the environment. It minimizes the effect of driving long distances, of building vast homes that use huge amounts of energy. Cities come together in their effect on the environment and on the economy. There are places in which human beings can empower each other by learning from each other and can actually make the planet safer for all of us. Thank you.


The CUBE's live coverage is made possible by funding from Dell Technologies, creating technologies that drive human progress. Hi everybody, welcome back to Barcelona. We're here at the Fira live. The CUBE's ongoing coverage is day two of MWC 23. Back in 2021 was my first Mobile World Congress. And you know what? It was actually quite an experience because there was nobody there. I talked to my friend who's now my co-host, Chris Lewis, about what to expect. He said, Dave, I don't think a lot of people are going to be there, but Danielle Royston is here and she's the CEO of Tatoghi. And that year, when Erickson tapped out of its space, she took out 60,000 square feet and built out Cloud City. If it weren't for Cloud City, there would have been no Mobile World Congress in June and July of 2021. DR is back. Great to see you. That's great to see you. Chris, awesome to see you. Good to be back. You guys remember the narrative back then? There was this lady running around, this crazy lady that I met at Google Cloud next. The cloud's going to take over Telco and everybody's like, wow, this lady's nuts. The cloud's been leaning in. So what do you think? What's changed since you first caused all those ripples? I mean, I have to say that I think that I caused a lot of change in the industry. I was talking to leaders over at AWS yesterday and they were like, we've never seen someone push like you have and change so much in a short period of time. And Telco moves slow. It's known for that. And they're like, you are pushing buttons and you're getting people to change and thank you and keep going. And so it's been great. It's awesome. Yeah, I mean, it was interesting, Chris. We heard on the keynotes, we had Microsoft, Satya came in, Thomas Curian came in. There was no AWS. And now I asked a CMO of GSMA about that. She goes, hey, we got a great relationship with AWS. But why do you think they weren't here? Well, I mean, they are here. I mean, not here. Why do you think they weren't profiled in the keynote? They weren't on the keynote stage. You know, at the AWS, a lot of the times they want to be the main thing. They want to be the main part of the show. They don't like sharing the limelight. I think they just didn't want to be on the stage with the Google guys and the Azure guys. What they're doing, they're building out, they're doing so much stuff, as Danielle said, with Telcos, changing the ecosystem, which is what's happening with cloud. Clouds making the Telcos think about what the next move is, how they fit in with the way other people do business, right? So Telcos never used to have to listen to anybody. They only listen to themselves and they dictated the way things were done. They're very successful and made a lot of money. But they're now having to open up. They're having to leverage the cloud. They're having to leverage the services that talk to you and people that provide. And they're changing the way they work. So, okay, in 2021, we talked a lot about the cloud as a potential disruptor. And your whole premise was, look, you got to lean into the cloud or you're screwed. The flip side of that is if they lean into the cloud too much, they might be screwed. So what's that equilibrium? Have they been able to find it? Are you working with just the disruptors or how's that? No, I think they're finding it, right? So my talk at MWC 21 was all about the cloud as a double-edged sword, right? There's two sides to it and you definitely need to proceed through it with caution, but also, I don't know that you have a choice, right? I mean, the public cloud, is there another industry that spends more on CapEx than Telco? I know. Right, now, hyperscalers are doing it, right? They spend easily approaching over $100 billion in CapEx. That rivals this industry. And so, when you have a player like that in industry, driving and investing so much, Telco, you're always complaining how everyone's writing your coattails. This is the opportunity to write someone else's coattails. So jump on, right? I think you don't have a choice, especially if other Telco competitors are using hyperscalers and you don't, they're going to be left behind. So you advise these companies all the time. I mean, the issue is they're all using all the hyperscalers, right? So the multiple relationships, and as Danielle said, the multi-layer of relationships, they're using the hyperscalers to change their own internal operational environments, to become more IT-centric, to move to that software-centric Telco. And they're also then, with the hyperscalers, going to market in different ways, sometimes with them, sometimes competing with them. What it means from an analyst's point of view is you're suddenly changing the dynamic of a market, but we used to have nicely well-defined markets previously. Now everyone's in it together, you know? It's great. And it's making people change the way they think about services. What I really hope it changes more than anything else is the way the customers at the end of the supply, the value chain think, this is what we can get hold of this stuff now. We can go into the network through the cloud, and we can get those APIs. We can draw on the mechanisms we need to run our personal lives, to run our business lives. And frankly, society's a whole lot. It's really exciting. But your premise is basically, you were saying they should ride on the top, over the top of the cloud vendors. Okay, but don't they lose all the data if they do that? I don't know. I mean, I think the hyperscalers are not going to take their data, right? I mean, that would be a really, really bad business move if Google Cloud and Azure and AWS start to take over that data. Well, they can't take it. They can't. They can't because of regulation, but also just like business, right? If they started taking their data, like no enterprises would use them. So I think the data is safe. I think, obviously, every country is different. You got to understand the different rules and regulations for data privacy and how you keep it. But I think as we look at the long term, right? And we always talk about 10 and 20 years, there's going to be a hyperscaler region in every country, right? And there will be a way for every telco to use it. I think their data will be safe. And I think it's just, you're going to be able to stand on the shoulders of someone else for once and use the building blocks of software that these guys provide to make better experiences for subscribers. You guys got to explain this to me, because when I say data, I'm not talking about personal information. I'm talking about all the telemetry, you know, all the plumbing data, which is... It will increasingly be shared because you need to share it in order to deliver the services in the stream-manifessional way that needs to be done. Did I hear the CEO of Ericsson right where he basically said we're going to charge developers for access to that data through APIs? What the Ericsson have done, obviously, with the Vonage acquisition is they want to get into APIs. So the idea is you're exposing features like quality on demand type features, for example, or even pulling, we still use a lot of SMS, right? So pulling that out using those APIs so that it will be charged in some way. Like Twitter is charging me for APIs now, I mean, API calls, that's the deal. You know what it is, I think it's Twilio. Oh, okay. Right? No reason why telcos couldn't provide a Twilio-like service themselves. It's a horizontal play, though, right? Correct. Two developers charged by the API. It doesn't need to be an industry standard to do that, as opposed to... Well, I think that's what they just announced. I mean, they just announced that. Yeah. Right, now, I haven't looked at that API set, right? There's like eight of them? There's eight of them. Twilio has... It's a start. You guys started so many days. It's a summary of them. And there's all the TM forum, there's all the other stands. Right, eight is better than zero. Right, I mean, for an industry that didn't really understand, you know, APIs as a feature, as a product, as a service, right? For Matt's granite, the deputy general of GSMA to stand on the keynote stage and say, we've partnered and we're unveiling, right, pay-by-the-use APIs. I was Ford. I was like, that is insane. I liked this keynote, actually, because I thought he was going to talk about how many attendees and how much economic benefit he said. We're super diverse. He said, I usually talk about that, and, you know, greening of the network, but I want you to talk about it a little bit. But that surprised me. But, you know, I've seen, in the enterprise, this is not my space, as you know, you guys won't live this. But I've seen Oracle try to get developers. IBM had to pay $35 billion for Red Hat to get developers, right? EMC used to have a thing called EMC code, you know, fail. I mean, they got to do something, right? So 4G, you know, they didn't really make the business case, the ROI on the investment in the network. Here we are with 5G, same discussion as having. Where's the use case? How are we going to monetize and make the ROI on this massive investment? And now they're starting to talk about 6G. Same freaking problem is going to happen again. And so I think they need to start experimenting with new ideas. I don't know if it's going to work. I don't know if this new API network gateway theme that Matt's talked about yesterday will work, but they need to start unbundling that unlimited plan. They, you know, they need to start charging people who are using the network more money.  They need to figure this out. This is a crisis for them. Yeah, the orange CEO, I mean, she basically said, hey, I'm for net neutrality, but I want to be able to charge the people that are using it more and more. Well, it's the choice to make a return on a capital. I mean, it costs billions of dollars to build these networks, right? And they're valuable, we use them. And we talked about this in Cloud City 21, right? The ability to start building better metaverses. And I know that's a buzzword and everyone hates it, but it's true, like we're working from home. We need, there's got to be a better experience in Zoom, in 2D, right? And you need a great network for that metaverse to be awesome. But Daniel, you don't need cellular for doing that, do you? So the fixed network is as important. And we're at a mobile world conference, but actually, what we're beginning to hear, and Crystal Brem did say this exactly, it's about the access is sort of irrelevant. Fixed is better because it's more of the cost of return and investment is better from fiber. Mobile, we're going to change every so many years because of a new generation. But we need to get the mechanism in place to deliver that. I actually don't agree that everyone should pay differently for what they use. It's a universal service. We need it as individuals. We need to make it sustainable for every user. Let's just not go for the biggest user. It's not the way to build it. It won't work if you do that. You'll crash the system if you do that. And the other thing which I disagree on, it's not about standing on the shoulders and benefiting from what, it's about cooperating across all levels. The hyperscalers want to work with the telcos as much as the telcos want to work with the hyperscalers. There's a lot of synergy there. There's a lot of ways they can work together. It's not one or the other. But I think you're saying, let the cloud guys do the heavy lifting. Not at all. And so, you don't think so? Because I feel like the telcos are really good at pipes. They've always been good at pipes. They're engineers. Are they hanging on to the connectivity or should they let that go? And go toward the developer. I mean, AWS had two announcements on the 21st, a week before MWC. And one was that telco network builder. This is literally being able to deploy a network capability at AWS with keystrokes. As a managed service. Correct. And so, I don't know how the telco world, I felt the shock waves, right? I was like, whoa, that seems really big. Because they're taking something that previously was like bread and butter. This is what differentiates each telco. And now they've standardized it and made it super easy so anyone can do it. Now, do I think the five nines of super crazy hardcore network criteria will be built on AWS this way? Probably not. But it's not N20, you can't know. Right, but private networks can be built with this pretty easily, right? And so telcos, they don't have as much funding, right? Smaller, more experiments. I think it's going to change the way we think about building networks in telcos. And those smaller telcos, I think are going to be more developer friendly. They're going to have business models that invite those developers in. And that's, the disruption's going to come from the ISVs and the workloads that are on top of that. Well, certainly what Dish is trying to do, right? Dish is trying to build, they launched it, reinvent a developer experience, built around their network. And again, I don't know, they were not part of this group that designed these eight APIs. But I'm sure they're looking with great intent on what does this mean for them. They'll probably adopt them because they want people to consume the network as APIs.  Okay, and then they're doing Open RAN, but is it, you know, they're not really concerned, they're not as concerned as Rakuten with the reliability. And is that the right play? In this discussion, Open RAN is not an issue. It really is irrelevant. It's relevant for the longer term future of the industry by disaggregating and being able to share, especially RAN sharing, for example, in the short term, in rural environments. So we'll see some of that happening. And it will change it, but it will also influence the way the other, the existing RAN providers, build their services and offer their value. You've got to remember in the relationship between the equipment providers and the telcos vary dramatically, whether it's Ericsson, Nokia, Samsung, Huawei, whoever. So those relationships really, and the managed services elements of that depends on what skills people have in-house within the telco and what service they're trying to deliver. So there's never one size fits all in this image. When you're very balanced in your analysis, and I appreciate that. I try to be. But I am not. When DR went off, this is my question, when DR went off a couple of years ago on the clouds going to take over the world, you were skeptical, you gave a balanced approach. Have you moderated your thoughts on that? I believe the telecom industry is a very strong industry. It's my industry, of course, I love it. But there was a relationship, it is developing much different relationships with the ecosystem players around it. You mentioned developers, you mentioned the cloud players, the equipment guys are changing. There's so many moving parts to build the telco of the future, but every country needs a very strong telecom environment to be able to support the site as a whole, people, individuals. Well, I think two years ago we were talking about should they or should they, and now it's an inevitability. I don't think we were done yet. They're all using the hyperscalers. We were always going to need to transform the telcos from the conservative environment in which they had control of everything, in order to reduce, if they get no extra revenue at all, reducing the cost, they've got to go on a cloud migration path to do that. That was all we thought. It's been harder than you thought? It's been easier than I thought. You think it's gone faster than you thought? It's gone way faster than I thought. I mean, pushing on this flywheel, I thought for sure it would take, you know, five to 10 years. It is moving, I mean, the maths thing, the AWS announcements last week, you know, they're putting in hyperscalers in Saudi Arabia, which is probably one of the most, you know, sort of data, private places in the world. It's happening really fast. I mean, I feel like I can't even go to sleep because I got to keep up with it. It's crazy. Guys, this is awesome.  Chris, thanks for co-hosting with me. I appreciate you staying here. Danielle, amazing. We'll see you. We got a lot of action here. We're going to come out and check out your venue. Yeah, the Chitogi buses that are outside. The big buses. You got a great setup there. We're going to see you on Wednesday. Thanks again. All right, keep it right there. We'll be back to wrap up day two from MWC 23 on theCUBE.


Everyone, you are here for, in it for the long haul, supporting and growing living sites in the post-Drupal 8 landscape. Hopefully you were queued off by that because there's a sign right there that says that's what you're here for. My name is Corey Nussland. I'm a senior project manager within Palantir.net's continuous delivery portfolio group. I've been with Palantir for about two years, I think, and I'll pass it over to Jew. I'm Jew Vanderwater. I'm a front-end developer at Palantir.net. I've been here for about four years, and within the continuous delivery portfolio, I'm playing the role of a product owner. I do a lot of work with clients, managing boards and tickets, and working with other teammates. And I'm Joe Meersman, a technical architect at Palantir. Been there about coming up on four years. I mostly play the role of product owner on our continuous delivery portfolio, and I get to work with these lovely people every day. Hi, I'm Jill Farley. You have to have a J name to work on the continuous delivery portfolio. I am a UX strategist by trade, but on the continuous delivery portfolio team, I play the role of agile coach, which really just means I'm kind of there to support the team and really look at the continuous delivery practice from a 10,000-foot view. I help with sales opportunities and really just help with long-range planning. And I've been at Palantir, did I say five years? Oh, you've said it now. And it sounds like we all are in a Shakespeare play because you're all like, I play the role of whatever, so we'll have to figure out what that's titled. We do have a couple polling questions that's just a raise-your-hand-style thing, so that we have an idea of who's in the audience. The first one is, who here is technical? You hold a technical role. All right, the vast majority. And who here is not technical by default, so you can feel included. Okay, great. Who here, what? Oh, Kent, yeah, that's a lie. All right, who here is maintaining or administrating a website that is currently live? Okay, oh, great, that's fantastic. And who here works at an organizational with a traditional hierarchical structure? As in you have a formal boss or a manager or supervisor? Okay, great. So, bit of context who we are. So, Palantir.net is a full-service digital consultancy within the company. We are with the continuous delivery portfolio. We support and maintain live sites. As my lovely colleague said earlier, we are both reactive and proactive. So, in the reactive space, we fix bugs. We will help with security updates, that kind of thing. But we also do proactive work. So, strategic work, building new features, that kind of thing. And we work to make sure that our client sites are so relevant regardless of how old they are. The reason why we wanted to do this talk today is because in the past, we didn't necessarily always operate within the best communication model. In the past, we had a lot of work rolling. We were always struggling with, not always, but we frequently struggled with swimming in the same direction. And communication within certain, maybe just within the team wasn't always as open as it could be. So, for the last year and a half plus, we've put in a lot of serious concentrated effort into forming new ways of working, kind of diagnosing what was going on and working with our communication. And largely, we've been very successful with that, in our opinion. So, the first question we have today for the panel is how is our team different? Palantir, I think we are, as a company, we're on a journey to a flat organization. And CDP, which is the short for continuous delivery portfolio, which can be a mouthful, we're a self-organizing team. And this is a pretty unique structure. A flat organization means that we don't have formal managers and the teammates work and make decisions as equal participants. And this is a, I feel like, sort of a really unique structure in tech and other arenas. But this doesn't mean that everyone has, say, equal responsibilities. Individuals hold roles and responsibilities that are proportionate to their skill level. Corey came up with this perfect analogy. She calls it the skill gravity. So, more skill you hold in an arena, an area, you attract more responsibilities that's related to that skill. So, I think that's a really, really great analogy. CDP is also a self-organizing team. This means that every team member contributes to the decisions that we make around our working environment and processes, as well as our goals. As an example, we create our own working agreements. We spend quite a bit of time talking and discussing brainstorming. And through consent-based decision-making process, we come up with a proposal with all the items that the team members are comfortable moving forward with. And once this is done, the entire team is accountable for following the working agreements and we're on the same page. There are many advantages and disadvantages to, I think, flat and self-organizing structure with everything, we're all people, right? But one of the most powerful advantages is that every teammate has decision-making power and feels more invested in their team and work because of it. If you have a say in something, you're gonna just feel more driven to accomplish goals and because you decided you're part of something. This environment provides teammates with excellent opportunities to take initiatives and demonstrate their abilities. This can be helpful in furthering career goals and you can really build leadership characteristics. Also, it allows our team to pivot real quick. We can respond to new opportunities or risks really quickly because we're self-organizing. We're a little bit more agile and nimble when it comes to these decisions around opportunities or risks. Some of the disadvantages would be it's a lot of work. It's very, very hard. Most of us are used to traditional hierarchical structure from a very young age, parents, teachers. We're comfortable in that top-down, doing what you're told environment. So self-organizing is really hard and you have to practice this mindset that's different that allows you to participate in this kind of team. And another disadvantage, I would say, is if everyone isn't bought into it, if a team member is not actively participating, sometimes some of those responsibilities can fall on other teammates. So that can happen because, again, we're all people and we're made of different personalities. So and some people are naturally uncomfortable in this kind of environment because we're in a society that has a lot of this top-down structure. And so not everyone feels comfortable being in there. So that would be a disadvantage. And as a team, oh, it's okay. And as a team, we try to foster psychological safety and Cory's gonna talk a little bit about that. Yeah, as soon as I don't die. So I did wanna, if it's okay, I did wanna jump in there a little bit. I'm not sure if everyone knows what consent-based decision-making is. Essentially, we make our decisions by bringing a proposal or a line item to the group and the group will discuss it, but people can't veto it just because they don't like it or maybe they have a better idea. It needs to be something that is unsafe or would cause damage to the team. The idea being that if someone has a lot of personal initiative and they wanna push something forward, they shouldn't be blocked by someone who just, excuse me, so sorry, would prefer to find a different way. Any chance you could take that? Because I think I'm gonna copy it. Yeah. I can jump in on second. Oh, sorry, sorry. So again, what's different about our particular team is, and you may have heard a lot of this thread throughout the conference and some of the presentations, especially from our team members, is we focus a lot on psychological safety. So, and I know we're talking a lot specifically about the way that we work as a team versus our technical solutions. So we, this is really like the core of why we think our continuous delivery team is really, really effective. So psychological safety is really the shared understanding within the team that people can take risks, they can make mistakes, that it is safe to try new things. And we try to foster that. There's a lot of data out there that talks about how teams that feel psychologically safe just foundationally are way higher functioning, that folks are just more comfortable trying and innovating when they do feel safe to fail. And so as a company, this is a foundational belief of ours, but within the CDP team, we've really, really embraced it and it's allowed us to kind of innovate in a space that maybe isn't always thought of as the most innovative. So we encourage asking questions, really building trust. We have a really open communication amongst our team members. And we're also 100% remote. And so being able to build that trust over Zoom, over Meet has been a challenge. It's been really interesting, but and this is the first time like some of us have met each other actually here. So to be able to feel psychologically safe in that kind of environment is really, really powerful. We talk about things beyond work and it really helps us build that support within the team. So those are a couple of things that we feel just fundamentally make our team maybe different, but mostly just more functional. We've built that foundation and we feel really strongly that it contributes to our performance. So Corey, if there's anything else you'd like to add about what makes this different, otherwise we can. Yeah, thank you. I'm so sorry about that, I was out of nowhere. One of the things I think that ties all this together is that Ju was saying the work is very hard initially. And I think that's a very valid statement, but we've gotten to a point now where the granite ball is like rolling down the hill. It's becoming somewhat self-fulfilling at this point because we've done enough practice with it. We've really worked with each other long enough that it's a lot easier to innovate and kind of decide, hey, what's the next direction we wanna go on? What are the next processes we wanna try that would help continue us on this path? And I think our team, of which several people are here in this room, would agree with saying that everyone is very participatory at this point. Like we've created the environment where people who maybe wouldn't have felt comfortable somewhere else do feel comfortable stretching, maybe picking up something that's new to them because they know that they have the support of the team. And when a mistake happens, we've really embraced this blameless culture of like it's not you that was the problem, it was we didn't address this situation fully, we didn't have a good handle of it maybe. And so now we're gonna take that forward into the next project, the next interaction and say, hey, how could we have caught this earlier? How could we have provided you the support that you needed so that it didn't go this route? And I've never worked at a place before where it had a blameless culture where you could make a mistake and be human and move on with your day. Yeah. All right, so our next question is how does this play out practically within our work in planning and how does that make our outcomes better? So to tie it back to the work and to tie it back to the theme of the presentation, I'm gonna talk a little bit about, since I am a strategist by trade, I'm gonna talk a little bit about how it plays out in our approach to support from a strategic perspective. So in traditional, I think in sort of a traditional idea of support or maintenance service within agencies, support work is often seen as a commodity. It's repeatable. There's a lot of times, both from folks that have been on our team that have worked for other agencies in that capacity and also first from some of the companies that we worked with in the past, it really is about how many clients can the support team take on, how many tickets can they move through since it's allegedly repeatable and it's the same old same old, whether it's security updates or bug fixes. And it's really about how much can they take on in order to have good margins. And that leads to burnout. So there's plenty of people that are like, I'm not interested in working in a continuous delivery or support atmosphere because it's just about cranking up the work. And even in our own company in the past, I think people have thought like that's not super creative work. It's not, support is not necessarily strategic. And I think that we, in our self organizing team driven approach, what we've sought to do is make sure that the work is fulfilling for our team. And so in shifting to that mindset, we've sought out the cool parts of support. We've tried to figure out how can we make maintaining live sites which I personally think is incredibly exciting and important because when you spend a ton of money redesigning a site and then it's out in the wild and people are actually using it, that's the fun part. And so we've really focused our energy on how do we make this support team feel fulfilled by the work to be challenged, to be able to stretch. And so we, in changing that mindset, we've been able to really have a good time with support. We've figured out how to share that with our clients, to get our clients perspective moving in a direction where they're thinking strategically about the long term of their sites. And that's kind of why we call it continuous delivery. It's not about just more passive support. It's about how do we keep your site growing and evolving and supporting your business. So just one sort of, I guess, tangible example of how we do that is we do road mapping with our clients. So we started this practice about six months ago and instead of focusing on a shorter sprint or a month long set of work, we actually sit down with our clients and co-create an annual road map with them. So what's coming up on the business horizon for your organization? Are there initiatives that we should be aware of and how can we plan for those as long in as much advance as possible? There's always things that come up in support. There's bugs, there's last minute requests. But the goal is for us is to try to think much longer in advance, make that visible to everybody and sort of be able to use those as like the markers through the year that we work toward and can strategically plan around and then fill in the gaps with anything that comes up or is necessary, whether it's patches or bug fixes. So the way that we do that is we really focus on three areas within the road mapping session. And we use Miro for this, so it's a very flexible kind of, again, visual co-created thing. But we really come into the session thinking about three things. So community-wide technology milestones, so as a new version of PHP coming out, obviously D10, some proactive from our team, some proactive ideas for enhancements to the site. So focus sort of an accessibility plan. How do we improve a site's accessibility over time? How do we proactively chip away at some of those things that we all know we should do? But they tend to fall to the bottom of the list when the emergencies come up. And then finally, as I mentioned, initiatives from a business perspective that are coming up for our clients. I mean, I don't know if anyone's been in the situation, but it sure is better to know about a CRM replacement six months in advance versus two weeks before all the forms on the site need to hook into a different source. So yeah, just really trying to proactively get out ahead of the things that are happening with our clients so that we're hooked in not just from a technology perspective but a strategy and business initiative perspective. So yeah, we've really learned a lot about being more strategic and less reactive. And we really feel like it's benefited our relationships with our clients because a lot of times it's hard for some of the folks that we work with to be sort of like the lone team member that's supporting the site or a small team that's supporting the site and to have a strategic partner, not just somebody who's like taking tickets and working on bugs is really, it's really helped folks think about their sites in a different way. I'm gonna stop for a moment and monologing. And Joe's gonna talk a little bit about some other ways that some other ways that this structure has helped us be more strategic in our delivery. Yeah, so I mean, we've talked a little bit about psychological safety. We haven't really talked a ton about how that's created and some of the benefits that come out of that. So starting with the benefits, one thing that I've seen from the technical side when people feel safe to make mistakes and or to talk about where they're at in their day to day work, people reach out much sooner when they're stuck or blocked. So, and I think the ways we get there are by really, I went to Brittany's session earlier and it's kind of reformed some of the thoughts in my head about the work that we've been doing. And I really, it really resonated with me. I think being authentic with your team is the way to really foster this psychological safety. So, one thing that I make sure really everybody I work with knows is that it doesn't matter where you are in your kind of engineering or design or whatever track you're on. It doesn't matter where you are on that track, you're still, everybody on that track is learning. There's never a time when you are planting the flag and saying like, I'm a senior developer now and I'm good, right? Like, I don't need to learn anything else. So, in that sense, we really are all in the same boat. I admittedly have swaths of the Drupal code base and contrib area especially that I don't know much about. And I've been doing Drupal development for about 15 years. So, I think it's really important to kind of share, make sure that people understand that nobody is the king of all knowledge and that we're all learning together. One thing that I often do as well is talk about times when I have been truly stuck or times that I frankly really messed something up which happens as well. And I think that that allows space for my team and teammates to then share that with me as it's happening or if it has happened in the past. And so really my point here is if you want honest and authentic interactions with your team, you have to be honest and authentic. And I can say that and it's easy to say but I will also say that sometimes those conversations are more difficult because you are opening up and sometimes that can feel like it's embarrassing or difficult to do. But I think it's really, really important. Another area that I'll talk about briefly is that we have different chapters that we've opened up for a lot of cross-team communications. So, all this stuff that I'm talking about for psychological safety applies to our team but it also applies to our development chapter. So, our development chapter is for front end developers, engineers and really open to anybody else that wants to come to it. And this is an area where I've really encouraged several times to have more of our junior team members to present topics, to help facilitate discussions, to bring something in that they're stuck on. And again, it's really creating that space for people to talk openly about where they are in their development process, where they are on their current project. We do a bi-weekly check where we just find out what everybody's literally working on that day. And that also creates opportunities for people to say, well, I'm not on a totally different project but I'm doing something super similar and I didn't even know you were doing that. So, opening up that communication and really, again, making sure people have the space to talk about it from whatever perspective they're at. Another thing I think that this allows and that I encourage is for our developers to look for strategic opportunities with the client. So, by being kind of flat and unstructured and also by kind of allowing this open communication, I highly encourage everyone on our team to have direct communication with clients. There isn't, there doesn't need to be a filter through a project manager or the senior dev to review the comment. If someone's having a problem communicating with the client, we're gonna hear about that anyways. So, and that really honestly just never happens. People are talking about where they're at in the code and they're putting stuff into places where the client can see it. It just opens the door for more communication and allows people that visibility and insight into our day-to-day work. Is it okay if I add some on that, Joe? Yeah. When we, when we have someone pick up a piece of work and we have a client call and that piece of work is gonna be discussed, that team member attends that meeting. If they want to, I don't know, be responsible for that piece, then they should be able to communicate with the client and tell them what they're doing and give the update on their own. So, it doesn't need to go through one of our POs to get to the client. And I think that's kind of unique. I don't think I've seen that in other places. Not only do you lose details when there's a middleman, but I think the most important thing you lose is that understanding the context of the bigger picture, the why, you know, why is the client asking for this? The other side, the other thing that that does honestly is allows the developer to have compassion, right, for the client, which, you know, if it's coming in as a ticket and you're just getting this request, you know, you can be like, why would you want to do that or whatever, you know? And I think when you hear them talk about it, after having done this for a long time, people, you can really understand kind of where they're coming from. And you can have that conversation if you still disagree in person and face to face. Did you wanna say something? No. Okay. Okay. Okay. Yeah, and I think the only other thing there is just really encouraging out of those conversations for our developers at whatever level to, you know, add tickets to the backlog from that. So if you heard something from the client and you think that might be some work we do, not only is that going to look proactive and great for the client, but it's basically soft selling, you know, more work for us to take on. Yeah, so I think all of that stuff, like that really authentic direct communication needs to be between teammates and between our team at all levels and the client. Yeah. Any final thoughts on that? All right. Does anybody have anything related to what we've said so far, that you know, you have questions about our comments and we don't wanna just talk at you this whole time. I know we left some space at the end, but yeah, there's... I feel like going back just a little bit, I really like the idea you're sharing reaching out to your clients. Yeah, great. Maybe you can talk. Yeah, go ahead. Just to finish my question. Yeah, definitely. And we do work agile. We use, as a company, we use the Scrum framework. We've actually adapted it pretty significantly in the continuous delivery portfolio, so we don't have as many ceremonies typically. We dedicate, you know, a pretty significant amount of our time that, and we work on a retainer basis typically, so we have like monthly minimums. And we try to use as much of the time as we can for the work with the appropriate amount of strategy and communication time and management time. It's a really good question about sort of the promise of timing. What we do find through the road mapping process is that we're able to plan further ahead and visualize for clients how much that work is actually going to take. And if we just stick with our minimum sort of retainer amount of time, sometimes how long that work will take or how much percentage of the work that we can do for them in that month has to be dedicated to that initiative. So an example might be like, you know, we had a client who, I think was at like a 20 or so hour minimum or 20 or so hour contract per month. And they wanted to do this significant redesign of like their news section of their site. And we estimated, you know, broad strokes estimated out the work and we basically said, okay, we're gonna give you a couple of options. If you do this with your minimum amount of hours, it's gonna take six months to get this feature rolled out. Given the amount of time we think it's gonna take.  If you surge at this level, you can get it done in two months.  If the cost is the issue, it's gonna take you six months to get it done. So it really allows us to anticipate and plan for that work way in advance if we know what's going on. As far as like nailing the date, that's the hard part. It sort of, like, since we're agile, we really, we say we can estimate the pieces of work as much as possible and then give you an option of how many, how much dedication it's gonna take to get it done by that time. So it really kind of is up to the client if they want to increase our focus on it or if they just kind of wanna wait and use their budget over the course of time. I hope that, does that start to get at any answer? Well, the advantage is you have your structure set search. Yes. I think for a team where it's like, they're kind of not always quite pegged with just kind of normal stuff, whether that's patching, bugging, whatever. And then you have initiatives on top of it. It can set these unrealistic expectations where it's just like, oh yeah, do all the normal stuff and then here's the other. Right. 60% of the work, we're just going to take 60% of the time where it doesn't exist. This is like, oh, we all wanna jump in. Do you wanna go first? So we just sprint planning with our clients because they have limited amount of work or like blocks or time that they are paying us for on a monthly basis. So we know how much work we can take in a month. And so we always try to prioritize the tickets in a sprint so that we can accomplish a certain amount so that there is no unreal expectation that we're gonna get 30 story points of work done in this month, even though they only have 15 story points available, right? And so that's where the road mapping I think is super useful because the client and we can just stay on the same page as to like how long it's gonna take and here are the sprints. There are bug fixes or like unexpected security update that we need to patch, then we contact the client. We make sure that they understand, hey, we have to pull this ticket in, but that means this one ticket for this feature has to be moved to the next sprint. So I think that open communication and clarity in how much we can fit into a sprint is really important in like managing expectations. And it sounds like you guys are able to not do that. Yeah, correct. We try to be. Yeah. There's definitely attention, you know, the idea of like, well, it just needs to get done versus we have a certain capacity and you have to make choices. It's very tough. And I think some clients have taken to that better than others, but the benefit of the longer term planning is that we all see what's coming up rather than it being a, you know, sort of this awkward sprint conversation in the moment where it's like, well, you know, we got to get this done. We have to get this done next week or in two weeks, like that example I used of the CRM replacement. If we get, if we back ourselves into something where we couldn't plan for it, that's, that is definitely a tough situation. But if we know it's coming in six months and we can kind of do things to account for, you know, maybe a shift in focus that it's not, it doesn't make it go away, but it's definitely improved our ability to like, think ahead, think about giving them options. So if like, we're like, okay, well, we can get an MVP done with the hours that you have available and the time we have available, and then we'll add to it as we go, that that's definitely a more proactive way to, to tackle it. I'll just add, I really think that you're, you're Jira board and the roadmap, they're, they're conversations, right? Which is, I think something that people tend to forget. Like you're, you know, your client should be looking at that board and making decisions with the hours that they have about what's the priority for this month. And it's the same thing for that long-term map. And so if you view it that way, the agile, the agility, right, is built in because you're not setting a roadmap and then saying we need to follow this. It's, it's building a roadmap, understanding that it's going to probably change as you get down there and you find something else has come up or whatever. But that's, viewing it as a conversation is the important part because the, I think every single hard conversation that I've had with a client throughout my career has been around managing expectations. So if, if the client knows what's coming and you know what's coming, you're usually pretty good.  Yeah, just to Jill's example about the client who was at the 20 hour mark and wanted this news feature, as we've gone through that project, we've sent them, you know, emails that are very like MVP related about like, here's where we're at. Here's what we told you. Here's what we think is going to happen. Here are the things that have changed since we last talked to you. I mean, granted, we're not spending huge amounts of time between each point of contact, but it is very clear. We're very much trying to like set the expectation for them that, yes, we told you, we think we could get it done within four months based off of the budget that you wanted to use. Here's how that's being impacted and like kind of giving them a window into what we're doing so that they don't feel like, oh, well, you promised us some date or whatnot. Like even people are human, right? So even if we don't put a date on it, they'll naturally say like, well, you know, we thought you said you were gonna be able to do it by this point. And that I think has really helped. And I don't think we've had, it's really helped. The client clearly appreciate it. I think somebody else had a question or a comment. Yeah, go ahead. That's a great question. And we're actually just to be totally transparent, like we're trying to figure out what our threshold is. And so we work a little differently than some of the other project teams at Palantir. Some of the other project teams are, you know, we call them more like solution delivery. The folks that are allocated to those projects work half and whole time allocations, which are done in weeks. So basically the way we estimate it is it's X number of people, full time or half time for X number of weeks. The continuous delivery team works on half and whole day allocations. So it's kind of like if a project is at a certain threshold of time and it's gonna take a dedicated team, then usually that is pitched more as like end-to-end solution delivery project because we're what we call a fractional team. So we have 13 or 14 clients in the portfolio. And so it's almost like a work marketplace. We scrum every day and we have this pretty cool tool that Corey puts together called our Black Model. And depending on how much time all of the different clients have available, our teammates are able to sort of pick and choose what work they wanna do that day. And so we're able to divide our time across the portfolio. And if a project requires too much of a dedicated resource or multiple of those, that's usually when it transitions. We have a very unique structure in that we're able to kind of like fill our space by nature of the fact that we have a lot of different clients. So yeah, hopefully that answered your question. It's usually if there's more than three dedicated people on the project is what it would take to actually complete the project and the price tag gets to that point. That's when it would transition over to more of a dedicated team. But they may come back to us. Like it is possible that we would sell a solution delivery project that has a dedicated team where part of our conversation is, do you want continuous support after you're done with that? And then they would come back into our team within that fractional model. Any other questions? Really good questions. Thank you. Well, we have one more question because I think we do have 10 minutes left. That's accurate, right? We started at four 10. Yeah, okay. All right, so how do we make sure that we keep learning and getting better on this journey? I can kick us off. So if you attended Brittany's talk earlier or Corey and Travis's talk, we talk a lot about experimentation and incremental improvement and the idea of 15% better. So instead of overhauling things very regularly, we do small incremental experiments to try to see how we can improve our processes and improve even with our clients. Like we're starting to work on, okay, well, we're noticing that your site's performance is here. What can we do to get to 15% better performance or 15% stronger accessibility performance? And so we just have really ingrained into our team that experimentation and incremental improvement is way more valuable than trying to either get perfect or have zero tickets roll. How do we, and we've actually started to measure, we have some metrics as a team. Like how many tickets have rolled? How long have tickets been sitting in different swim lanes in Jira? And when it comes to the road mapping stuff, like I can be honest, we've tried this with half of our clients. Thus far, we've done like hour long road mapping sessions. Every single one has been a little different. We did a retro at the beginning of one to see what the client was thinking about our relationship. And we adapted the session based on, you know, their feedback on how our service had been over the last year. And there's some, it hasn't worked in every case. There's definitely some clients that are like, I don't wanna talk to you about my annual roadmap. I just want you to fix the bugs that I throw your way. And we're progressively getting closer and closer to more strategic relationships in continuous delivery. But, you know, in some cases, it's been hard to get folks to prioritize that time, but it's an experiment. We're trying to learn more and more incrementally about our clients and their needs. And so that's just one example, but I don't know if you guys have some more examples about growth and improvement. Jew, I think you were gonna talk a little bit about our team structure and teaching folks. Yeah, we love growing in different ways. And one of the ways is we just added some junior members into our CDP team. And we love it. They're so much fun and palantir. What one of them is here? Palantir in general, like we're really passionate about growing talent and giving folks opportunity. And so CDP has been a really great place for us to bring on junior devs and mentoring and helping them grow. And it also really provides an opportunity for senior devs to grow as well because they are learning those coaching and mentoring skills. They're coding together and doing PR reviews together. And it is a really valuable experience for everybody. And clients love it. Like when we tell them, hey, we have an intern who's learning stuff. And most clients, they love that kind of diversity and the fact that we're passionate about it, I think is a positive thing for the clients as well. So that's one of the ways that we grow our team and experiment them, learn. Any other experiments, Corey, that you've launched recently to learn and grow that you wanna share? To be honest, I think I torture this team a little bit with all the experiments that I throw at them. It's quite fun to say, like, hey, I saw this thing. Why don't we try it and see what happens? And sometimes they're like, yeah, let's absolutely do that. That sounds exciting. And sometimes they're like, you've asked us to experiment twice this week. Can you please take a step back? And we've done that as well. And it has worked out, I think for all of us. One cool experiment I feel like that you brought to us was the blameless postmortem structure. Obviously in support or in continuous delivery, we're learning a lot very quickly with a lot of clients. And so we have to learn and adapt and pivot quite often. And one of the things Corey brought to the table was a process called a blameless postmortem when there's an incident or something does not go as planned. How do you learn from that without having someone feel like they're responsible? Yeah, and that directly contributes to our psychologically safe environment because the idea that anyone is gonna be able to say, oh, I provide service to clients and we never have anything bad happen and so we can't learn from it. Like even if you say that privately or publicly, like we all know that's not accurate. So what would be more beneficial for the team is to say, hey, what were the set of circumstances that occurred here and how do we have them not happen again? And or how do we address them when we start to see that something is going down that path and those paths can be started externally or internally. But if people are willing to recognize that a mistake has occurred and we can talk about it in a non-judgmental way. So like we don't spring this on anyone. It's more like, hey, this thing happened. Do you feel comfortable debriefing on it with us and we'll work through the blameless postmortem format which is out there. So if you're interested in trying it, you can definitely look it up.  It's more like in a circumstance where you have a client who wants this and you have this set of skills, what is it that's missing in that equation to like kind of ensure that the end product is the best that we could possibly deliver. It's a very like honest thing to look your mistakes, I think in the face and say like, my bad, how do we not do that again? And I think our team is really good at it. Any other questions with our five minutes left? Yeah. Everything we do is bespoke. Thanks, Fred. Yeah, so my question was if people on the website are using www.cbt.com. I'm not sure if anyone can tell, but this person works with us. So yeah, you could go to Valentineer.net and I believe there is a CDP page. And www.dripplecdp.com. Yeah. Oh, www.dripplecdp.com. Oh, look at that. Yeah, yeah, we have a small army here. Yeah, we're a small mob. We also have a booth so you can come by and get the best tote bag ever. And I know we had some technical folks and we didn't do a lot of technical discussions if people are wondering, you know, I wrote down so many notes for this and some of them are specifics about some of the problems that we've encountered with dependency chains. I think it's been really interesting in the post-Drupal 8 landscape that we're now supporting sites instead of for three years, we're going to five, seven, 10 years. And kind of how do we set up and maintain 13 sites when we bring a new developer on? Do they have to set up Docker and DDEV for all 13 sites? If anybody wants to talk about that afterwards, I'd be happy to talk about it. Yeah. Yeah, and I think that's a really cool positive. Yeah. Used to be, yeah, we're doing this awesome thing for you and we're getting things. Yep. Because it's a Drupal 7. Right. That's right. And I think you'll find quite a few for that. I really like you guys. That's why I think we find that there is such value in putting energy and time into a continuous delivery team because the more investment, the more incremental investment folks can make on their sites in this age and think about it again, proactively and strategically, just the more the healthier the site's going to be and the more it's going to work for the organization. And I think what we spend a lot of time doing is justifying the effort and the investment in the incremental improvements. We work with our immediate clients to sell up to the higher ups or other stakeholders, why this incremental investment makes a lot of sense this year or six months before something is end of life. Like let's do it now so that you're not encountering issues later or let's look at your accessibility on a regular basis so that it's not this like, oh God, we're out of compliance. I mean, COVID literally opened the door for I don't want to say board people but people looking at healthcare sites and saying how can I file lawsuits against these healthcare sites because they're slightly out of compliance in some way. Like some of our clients have encountered that. And so staying ahead of that kind of thing has really paid off for a lot of the folks that we work with. Well, I think that is our time. I hope you all got something out of it. We do have a booth. So if you have any further questions you can come chat with us there or you can stay after and chat as well. Thanks for coming. Thank you.