 Today's session is about, like it's a bit confusing, maybe, but I hope it will be interesting for you. It's a dream team therapy of how to maintain humans within a team. And actually, this is the first time I'm putting both my position into one slide. My expertise in terms of IT is DevOps and PHP programming, architecture scenes, and also team leading. My other position, so I'm a developer since 2002. I'm a software hardware architect working for FFW. I'm a mentor. I help in our local Ukrainian community to grow people to understand how the Drupal community works, what are the rules within. And another position is like an opposite one. I'm a private psychotherapist. I'm a certified guest-style therapist. I would like to ask you who is familiar, what is guest-style therapy here? So two people. And probably I can tell anything you will just believe me because nobody knows what is it. So I'm a lead of two b-weekly long-term groups in terms of psychotherapy. And also, from time to time, I'm involved into coaching personal and company coaching sessions. And today, I was presenting already on previous Drupal cons. But there were technical sessions. And today, I can feel almost everything that this guy on the slide, because it's the first time I'm presenting sort of therapy things to the IT community. And I feel like worry, a bit of fear, some shame, because probably I will be talking about some ugly things. And I'm not an native speaker. You know, you have a beautiful world in your mind and that ugly thing on your tongue. And this is all about how I feel. And in current session, I'm going to present you some ideas, some steps, and actions that you actually can approach into your team to deal with feelings, to deal with different situations. And for particular, this guy would be helpful to get performance review from a team feedback and probably some mentorship to figure out what is going on. Also, I have to talk a few words about our background. It's Andriy Sakhaniuk. So he is one of the five, actually, from the 10 guys from Ukraine that were happy enough to have a luck to get the visa from Irish Consulate in Ukraine. So statistically speaking, about 80 to 100 people from Ukraine all attending Drupal cons. But this year, just because of local Irish embassy issues, we have only 10 of us. And by visiting such a consulate, the feelings almost the same disappointing and similar to the feelings when the new guy joined in the team. Like you can feel fear, shame, sometimes humiliating things. And in this presentation, I'm trying to draw parallels between different contexts, but when you have similar feelings about them. So enough for introduction and what is drawing parallels. I would like to present you eight ideas or main points that are valuable from our perspective as a team and psychotherapy practice. They are sort of keys for getting good team relationships and have tools for approaching the team or company goals. And if I would be asked about what idea is the most powerful in terms of creating better relationship in an IT company context, I would say pair programming. So for those of you that are not familiar with pair programming is the process when two guys working with the same keyboard close one to each other on the same task. And when you have two guys working on task separately, basically the efficiency would be like 200%. 100% plus 100%. But when you put two guys to the one keyboard, the magic happens, the efficiency grows up to 380%. There are even companies that put this into the business like everyone work only in pair programming. But this thing has its own drawbacks, like you can't work eight hours per day in pair because you started to be tired much more faster because of the high intensiveness. And but the good thing about pair programming also is that you are getting confidence. The confidence that team actually works. It's because you, by working with some guy from a team that already works in it like for two years and you're a new guy, you are getting that understanding that how your team would be helpful for you and how you will be helpful for the team back. In both cases, HR department would be happy to get this into your team. Also, our team is totally remote. And for remote teams, it's not easy to approach pair programming because I'm working from Ukraine, from my home. Other guy working from like United States. But by using modern technologies to monitors, you can easily go into deep debugging session and it works. Not so efficiency like you work close in face to face, but it works. Team building and doocracy. It's its idea too. So for those that are not familiar with group therapy, what is it all about? So when people are gathering into group, person actually getting an ability to think not like the other guy in the team. It's like a competition thing when you are trying to say something and you see that other guy already said that. And you need to push yourself to get another idea to provide some feedback. And when you work in a group, you will definitely be working slower instead of when all those persons will be working separately. But in a group, you will definitely be more each in terms of new ideas of brainstorming, different perspectives, and vice versa. Another thing here taking place is a synergy effect. When team members start to motivate each other because you see an example of the guy how it works and you can try to behave in the same manner. Doocracy is like an additional discussion. So I've met this term when I was investigating different translation teams on localized Drupal org. I'm also a translation team manager on localized Drupal org. And this thing came from a Chinese team. So Chinese teams know how to work in a crowd, right? And actually what is doocracy in a few words? It's like highly controlled chaos. So you should have any team siblings that can cover each other work when, for example, somebody gets burnout or somebody wants to go to vacation. And also, your team should be splitted to small subteams because when you work in a large team, a lot of collisions will be happening. Since God, we have agile approach, right? That tells us, please use teams not larger than six or nine people. It's like opposite thing to group personal attention. So maybe you are familiar with the Parkinson's law. It's not a psychiatric term. It's a book written maybe a few decades ago. There is a link to Wikipedia that describes this thing. But the Parkinson's law is a problem that huge companies are facing with. So the problem is that when you work in a huge company, you're starting to feel like you can't change anything in this company. And you're starting to lose your motivation. You just start to do regular job without any passion. And the only things that I know that can help you to beat this law, it's a personal attention from another team, guys, from team members, actually. So when you work on your team and you see there is not so much motivation, probably this is because it's not actually a team. It's like only a few individuals sitting in the same room without any communications. And this is even true for distributed teams. Because when you are not in the same office, you can feel the group. You can feel that you work in a huge company, like our company is more than 400 developers. But I even don't know all of them because some of them work on the opposite side of the planet. We're even not meeting in a chat. I'm not talking about real cause. So the good thing about Drupal community is to meet on Drupal cons, right? And personal attention, that things that can be approached by team leads, project managers, sometimes human resource managers, that can just directly ask every person about the issues that he's expecting right now. And this will work really well with some issues like when you have different cultures, different guys from different countries, it could be a problem. And you need to have at least two guys from the same country to let them to feel like they have work. They have somebody that understands how the things are happening. The friend of mine, actually, Dennis Poshadny, that was unable to go here, he is saying, if you don't ask, you lose. And this saying started to be like a common phrase in our local community because almost all the things in Drupal are happening when you're asking for something. When you're starting to connect to people, when you start to ask them how it works, how you can help, how they can help you. And this rule is especially good for new people because new people that are going to company feels like the company doesn't care about them. And the only thing that can help them, just to ask in chat, how you can help me, what is the task, how I can approve this task. And it really works. And I believe it should be pushed a bit more by team leads or project managers. Tox, I need to talk a bit more about difference between remote and office teams. When you work in office, it's easy to have a Tox because you have a coffee breaks, you can go for a lunch together, and it's more easy to have Tox in your team. But when it's a remote team, you need to put some effort to facilitate this process. You need to create some offline meetings. We have Friday Tech Talks in our team. Every Friday at 3 AM, we are starting to represent some ideas to share our knowledge. And it helps really well to understand what other part of the team is working at. And it helps us to get more closer relationships. That's it. Next, I was surprised that this saying is from Africa. If you want to go fast, go alone. If you want to go far, go together. And it's true. Sometimes there are tasks that you need to work on like alone. Just you need to disable all your mobile phones, to disable different messengers because you need all your attention to put to approach the task. But this work only in short term. When you are working in long term and you are trying to play alone in this game, you will definitely start to confuse your team to get the conflicts, to start to have collisions just because somebody else already approaches the task and you are duplicating the work. That's why going together is a preference in terms of development, in terms of communities, in terms of companies. And this thing is a new thing for our company. I started to make group decisions a couple months ago. And this thing about, for example, creating estimates or creating architecture decisions. So previously, the only guy that was aware of real architecture was architecture. But it doesn't work really well because the background of this architecture is not shared with the team. And we started to talk with senior guys, senior developers about future architectures that we are going to work on. And this work really cool. Right now we spent a lot of time for these group talks. And the good thing about this is that these senior guys that will be working on this start to be more passionate, more aware of all the drawbacks, of all the risks. And we started to have much less deadlines, breaks. Also, another part is to work on estimates. Because when you're just guessing, like this guy will do that task for eight hours, probably it will work just because you have some skills, some past performances. But when you start to discuss with the guy, this estimate could be from three hours to 20 hours. But the actual developer starts to be more responsible by approaching this task after this communication. And it's a really powerful thing because guessing is more risky part than the real estimate the guy gives to you. So empathy, I know that there is another session about totally empathy in DrupalCon. But I want to talk about empathy as a tool. So when you're working with people, you have empathy. When you're a machinist, you have a hammer. And empathy is like a natural sin. Some of us are really good in it. Like, women's are more better in empathy than men's. But the good news is that empathy could be trained. And from the psychotherapy perspective, the father of Gestalt Therapy is Fritz Bells. And he invaded the hot chair technique. So for example, when you have a conflict in your team with somebody, and talking directly to the guy is not possible for you just because it's maybe painful for you, humiliating thing, or just, I don't know, any other thing. And this technique gives you an opportunity to pretend to talk to the guy. You can put two chairs to sit to one chair and start to talk to another chair like you are talking to the real guy. Then after one minute of talking, you should replace seat to another chair and start to reply to yourself like you are the guy that you was talking to. And this crazy thing helps really a lot to improve your communications. It works like a magic, but it gives you an opportunity to feel exactly how the other guy. So to be more close to the real development, we have a thing that name it Steps for Review. So all our developers should create Steps for Review when they approach the task. They should create them, and these steps should be understandable for the client. So when your developer you're creating something, you are not thinking that you will be using that, right? So you need to fix your task. But when you start to click like a user, to use your forms, to create screenshots, you start really think like a user. And you start even improve your work before actually passing to CodeReview, to QA, or to PM. And it really works well. Another idea, it's a relaxing team flow. So in my career, I met two type of companies. One company is like an army-based flow, right? So you have tough deadlines. You have tough estimates. You can break deadlines. When you break deadlines, you definitely will be blamed by somebody. And this company is good when you really need their product quickly. They do it really well. But the background is like burnout, like people start to procrastinate, and they really start to hate your company at some point. When I was searching for the image about relaxing team flow, I was getting only spa saloons and hotels. And the thing about relaxing team flow, it's about timing. It's about delivery products. In our company, I don't remember really real tough deadlines that we were broken. So yeah, we have some projects that were shifted. But the client feels like it's normal, just because there are new things coming during timeline. And it's normal to shift the deadline, just because we're allowing to behave like we can shift. We can change everything. And when you start to blame, the better thing is start to cooperate. Because in every blame, there is a thing that you need from the guy. Like you need his help. You need his attention. And here is the place when you can get a response by not blaming, but just asking how I can help you and get help from you back. And we have a national saying in Ukraine that keep telling somebody easy pick and you'll get a grant back in three months. And it's true. So when you start to yell on somebody, even really patient guys will start to yell at you back. It's after some time. And last but not the least, so by making some coaching sessions, I've met an issue in a lot of companies that they were thinking that HR managers are all about hiring and firing. And that's it. And it was like a really confusing thing to me because I was asking them, like, guys, what about management? What do you think about that vault in your position? And as an example, right before flying to Dublin, our team was working on fixing some SLA performance issue. And I saw that they posted a lot of comments in that chat. But at some point, both of the guys started to write to me and just say that, hey, that guy is as whole. Please help me to understand what is going on. And write 10 seconds after another guy like the same message. And here's the thing about HR management. You can be like sort of a glue between people. When they have no ability to communicate directly, you can start to be like a translator for them. And after some time, they will get used to communicate between them without your help, not yet. So the good thing about HR management, at least in our country, when I was studying for psychotherapists, 30% of our group were HR managers. They are not working like a psychotherapist right now, but because they allow more to be managers, not the therapists. But the good thing about this is that you can get a lot of information for how to maintain your team from the totally different fields. So not from the IT, but, for example, in my case, from psychotherapy. And that's it. I would like to join us for contributor spins, but try to look at the sprints a different perspective. They can see mentorship, feedbacks, help in communications, per programming, and so on. So you can not only get better in programming, you can get better in mentorship. And we had a code sprint in Ukraine where we had two PMs that were helping us to organize that code sprint. They were working in the same team, in a company with totally unknown guys for them. And it was awesome practice, because after that, we get a lot of feedbacks, a lot of good articles about that experience, and try to look to sprints from different perspective. I believe this is it. And now there is a time to do two things. First thing is evaluate this session. I accept any likes or dislikes, because any feedback would be really appreciated. Another thing, if you have any questions, please ask. Hi. Thank you. This has been a very lovely presentation with a lot of good examples. One of the things that stood out is that you said that men are generally a little worse at empathy than women. I think that might also be related to cultural backgrounds. Yes. World's been a patriarchal place for a long time. In your experience, you obviously have experience with this. Have you tried solving this, encouraging men to be more empathetic? So the gap between people is closed more? Yes. Actually, I'm the guys that glue between these people. And our team mostly are men. And we have a few women. But I guess that by working with me, guys became more empathy just because I'm pushing them to that age. And the good thing about improving the people like to communicate, to talk with them, to ask them to create something. So everything that leads to creation gives you an opportunity to be more empathetic. I don't know how it's. And actually, when we are developing something, it's not always the creation. Sometimes it's just a simple copy pasting. And when I'm a team lead, I'm creating tasks for people that could encourage them, that could bring a lot of communications just because they are more interested in doing their job than just creating forums, buttons, and that's all. Thanks. Welcome. Yes. So it should be a tough question because the guy ends from our company. I will give a few. So first one addition to your previous question. So probably the pair programming is the answer. I mean, when people work together and they're aiming something together, they really start empathy each other. So about the pair programming, I'm really interesting. We have used this one, especially in the cases where we have like a really serious problems. Two guys, I mean, experience start working on the same issue and the results are really good. But how often we have to use it? I mean, as you mentioned, it is not something that it should be used on a daily basis or it could be. Well, it totally depends from a cultural difference. But I'm pushing this more in our team because, well, when you were working on Drupal 7 and your estimate is like eight hours for the task, when you start to work on Drupal 8, your estimate for the same task is, again, eight hours. But in case of Drupal 7, you spend one hour for investigation and seven hours for approaching the task. In Drupal 8, there is a totally different thing. You need to spend seven hours for communications, for investigation, just because somebody else already created that. And this helps a lot to understand that people should ask questions. Sometimes asking questions is like self-blaming thing because when you ask a question, you need to be aware that you don't know the topic that you are asking about. And it's not easy for senior guys, senior I'm. But you can be an example for your guys, for example. I know the loan I'm in Drupal community, the less I know. I know a lot of things. That's why I'm an architect. But I understand that sometimes by just communicating with a senior guy or even middle guy, my decisions, my final results are much better. So I'm learning from the people on my team. And if you can share this experience, if you can talk to other guy and say to them, like, thank you, it will bring your communication level in your team at much higher level. OK. Yeah. Answer the question. Yeah. Makes sense. And another question about team buildings, a few team buildings during the year. And I really wonder, what is better, to have more relaxing team buildings, like Piappa or some leisure somewhere, and just talking to each other, or to have team buildings which are more physical, like playing games, which is better for the mind. As you might understand from my session, I like to combine things. So our team buildings' fashions are really often like relaxing flow. And on other side of the table, we are deploying things. Physically deploying, it's like what's happening yesterday. We were preparing to our company meeting and working on some code. I was talking more about playing football or playing this kind of activities. I guess the best thing you should ask your people and maybe to vote what they prefer. And from the operation side, you need to make the final decision if it fits your goals, your needs, like lead of your team. Yeah. You've been being inclusive as well. I think that's the most important thing. Yeah. You've got to be inclusive. Yeah, good point. Thank you very much. What about burnouts? Yeah. You already mentioned them. But yeah, well, again, just to repeat our conversation just before the session. So we were discussing that sometimes we're working. I mean, DuPo projects are getting bigger and bigger. Sometimes we are breaking agile best practices. And we don't. And we're not like six or nine people on a project, but like 20 people. We are implementing scrim off scrims. Our project managers are really good in a fancy. But seeing about having a big teams is that you can get lost in that team. Yes, absolutely. Well, we are like 20 people on a project. We are remote, the different teams are remote. So I work with some of the people in our offices. But we are international company. We work with different offices. And sometimes I feeling the people which are remote, they feel like a bit on site because I pay more attention on the people which are, yeah. Yeah, you just need to be aware of that. Paying attention to the people in office is like a natural sin. You shouldn't push it because it's just happening. And the main thing that I was talking about, you need to pay more attention to the remote guys. Even if it's not equal to the guys that actually work in office just because, come on, I'm working from home. Yes, I have a spooze, I have my dog, and I feel comfortable with that. But I need to be a part of a team. And this feeling should be trained. It's not coming just in one moment. So all the team leaders should become therapists? No. No, it's a tough way to get. I'm joking, but yeah, I do understand what you mean. I would try to do my best to pay more attention to my people. Thank you. Thank you for your question. Any more questions, guys? Oh, yes. We have 10 more minutes. Hi, everybody. My name is David, and I enjoyed the talk very much. The slides were really funny, and I think you did a good job. What I wanted to ask you about was the limits of empathy. Like, for instance, there's a saying in the United States where it's like talking to the wall. And I meet a lot of developers where it's like talking to the wall. And I can't empathize with the wall. Or you meet problem developers that you have them on your team because you need the resource, but they're just not good. They're bad developers, they're problem people. And it's difficult to empathize with toxic thinking. Yes. Actually, it's a dangerous thing. Exactly. So you don't want to do that, right? But the implication of empathy is that somehow it's my duty to think on your terms so that I can preserve you for some reason. And so that ultimately comes back to the limits of empathy. At what point do you reach the limit of empathy and you take some kind of, let's just say, non-empathetic or unkind action? So my answer would be an example. Because in our team, we also have guys that are not so good, not so kind in group communications, in personal sessions. But in my practice, I'm just trying to find a right guy that can deal with that guy. Because if I can't do that, no need to push myself to do that job. Because it could be toxic, I can get burned out because of that. And I'm really asking for other people, for other project managers, hey, do you have any successful experience with that guy? How it was done? So again, asking other people. Sometimes we, so I was not telling about that yet, we are doing performance review. For example, we have a new guy in our team and I'm asking all our team leads about how you experience with that guy. What should be fixed? What do you need from him on a regular basis and you don't get in that? And by gathering that performance feedback, we are fixing not only communication with that particular guy, but communication between all the team leads just because they are starting to think that performance review could be applied for them as well. And by sharing their experience, we start to understand how to behave with that guy, what's happening in the background, just why he's yelling on us or why he's starting to procrastinate or to skip our tasks or to break the lines. It helps a lot just to do performance review. And another thing that I've learned from our team in particular, that you not only should tell the guy how to work, you need to ask how we can help you to get better as a team. And here is the magic. So guys start to understand that the team can be helpful for him. And there is no room for yelling in this. Yeah, that's why we use that scene that name it firing. Yes, another question. It's like not a question, right? Nothing to be sorry about. Yes. Yeah, agree with you. And that's why the programming works better with the siblings, not when the junior and senior guy, just because the exchange should be equal between the guys. And sometimes you need to work with the junior if you're a senior, just because it's your job. You need to share your experience with them. But it works better when you play as an equal situation. Yes, another question. So getting back to the previous issue and talking to War from my previous experience, it showed me that maybe I didn't showed my empathy to the wall, but actually hit the wall with my empathy. So maybe when you really show your empathy, the wall will start to get softer. And it's not about promoting being a wall, it's just that you want to get him softer and you do that by showing your empathy, not hitting with. Yeah, feelings are always not only mine or somebody else. Feelings are between us. And when you're talking to the wall, in some particular case, you are the wall back to that guy. And by legalizing that, by being aware of that, it will probably help you to understand why it's so and how to behave. And maybe we can just talk about that wall thing between us because in 100% situation, the guy that you think that he is as whole, he thinks that you are as whole as well. It's like a rule. And that's a good point for conversation because you are at the same level. That's a cool, this is awesome, yeah? Yeah, good point. So any other question? Yeah, yeah, we have one minute yet. I mean, I think a fairly important point is how to train empathy. And I think you were a little, you sort of touched on that subject. Do you have any experience in sort of formalized training in empathy, like meditation, for example? Mindfulness, meditation, anything like that? Well, I personally don't like meditation, so I'm not using that tool. But I know that this helps some of the people to change them, and why not? Yeah, I know that Google, for example, have a program called Inside Search. Cool, I will be happy to hear about that program just because when I was preparing the slides and was trying to search IT plus Gestalt, it's like nothing. So it's rare when you are a team lead or architect, and on the other hand, you're a psychotherapist, right? Yeah, it's an art combination. Well, good talk. So thank you. Hello. Thank you. Enjoy the lunch, and don't forget to evaluate the session. Thank you.