 So Heather and I were joking around that early in the morning on the last day of the conference, right after the Pantheon party, which are always bound to be great, that maybe like 10 people would show up and half of them would be wearing green jackets. But we've got way more than 10 people. Thanks all for coming to talk more about tactical strategy. So today, we are going to first go over some things that have changed in the last decade or so in the process of creating websites, how that should change how we think about making websites, how we as a team at Four Kitchens, or part of a team at Four Kitchens approach building websites, and how you might also be able to take on some of these in your own practice. I'm Dave Hansen Lange. I go by he, him. I don't have a background in computer science or anything. My previous career was in music production. It seems to be kind of a theme in the Drupal community that a lot of people come out of the arts and then move into web stuff. I've been working with Drupal since 2005. I'm a co-organizer of my local Drupal group, wherever I happen to be living at the time. Currently, that's about an hour from Toronto. And yeah, this is Heather. Hi, I'm Heather Wozniak. No, I'm not related to Steve Wozniak. Yes, it's okay to ask. I live in Seattle area now. My pronouns are she, her. I've been working with Drupal for over 15 years, long enough to forget how long it's been. I started working with it first as a hobbyist and as a grad student when I was working on a PhD in English of all things. And eventually, after I finished that degree, I ended up getting a job as a web developer at UCLA. Then after that, moving up to University of Washington, where I was for a long time, working on a framework to support departmental sites for college there. So I have experience with development, project management, strategy, like a broader way of things over time. And then just, it's been not quite two years since I made the switch to the agency world. And I was first at Adbomatic, and then we merged with Four Kitchens. So here I am today. All right. So it is still early in the morning on the last day. So I want us to like do a little bit something with our bodies to like wake us up and like get us in the mood. So if any of you have been on TikTok, you know that sometimes some that people do is like, put all your hand fingers up and like put a finger down of this and a finger down of that. So we're kind of going to do that, but we're going to do it with our own whole bodies. So can you all stand up? Okay. So we're all of us here. We're all here because we're like somehow involved in like making websites and building websites. And so I want you to stay standing if, oh, and many of us might work for an organization, and we might be the web people for that organization, but some of us work for agencies. If you work for an agency or other organization where you have clients, just think about like your most, the kind that you work with the most right now. So stay standing, otherwise sit down, stay standing if you know one to four long term goals for the organization. Stay standing if you regularly, monthly, quarterly, whatever, pause from the day to day and you like check in and focus on those goals for a bit. Stay standing if you feel that the majority of your web work focuses on those long term goals. This exercise is not meant to make us feel bad that we're falling short. I think there's a lot of, the rest of you can sit down. Sorry. I think there's a lot of opportunity in the Drupal community at large that we think more about these things. And if we can be stronger in this area as a community, that'll benefit all of us, let's work together to figure that out. Okay, let's go over some changes from the last decade. So when I first got involved in the web, this was how we built websites. Our clients would spend a ton of money upfront to build a new website, probably too much money they really tried to push beyond what was probably the right thing for them to spend. Spend a lot of money, push out this new website, and then not spend money on it for years and years. And what that resulted in was this kind of terrible emotional situation where you've spent all this money upfront and you don't know, oh, is it actually going to work out? How do I know that like all this investment is actually going to pay off? So you go through this emotional roller coaster up and down, launch the website, but then because there's no ongoing investment in it, like it just slowly deteriorates over time, everybody gets upset with it. And then it's like tear the whole thing down and we'll start the whole process over again. That, of course, was terrible. So if we try and approach things a little bit differently, let's maybe not spend quite so much money upfront, let's invest in things over time. And hopefully what that can result in is no emotional roller coaster because we know we don't have to get everything perfect out of the gate. There's opportunity to see how things work out in the real world, make improvements over time, slowly make more and more improvements. Is the website better than it was last month? Yes, great. And so our satisfaction level remains high. And maybe one day we still will decide to tear down the website and start again, but let's ensure that we're doing that for strategic reasons and not just because we hate to think so much. Right. And then a second major change that's happened in the last decade is that there's just so much more effort put in upfront for the strategy and planning. We're going to build a new site, right? We have all of these other disciplines now, UX specialists, branding, messaging, all the user research, graphic design, everything that goes into it. It's time, it's emotional investment. There's all these resources. And so it's important, right? Like, that's great. We launched the site day one and then we don't want to lose sight of all of that effort went into the upfront strategy and planning. We want to find a way to keep it alive and continue it throughout the lifetime of the website. Let's also take a look at the historical role of the tech lead. So I was a tech lead for many, many years. And how I thought of my role was these two main things, take other people's ideas and turn them into a technical plan and then guide the development team to build that thing. Historically, there's many of you probably in this room who call yourselves tech leads. Historically, that role has been super important and it's one of the reasons why Drupal has been so successful. But that, especially the first item on here, it's all about responding to what other people are doing. And that's great. But because websites are now living longer, like I described, like just responding isn't enough to ensure that we have that high satisfaction for years and years to come. And so yeah, for a website to be successful, we need that plus more. All right. So now we're going to start digging in a little deeper into how we've been thinking about technical strategy with our team and our projects. And so first, there's sort of three things we call our elevator pitch. One is that technical strategists are kind of in the middle of everything. They are a connector between all those different people that are involved with the website at various stages, right? So you have stakeholders and clients, the content editors, the UX specialists, designers, developers, a whole lot of people that are working on the site. And the content strategists or technical strategists can help connect those things. And we'll elaborate more on that in a bit. A second really important role we have is helping to refine and prioritize all the ideas that are coming from these different participants and evolving over time, right? Because there's always a limit to the budget and the time and the resources we have. We can't do everything. So we have to find a way to decide what's going to be most important, most valuable, and someone needs to help make those decisions and help the rest of the team understand it. And then lastly, it's really about being visionary and, again, understanding those long-term goals for the organization and for the site and making sure that we're always keeping our eye on that as we're considering the day-to-day requests and bugs and issues and new ideas that are coming in. And so it's trying to find that balance with all of that. Okay, so digging in even a little bit deeper, like how do we put this in practice? We thought about this so we could organize this presentation. And so we sort of have five main verbs that we feel like help to summarize the kind of work that we do. So we'll talk about those a bit and try to give a few examples. The first one is understanding. This is really important. Kind of underlies everything else that we do, right? It's really important to understand the technical and the non-technical side of things and help to bring those together. So we have the goals of the organization, the constraints that they might be facing, that side of things, and then also being familiar enough with the technical stack and the architecture of the site so that as we're discussing specific scenarios and ideas and requests, we're able to find the solutions that are going to be the best fit. It's also a lot about listening and asking questions, not just from the stakeholders, but also making sure to go back and bring it, get input from users and really think about their needs of the site. So this is just one, these screenshots are really hard to see here, but you don't need to see the specifics. But this is one example with one of our clients, the Brennan Center for Justice. On the left is a before page where they came to us with, we have this page, there's a ton of text and links on it, and we know it's not very user-friendly and hard to navigate. How could we do this better? And so we took that as an opportunity to step back and think a little more deeply about the experience for users, what they might be wanting to do, and also how we could create a solution that's not just one off for this problem, but we actually created a component that could be used throughout the site in other places whenever they have this kind of data that they, the data by state component that they want to organize by list of states. So on the right, you can see it's a little more compact, visually friendly, and as users click on the different state names, they're highlighted if there's data available for that state, then there's some accordions that expand to show them that information. So it's not all there on the page at once, and there's even a search tool with it, so they could be searching for keywords too. So that's just one example of really trying to understand, think about long-term implications of the change we're going to make, and not just the low-level problem. Anticipate. So it's many of us here, we've been working on web stuff for years. It's really useful to take ideas that we've learned from one place and apply them somewhere else. And it's sometimes easy to forget about the future when we're planning about how to build something. How can this thing, how is this thing that we're building, maybe a component, maybe something else? How can it be misused, maybe? How can it maybe be evolved in the future to accommodate other problems? Or how maybe in the future, if we don't like the thing, how easy is it going to be to just tear it all down and replace it with a different solution? With some practical examples of anticipating, of course, one of the obvious things is end of life. And that's not just for Drupal, that's for PHP, for various libraries, but it's also for other things too. For example, Google Analytics, the version that is most popular and most used is being winded down over the next year, and we've got to put in some effort to replace that with something new, because it's not just to flip the switch and change to the new version. So how can we anticipate when those things are going to happen and line them up in advance so they don't surprise us at the last minute? Another example of anticipation, anticipating how content creators are going to be using the tool or need to use the tool. Where does the field go? Does it go on the node, on the paragraph, on the media entity? We want to make content featured and content sticky. How do we do that? Is it on the paragraph or the original node and having conversations to figure out what content editors need to be successful? All right. And then third verb is plan. So this one has a lot of overlap with the tech lead role as we were describing it earlier. It's about taking in all the information and making plans. That could be writing user stories, acceptance criteria, build specs, tickets. It can vary a little bit depending on the context for the project. And sometimes it can be very micro small scale and sometimes it's large. There's a very large plan with lots of phases and steps. Also with part of the planning, as a strategist, it's not always just about guiding the development team into what they're building but also helping our sales team estimate projects, like what it's going to cost and the effort and how we're going to staff it and things like that. So that's important part of the planning. So just a few examples. This is just some text but writing acceptance criteria for a very small specific detail that is going to be built on the site. And then that can magnify and you can have a whole bunch of that. This is a spreadsheet of build spec from one of our projects, which those can take many forms. But there's a lot of details in here that are being planned out with the technical notes and the AC and then categorizing and prioritizing the steps of the order and the effort involved. So there's a lot of planning that goes there. And then always at some point, once you do that huge big plan, you have to come back and digest it and make it summary so that other people on the team and the clients and everyone can understand again, like what are we doing? Like how does this break down into different phases and what's going to be the level of effort involved with each of these steps in the site? Okay. This one's my favorite. So we try and be guides to the stakeholders and the clients that we work with. One way to think of it is like as a trekking guide, we might say, okay, we want to get over the mountain and to the valley on the other side. And we could either go straight up over the mountain and then down or we could go around. If we go straight up and over the mountain, it's going to be a really hard climb. But if we go around the side, there might be bears. What's more important to you? An easier climb or avoiding bears. And how this applies to building websites. Number one, we don't bring every decision to our clients. We don't need to get them to approve and sign off on every little thing. They're trusting us to make the small decisions on their behalf. But for the big decisions, we can distill them down and avoid the technical jargon, avoid the finer details of bear avoidance and avoiding what is the technical difference between blocks and paragraphs or something. Distill it down into a simple, do you like this or this? And our stakeholders can really appreciate being able to make decisions based on those kinds of criteria. So one example of how this works out in the real world, on this project, we were trying to evaluate whether to use solar or swift type to power the search of the website. The search was a big focus of this website. So we broke down all these different aspects. Here's one. Here's how they compare. But the main point was the conclusion, basically what I just described. If money is most important to you, then go with this option. Otherwise, if this other thing is important to you, then go with this option. All right. So our fourth verb is connect. And as we were saying earlier, there are a whole lot of different skill sets required to maintain a modern web platform these days. So we can't always have all of those people in the room at the same time when we're having discussions about the website. So one of the things that we can do as technical strategists is with our experience, we have a little bit of knowledge about all these different areas, the UX side of things, the front end, the back end development, the content strategy, the overarching goals of the site. And so we can help be there to listen and contribute to the conversations, represent people from those adjacent disciplines when they're not in the room, and also know when it's time to reach out and get some more help from some of those experts on certain things. That might be us individually talking to a colleague or a contact about it, but sometimes we literally will reach out and bring in another team member and say, hey, there's an opportunity here to talk to Randy from our creative team and get some ideas about how we can make the design better. And so it's important to have someone who knows enough to know when they don't know and they can bring in some other team experts. So an example of that is with one of our clients, Museum in the City of New York, this is just a screenshot of their current site, but they are going to be doing some branding updates because they're going to have a centennial anniversary. And so they're one of our continuous care clients, and originally they kind of came to us and support and like we need, we're going to change our logo and have some branding stuff. And we said, okay, let's slow down a little bit and think about this further. Maybe this is an opportunity to rethink the visual design a little bit more deeply if we're going to reskin it and then also decided they want to do some user research and think about the UX on the site and some certain key places like their events pages and things like that. And so they just agreed that would be a good idea and we're going to dig in and do some mini project work on that. And so they're going to have their same Drupal site. We're not going to have to raise it down and build it from the ground up, but we're going to be able to enhance it in a lot of ways and make it better with the help of a lot of our colleagues. And this is just a facilitation map, trying to again like visualize this idea that technical strategy is this role that kind of helps to connect and facilitate and sit in the middle. You may be thinking this is looking familiar like it doesn't the person doesn't have to have a job title of technical strategists, right? They can be a lot of people at your organization. Sometimes it's a project manager, somebody else. But the important thing is that there's somebody kind of owning that overview on the site and helping to bridge the gap between the technical details and the non technical stuff. And so you can see here it's yeah, like just connecting all these different people and disciplines and not always not being a go between, right? Like getting them involved in the conversation, but just helping to bring everybody together. All right. So like what what does this mean? How do we apply this? What what techniques do we use? At first you might be thinking, gee, Dave and Heather, this all kind of sounds obvious, like focus on goals and make plans. And like what's the catch here? The catch is that it's super hard to like not just be bogged down by the day to day Bob wants this change to his page on the website and kind of lift our heads up and focus on on long term goals and try and simplify things down. Yeah, it's harder harder than it appears from the outside. Yeah. And so especially thinking about it as an ongoing thing that happens throughout the site, like once it hits support, it's not like this stuff stops. Like we said earlier, you did all that upfront strategy and planning, let's continue it, apply it, evolve it, making sure that we're always having that holistic view of the site and being intentional about it, even though some people don't want to slow down, right? Like taking the time to pause and consider and be thoughtful about all the decisions we're making and how they're going to affect the long term life of the site and the success of the organization that owns the site. Very important thing, maybe the most important thing. How does this change outcomes? This quote, I've heard this many different variations on this. But if you weren't thinking about strategy, your good clients or stakeholders will leave. Oh my goodness, I still have this note here about Ask God who said this. Whoops. And what we mean here by like your good clients, those who are thinking long term and those who are trying to be intentional about the changes, if they leave leaving you just with the bad clients who are like fix this thing on the website, of course, that's the kind of the hell that we all want to avoid. Another thing, also heard many variations on this over the years, one fifth of the effort, maybe one tenth, one quarter, whatever, it's much easier to sell to an existing client than a client who you've never met before. This quote is more really focused on transactional sales of like selling widgets. But like fundamentally it still works in our context where if you have a relationship with someone and you know what they're like and what their underlying needs are, it's so much easier to figure out the right solution for them than with just an RFP that comes in the door and you have no context. Okay, so let's talk a little bit more about how you can become a technical strategist. I'm going to say you already are because you're in this room. So that's good. That means you're interested in thinking about these things. And obviously one thing you could do is those five verbs we just said understand, anticipate, plan, guide, connect, like ask yourself, am I doing these things? How could I do these more or better? So that's one thing. And then we just have a few other techniques that we're just going to share that talk about some of the things that we do that we found to be helpful as we're working on projects. One of them is documenting goals. This is super important to actually document them, write them down somewhere where everybody can refer to them. And this one's an interesting one because sometimes it's really easy. You might have a bunch, especially if there was a complicated planning stage for a site, you may inherit a whole bunch of written goals and things that you can refer to. It's like, aha, great, we understand. But more often the clients I'm working with, it's not that simple. Like they don't know themselves what their goals are for the website. And so we're always trying to get them to sit down and do a workshop or have a conversation about what is it that your organization really wants to accomplish. Like putting a carousel on my front page or adding a Facebook feed, that is not a goal for a website. It's more like, if you're a university, what's your primary goal this year? Are you trying to recruit students into a particular major or program? Or maybe you're actually over-enrolled and you don't care about that so much and faculty hires and faculty retention is more important. Because once we know that, we're going to make different choices about that Facebook feed because we know like those high schoolers are not looking at Facebook. So let's not do that if you're emphasis on recruiting. So having those goals, having a conversation about it, having it documented gives you, we'll touch on this again in the next few slides. Like at least everyone can see it. You are internal team, the clients, the content editors who do the day-to-day work on the site so that there's a shared understanding of what the purpose of the site should be. This is another one, right, that we have to do a lot is think about how to push back and probably all but in that situation where somebody on the team, it could be from your own team, it could be the client, they propose something that's like, ha, this is probably not the best idea for the success of the project. Maybe it's way out of scope. Like there could be a lot of things. But how do we handle that effectively so it doesn't just turn into an awkward confrontational situation or just constantly saying, no, no, no, no, we don't want to do that. So we have a few thoughts to share about how we approach that. So here's a list of questions that I try and use when I'm in these kinds of conversations. These questions I actually got from something completely unrelated. Brené Brown has a book called Dare to Lead. And these are just great questions for interacting with any human on any topic. And the idea is like, how can we come, how can we approach the situation with a perspective of being curious and trying to get to like the root of the problem? How do we approach things in a way that encourages dialogue and interaction and doesn't just like stonewall the conversation? Brené Brown calls these rumble starters. There's like a dozen more, but I just picked out the ones that kind of most apply to our situations. Yeah, go take a look at more Brené Brown stuff if this sounds intriguing. And then some of the other things that I have found to be useful. One approach is sticking to the facts when you're having this kind of conversation to make it more of an objective discussion and not a like, I think this, you think that, or I want, you want type of thing. So things like citing accessibility standards, any metrics you have about analytics and actual use on the site, referring to blogs or articles or books written by other people, referring to actual experiences with other clients where maybe tried the thing and you can explain what happened when you did that. All of those techniques can be useful to help make the conversation more productive and not just turn into a sort of clash of opinions on things. Of course, always bringing it back to the goals and priorities can help with that, too, because you can get really far down a path. But then wait a minute, what are our goals for the organization again this year? Let's go back and we documented it, how is this going to feed into that? And sometimes it might be like, oh, yeah, actually, this isn't connected to any of that. Or maybe it is, but then you can think about it a little deeper and carefully and figure out the best way to implement that idea so that it's going to serve the goals. This is another, you know, everything in life like choose your battles, especially if you have, we're working with someone where there's like tends to be a lot of disagreement on things. Like if you know you're going to have some ask coming up, like maybe you need to decide you won't worry about the font size because we know the accessibility of the colors is going to be a bigger issue that we're going to talk about. So we'll just like let some things slide. And that's okay. Another thing I have had to learn for myself is not to take it personally when someone doesn't want to take my advice and they're not doing what I would consider to be the best solution for a problem. Like that is going to happen. And like that's okay. It's not a reflection on your personal integrity when that happens. So you just have to live with that. And then the last piece of advice I found is just not getting really deep into things over email or chat or some written form, because it can be really tempting to get drawn in and like sticking to the facts, like write out a litany of all the reasons of why this thing should or shouldn't happen. But I just find that doesn't that's not fruitful. It tends to make bring things to be more uncomfortable. And so just being like, Oh, let's let's get together. Let's have a discussion face to face meeting about that. It usually is a lot easier to hash things out. And people are a lot more pleasant when you're looking at each other across the table or on a video camera. And it usually results in a solution that is better for everyone. Okay, another technique that's really helpful is making sure you have regular check ins of some kind. So this could take a lot of different forms. There could be something like an annual strategic review, which is something that we do with a lot of our clients. But you know, even making sure you're once a year, let's revisit our goals. Let's revisit how the site is performing in these areas like that can be that's really helpful to have. But of course, more frequent than that is great to whether it might be monthly or bi-weekly, the cadence is going to vary depending on the project, but just making sure you have something scheduled for either face to face or video call meetings. There's a lot of stuff that comes out when you do that that just doesn't come out when you don't put everyone together in the same room. There's people have different personalities. And I find there's a lot of people that will just like save everything until they see you. And then suddenly they have these questions or these bugs or these things that ran into. And so it's really great that you make that time to talk with each other and get those ideas. Other people like you could do all this wonderful work on the site. You're sending it for them to give you their feedback and approval. And they're just too busy. They don't have time to do that. So when you have those scheduled sessions to get together with them, you can focus some time and get their input. So then they end up being happier with the way things are moving overall. And you don't just have wall of silence between you. And then this is our last area to talk about is prioritization. Somebody, I get asked this, like how do you decide? Like how do you prioritize what should be the most important? So I can say a little bit about some of the things that I consider we consider to one of them, of course, is the whole effort versus value with something like is something going to be like pretty easy to do, relatively low effort, but it's going to add a lot of value enhancement to the site. Like that's great. That should probably be something we do sooner. Something that's going to be a really high effort and not bring a lot of value would obviously be later. Thinking about who benefits from the change. Is it going to benefit the end users and the visitors to the site or something that benefits internal admin users? We're usually going to prioritize things that benefit that external audience because that's going to help move the needle for the organization in some way more than things for internal. Although depending on the internal thing for admins, like if it makes it way easier for them to do a certain thing that then they can make the site more successful to the public, like that could be higher priority too. But in general, we try to benefit, prioritize things that benefit end users. You could try to sit down and have the whole must have versus nice to have conversation. When you look at things that way, sometimes the must have list could be a lot narrower than the nights to have list. Again, things that support the goals. The frequency of use of a feature. Like if you know from your Google analytics, a lot of people look at a certain page or you have like thousands of instances of this component on a site versus some map that's a one off that only appears on a certain page. Maybe even though it would be lovely to have this beautiful interactive map, that's not going to be prioritized because it's just not going to be used that often. Those are some of the things that I think about. One of the techniques in prioritizing that I find super useful is to break things down into a simple version and then fancy your enhancements later. The kind of tendency when we're building things is always to continue refining. You're building something, you want to just make it a little bit better, a little bit better, a little bit better. It's really important to hold back and just stick with the basic version to start with because we often lose sight of the forest for the trees. It's a common scenario where we're working on say the events section of the website. We want to do everything about events, but the downside is that we're neglecting the other sections of the website. Instead, if we can start with a simple version of everything across the entire website and then come back to the fancier things later, then sometimes we gain some perspective and we realize, oh, making this fancier thing isn't actually that important anymore. We really want to focus on this other area and that allows us to pivot and be flexible and focus on what is truly important for any given day. Another way to be a tech strategist, we're hiring. We're hiring not just for tech strategies, but lots of other roles. If this concept sounds interesting, come check us out at our booth. But fundamentally, tech strategy means happier site visitors, happier site owners and stakeholders, and longer lasting websites. To kick us off for discussion and questions, one thing to think about, do you have anyone on your teams who are taking on these kinds of responsibilities? How do you do it? Do you break it up differently? Does someone have these things in their job description? Or is it the responsibility of everybody on the team? I'm interested to hear all your perspectives on this. Awesome. Any questions? Did we get any of this wrong? Are we missing anything? Yeah, go ahead. So that is one thing that we're really trying to figure out. Because there's a lot of gray areas that overlaps between all these roles, not just project management and tech strategist, but tech lead or content strategist or UX strategist. And we're really working to define those things, what they are, and then being able to come into any project and say, okay, based on the skills of the three people that are involved on this project, who should take on this particular task? That's what we're trying to get to, not quite there yet. Well, I mean, sometimes there might be someone taking notes at the meeting, but usually it revolves around we have like tickets already in the queue or backlog that we're working on. And so after we have the meeting, we come to agreement, I'll go write the summary notes about what the next step should be. Or if there's not a clear next step, it might be a follow up email to the people that were at the meeting or people who weren't at the meeting, but need to know what happened at the meeting to summarize what happened. So yeah, I usually try to write it down somewhere afterwards what the result of the discussion was. Yeah, yeah, for sure. Right. So that's where like trying to be really proactive can be helpful. So if we do an annual technical audit, then we can come to them with a list of ideas that we propose, like, Hey, have you thought about doing this for your site? It would make it better for these reasons. And like, if we keep doing that, like certain good clients will be responsive. And they're like, This is great. I didn't have to think about this. They're coming to me, they've got these ideas. The site is continually getting better and better. I will say like occasionally there's clients where we've tried that and it just doesn't work. Like we keep trying to give them these great ideas. There's all these opportunities and it just doesn't stick. And so again, like that's okay. It's not a personal reflection on you. Like maybe that just relationship doesn't work out and they need to work with a different type of team or agency because they have totally different expectations. But like I'm always optimistic, like, just try, try be be proactive, like set the example, right? Be the model. Yes. Yeah. Yeah. And many people, many of our clients are, they're just frazzled because they've got like responsibilities for the website and email campaigns and a billion other things. And so yeah, like if we can like be that, like, I don't know what word to describe it, conduit, like tool for them to like help reorient them. Some, many can really, really benefit from that. Yeah. Another thing that happens is people change at the organization. And so you might be working with someone and it's not going anywhere, but then that they leave and hire someone new into the role. And suddenly it's a whole different situation, which is why it's important to have that guiding document because the new person comes in and you're not just starting from a blank slate and they don't, they don't know why the site was built the way it was or what it does, but you're able to sit down with them early on and orient them and explain the strategy and show them how to use it. And then that usually makes them a lot happier with it. So they don't just come in and say, okay, I'm new. Okay. We need a new website. Like I don't understand this. So we, we don't really quite know what to call this. We've used the word technical strategy thus far, but yeah, we're toying with like product manager, product owner. Yeah. And there, there are some like existing definitions of those things and like how, how comfortable are we with those existing definitions that are kind of like a little bit outside of what we do in the agency world, but yet there's still like so much overlap. Yeah. So to answer your question, yes. Question back there. Sometimes. Yes. But, but, but I think that's more, yeah, I think that really falls into like the connecting thing that we talked about. Like, okay, we know, we know that like this is going beyond like the limits of like what my expertise is for, for example, but at four kitchens, we have like content strategists and like our creative team, they're, they're great at running like workshops with high level stakeholders to like come up with goals and stuff. And so we most likely like try and funnel them towards like finding another way to, to meet that, that kind of gap and that, that problem that they have. Right. Any more questions? Well, thank you all very much. This has been great.