 My name's Kevin, I'm with D-Dev, obviously. We've heard a little bit about that today so far. Going to apologize to everybody in advance because I did not know that I was doing this session until I was boarding the airplane to come here. So this is not as polished as I would like it, but I'm very passionate about the topic that I'm going to walk through. And it's basically the concept of taming complexity to champion creativity. Now, what that means for us personally being a product company is how do we align our product vision, how do we get everybody on board to understand what it is that we're trying to create, how do we keep the engineers engaged in what we're doing, how do we make sure that we're delivering value to the business, and how do we turn that into a community-based cycle so that everybody can participate, have a voice, make sure that they're being heard, and how do you do that in kind of a predictable fashion so that you can report to the right people so that you can have your executives be happy, have your stakeholders be happy and understand what they're getting and the timelines that they're expecting, basically. So, you know, really, why are we here? And for me, being the founder of DDEV, it's really simple. It's all about advancing developer communities. It's about working and finding the patterns, both with technology, with people, with the approaches for community management, engagement that we've fostered in the Drupal community, and then taking those ideas, not only to other communities, but to businesses in general to help people succeed in what they do. And for me, you know, the entire purpose of being involved with internet development, the reason that I got started was specifically because this is the first medium in human existence that allows us to span geographic borders, language borders, physical barriers. It's a very powerful tool that we have, and we're still trying to learn how to use it. So, the real question is, how can we bring all the complex pieces of a business together to execute effectively? And I'm going to walk through a little bit of philosophy and then maybe give you a couple of examples of how we do it at DDEV. And the one thing to recognize is that no matter what process you have now, you're always learning. You're always going to find new improvements that you can bring into your business, into your way of doing things, and you're going to need to have an open mind to be able to remain effective as the landscape continues to change. So, for us, you know, we focus primarily on hosting, on essentially the full life cycle of developer workflow, essentially. So everything from local development up through CICD integration, testing, environments, deployments, and being able to cover that entire gamut of things. And for me, a lot of times, the type of work that we do is very related to a pendulum. You know, sometimes it swings one way, sometimes it swings the other, but it always comes back to the middle. So the early part of the 90s, for me, 1990-ish, was learning about this new medium that we have, about the internet, about some of the possibilities out there. And then when that pendulum came back around from that initial learning, we started looking for patterns. It's like, okay, well, I created a login form. That took a lot of effort. What else is out there that's doing this login form concept that I can use? And that made you start looking at projects like Drupal about different communities that were coming together, that were working together to solve the same problems. And, you know, you've all probably heard somebody say that they're not the smartest person in the room in this community. And I'm the first person to say that. But what makes me smarter than everybody else is the ability to come together with community, with people like yourselves, to be able to realize all of the different nuances of problems in a way that I alone could never be able to address or solve. And as a result, we end up becoming smarter together. We solve larger problems. We impact the world. We change the world, essentially. You know, Drupal was not a name in the early 90s. It's definitely a name now, and it runs some pretty impressive web properties as a result. And those people have a voice now, and that's what this is all about. So essentially for us, you know, back to the slides, everything's been very difficult with understanding that pendulum. We had Drupal for a little while. We focused on the CMS side of it. Then it came back to the infrastructure side. Now that we have all these great projects in place, how do we get them out there? How do we make this effective? How do we keep doing this on a repeatable basis? And how do we deal with increasing amounts of traffic and increasing amounts of stress when our primary focus is not that side of the pendulum, right? We like to put the paint on the car, but sometimes we have to get our hands dirty in the engine. And that's a concept that brought about words like DevOps or, you know, a lot of the principles that you're seeing in that specific community about being able to represent your systems in a way that are automated, that are human friendly, that increase your productivity and your efficiency. So the people that feel the pain the most and the ones that we're really speaking to with this are the web application developers, the agency owners and the business managers that own digital experiences. So for us, there's kind of the concept of making these people more effective to stay very effective. And a lot of times right now in today's market, it's very easy to think, oh, well, I just use this one provider or this other provider, and then suddenly I don't have to worry about it anymore. But you make sacrifices when you do that, when you don't have the full understanding of how to be effective in the more complex parts of the infrastructure. So what that means is you might, as a small business, need to realize the recurring revenue from a hosting provider or a hosting relationship. If you throw that burden to somebody else, you tend to lose that ability to do that completely. So ultimately what ends up happening in my opinion is if you're running a service-based shop and you're continuously giving away the bulk of what should be your revenue, then you're stuck in a circle where you're constantly chasing that next gig, that next service. It's not a sustainable model. You have to work smarter, you have to start to productize what you're doing to become more efficient, to stay effective and to stay competitive with some of the larger providers out there. Otherwise it's a bit of a problem. So how do you get started? How do you become effective at what we do? Jam touched on a lot of the key concepts that we've ended up discovering by working with open strategy partners. So number one for us is how to define what it is that we do in a way that other people can understand. Those initial conversations were very difficult. They were very hard to nail down because we have a complex vision. We have a lot of moving parts that need to come together to be able to create a whole and being able to distill that down into something that's succinct that people will understand is very challenging. For us, the big push right now is doing it from a feature-based approach. So what does that mean exactly? Number one, it means being able to define on a product level exactly what we're building actually does. Being able to have a mechanism to communicate that with technology leaders to be able to align the product with the technical realities of the implementation. I believe it was Jim that talked a little bit about very ambitious salespeople that want to get out there and promise the world. You can't do that if you're gonna be successful. You have to be able to, number one, have people understand what those features are and let them understand how they can use that to deliver their sales pitch or whatever problem that they're trying to accomplish. So that means identifying your personas, turning those personas into use cases and user stories so that people can use them in a way that makes sense to them. And if you do it properly, then you can build a good base of features that can be used to address many user stories, many use cases. And that's when things get really interesting because then it's kind of like the module system for Drupal. You have a whole host of Lego blocks that you can put together in a different way to achieve a different effect based off of what you're trying to do. So general questions here. Where does complexity arise for your business? For us, the primary complexity that we have is not technical, even though the technology is very hard. We do a lot of work with Kubernetes, a lot of work with the Go language. We do things that are very progressive in the Drupal space. It was very difficult finding people that had that technical still originally, but as we align ourselves with larger and larger open source projects, we know that we're making the right technology decisions because we're seeing that there are talented people being created from making the right decisions. So by picking something like Kubernetes, instead of saying, hey, we're smarter than everybody else, we're gonna do our own hosting system and this is how it's gonna work. We're gonna make it all black box. We're not gonna tell you how we're actually going to do it. And then we're gonna market it as an open source thing because we think that we're smarter than everybody. That's not what we do. Instead we go out there and we look at the same kind of conversation that I had about the login form when I found Drupal. It's who's doing this? Who's doing it the smartest way possible? Who's aligning the most people possible to be able to achieve a specific thing? Who has the clearest vision? Who has the best governance model? How do they make decisions? And from out of that, we've determined that the Cloud Native Foundation is doing some amazing work right now. Out of that, they're hosting projects like Kubernetes, which everybody has probably heard of, but few people understand deeply. And the reason that they're being so successful at it is because they're evaluating previous projects that were successful and then building new models off of that. So again, not claiming to be the smartest people in the room, but learning from the collective. And honestly, they learned from projects like Drupal how to do open source even better than Drupal was capable of doing. So by aligning yourself with the common good it sounds a little cheesy sometimes, but it really does pay dividends. So that's one of the things that you have to ask yourself as you're making technology choices is are you making choices because you think that you're the smartest people in the room because you're going to solve some new novel problem that nobody else has or are you aligning yourself with best practices that are going to be sustainable, that are going to allow you to continue to hire talent, that are going to allow you not to isolate yourself and allow you to continue to grow and making that at a business level is a very important process that everybody needs to go through. So how can we minimize, clarify and manage complexity starting from plans, goals and roadmaps? Once you have a general idea of what it is that you're going to do or how you would like to accomplish it, you really have to start identifying the roadmap that you're going to be working on and it has to come from the top down. For us, how can leadership help with the team in a position to succeed from the outset? So we use something called objective key results and basically that's a system that comes, I read about it from a book called Measure What Matters which was written by one of the Google founders and this is something that's used in Google and many companies. So basically what you do in the general concept is you determine three to five main things at each different part in the company that you'd like to focus on. So from the top level that that may be something like, oh well, we want to increase sales by 15%. In order to do that, we have to have this specific key result actionable, this one actionable, this one actionable. So typically you come up with three to five main overarching concepts and then you break that apart a little bit into three to five supporting actions that need to happen to make that concept real. And that gets propagated throughout the organization. So based on the size of your organization, you might have different levels of that. For us, we have it at the executive level, we have it at the board level, we then again have it at the engineering level and potentially at the product and support level for us. So it's really important to be able to communicate exactly what it is that you're working on and a prime example that I use a lot is when you have alignment, when you know, everybody knows what you're working on, you can think of it almost like a naval ship. And if you contrast that with asking, say for example, you look at the dishwasher in a naval ship, you go find a dishwasher at a restaurant that has an after-school job, you ask that person what their role is at the restaurant that they're working at, they're gonna tell you, I wash dishes, I get a paycheck, I go home, I don't know why you're even asking me these questions. You ask that same question to the dishwasher of a naval ship, that person's gonna tell you, well, I get up ridiculously early, I make sure that my kitchen's clean, I make sure that my chefs can do their job so that we can get the food out to the troops so that they go out there and they win the war. They have the strength necessary to achieve our objective. And the distinction is very interesting because if you have an engineering team that isn't aligned with that ship, with that main direction, because it's not being communicated well enough, you're gonna find that there's a lot of busy work that happens. They may think that they're doing the best things for the product, but they might not be. So you're gonna find that your team may be overloaded or stressed from the amount of work that they feel like they need to do because in each engineer's mind, they wanna do the best job possible so they come up with every nuance possible, but they may not understand what exists outside of their immediate space. So they may not get the feedback from the users that they need to make the right decisions. They think that they're making decisions in the best interest of the user, but they're actually making decisions in isolation. And when they do that and you're not communicating clearly from the top down, then you tend to find that people start thrashing, that they're not as effective as they could be. So for us, we're gonna walk through a little bit of an example. I think that focuses on some of the personas that we like to involve on the team. And really, you're gonna have a whole host of different types of people involved in this decision-making process. And here at Focus is mostly on engineers. We've got Julie, the front-end experienced designer. We've got Dwayne who's a bit more API focused, maybe a back-end developer. And then we've got somebody that kinda spans the entire gamut. The other people that are included on this that unfortunately aren't on this slide because they didn't have enough time to prepare are your product people, your QA people, your stakeholders when you're communicating with your clients. These are the people that are also important in this conversation. So basically, we went through and did a little bit of an evaluation of how these people might want to work in some of the problems that they have, how they might relate to each other. So Julie's and how making the right tool choice and the right decisions can really elevate the effectiveness of these people. So Julie's, you know, a talented designer really is very creative visually. Likes to work by ingesting services to display to the end users. Doesn't really like to get in and write your complex SQL queries, but knows how to parse JSON from an API call, for example. They'd rather focus on creating the front-end than debugging a development environment or a deployment issue. So that whole concept of DevOps, a lot of the things that they would need to do to be effective to deliver their work to the customer, to reduce those feedback loops, to be able to make sure that they're delivering the quality work that the customer's expecting. Those are very important things and this type of person can get stuck in some of that nuance when it doesn't work very smoothly. When that ends up happening, they're not effective. They start losing their message. They have to focus on other things. Well, I don't know how to deploy to environment one when you're asking me to deploy to this environment. Instead, it works on my machine, how come it doesn't work on this server? How come everything that I just made died because we got an excessive traffic spike, for example. We also have Dwayne. Dwayne enjoys building APIs that work with server side data. Likes providing a bit more of the structure. It needs to use interfaces sometimes, but probably not their primary thing. This person's gonna have a significant difference in the tooling that they need to be able to do their job effectively. This type of person might be more interested in running XD bug instead of React, for example. They're gonna have a different way of looking at the system of getting in and understanding what the bottlenecks are than a person that's a little bit more visual will. They're more comfortable developing on a local environment than working with servers and would rather everything to just work. So they can get technical, but if you ask this person to scale up a memcache cluster or something like that to be able to account for a traffic load because you know that an editor is about to release an article on, say, a virus that's propagating and that's gonna get a lot of traffic. This person's probably not gonna be able to do that efficiently. They might get it done eventually, but it's going to be difficult. So you need to find a way to combine all these people and make them effective. And then we have the third persona that we're gonna be talking about. And this is kind of your unicorn. It has a full understanding of the entire stack from top to bottom, can solve React problems, can actually speak MongoDB, knows what clustering and sharding and indexing are. I don't believe that these people are real, right? I really don't. And I can probably answer a lot of the questions that a full stack person would answer, but I still don't believe that this person's real because it's too broad. You can't be an expert in all of these areas. So to even attach something like full stack is kind of silly in my mind. So basically what we do when we create what the tools that we have now is basically walk through a process of what should you look for when you pick these tools. And what we're really looking for is how to reduce complexity in a way that we can quickly share amongst a group of people. So for us that means things like exportable configuration. It means things like test driven development. It means finding the tools that are going to support your use case in the broadest way possible and in the most open way possible. So we spend a lot of time on what that means. And for us that means building communities. That means going out and finding the people that are using the tools and engaging in an active conversation. It means showing up at events to show people that we help support them and then getting the feedback. So the way that this translates to your business is if you're not talking to your stakeholders, if you're not talking to your users and you're not engaging them in a productive conversation that allows your product or your service to get better over time, then you might want to reevaluate some of those approaches because they can be very effective. And if you're not able to have that conversation with your customers, you're probably not able to have that conversation internally, which tends to lead to problems as well. So there's a lot of considerations that you need to go through and this is kind of how we do it. It might vary depending on your organization or service level, but this is our roadmap for the entire year as it stands right now. And it's very simple. This is an entire year's worth of work outlined on this board, but you start in very broad strokes when you're trying to paint a picture. It's much like rendering a picture on a computer. It starts off with maybe four blocks and then it turns those into eight blocks and then 16 blocks. And it continues to make that picture finer and finer until finally you have something that's just amazingly beautiful. So for us, we go through and really it starts at the product level and that product decision point comes from talking to your stakeholders. You have to be in communication with the community, with the people that you're building your services for to make sure that you're delivering them the value that they need. So for example, if I go through and look at that pass get lab support, sounds pretty not clear as far as what that is, but we break it down into user stories and these user stories become testable. So essentially what's happening by going through this process is we're starting to see not only the ability to communicate to our engineers, to the people that need to build the products, but we're doing it in a way that's easy to break a part, easy to validate. So what that means is if I look at one of these and I say as a user, I can connect my get lab pass in order to deploy my sites to DDEV Live. That's a binary, it's yes or no. Can you achieve that inside of a given time period? So for example, if I take that and tie it to one of the KRs inside of my OKR approach, I have my objectives, I have my key results that need to be achieved and this is something that I wanna support. I can turn that into a binary and generate a report off of that. So essentially in an ideal world, each of these user stories comes down to some type of a test, to some type of a way to validate that this actually exists in the product. And for us, that ends up becoming a Gherkin story. So we actually do have testing that supports some of these user stories. When we first started this, we involved most of the team in these types of conversations and we quickly learned that that did not scale very well. Everybody has an opinion, everybody has valid input and needs to be heard, but we needed to get the ball rolling to be able to continue to be successful and that's where first aligning the executive understanding of what's happening, what the business feels like it needs with what people are actually working on is very important. Without that alignment, you're just people are creating complexity for no reason. That's creating technical debt. That's making you slower and less effective at what you do. So what we did instead is we broke it up into a conversation that's a bit more between product and our lead engineers. So we go through from a product basis and basically say, okay, well, what is it that we need to do? Then we have our technical check and balance kind of conversation where the technical side says, well, I don't think we can do this or I think that we might be able to do that. And one of the things that we found out is that if you introduce a single point of failure, then it really does create bottlenecks. So for example, if we had a single architect that was responsible for all of the architecture of the system, there's a finite point where that system's not going to scale anymore, where that architect is gonna lose effectiveness and they're not gonna be able to drive a technical team. So breaking that up in a way that it can have multiple levels becomes important. And those are the types of things that you need to continue to look for in your organization is who is the single point of failure, who is the bottleneck, who feels like they're the most important person in the company and the company would come to a standstill without that person's participation and then look for ways to pull them out of that and split it up because that's going to make you more successful, it's gonna make your communication happen better, it's gonna share knowledge across the company and it's gonna make you more effective. So here we go through with the product team, flush out a little bit of the technical details and then essentially move that into the beginning of sprint planning. So for us, we take the ideas, the concepts that were kind of outlined in that initial conversation between product and engineering. We have something called an ADR record. So it's an architectural decision record. And what that means is that when there's a conversation between that initial technical person and product and decisions are made based off of those conversations that they're recorded in a GitHub repository where this work is about to happen so that each person along the life of whatever you're working on has the ability to understand why specific decisions were made and that stops youth from having to reinvent the wheel. So say, for example, you make very valid decisions five years from now, you have new engineers involved and they question the assumptions that those decisions were made on, they wanna re-architect the entire system. They at least have the ability to go through and evaluate what was done, why it was done and make more educated decisions based off of that. Otherwise, you'll come to realize that we as humans have a very limited amount of memory and we tend to reinvent the wheel consistently. Once we have some idea of what we're working on, we go through and start to size it. So here is just a snapshot from one of our Slack windows where we have something called poker planner going on. So break down the initial bulk of work that needs to be done, allow people to go through and start putting sizing on that and being able to measure your velocity and understanding where you're going as a team is super duper important. So let me try the right button, there we go. So for us, we use something called Zen Hub and what we do is we go through and we have some idea as a direct result of working in spreadsheets to record the amount of velocity that we can do. So we take that point system that was outlined in the previous step with poker planning to say, someone says this is going to take a three, somebody says this is going to take a five. That gives us a baseline unit of measurement to be able to say how many points we think that the team can do. So let's say for example, each engineer per sprint can do 20 points of work roughly. We know how to fill that bucket with requests. We don't want to overload that system but we want to keep it kind of loaded enough to be able to keep people moving rapidly essentially. So it's important to understand how fast you can move and then be able to adjust accordingly because if you can't set the right expectation that doesn't matter if you're dealing with your users, it doesn't matter if you're dealing with your team that's developing the product or the product people that are defining it or the sales people that need to sell it, then you're not gonna be successful. You're going to create stress, you're going to create tension that's unnecessary. It leads to reduced qualities of life and all kinds of fun stuff. And then essentially what we do, which I think is also very critical is we go through and extract each of those user stories that you saw, those are features basically. And we put those features into very specific files that we can then test on an automated basis. So part of what I need to do is I have a board of directors that I'm a part of that I need to report to and they need to understand what is being built, how it's being built and when they're going to be able to see X, Y and Z. So in order to do that, one of the things that we can do is we can go out and write the feature file for what's being developed that can happen at a product level and it kinda looks something like this. And what this is is basically a Gherkin file that tells us how we test Kron on our hosting platform. And everybody's familiar with Kron, we've done enough work with Drupal to understand it but it's a very basic thing. The feature here is users can enable or disable Kron tasks for their Drupal sites. That's something that we can test. We put that into an automated test run. We can say that, okay, well, we have zero percent test coverage, so now suddenly I've created a system that I can do reporting back up to the board of directors that says, okay, this feature that you're interested in, here's the dashboard that you can go to, here's the test coverage and you can see exactly in real time what percentage of that functionality we have implemented in the system and that sets the expectation properly. So out of the feature, we break it up into different scenarios that can be tested. So I have one, two, three, four scenarios on here. Each one of them may be 20% something along those lines. And eventually we get to a green board, everything's passing. Everybody knows that this functionality not only exists but is tested regularly inside of the system, so that way we know that even when new features come online, they're not breaking these features and we're not causing regressions or anything like that. So it's very important for us to be structured in the communication that happens from the product level to the engineering level and that structure is so important that we can use a vocabulary that will start to invoke automated tests. So it's almost magical at a certain level but it's a pretty neat system. Once we go through a sprint, we get a little creative, a little weird sometimes. And this was our last sprint, actually. So all of this is real data that you're seeing. This is our working system. So here we've used pirate ships in the past. We've used cowboys. We've done a lot of different things but we focus on the concept of a casualty. What was fallout, what didn't work well this particular sprint that you wanna talk about? And what we found is that by getting creative like this, it breaks up the monotony. So we started with spreadsheets just like we do with most things. In the world of DevOps, everything's essentially a checklist. So a spreadsheet's a great place to start. This is step one, this is step two, this is step three. Those are easy to automate. When it comes to dealing with people, people need a bit more engagement. So we found that the spreadsheet became real after a certain amount of time. People just constantly gave the same answers or stopped participating. But suddenly you switch it up a little bit, make it a little bit more fun. People get involved in it and we get better feedback. So we focus on what worked, did not work for us. And you see stuff like due to the rapid pace we are moving at, it's harder to document bugs issues and counter quality bugging problems. Dev environment is dead. Very specific things that we can make actionable. So and we continue to do that. It's important that you also listen. So you can't just receive this information and not do anything from it. You have to receive bits of information like that, turn it into a plan, let your team know that they're being heard and then help provide solutions for them. Even if it means engaging them or switching direction to be agile, to be able to help the team succeed. We focus on cabinets, things that might be a waste of time or take up a whole lot of effort that we didn't specifically identify initially. So that gives us the ability to make sure that we're not missing anything. The treasure, Rachel mentioned treasure a little bit earlier today, but for us treasure is things that went well. What did you succeed at? What were you impressed with? And then Valarice is kind of who went above and beyond. What was something that happened that you thought was exceptional? Do you want to call out any of your peers or anything like that? So engaging the entire team in the conversation gives you another opportunity to help align the objectives, the key results, make sure that people are on track and doing it in a friendly, kind of banter, light and conversation. So a lot of this comes back to just really focusing and this slides maybe a little bit out of context for the type of talk that I wanted to give today. So again, apologies for my short preparation time, but really can you look at the tools that you're working with and find direct value correlations is really what this is all about. Are you able to make a tool selection that scales for your entire team? Does that have implications for people that might come before or after? So say for example, you're working with a client that has a Drupal 7 site and you need to convince them to upgrade to Drupal 8. You need to make the types of correlations that exist here. Is this going to impact your business in a negative way? Is it going to be straightforward for us to do this migration? Is it going to disrupt your entire business in the process and why are these steps necessary to help reduce that complexity so that the next time that you need to upgrade, it isn't such a big deal and it starts to get easier, right? And those are the types of things that we consistently need to talk about to the people that we work with. So really for us, we have two tools that I think can help out a lot when it comes to agencies, when it comes to people that are making properties on the web or trying to help people communicate on the web. The first one that we have is something called DDEV Local. DDEV Local is essentially a map replacement. So if you've ever used map or anything like that, it gives you some of the things that you need as far as exportable configuration. It aligns people with future technology that they're not currently aware of. So for example, going back to that Kubernetes concept and what I was talking about earlier, the entire landscape of the internet is changing and it's changing so rapidly that most people that develop on the internet don't know how to keep up and don't even know that it's changing underneath them. So tools like this without people knowing about it are aligning them with that future direction. Now what that means is that, let's say for example that Docker is just a buzzword and it's gonna go away in the future and that's gonna be replaced by containerization but in a much more refined way than it actually exists now. What does that look like? What does that landscape look like? Well, if you look at a project like Kubernetes that has Google, Oracle, Facebook, Twitter, all kinds of larger enterprises engaging in it, you have to wonder if that's maybe representative of where the internet is actually going and how do we introduce tools that align people with that direction so that the work that they're doing now is future proof so that it can play into this modern landscape. That's where a tool like this that might use Docker now may one day export things as a Kubernetes manifest and suddenly we're moving people beyond Docker, beyond containerization, to running a very generic YAML-based approach to development that scales not only on their local machine but outside of their local machine. So if you have a Kubernetes manifest and you take it to digital ocean, you can just spin up your entire environment the way that you were using it without doing any translation at all. And if you have platforms like DDEV Live that are unable to work with that, then it becomes a super-duper easy transition and suddenly you're finding that the work that you're performing is more portable, is something that you can capitalize on and get more revenue than you have been because you no longer have to give it away to larger providers. You have the ability to own that a bit more which speaks to data sovereignty, it speaks to medical issues, say for example, you're in a HIPAA compliant contract and you need to capture the versions of everything that you're working on so that it can be stood up and recreated at a little later date if litigation happens. That type of thing is not possible with traditional ways of thinking but with some of these newer systems, not only is it possible, but it's easy. And that's the type of conversation that we're helping people understand by being thought leaders, by trying to give people the right tools that solve the complexity that they're dealing with on a day-to-day basis. DDEV Live's very similar, it's fast in every way that matters, it's got a developer-friendly CLI, modern framework preparing you for the future, that means starting to focus on a service-based approach, understanding the differences between what might work locally, what's necessary to do that, so for example, back to that XDbug example. In a local environment, you might want XDbug working but in a production environment, you don't want XDbug anywhere close to there because it's gonna slow down the system. However, you don't want any difference between the PHP version that you're running or the MySQL version that you're running so it's very important to have something and we use a technology which is also a cloud-native approach called BuildPacks and BuildPacks have the way to build Docker containers that are environment-specific so I can go through and say, if I'm on a local machine, I want XDbug to be installed whenever I have PHP running but I want that same stack to be deployable inside of an AWS-managed Kubernetes instance and I need those versions to be the same. We now have the technology to do that very easily but most people don't know that yet so there's an education process in a lot of these tools. It's very fascinating. So basically, using these approaches, using these tools, it changes the landscape completely. There's no more confusion. People like Julie can work on a broad range of sites. It's super easy to switch context. It's super easy to jump to a new client or to go back to an old client because it's just a single command and boom, all of that complexity is completely managed. It allows this person to communicate their message, their skill, what they're good at and do it effectively and it completely changes their life because they have extra time to focus on what that next creative piece is gonna be. They have the ability to innovate whereas before they may have been so overwhelmed by the problems that they were dealing with it, they may not have even seemed to be an effective contributor on your team so this does help people quite a bit. Dwayne has the ability to work with complex tools that mean a lot to him, don't mean anything to Julie or possibly anybody else and that person knows that what they create is what's going to be delivered so they don't have to worry about making things too complex or having to make them simple enough for other people to ingest. They do what they need to do as a service and then it deploys across many environments without any problems. And this person who I still don't believe exists has the ability to really focus on the other people on the team. They can suddenly, instead of being that one bottleneck that's so buried underneath the technical work that the rest of the team's asking because nobody else knows how to do, they're now free to teach. They can go and share some of these advanced concepts that they're aware of to the rest of the team, have the rest of the team implement them and suddenly everybody gets much smarter as a result. So it's a win-win-win situation essentially. So become a part of the conversation. If we solve common challenges together we can do a lot of good for a lot of people very quickly and that's the premise of why I'm up here talking. It's why we make these tools. It's why we engage in the Type O3 community in addition to the Drupal community, in addition to the WordPress community, in addition to the Sulu community PHP conferences. We like to help people and the more that we collaborate from all of these different communities, the better off we are. And a good example for the Drupal community I think is if you go through and you do a composer install of Drupal you're gonna see libraries from the Type O3 community come into that install to solve specific problems in the Drupal code base. You will not see a single Drupal-based PHP library go back into Type O3 because Drupal is not in the mindset of contributing those libraries back to the broader community. Those are the types of patterns that we need to help people understand and collaboratively I think we can do. So that's basically it. Thank you for stopping by. I'm doing the keynote tomorrow morning. It's gonna be on DevOps and emotional intelligence. And then David Stolen, our product manager, is gonna do a session on auto updates inside of Drupal which I think is pretty exciting. It finally brings Drupal on par with some of the other CMSs out there. So given that, any questions? I know that was a lot of information. Cool. Thank you.