Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I'm taking a listener question from Lars about how to deal with a difficult team member. Today's episode is brought to you by spec.fm. If you're a designer or developer and you're looking to level up in your career, spec is the place to go to find other people just like you talking about that exact subject. You have a ton of shows on spec and I can't wait to hear what you think of all of them. So go and check out spec.fm. Today's episode is also brought to you by heap. If you're still using Google Analytics as your primary source for analytics, then you're probably doing things wrong and we're going to talk about how heap can help you later on in today's episode. So Lars writes in, he says, hi Jonathan. First of all, I really like Developer Tea. Great podcast. I may have an interesting listener question for one of your next episodes. Lars I'm glad you decided to send this in by the way. It is an interesting question and it's one that we haven't really covered in detail up until today. So I'm excited to talk about this. Lars says, I am the lead of a small Developer Tea of five developers. One of the team members is pretty difficult to work with. He denies to do tasks that I give him. Also he always complains about almost everything and he says that every decision basically made by management is bad. Of course, he's cynical all the time. Maybe you have good advice for how to deal with team members like that. We've had many episodes about these subjects from the perspective of the developer. We talked about how cynicism for example is a poison for developers. But I want to approach this from Lars's perspective. Lars is trying to lead this particular developer and that's a difficult position to be in. I do have some key pieces of advice for you Lars. But first let's take a step back and say, if you as a developer, if you find yourself in this position, then it's important for you to listen to this episode and understand that these behaviors are ultimately very difficult to lead. In other words, you're making your boss's job harder. Now we've talked about getting raises on this show before. We've talked about how to move up in your career, how to level up. That's what spec is all about how to level up in your career. And one guaranteed way to not level up in your career is to make your boss's life hard. Another guaranteed way to not level up in your career is to make your co-workers' lives hard. So if you're a developer and you're listening to this and you think maybe you fall into the category of developer that Lars is describing, then I want you to listen to this episode very closely and also consider how you may change for the better. Now that we've said that, let's go ahead and jump into the key pieces of advice. And the reality is a lot of this advice is based on the leadership, not based on what you should tell the developer. Because as a leader, if you aren't looking inward first, then you're probably missing a lot of opportunity to incite change in others. What you do people will respond to. That is the fundamental concept of leadership. What you do, the things you say, the way you act, people will respond to those things. So a key piece of advice number one, take time to meet one on one with that developer. Take time to meet one on one with that developer. Sometimes if you don't have a weekly meeting with each of your five developers, even if it's 10 or 20 minutes long, if you aren't setting that meeting up, I highly recommend that you invest the time to do that. Go and get breakfast with them or lunch or even just a coffee. The point of going and getting food or a drink is to get you out of the office environment and into a one on one personal environment. Hopefully this will help your developers open up a little bit about how they're feeling about their job. And really what you're doing, Lars, is you are simply listening. You're giving them an outlet to share their opinions. You're giving them an outlet to share their emotions about their job. You're giving them the opportunity to express what they are thinking. This is something that is so often forgotten how important this is. If we don't have the opportunity to express how we're thinking or how we're feeling, a lot of times that builds up pressure, that builds up tension, and ultimately that can convert into resentment. So it's absolutely essential that your team members have the opportunity to share their opinions, share their ideas and share their emotions, their thoughts. You should give them a safe place to do this. You give them the opportunity to speak to you and you keep that confidential between the two of you. This is hugely valuable. It may sound like it's just a bandaid, but really this is a fundamental part of the leadership role. And that is to give the people that you lead the opportunity to speak to you. Number two, ask the developer for their input and collaboration. This is not necessarily the one-on-one moment, although it is important for you to mention this in your one-on-one moments with that developer. But what you're saying here is you want that developer to work and to give their expertise or their opinion about the work itself. This is in the office environment. You're opening the door for collaboration in the office environment. And what this allows is if that developer truly does have a better idea for management, now they aren't just grumbling about it and saying it under their breath or sending it in a message to you after the fact. Instead, you're opening the door for collaboration up front. This does two things. Number one, it democratizes the idea space. In other words, good ideas can come from anywhere. And even though this developer's attitude may seem like it's not that great today, that developer may have a great idea. It may be the case that that developer has the opportunity to help management with their problem solving. That's number one. And number two, the second thing that giving the developer the opportunity to collaborate, the second thing that that does is that it gives them no excuse for when they disagree later. If they disagree now, they have the opportunity to voice those concerns. And if they don't voice them, they're much less likely to be disgruntled later. So number one is take time to meet one-on-one with the developer. Number two is ask the developer for their input and collaboration. Both of these are giving the developer a stage to express themselves. Both of these are giving the developer the opportunity to have input into their job. And the reason for this large, the reason we want to give the developer the opportunity to have input is because this behavior is indicative of someone who doesn't feel like they have input. This behavior is indicative of someone who feels like their ideas are generally not heard. So that's number one. And number two, take the time to meet one-on-one with the developer. And number two, ask the developer for their input and their collaboration. We're going to take a quick sponsor break to talk about heap. If your web or mobile app is still using Google Analytics as its primary analytics source, then you're probably doing things wrong. Because with Google Analytics, you need to manually code up your event tracking for everything you want to visualize in the different funnels and graphs, whereas heap analytics automatically records everything users do on your site or in your app. Every page view, button click, form entry, swipe, and tap. How great would it be as a developer for the non-engineering folks in your company to stop asking you to add new Google tracking events? That's exactly what heap does. With heap engineers and project managers see all user data in funnels and graphs automatically. And the coolest part about heap's automatic data collection is that you don't have to figure out what questions you want to ask of your analytics from day one. Since everything is being tracked, you can go back and decide what those questions are later. You can run a query like how many users clicked, request a quote, button, then wound up signing up, six months down the line, even if you never thought to originally manually track, request a quote button clicks. Now, if you're a developer and you've worked with analytics before, you know this is incredibly important and having a single solution like this is incredibly valuable because you never know the right questions to ask from day one. And of course, all of the things that you're used to in a good analytics engine, heap has, you can break people down by device type, geography, etc. You can view their view maps, you can see where people are having trouble in your application. And that's exactly what heap is made for. So go and check it out, spec.fm slash heap, and you'll be redirected to heap's special landing page where you can see a full feature breakdown of what heap can do for you. Go and check it out, spec.fm slash heap. Thanks again to heap for sponsoring today's episode of Developer Tea. So today's episode we're taking this listener question from Lars about dealing with a difficult to work with developer, particularly as a leader. And the first two pieces of advice that I gave you, Lars, were all about you and giving that developer the space to speak to you. Right? Number one was take time to meet one on one with the developer. Number two, ask the developer for their input and their collaboration. Number three, we start talking about what you may need to do. Lars, how you need to speak to this developer about their behavior. Number three, talk to them about the impact of their work and their decisions on others. Talk to them about the impact of their work and their decisions on others. There are two people or two groups of people rather that are impacted by this person's decisions. Number one, perhaps the most important one is the client. And number two, more directly, is other team members. Right? So other developers or non-developers, whoever they are, this person's decisions, this person's behavior, is affecting those two groups of people directly. Sometimes people have a hard time connecting their behavior with the outcome of that behavior. Sometimes people have a hard time understanding that their cynicism leads to poor working quality. Sometimes people have a hard time understanding that their work is actually affecting the day-to-day lives of their clients, most often. So in your one-on-ones or impassing, make the effect of the work more visible to your developers. Make the effect of the decisions more visible to them. And it may take you actually sitting down with this developer and saying, hey, you know, your behavior is actually affecting those around you. And I've noticed that you seem to be in disagreement with management. And I've noticed that you've not been able to finish the tasks that have been handed to you. And I just wanted to make you aware that number one, it is the expectation that you do finish these tasks. And number two, when you don't finish these tasks, and this is the important part, when you don't finish these tasks, the other people around you have to pick up the slack. Right? I have to stay, I had to stay late an hour yesterday or something like that. Right? And what this does is it connects concretely the consequences of this person's actions, the consequences on other people of their actions, which leads us to number four. And this is a very uncommon thing for us to talk about on this show. And I want you to understand that this is a last resort in my mind. And that is a crucial conversation. Ultimately, if these discussions don't help to shift the momentum for this person, for this developer, that you are the leader of, Lars, if these types of conversations in the open floor, and all of this extra space that you're giving this developer to express their needs or their opinions, if that doesn't help shift the momentum for this person, you need to have a conversation about attitude and expectations, with the developer. A very specific conversation about attitudes and expectations, where you outline that the person that is supposed to fill their position, the person with their job, is expected to have a particular attitude, and they're expected to reasonably do the work that they are asked to do. If this doesn't help encourage better behavior over a period of time, it's time to let the individual know that they are now breaking their employment agreement with you. As you have laid out your expectations, and you've provided plenty of time, and patience to see change. In other words, they simply are not doing their job, and they're belligerently not doing their job. They aren't accidentally doing it because you've been explicit with them at this point. As a leader, it's incredibly important that you also recognize that at some point, these actions of this one developer may ultimately be damaging your other teammates. Don't allow yourself to sacrifice the health of your entire department, or the viability of your company by compromising for one person, by giving this one developer an endless amount of leeway. If it comes down to it, if someone is belligerently defying what is necessary to help the team succeed, it's time to consider letting the person move on from their position. That means, and this is the ugly word we don't like to use, and thus we absolutely have to, that means letting this person go. If this person continues to be unhappy, if they continue to choose to be unhappy in their job, ultimately you may be giving this person the opportunity that they've been waiting for to leave the job. Now this also provides you with an opportunity to have someone actually fill the position and do the job that they've been hired to do. But Lars, first, I want you to look in the mirror. As a leader, it's incredibly difficult to get things right for everyone. It's not easy to be a leader, and it's also not easy to get everyone to understand the implications of their actions. But if you aren't looking in the mirror first, then it doesn't matter what this developer does. It doesn't matter if you fire this one developer. If the problem still exists once this developer is gone, if you are generating the problem yourself as the leader, by not giving them the space to discuss their opinions and their ideas, or by not making them aware of the interactions between what they do and the consequences of what they do, if you as a leader are not doing those things, then you're going to continue having the same problems. If it comes down to it, firing is an option. Letting someone go, letting them move on to the next stage of their career, that is absolutely an option. And in fact, many times it is the right answer. But if you don't solve an underlying problem, then firing doesn't do anything more than treat the symptom. So understand that you have a big responsibility here Lars. You have the responsibility of leading other people and helping them find their most effective work. That's what you're doing day in and day out Lars. Hopefully you will be able to see change with a simple one-on-one meeting. Hopefully you'll be able to see change by giving these Developer The opportunity to collaborate a little bit more and to have input into their jobs. Thank you so much for listening to today's episode of Developer Tea. Hopefully as a developer you found this both convicting and exciting because you have the opportunity to understand the consequences of your actions each and every day. Thank you so much again to Keep for sponsoring today's episode. If you're using Google Analytics as the primary source of analytics for your app or your website, then you may be doing things wrong. And you may be able to find a lot of joy in using Heaps. Go and check it out, spec.fm slash heap. Of course, go and check out all of the fantastic shows that we have on spec at spec.fm. Of course, the show notes for today's episode can be found at spec.fm. Thank you so much for listening. You are the reason this show exists. Until next time, enjoy your tea.