TJL #20: Reflections on my first remote project (part 2)
Hi friends,
Welcome back to Today Jan Learned (TJL) #20. This is the second part of my reflections on my first remote project. If you haven’t read part 1 yet you can do that by clicking here:
The key lesson in the first part of this series was that you should communicate more than you are used to in a remote project. The key lesson in the second part of this series is that it is your responsibility to be a productive member of a team.
Let’s start with a bit of team dynamics.
Lack of team cohesion
I really experienced a lack of team cohesion. Our team was remote with some of our team members based in Europe and others in Asia. Perhaps the personalities of the team members didn’t match either but it often just felt like I was working alone, together. There was not really a “team spirit”, whatever that means. Communication was formal, professional, not a lot of banter or time for “fun”.
What I wonder is if you can “force” this kind of team spirit through team-building activities and doing other fun things together remotely. I wonder.
And here’s something that I learned the hard way.
It is your responsibility to productive
It’s your responsibility to be a productive member of a team, no one else’s. This might sound like obvious advice to most people, but the implications of this weren’t obvious to me at first glance.
I like to think of myself as a person that likes to take the initiative. I also like to tell myself that I operate under motto of “Lead, follow, or get the f*ck out of the way.” Why this matters becomes clear in a second.
Our team was experiencing a lot of organisational issues like not having access to client systems for example. I was planning on taking up a leadership role in this project, but due to these organisational issues I was literally unable to do so because I was locked out of so many systems. The only thing I could do was follow in lockstep of our other lead developer, whom I didn’t have that good of a relationship with. He was the only one with access to the client’s codebase and was the sole person with rights on our codebase as well.
While nothing is wrong with this per se, in hindsight, the way I handled this is wrong. Remember the line, “Lead, follow, or get the f*ck out of the way.”? I skipped straight from the “Lead” part to the “Get the f*ck out of the way” part, skipping the “Follow” part.
My silly mind it went something like this: “OK if you want to lead this project go ahead, I’ll step aside. You do you.” I stepped aside. I let him take over. I did my jobs and tasks and whatever was asked of me.
Then suddenly a couple of weeks I got blindsided. I was told I didn’t take enough ownership of the project. I was kind of surprised. I’m a firm believer of the fact that all criticism is valid, no matter how much you might disagree with it. So I decided to look for the kernel of truth in this painful piece of feedback.
I realised that it is me, and only me, that is responsible for being a productive member of a team. This also includes my difficult relationship with the lead dev. The implication of this is that if I feel like my relationship with the lead dev is making me less productive as a team member, I need to tell this to my manager. I need to indicate that I am not working at my full productivity. Whatever the reasons are don’t matter. What matters is that it is my responsibility to be a productive member of the team. No one else’s.
Recap
The key lesson here is that it is your responsibility to be a productive member of your team. If you are feeling less productive of anything, including people, process, and heck, even the weather, then you should speak up. It’s your responsibility to be a successful member of the team. No one else’s.
That’s it! Enjoyed this? Feel free to subscribe! Hated this? Feel free to subscribe and let me know what to improve!
As always, you can find me on my website janmeppe.com or on Twitter at @janmeppe.
Previous TJLs
Read my previous TJLs by following on the links down below: