 All right. So I think we are going to start. So we gave two minutes for the people who was going to attend a session from Coffee Break. And we are going to start. First of all, I wanted to say to you, thank you for joining us today. Really happy to see all of you here. Really appreciate that. And today, we are going to talk about how to build relationships with the clients. And the reason for this talk, because relationships almost the most important part of our life. Relationships with the clients, with our families, friends, employees, and teammates. So we are going to talk about this, because good and healthy relationships, they drive our businesses. So my name is Alex Shedrov. I came here from Ukraine. I work at DFW as a team lead and architect. And also, we are building open wide distribution. So potentially, you may have heard about it, something. So I'm an architect of this project. And I have my own blog, so in case if you'd like to contact me with the data, I write some articles about technologies and everything that is around me there. Hello. My name is Zmajra. I'm really happy to be here today. I'm a Drupal developer. And I'm really happy to have a chance to work with Alexander on open wide distribution. And currently, I work as technical lead at root.ua. Thank you for coming for this session. We'll do our best to make this session interesting for you. But let's set up the right expectation from the beginning. We are technical guys. So probably all the stuff we are talking about will go from technical perspective. At this presentation, we'll talk about the common problems and issues which faces nearly each development team while project implementation. We'll guide you through each phase of this really wonderful process and try to share our experience and recommendations. And eventually, and hopefully, with your help, we'll find the best solutions for the most common problems. So just close your eyes, relax, and imagine you get a fantastic client who wants to implement his next project with your team. So let the fun begin. Yeah. And all we know that the most funny things and fun begins from first phase. That's the sales discovery in the estimate. So we are going to start from this phase. But first of all, I would like to ask a few questions. So first one, who is the client and what kind of business he does? What does the client want to build? So eventually, which product you are going to build? How it should look like or something like this? Why does the client build the solution? So what is the purpose of this solution? And who will be the end user of this solution? And how the client build this solution? So in case for your client and your project, you do not have an answer at least to one of these questions. So you are in big troubles because this is the beginning of the project. And in case if you do not have background information, you may get different expectations from your client. And let's take a look at the example. So we are going to build a sport car, but eventually we've got something like this. So let's think what will be the level of frustration for our client because he wanted the sport car but get something like this. So because of that, it's really important to focus on the beginning of the project like sales, estimates, and stuff like that from the beginning. So first step to do that is listen, ask, and analyze. So that's three simple words. And you may think like this is so obvious. What are you talking about? So that's we are doing that. But yes, this is simple. But not all of us are doing this. We all know that we should really focus on the estimates. We should really focus on the discovery and sales, however, not all of us doing this. And I really encourage you to do that. So we can have plenty of meetings with clients. We should find appropriate questions in order to get more information. And then we can analyze this. And this will give us like big vision of the project, big vision of the client's project, what exactly he wants to get, and how we are going to move forward. And this will get you through all these phases. So remember, we are only in the first phase, beginning of the project, and big vision will kind of inspire you to get through the all phases. And based on this, you can circle back to client and recommend something. You haven't started the project yet. You do not have like budgets, money, estimates, deadlines. But if you at the beginning circle back with client or recommend something like reduce functionality or remove some functionality or like reduce costs for the project. So using that you will show that you really care about the project. And all we know when client feels that you care about project, you will do your best in order to finish it and finish it with a good quality. But the next step, next thing that we are using in our company with our clients that it's important and it's hard to implement, yes, but it's important to involve the whole team during the estimation process, during sales, bring your sales department, technical leads, architects and even developers. So why not? Because if you can get the whole team for the sales and for the discovery and estimates and the same team will start this project and we'll work towards the end of the project, that will be the ideal solution because they will have a vision. They will have the all background. They will have everything in order to do it and implement it successfully. In case if you have separate department of architects who are doing estimation and then they transfer their knowledge to actual team who will implement this and there is big gap between those two teams. So just try to involve everyone to this process. And the reason for that because everyone will feel the responsibility. So everyone will feel responsibility of this project and everyone will do their best in order to implement it with a great quality, with a great, without failed deadlines and stuff like that because when I feel responsibility, I will do my best to finish that with a great quality. And also if your agency and provide designs, try to bring everyone to design sessions like in case you can get end user to this session, that will be perfect because end user might provide so valuable feedback for the designs because they eventually will use it, not you, not client itself, their customers, their users will use the design. So try to get this feedback from them. And if client can provide this, that will be great. But let's say you implemented all the steps. You listened, asked not lies and all that thing. But in case if you price your project, so you provided wrong estimates or small estimates, your project probably will be failed. You will go over budget. Client will be frustrated because you will ask for more money. So it's really important to price the project right from the beginning. And in order to do that, try to do a review. So just ask developers to review estimates of the architect. Ask other architects to review the estimates. Ask like sales, PMs and QAs to review the estimates because as more people can just take a look and review, as closer your estimates will be to the reality. But of course there may be some gap between estimates from developer and architect but this might be fixed just by communication between them. So you can decide which exactly, how many hours you need to implement this or that thing. But in case if let's say you failed completely, you screwed up the project, fail estimates over budget like our daily basis life. Failed project over budget. There is one magical thing that might help you to proceed with your client and save your collaboration. It's called empathy. It's something magical. It's like chemistry between you and the client and it's impossible to describe that, however it exists. Believe me, we've had a lot of empathy between our teams and clients so it's important to build an empathy. It might help you in case if you provided wrong estimates. You have no background of project so you completely screwed out the project and that thing, that chemistry empathy will help you to proceed with collaboration, your client will not leave you and just remember that most of the projects they are failed from the beginning so it's really important to focus on this phase like discovery, estimates and sales so you will protect yourself from failure eventually. So congratulations, you've got the project. Let's start implementing it. Everything is going smooth. The client is happy. The list of planned features is really long and exciting. Sales managers were so good and sold absolutely everything but every time you're reading through the list of planned features, your heart starts beating really fast. Why? It's because limited budget. And here you have to relax because every budget is limited. So let's talk about how should we behave in this situation and as it appears, parental law makes sense here. Almost 80% of troubles are caused by 20% of features. Just imagine this awesome header with complex navigation or this really awesome footer which changes its color or structure depending on some logic. And these features could be potential time killers and they give too little business value for your customer and the project and accordingly, only a few years later 20%, small percent of features make really, really business value for your customer. And just imagine small, gray, tiny, hidden somewhere web form. Surprise, this form really makes money for your client. So right from this moment, you should think like your client thinks you are not developer now. So start by sorting your features by business value and do not make assumptions here. Ask your client to help you and after that, you'll be able to pinpoint the most critical parts of your application. Start, discuss these parts, feel the pain of your client, try to fix essential problems and if the client will understand that you understand his business, he will be happy and happy client is a client. Easy client, easy negotiations and that's what we want. So right now you are full of energy and fire. You'll make awesome project. You'll make really awesome project. You'll create documentation for each feature. Okay, you'll make tests for everything. No, eventually, you'll open source your modules but it seems your team burns a lot of time for ideal solutions and it's look like a problem. And we'll do everything right starting from this project. Let's be more realistic. Your new project won't be ideal. Statistically, your new project will be at least 80% similar to previous one. Otherwise, you will break the deadlines. So think twice before changing your workflow or tools or environments. Our point is that single but really stable step further is way better than quickly and risky movements. So do evolution but not revolution. And it's always a good idea just to build your project. Do not look for ideal solutions. A good software appears through the implementing iterative improvements. It's impossible to create something ideal from scratch. That's how OpenWide distribution appeared. We've built really cool stuff for the first YMCA project. Some of the features have been reused in the next projects and eventually after polishing, refactoring, the code was committed to the distribution. So just do it now, build your project. And probably the finishing your project in time will be ideal goal for you. Yeah, ideal projects and solution. How many promises we've made when we started projects like test coverage and stuff like that. But in addition, let's think about this in a little bit different perspective. Let's say that the client doesn't ask your questions. So it's just joining meetings, say yes, yes, yes. Just left meetings and no questions from client. Or client reviews demo too quickly. So just a few minutes, he says, everything fine, buddy. Yeah, let's go ahead and deploy that. Or the client doesn't point on backs. So that happened sometime. So based on those three things, we can make an assumption that clients doesn't participate in our project. So he's not proactive. And I personally call these clients like a sleepy client. So they are hanging around. They are joining to the meetings. They're trying to do something but eventually they are not kind of interested in this project. And they leverage responsibility from themselves to you. And we all do not want to have this responsibility, right? So it doesn't encourage the team to work on this project, so stuff like that. But maybe they're just have some blockers on the road to actively participate in the project. So let's say they have blockers, like they have no environments or they have no understanding how tests this or that feature or they are new on the project. So how much time you've had in transition on the client side and there isn't boarding periods on you people do not know what they are going to do or they don't feel responsibility or they just too shy to ask you that they have a blockers on the road. So just ask them, so simple sentence. Do you have any blockers or problems with our team and testing our product? So in case if you ask this, they may just say, yes, I have, I do not understand the environments set up. I do not understand how it works this feature and that feature, but if you do not ask, it may bring a lot of problems like at the end of the project and eventually ruin the relationships with client. And another thing that might also help you to encourage client to participate more that's the early demo. Whenever you have something to show, just show it. Even in case if it looks terrible without design, but it works and it brings some business value. So your meetings might look like this. You just show the demo, there are some bugs appears like in software where we're working in AT or trying to hide them, but that's fine. We all make bugs, so world is not perfect. Just see, there is cool thing that you can see. We will fix this in the next release. That works kind of, that's good excuse that you will finish this and fix this in the next release. Coupled with early demo, we are always trying to start user acceptance testing period. That's the period when client tests his features and approve some of them. So we're trying to start this from the beginning. So when some feature is ready, we just send it to client for testing and signing off. We do not wait for the end of the project because eventually it might bring a lot of problems. Let's say you've built 15 cool features and he was waiting for the UAT period to set. All right, we will allocate one month before the project launch. We will send everything to client. He will take quick look, share with his colleagues and eventually you get huge spreadsheet with things that should be fixed or with bug reports and no one can take a vacation, seek leave, go to cinema with kids and family and wife. They should just work that the whole month in order to fix everything. That's not gonna work in long term perspective because everyone will completely burned out. So just starting user acceptance testing from the beginning it's like beneficial thing because you will go like smoothly through the project and there will not be that big bag of things to do at the end of the project. And also this, this will make everyone excited. So whenever you show something on your meeting so everyone will write a meeting for you. Like let's say you have a weekly meeting. So client will be excited to join these meetings because you always have something to show him. It's not just conversation between you and him. It's like you show the results and they actually see something that they are paying for. So they actually give you money for that. And in case if you do not do that it might lead to unexpected results as I mentioned. So at the end of the project you had to work 24 hours per day, no sleep, no like pizza, just coffee, work and stuff like that. That's not what we want actually, right? So just make sure that you engage the client, you go smoothly with the project. One more challenge that can happen is frustrated and bored developers. And it's obviously that the project can't go smoothly with the motivated team. So let's speak about no patient problem and how to avoid it in the future. Just look at these guys. Believe me, these guys will be frustrated eventually. Money isn't always makes us happier. And it's our goal, it's your goal to make each team member understand that he should have really higher goal than just earning more money and doing less. And it's our goal and our duty to help to find and identify this goal. And learning something new is really helping here because every developer like to learn new things and probably he can learn framework sub system, new design pattern, even new JavaScript library, but be careful, the goal isn't learning itself. Developer should understand that the goal is successful adoption of the technology on the project. So it really helps. Also you should write pair programming sessions. This session can help to solve really challenging problems but also they helps the team to be engaged. And try to set up global missions. For example, on YMCA projects, we had some missions like we are helping people to start healthy life or just we are helping children to learn swimming and it really working. And learning the business of your client will help you to identify these missions for your particular project. And of course you have to create proper issue tickets. Just move this button 10 pixels right and make it green. It's really the motivating issue. Always leave a space for developer to think and you should include three items at your tickets like the first, why we are doing this ticket? What should we do in this ticket? And little, little description, how we should do it? Help your developer to think and make some proposals. And obviously you as a team lead have to like your project because absence of passion will burn out you guys, be careful. Yeah, and we are still at the beginning of the project and there are so many problems so there is another one. Let's imagine that you didn't ask the client which way of cooperation is comfortable for them. You just started the project, you are using your setup of tools that you usually use for the clients because that's like historical thing you are using them or you didn't demonstrate, you didn't have a demo or proposal how you would like to work with them. So eventually it may lead to some kind of providing and comfortable services for the client. So good example, let's say you are sitting on uncomfortable chair, so you may sit for five minutes, 10 minutes, half an hour, one hour, two hours but eventually you will be happy to stand up, have a walk and sit down on comfortable couch, right? The same maybe with the client in case if you created great product, you haven't failed the deadlines, you haven't had over budget but you provided uncomfortable services, eventually even if you had great team, client will be happy to leave you and find another agency to work with because the whole process wasn't uncomfortable. He didn't feel that it was comfortable at all. So now let's think what good service is because there are so many definitions. For me, good service is when you walk into the restaurant or shop or Starbucks, you do something there or do a coffee or buy a new t-shirt and you walk out from this place and you have a good feeling and you have a smile. So it means that it was a good service. So the same I think should happen with clients and solution is pretty simple. Just ask your client which way of cooperation would prefer. Maybe they would prefer emails instead of base camp or they would prefer have on-site meetings instead of using go-to meetings, go-to meeting or Skype or they just would like to use RSC or ICQ or something like that. So just ask, no assumptions and they will tell you how to do that. Be flexible with that and also explain how you work, explain the full cycle. We are at the beginning of the project, explain that so they will have an understanding of the process that you are bringing them to. And the last, it's kind of the last piece of that of comfortable services that it's really important to define roles and responsibilities from the beginning. Include there everyone, client, your team, some third party vendors that you're working with or third party services. It's really important that everyone knows that what they should do and they feel responsibility. So good example, musicians and rock bands, jazz bands, so just musicians. They always know when they should start playing drums, when the guitar player should start playing, when the vocal should be started and that creates rhythm, vibe and melody so you feel it. In case if someone will start not in the right time, you will say that this song, I do not like this song. The same we should think about our team. So everyone should really know when they should start doing something, when they should stop doing something. So just make sure that everyone knows and just feel yourself like a rock band and you will create great projects and relationships with clients. So we are doing great and we are at the middle of the project. Let's face new issues. Sometimes the client requests the feature that has no implementation in the real world. The client really understands how should it work but no one understands how should be implemented this feature and it's really a problem, no real world example. The development can take a lot of time but no one guarantees that the client will accept the solution. And the fair example of this problem could be third party service integration. And proof of concept and MVP will help you. It's really simple, like one, two, three. So the first step, just pinpoint the most critical parts. The second step, just quickly implement the feature. Yes, you have to write dirty and quick code. The goal is just show something to the client because early demo will help your client to understand basically what he wants. And after you show him something you'll see, your client will start participate in your development and probably will help you to move in the right direction and of course everybody lies. Do not trust third party services. We had an experience when only half of documented features were really working, so don't rely on such services. And sometimes you have to ask the client how to implement some feature and I think you should provide two or more proposals. Let's have a simple example. You ask client, what kind of button do you like? Blue or red? The client will tell you, I like blue button. But what if you ask, what kind of button do you like? First of all, the client will wait two or three days and then he will ask, he will tell you, I like big button. So the idea never ask open questions. My point that simple questions will lead to simple answers. And of course it's good idea to set up workshops with your client and probably pair programming sessions. Yes, it's not a joke. There is a guy who was sitting in pair programming session with the client and eventually they got the results. So it works. Yeah, we've had that example and a few more examples when we were working with YMCA and actually client was in the meeting. He brought there a few trainers who were working at the gym and together we were sitting there and trying to write some code and identify how we should eventually create an integration with third party services that those trainers are using. And eventually in case if we haven't had that we would spend like one month just for back and forth emails between us. So it's really cool that we can sit together and do that. But also in the middle phase. So we are already in the middle phase. We went successfully through the beginning and at this phase there might be some syncs that can be identified only during this phase. So let's say that you have a communication that is going only through one single person or your team works some kind of vacuum. So they at the end of the day. So for me measurement of working in vacuum is that developer at the end of the day they will say that I've completed three tasks in JIRA. But for me like personally as a team lead they should say I've completed three tasks. In the first one I make a blue button that will make a lot of money for the client. In the second one I completely redesigned the homepage and stuff like that. So it's not measurement that you just completed your day to day tasks or something like that. You should really help and care about project and client. Or your team doesn't have a path moving forward. So they are just working and working, no development, no learning, nothing like that. So it means that you may have communication bottleneck or communication gap that should be fixed eventually. And the first step to do that, just remove overhead from that single person who handles this communication. So that could be in most cases that's the PM project manager. And I think that's in case if project manager handles all communications it's like secretary. I don't know because everyone like team leads, architects and even developers they want to talk with client directly. They really need that. Of course there are some examples that developers are introverts. Yeah, we all know that and they are going to work on them caught. However, it's really important to talk with client directly for the whole team. Let's say, let's take a look at the example. You have bottle of coke in your hand. It's closed and you have inside it a lot of energy. You just shake it a few times. You remove the bank from the bottle and that crazy energy goes outside of the bottle. So the same will happen in case if you allow your team talk with the client because they have a lot of energy. They have a lot of pain in most cases developers. They feel that pain, not PM feels the pain of integration with third party services. So developer do that. So they really, they will be inspired and encouraged to work even better when they talk directly with client. And so the question, who is more important? Your employees or the client? What do you think guys? Who is more important? Your employees. Employees, employees. No clients, no projects, no employees. So yeah, yeah, maybe that's a good point. However, yeah, I think that both are important. So you should really care about everyone. It's in case if you will care only about clients, your developers will be upset and they will deliver some shit at the end of the project. In case you will care only about developers, your client will be upset and he will leave you alone at the end of the project and go to another agency. So you should really care about both clients, employees, because let's remember we have magical thing called empathy. When you care about everyone and just show this to the whole team that you care, it will get your closer to this chemistry between you and your client. And another thing that will help you to create empathy, that's the person who can help with client with everything. Of course, he's not going to deliver a pizza or clean the apartment. However, he can help with the questions that are pretty close to your expertise and area. Even in case if they are not related to your project, just try to help client or just to say, I'm not an expert in this, however there is someone or there is a link, just do not leave them alone with the problem, just because this will really show that you care about them. And of course, you shouldn't be 24 seven help, you shouldn't be exploited because in some cases this happens, we've had that experience, but just try to think as a client, try to help them because empathy is really magical thing. And kind of in order to summarize everything that they just said about communication, let your client care about their relationships with client, not the PM responsible for that, not the separate department responsible for that, not the individual guy with the title, kind of clients relationship manager responsible for that, your team responsible for that, not only through product or code, through services, services that you are providing, we almost all providing services, so just let your team to care about that. And we all do internal retrospectives, retrospective meanings and then the springs and then the projects bring and involve the client to provide feedback about your team, about your teammates and of course share them because they've had a couple of examples when client provided the feedback, but that feedback just like didn't, didn't get to the developers at all. So ask your client to provide feedback because this will actually inspire your team. Good feedback will inspire your team, bad feedback will inspire your team even more than good feedback, believe me. So because when you hear something bad, you will get what I will do that from the next project even better. So, but good feedback inspires as well so you can kind of allow yourself to take a bottle of beer and hang out the whole evening because you've got a good feedback from client. And eventually we are at the most challenging part of any project. Let's talk about what might happen just before the launch. Sometimes something goes wrong and it's totally okay when something goes wrong. It could be two optimistic estimates or broken deadlines or problems with third party services. But the main question here, should we talk to the client about that? And we are pretty sure we should because transparency will help to make stress less and to make process more effective. So just talk to your client and under promise and over deliver. What does it mean? Basically breaking promises will make our client frustrated and again, delivering more than clients expects will make him happy. So in other words, no one likes to pay more but everyone likes to get more. So let's have a rule, just promise less and do more. But the question, how can we achieve that? The answer is simple. Just always add some buffers to your estimates. It will help you. And sometimes we do two optimistic estimates. And I think we should talk to the client about that. There is a really big chance that the client will adjust the budget. Yes, there is a chance that the client will tell you, there is a contract, there is duties, we have no money and blah, blah, blah, blah, but eventually there is a good point. Now your client knows that there is a problem and he is ready for this problem. And the same thing should be applied to failed deadlines. It's always better to fail deadline for single feature but not the whole project. So just talk to your client and probably he will remove some features to finish the project in time. And this slide is probably the most important slide from my part of presentation. Indeed, the deepest need people have is for a sense of control. Not control, but a sense of control. So give this feeling to your client. And believe me, he will forgive you broken deadlines and even over budget. I forgot really cool trick. Always say yes to your client. What does it mean? Let's have a simple example. Could you make this button green? Yes, sure. We will do this button green but please contact our sales to make SLA agreement. And obviously do not charge your client for a simple solutions. Yeah, and all those things, you know, all those things, they get us through the almost all faces. So when it has only the most exciting things, the project launch, you know, that's magic feeling when you're almost done with the project, you just imagine how you will lie down on beach, have some heater or stuff like that. So that's, I'm excited about this part of the project. Are you? So, but there is always but, you know, but usually I hear that question almost at the end of the project. So client asks when and where I can enter my content in case if you launch a new website and you do not have immigration or you have just portion of immigration or the client doesn't understand how the website will be launched at all. So not all clients, they are not tech savvy. So there are some use cases when clients is not technical details and overall process or the client doesn't know how and where to test to perform the final testing and stuff like that. And this, this might screw up the whole impression of your work from first phase in case if you didn't really grade the first phase sales and estimates of the overall project but at the end of the project you might screw up your project in case if you do this phase in the wrong way. But there is one thing that might help you. The first one that's you can create the go live checklist. You can create go live checklist, put every step in this checklist so that could be spreadsheet with steps like check performance, check perform lot testing, disable devil module, take status page, configure write directs and stuff like that and make sure that everyone is assigned to some tasks. For example, architects or team leads they can perform some high level tasks. Client might change the DNS. Client might contact you, let's say Aquia to perform some lot testing and stuff like that. So everyone is responsible for that process as well. And explain this process in a really simple words. So example, your architect or a team lead on meeting with clients will answer to the question how the launch will going to happen. He will answer, oh, I'm going to log into the server using SSH and I will execute Drush, update DB using alias, then I will make sure that Warnish is up and running and anonymous users are hitting Warnish and stuff like that. What the heck are you doing? So you should really answer to this question that I will make data backup then I will make sure that code is up to date on the production environment and I will make sure that your website will take a big loading on your website. So just in simple words instead of these technical things that he's not interested in. And in order to explain this in a simple words, visualize it, so we have great tool, we can visualize everything using diagrams. Here is one example how we do that. We split out the whole process of development new website in three simple phases. So we develop the platform. That's the phase where we set up content types, workflow, we're working with the content. When once we finished, we just say the client so we've deployed to this environment. Now you can start working with the content and in case there is immigration you should put on freeze your current website. When this phase is done, we just launch the website and we say like we are going to launch the website, identify date and stuff like that. Here is an example of GoLive timeline. So we usually split out the GoLive in three phases. Free GoLive, GoLive and PostGoLive. In the first phase we go through that checklist, perform some log testing, security updates and stuff like that. GoLive that's just changing the DNS. In most cases, that's pretty simple. And in case if you have write directs so you should make sure that everything works and PostGoLive we just check that DNS is up and running. So we check DNS propagation and performance, analytics and stuff like that and we are done. And client always understand that diagram so it's really simple. But after that it's always important to make sure that client knows how to set up so which environment they should use because before launch you have first setup of environments. After you always treat production as a primary environment. So make sure that they understand that in case if they will delete something from production it will never appear there or like you have to do some work in order to get it there. So make sure that they understand that. And always propose PostGoLive support. Make sure that they know the channels for communication in case if something urgent appeared on the website. They know how to apply hot fixes, let's say they cannot accept payments. So that's huge problem. So they should have someone whom they can contact to fix that. So make sure to do that. And congratulations, we finally launched the project. So we went through all the phases and we launched the project. So we are good to go. We can hang out to take our Python kits, go to the mountains and just enjoy our lives. So we are done with this. So we went through all phases. We launched the project. And if we take a look and if we get back to our first diagram where we outlined all those five phases. So we've done with sales estimates. We've done with the beginning. We've done with the middle phase before launch and launch. But our goal is to just connect those two phases. So that client will actually start a new project with you, start a new contract with you, build something new, build some new feature, build some new breakthrough functionality for the website. And you might just sit here and think, so I've spent one hour with those guys. They were talking about all the things. Like I know all these recommendations. Yes, we all know them, but we all not use them. We may use some of them, but not all. And then the result, if you will use all of them, this will bring your business to completely new level. This will create empathy between you and the client, between your teammates and the client. And relationships based on trust, they will derive your team. They will encourage everyone. They will drive your company performance, healthier and stuff like that. So just start to using them because we are using them and we are happy. So we are happy. Clients happy, hyper clients, easy clients. So we all really want that. And I wish you to build relationships with the client wisely. So just think about it. Not think only about the product or not think only about like budgets and estimates and stuff like that. Think about clients. Just take a few minutes to think how does the client feel? Maybe they have problems. Maybe they are concerned with something. So relationships are really important. And remember that cooperation with well-established partners, it's always more efficient, beneficial, favorable, happier, healthier and blah, blah, blah and stuff like that and less painful. So we all encourage when we work with the cool clients when we develop awesome projects. So I think we should always work in order to convert the clients to partners and to establish good relationships to have more and more and more projects with them. And so basically in other words, the terms, the client and the customers are both wrong. The right term is partner. So let's build partnership. Let's do not build projects. Let's build partnership. We've just shared our recipes to make our partners happy. So we truly believe you have your own recipes and tips and tricks. Please share if you have them. Thank you. Yeah, and there is one more thing. So, oh, sorry, that was not my face. That was Steve Jobs. So there is one thing that I wanted to just briefly mention. I have two sessions on this DrupalCon. Just imagine how beating my last two or three weeks are. So they are crazy. So I would really appreciate it if you will come tomorrow to the same room, 10.45. So we'll talk about continuous integration testing that we've built for Open Wide Distro. So it's gonna be DevOps track. If you're interested, welcome. We'll be happy to see you here. And also, contribution sprints are Friday in case you would like to be part of Drupal to contribute somehow, designs, management, not only code, so join us. Thank you very much. That's the time for questions and answers. And please, please, please evaluate our session. So there is a link. If you think that you have valuable feedback, just leave there a message so we will know what do you think about our session. So thank you very much. Questions and answers. Any questions? Questions? There is a microphone if you would like to ask questions. Please, at least one. Or just share. Or you can just share your recipes on the Facebook or probably on the comments to this presentation. It would be great. Thank you. Yeah. If you have no questions, there is information if you would like to catch up on some things. So thank you very much for joining us today. No, thank you.