Today we're focusing on self-improvements as a team.
We talk a lot about setting ourselves up for personal success. In today's episode, we're focusing on the philosophies of self-improvements as they would relate to working on a team.
How can we create better habits as a development team?
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Our sponsor GitPrime published a free book - 20 Patterns to Watch for Engineering Teams - based data from thousands of enterprise engineering teams. It’s an excellent field guide to help debug your development with data.
Go to GitPrime.com/20Patterns to download the book and get a printed copy mailed to you - for free. Check it out at GitPrime.com/20Patterns.
We've talked quite a bit on this show about what it means to have a well-functioning team. And we can talk quite a bit more, we certainly plan to. And we've also talked quite a bit about what it means to set yourself up for success. Whether that's in your personal habits or in your learning or your perspectives, your philosophy, there's a lot of things that go into both sides of this equation, working well with the team and then working well with yourself. In today's episode, we want to focus on some of the philosophies of self-improvement as they might apply to your team. How can you create better habits as a team, for example? My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in your careers. Now, while we've talked quite a bit about what it means to have an effective team and what the characteristics are of those teams, we haven't talked a whole lot about how to develop those characteristics. How do we create those teams? If we were given a blank slate, we couldn't just say that we want those characteristics and therefore suddenly snap our fingers and have them, instead we need to think about behavior. And in this regard, we've talked quite a bit about our individual behaviors, ways that we can develop good habits, for example. And this is kind of the spirit of many of the episodes of this show, for example, having good defaults, this concept that you will fall to the level of your training. Of course, that comes from the Greek poet Arquilicus. I had to look that one up. If we set ourselves up with these kind of rules for ourselves or our personal behaviors, then how much more important is it to set ourselves up for success as a team? So we're going to go through some of the negative or poor assumptions that we might make when we're thinking about our interactions on a team. And then we're going to talk about ways to address them. The first negative assumption that we make about teams is the assumption of equality. Of course, we're not talking about the equality of worth on the team. Everyone on the team should be respected for their worth and everyone's voice should be elevated. And of course, we believe in those kinds of values. Instead, we're talking about equality of perspective. This is really critical. We can assume that everyone has the same perspective as us. We can assume that similarly, another thing that we get wrong and this is related to assuming that people's perspective is our perspective, we also believe that people's perspectives stay the same. In other words, everyone else's perspective remains whatever it was when we first met them. This can lead to some surprising consequences and unfortunately, it can lead to conflict. If someone seems like they've changed their mind, for example, on a particular opinion, we don't see that as growth by default. By default, we're going to see that as the person not being able to make up their minds, maybe their flip-flopping on whatever their opinion was to begin with. We see this play out in politics all the time. Of course, here's what makes this worse. We allow ourselves the opportunity to grow and to change our own minds. And on top of that, if that wasn't already difficult enough, we also have a hard time remembering whenever we have changed our minds. We have a hard time remembering believing something different than we believe today. So we'll call both of these issues kind of a lack of understanding for the dynamic nature of other people's perspectives. And we need to address this kind of first and foremost because perception is arguably the entire basis for our relationships with each other. And so we need to address this. How do we do this? Well, when we talked about having useful defaults for ourselves and when we talk about building habits for ourselves, we need to start with something very simple. In this case, I encourage you to start with a recurring question. If you have a meeting already on the books, for example, a stand-up, maybe a weekly meeting that you can bring this question up on a regular basis, that would be helpful. The question is very simple. What have you learned or changed your mind about recently and why? This question is two parts. What have you learned and secondly, what have you changed your mind about? Because these are kind of two ways of talking about the same concept, the same idea of perception change. In the first case, you may have gone from having no opinion or no perception on a given subject to having a new opinion or a perception on that. And then in the second case, you may have changed your perception or opinion on a given subject. Both are incredibly important. And by asking this question on a regular basis, you begin to adapt to the idea that people's minds and perceptions change regularly. This is important for both the person that is asking the question and for the person who is being asked the question. We need to make changing of perception a safe thing to do on a team. And by asking people to intentionally reflect on ways that their perception has changed, we are inviting them to remember those things. We're inviting them to discuss those points of growth for themselves. We're going to take a quick sponsor break and then we're going to come back and talk about another harmful assumption that we make and how we can address it. Today's episode is sponsored by Get Prime. Speaking of high functioning teams, Get Prime is helping your team become exactly that. If you've ever seen a really high functioning engineering manager, you know one of the hallmarks of those kinds of managers is that they know how to debug problems. They view their teams as complex systems, inputs and outputs with biases with all kinds of interactions between their teams and they approach problems with curiosity and relentless pursuit of the root cause. And if you were to survey five or a hundred of these engineering managers, you would probably find that they see similar patterns emerging. So what exactly would those patterns be? Well that's what Get Prime's book will surface for you. Head over to getprime.com slash 20 patterns. That's getprime.com slash 20 patterns to download the book and you can also get a printed copy mail to you for free. Check it out once again, that's getprimegtprime.com slash 20 patterns. Thanks again to getprime for sponsoring today's episode. The next harmful assumption that we can make about our teams is that everyone on the team communicates equally effectively. This is a difficult assumption to break because communication seems like a basic skill. If we can talk and if we can express ourselves, if we all have our jobs here, if we're able to work on tasks effectively, then certainly we know how to communicate with each other. The truth unfortunately is just not quite that simple. Communication is not just about the person who is communicating. It's also about their audience and perhaps more importantly, their context. A given person who otherwise would be an excellent communicator on the wrong team may be less of an excellent communicator. This doesn't mean that the team will necessarily suffer, but it does mean that that person may not be able to contribute their full value to the team. There are other ways that these kinds of communication errors show up when we assume that everything is a level playing field. For example, often the loudest voice or the person with the most coherent story is going to be the person that people listen to. Even if the ideas that that person is presenting are inferior to the ideas of another person. What's more, often the complaints of a given louder person may be about something that they care very little about and the complaints of a person who is deeply dissatisfied in a project or if they have something that they care greatly about, they may not surface that complaint as loudly or as often as another person. This is kind of a difficult concept to understand until you actually experience it, but what you end up with is this asymmetrical communication pattern that ends up flowing from each person on the team. How do you address this? It kind of depends on what kind of communication patterns you have on the team, but one way to address it is to create some common and consistent channels of communication for each person. For example, ensuring that everyone's voice is heard at a retrospective meeting. If one person is dominating the conversation, find a way to elevate the voices of those who are not dominating the conversation. It doesn't mean that everyone has to have exactly the same amount of time in every discussion, but it does mean that we want to provide equal agency to each member of the team. Another way to kind of elevate everyone's voice or to create a less asymmetrical situation of communication on a team is to create some objective measures that represent subjective things. So, for example, if you are an engineering manager and you have one-on-ones, which I would highly recommend that you do, in that one-on-one, ask each person how they're doing on a scale from one to five. Of course, this doesn't replace the discussion that you're going to have with them in that one-on-one. It doesn't replace giving them an opportunity to express the full range of their emotions or their reasoning, but what it does do is it gives you a measure of severity. It gives you an idea of how deeply this person is feeling those feelings. Because everyone communicates differently, this is fundamentally going to change your perception of this person's communication of what they're saying to you. So, I've had this happen in many scenarios where a particular developer was feeling mostly good and we were using a scale of one to ten at the time and they would say, I'm an eight or I'm a nine or I'm a ten, and then they would go on in the meeting and explain all of the things that were going wrong. If I had guessed what that number was, then I would have guessed much lower based on what they said. So, this creates a less of an asymmetry of information, a less of an asymmetry of communication by building some kind of objective measure that everyone uses the same objective measure for something that would otherwise be implicit. Whenever things are implicit, we often have extra errors that we add into them. This is kind of a bonus point, but anywhere that you see implicit measures, it's worth considering if that measure would improve if you made it explicit. Thank you so much for listening to today's episode of Developer Tea. I hope that this will help you create some better patterns and do away with some bad assumptions on your teams. Teams require the same kind of intentionality that personal growth requires and in some cases that intentionality is even more important for a team because of the complexity of the different relationships on that team. Thank you so much for listening. Thank you again to get prime for sponsoring today's episode. Speaking of refining your teams, Git Prime has written a book that will help you do just that. You can identify 20 patterns of great software engineering teams head over to GitPrime.com slash 20 patterns that's Git GIT as in the tool Git GitPrime.com slash 20 patterns. Thanks again to Git Prime for sponsoring today's episode. If you haven't subscribed yet, then I encourage you to subscribe in whatever podcasting app you're currently using. Here's why I encourage you to subscribe. It's not because you have to listen to every episode of this show. In fact, I encourage you to pick and choose the ones that you feel are most relevant to you. Here's what I see most often happening. When people want to change their behavior, they have a lot of initial energy to do that. You may say, I'm going to listen to Developer Tea and I'm going to work on improving in my career, maybe I'll listen to a couple other podcasts, read a couple of other blogs. You rely on that initial feeling of energy, that initial motivation to carry you through. Fast forward five days or even two weeks, and a lot of that motivation is gone. Now it's about having a habit. One thing that we know about habits is that whenever we can put something on automatic, it's going to help us with that habit. If you want to make listening to this show a habit, subscribing to the show is one of the first steps to making that habit stick. Thanks again for listening. Thank you to today's producer, Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.