Not only is this post not strictly related to coding, but I also mentioned I am a PM right in the topic. What is this, reverse-clickbait?
Normally I post about code, but I sometimes want to write also on topics connected with teamwork. Most developers I met understood that good teamwork is everyone's concern, even though they probably don't spend as much time reading about it as they do learning about newest tech.
So today I wanted to write about three most valuable lessons I learned working with a team. They are not relevant only to a PM's work - on the contrary. The most valuable lessons I learned were not on how to hold a productive status meeting or effectively negotiate with stakeholders, but rather on how to work with other people.
I also want to say up-front that I learned there lessons in equal parts through success and failure. There were times when I stuck to them, and that felt cool, but also times where I failed and regretted it afterwards. So this is not an attempt to fashion myself as a genius project manager or anything like that - just to share some advice that turned out to be true for me 😉
With that disclaimer over, here comes the meat:
One thing that I’ve definitely heard too much of when working with a team (sometimes also out of my own mouth) is complaints about how other people work. “I think his coding is too slow”, “I don’t understand what she tried to achieve with this solution”, “I wish they could be clearer about their expectations”.
Complaining about other people’s work when they are not present is very common. Sometimes it seems like a natural way to vent some of the stress we face in our work. We also do it just because it’s so easy. However, it’s also something else: completely unproductive and potentially harmful. By complaining about how others work, you are wasting both your own time, and the time of the person who is listening to your complaints. Meanwhile, nothing is actually being resolved. Moreover, if “team gossip” like this escalates, it can result in a lot of unwanted conflict that could have been avoided.
There may be rare situations where talking to someone else about your teammate’s problem might be more appropriate, but I think that in most cases you are far better off talking to your teammate directly. You will resolve issues faster, and get a chance to understand your teammate’s work and the challenges they might be facing.
No matter what role you have on the team, sooner or later somebody might ask for your help with a problem. If you are their manager or senior, you might feel obligated to decide for them how to solve that problem - but I don’t think you should do that. Why?
People dislike making decisions. That’s completely understandable - we all have to make so many every day that sometimes it just becomes tiring. If we get a chance to push some of these decisions onto someone else, like a manager or senior, we will usually (even unintentionally) do so. However, that is a slippery slope. If a teammate comes to you with a big problem and you decide for them, they will come back to you the next day with a smaller problem. This will keep happening until you are drowning in a puddle of tiny decisions that your teammate was perfectly capable of making. You are now wasting your time micro-managing someone else’s work, but you’re also doing something far worse - you’re undermining their confidence.
Rather than doing that, I think it’s better to ask questions, to give your perspective when asked for it, and to help your teammate discover the solution for themselves. In the end, they are the ones that are closest to the problem - so they will probably be able to come up with the best answer.
You know that thing your brain does sometimes when you’re going to sleep, and suddenly remember something stupid you've said or done years ago? I’m not a psychologist, so I don’t know what the exact cause for that is, but I think we all tend to remember negative experiences much more vividly than positive ones. This happens in the workplace too - when I receive feedback, I tend to focus on the negatives much more than the positives. This is why I think you should criticize people’s work only when you really have to, but praise it whenever you can.
No team is 100% in sync - some problems are bound to crop up, either with your or somebody else’s approach. If you think it will be productive to point out an issue with your teammate’s work, by all means do so. Keep your feedback constructive and to the point, but also make sure that it comes from a place of empathy. The situation is rarely as straightforward as it seems, so I think you should always be ready to listen to your teammate’s perspective. Your aim is not to undermine anyone, but to resolve a problem so that your team can work better, right?
The flip side is that you should also praise your teammates for the work they do whenever you get the chance. I’m not saying you should tell everyone they are “doing a great job” everyday right after the morning coffee - that would be dishonest (unless your team just happens to be doing a great job every day right after the morning coffee). But when your team or one of your teammates does get something right, don’t be embarrassed to openly praise them. Get into the habit of pointing out small successes. You might notice that this builds up not only your team, but also your own confidence in the project and the work you do.
In the end, I want to stress that I don’t believe these are sacred rules that everyone should follow - or that anyone is wrong for having a different outlook. Every team is different, every company has their own management style and work culture. But regardless of where and how you work, I think it's a good exercise to try to verbalize your own principles. To think about the values that you believe in - like honesty, trust, courage - and how you can apply them best in your work in the work you do for your team.
If you have any of your own pointers about teamwork I'd love to read them 😊 And if you wrote a post on this topic in the past, definitely post a link in the comments!