 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, which is kind of what we are calling, you know, the ability to sort of go up in hours or whatever, if you surge at this level, you can get it done in three months. If you surge at this level, you can get it done in two months. And so we're able to really quantify for them, like if time is the important thing, then here's how much you're gonna have to spend or how much time we will dedicate to this to get it done by the time. 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. If you, if you throw in a surprise, it's usually a problem. 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. And then the findings go into our documentation and the findings aren't, you know, person A did this thing badly or whatever. 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.