 Thank you. Thank you all for being here. There's a lot of great content here, so I appreciate you guys taking time to enjoy this talk. My name is Michael Abbott. I'm a quality engineer back then, and I work on the Coral West project right now. And the reason I decided to do this talk is because since joining Red Hat in four years ago, I've been a part of a really great team, and I found the strength in the team is basically built on the relationships of the team members. So I'm here to talk about how you can build those relationships to have a really high function in the team. First, I said bad news though. I've got an expert in this. I'll give you some advice for ideas. You can probably come up with yourself with some research and business management practices and stuff like that. And I'm not going to guarantee that this is going to work for you and your team. Team by the mix are incredibly complex, and you have to figure out what's going to work best for your team. A good side though, I've been doing this for 20 years. I've seen a lot of good, bad, great teams. Thankfully, here's what I've had been all great. And before I went to the software development software, I had a technology group, so I have a little bit of that. Georgia's thought it's going to be focused around building a team in an agile framework, in an agile way. Building teams that use the agile methodology. I'll talk about why I think the old way of doing things, the waterfall method, isn't as effective and how agile solves some of these problems and how you can apply the basil's hierarchy needs to an agile team to grow and to be more strong. So this is our temptation of the waterfall method. The way I see this is that you have individual silos of each stage of software development with a single output that goes to one way. There's no representation of feedback to other teams for the previous stage of each model, and that has a lot of problems. For example, the silos tend to breed for communication. When you have one stage just giving the output to the next stage, they're not really taught. They're not worried about communicating with the people who are receiving the output of your state of software development, whether it's design or architecture or development. And there's not a lot of collaborations that everyone's focused on, just their one output. They don't really care about what happens the next time, from the next day to the evening. There's also a really poor model for accountability. Typically we see this in developing QB interaction where developing finishes their code, they throw a ball, keep the QB and QE gets it and it doesn't build. It's crashes and core dumps and then you have to restart the process and start over. I also found that it's not really conducive to feedback or improvement. Most people just want to get through their stage and then wash their hands of the work and move on to the next stage. They're not taking the time to think about what went wrong in this particular state or that particular product and they don't really want to improve because improvement is hard. And when the interactions do happen between the teams, they can be stressful, but it's usually around a customer that has a problem that where everything's on fire, you've got Dev and QE involved, sales involved, management involved, high stress, everyone wants to find a solution and no one's going to be acting on their best behavior. So this is where Agile comes in. By default, it encourages inclusivity and collaboration on your team. So I'm part of an added team at Red Hat. I'm QB and teammates are development. We have support people coming in to help out documentation people and to come out. Even marketing comes in our case and talks to talk to us. So we already have this inclusive collaborative model to work for. We also rely on frequent communication work. We have regular stand-ups. We have regular retrospectives where we get to talk about what worked and didn't work. And that leads us to the ability to continuously improve and evolve. So at these retrospectives, we can talk about what worked and didn't work and then try ideas to make that process better for our team. And finally, since we're all on this cohesive team, we have the shared accountability about what we succeed when we fail. If something doesn't work coming out of our team, it's not us pointing at one person or another. It's the whole team that owns that problem, that and that success. So this is where we can start to apply Maslow's hierarchy. So Maslow's hierarchy of needs was introduced by Abraham Maslow in 1943. It's a model for human growth, basically. And the model states that you can't start to think about the higher-order needs unless you met your lower-level needs. So in software development, hopefully all of us have basic needs met. We have food, water, warmth, security and safety over our heads. And that allows us to not think about the next-order needs. And when talking about software development on teams, what we're going to focus on is the middle-to-level psychological needs of the long-ness and the speed. I'll scratch the surface of self-actualization, but that's a really broad topic that I don't think we can limit to just working on a team and a group network. So the long-ness defined as intimate relationships, friends, and hopefully co-workers. It's human nature for us to want to be part of a group. You'll look at evolutionary evolved from animals that form troops that are human form tribes and then form towns and cities and have a whole civilization. Or if you take it down to a smaller level, you know, in the workplace, we're a part of a small group. You want to belong, you want to feel like you are part of a team. I think the best way to do that is to strengthen relationships. These relationships are at the backbone of your group. If you don't have a strong relationship with your team members, you're not going to be able to have the open and honest communication that I talk about here, or the trust to talk to your close team members openly without the fear of being bothered negatively. So how do we build relationships? In my opinion, the best way to do this is through in-person interactions. This isn't ideal for highly distributed teams, so you can approximate this with video calls. You don't want to forget those for no team members, but you're all working on distributed distributed teams because they easily feel like they're not part of the team if they're not included in regular conversations. So it's important to keep those lines of communication open. I think in-person interaction can and should happen during and after work hours. So during work hours, that's kind of obvious. You have to talk to everybody throughout the team. But after work hours, that's a chance we can share a beer, have a meal, talk about one another, get to know your team members. And that level of familiarity with your team members is going to breed that trust and that support within your team. And that just is going to benefit the team as a whole as you move forward through the software development process. I like to say if you have a large team that's distributed, you should aim to get it in one person and be included in here. I have all the money in the world. I'll be doing it like every quarter of my team. So to come to the recap, interactive grid test is, okay, video, you get better in-person, wow, and after hours of interaction, it's fine. So this is an idea I have in terms of belongingness. He is a confidence champion. When you're building a team or you're a new team, you may not feel comfortable enough to share all your controversial ideas or the group at large. So I find it helps to find someone on the team that you can trust singularly to say, well, I've got this idea or I've got this opinion, but I'm not sure how the group's going to react to it. What do you think? And they can help you kind of shape the, give you the feedback you need to engage whether you want to reach the topic with your large team. I also think it's even better to try to champion on your team or extra. This champion is someone that will support and encourage your work, provide you the sort of moral imperative essentially to pursue ideas that you think are interesting or you think are valuable, and hopefully make you more successful as an engineer and then as a person. Now we have some belongingness covered. We've built some relations with our team. We need to talk about a scheme. A scheme is designed as a scheme for you to accomplish it. And that basically means everyone wants to feel like their contribution are important. The best way to do that is to practice and get feedback. So feedback can take a lot of different forms. So I'll get into that right now. The easiest way to get feedback is just to gratitude. I think as an industry, you can do a really core job of giving thanks to each other for things as simple as like, hey, can you open up a bug report for me? Hey, can you create a Jira card for me? Just these small jobs, small tasks that we do on a day-to-day basis, we often forget to say thank you to the person who did it. And I think that thanking you a long way is you never know what kind of day that person is having, what kind of problems they might be facing, and that little brightness of thanks could make a difference in their day. Another form of feedback is celebrating achievement. So within a group, say you have a junior engineer, and they get their first PR emergency street. Like, that's worthy of celebrating within the group because they've never done that before. It was probably difficult for them. It was probably a big barrier for them to overcome. That deserves achievement. And then in the other hand, you might have somebody who was a ward of patent. That's something you might want to broadcast to your organization. Hey, this engineer's got a patent. Let's congratulate him on the work he did there. The core feedback, advice on how to improve. And this is sometimes labeled as criticism, but I think criticism has a negative contribution. So if you think about giving feedback on someone's pull request or code, if you were to say, well, I don't think the way you did this, you should do it this way, that is going to be received negatively. Instead, if you frame it as, that way will work. Have you considered doing it this way because it's more performant or more stylistic or more efficient? Framing that advice in a positive way is going to fill that relationship with those team members and make them more open to accept the additional feedback from you. The other type of feedback that I think we need to practice is apologies. No one's perfect. We're always going to make mistakes. Sometimes you're going to submit, you're going to merge that pull request, and it's going to break everything. So give her or his friend and you should take ownership of that and say you're sorry. Likewise, if you are interacting with somebody who's apologizing for a mistake, you need to accept that apology respectfully as well and move on. No one wants to be reminded of the mistakes they made in the past and having that hell over their head as some sort of battle. And hopefully all this feedback has to be of respect to me. Whether it's positive or negative, if you're tossing around feedback without justification, it's going to lose its value and it will cause your team members to withdraw from your team and not be as well integrated and participate. So I've thrown this quote up, put up your feedback. Someone's farther than me just said we did the day and it really resonated because when you think about getting that feedback, whether it's positive or negative, the positive one you can internalize to make yourself feel good about yourself in that day or that moment, whatever. The advice on improve, again, that's an opportunity for you to grow as a person, become better as a person, become better as you do. Self-actualization, this is a tricky one. Achieving one's full potential including creative activity as well. Full potential only talking about what you're doing at work seems to go contrary to each other. So you can't achieve self-actualization only working with the other things. But if you have these strong respectful relationships with your team, you no longer have to. Whether your ideas, whether your opinions are going to have a negative impact on your team or be received negatively. So that frees you up to kind of think of more creative solutions to problems pursue more creative goals or even attempt activities that are outside your normal job description. Using myself as an example, I'm a Q&A engineer by title, by trade. But having joined this amazing team at Red Hat and grown together has great relationships, a great respect for one another. Now I've been encouraged to pursue things like writing articles for Austrian magazines, Austrian blogs, public speaking. This is my first DevCon presentation which I never thought I would do but it's scratching a mission. I didn't know I had it, so. And the only reason I could do that is, like I said, I have this team that respects me and supports me and allows me to pursue these additional goals. So implementing a hierarchy practice. Number one is going to take time for patients because relationships are built over time. You can start implementing these ideas in one week and then suddenly we have a perfectly functioning team where everyone's happy to work and is willing to accept that people are progressing at different places and during this time you can discover the strengths and weaknesses of your team and that will allow you to assign work with our faculty and pair people up to a compliment point or another. So you need to have treatment interactions. In the agile or scrum, we use scrum in my team. We have those daily standouts where we talk about what we're working on and what we're going to work on. We have regular retrospectives where we talk about what didn't work and what didn't work and the previous sprint. And in our case, we have these open hours where we do ones a week where we all jump on a video call and we can talk about the problems facing, technical problems team is facing as well as a chance just to ask how the weather is, what kind of movies do they see, what you have for dinner, how are the kids, the kind of thing like building those personal relationships, forming stronger connections with your team and also it will be strengthening the team as a whole. As I said earlier, interact during and after work hours. Go grab a beer with that guy that you work with or that girl that you work with. By the way, I have a team dinner here at DevCon. It's great. I have most of my team here. We had a team dinner yesterday. It was amazing just to be able to talk to these people not necessarily about work but just to talk about the world and what we're into and all that stuff. And then if you're in an office and you have teammates that are on different floors for you to pass, take the time to have your desk go grab a coffee, go down to the guy who will know you or the girl who loves you and talk to them about their day and ask them how they're doing and just have that face-to-face interaction which is having a really powerful, powerful way to build relationships with your team. We also need team waiters to demonstrate these principles. The team wait doesn't necessarily have to be by title. You might have somebody on your team who is a little more charismatic, a little more energetic and excited about building these relationships with your team members. I think when you have people like that who are willing to put themselves out there and try these activities, try these practices, it will demonstrate to the other team members that it's okay to kind of build yourself up a little bit and share more things with your team. But it shouldn't be voluntary because not everyone is going to be excited about sharing their feelings or sharing what they did last night or sharing where they go and what they're doing. Some people just like to sit in front of the terminal, write code, and log off into the day and that's it. So that being said, you don't want to exclude those people. You want to continually give them the opportunity to participate in these discussions, the opportunity to share things about themselves with the rest of the team. Finally, how do you measure this? How do you know that what you're doing with these principles with the hierarchy is actually working? I've found a objective way to measure this. If somebody has some metrics of what you're going to do, you're about that. I think subjectively you can consider questions like this. So the set of personal questions instead of like quarterly questions, like, do you know more than the name where somebody lives of the team members that you work with? I know in some cases you might not be because you might want to share that with them, that's fine. But I know I don't think using myself as an example, I know the names and where, the names of everybody where they live, you know, if they're married, I know if they have kids and if they have cats I know what kind of music they listen to. We share beers together, we share drinks together, so there's a rich relationship that we have on this team. And like I said, that is the foundation of building trust and respect. Likewise, you have a conversation about things other than work. It's easy to get together in a group and then start really talking about the technical problems you're facing with me or the solution that you're working on or this project you're working on. Like, after work's projects might fall into the personal information you want to talk about. I'm talking about the same space where you bring one of these. The ability to do that is very powerful. And then in the workspace can you have open disagreements respectively in the military field? So, this means like, you have a problem facing there's two different solutions. How do you discuss those solutions and come out of there without having your team enchantment? Very difficult to do on a team. Have the respect and trust with one another. You have the respect and trust. You can get really heated about the solutions and talk about them. And then walk out the door and say, that was a discussion. We'll see you again. Can you hold your team members accountable? When they say, I'm going to do X, Y, Z by the end of the day. And it's really important to your deliverables. Can you hold them? Can you go to them and say, well, you haven't delivered this for me. What's going on? Can I help you? Is there something that we can do together to achieve your goals? Close them to the next question. Are you willing to help your team members to achieve their goals? Some people want to just have head down. I don't work in the group. But I think when you have a strong team, you're willing to collaborate together to try to achieve goals together. And then finally, does your team evaluate what are your milestones? If you recall the abstract I have from this talk, I said, well, what if you have a team that has all the technical talent in the world but they can't deliver their milestones? In this hypothetical team, I would guess that they're probably not a well-rounded team internally. In terms of having strong relationships, they're probably just head down trying to solve all the problems themselves and not willing to talk to another team member about how it can work. If you want to hit me up on Twitter, it's the beginning of the presentation I'm reading here on Twitter. That's the best way to get in touch with me. Thanks to this team building exercise site. You have your team and the introvert. They've been enjoying this kind of work. So the question is, what do you do when you're having to kind of force them to participate? Because that will immediately, most likely, after they'll do it, they will participate because they don't want to look bad to the team necessarily, usually, but it's not going to be genuine. They'll just say whatever the minimum is required to get them to do that participation. So all you can do is just encourage them to participate and have them.