TJL #19: Reflections on my first remote project (part 1)
What went well, what went wrong, and why remote projects can be challenging
Hi friends,
Welcome back to Today Jan Learned (TJL) #19. In this newsletter I usually try to share the best of what others have figured out already, but this one is going to be different.
I recently finished my first fully remote project and wanted to spend some time reflecting on it. Today I want to share two things with you:
Something that went horribly wrong
Why you should overcommunicate with your team
Let’s start with some context.
Doesn’t matter, shipped it 🚀
We just finished an 8-week project for a client. In these 8 weeks our team managed to deliver a new digital gifting experience for a large UK retailer. We built a chatbot on top of Facebook Messenger. The bot helps people search for the perfect Christmas gift for their loved ones using conversational AI.
Despite all the challenges and setbacks in the project, I feel we can be incredibly proud of ourselves of shipping the chatbot. What we achieved in such a short amount of time is, frankly amazing. ✨
For the next section, I hope you’re familiar with Murphy’s Law.
What can go wrong, will go wrong
Murphy’s law states that, “What can go wrong, will go wrong.” Oh boy, was he right. Take a look at the image below, what do you see?
What you see here is Facebook’s worst outage in four years.
Facebook’s whole Messenger stack collapsed due to a server configuration error. Read more about the technical details here.
Because Facebook’s stuff broke, our stuff broke. Of course, we sped to the crime scene to fix it but here’s the kicker: only our lead developer had access to the production stack. He was the only one with an internal client account which is needed to access the client’s internal systems.
Due to… stuff … only our lead developer was able to get such an account. He was the only one with access to the client’s stack. If you’re now wondering how we did development work, it’s basically how you guessed it.
We built a copy of the project on our own stack and the the lead dev ported it over to the client’s stack. Does it sound silly? Yes, that’s because it is. But you have to play the hand you’re dealt.
Of course this introduces more than one problem. The first problem is that the stack we are developing on is not the same stack that is running it in production. The second problem is that there is a very high bus-factor, if the lead developer is off and something breaks, we’re screwed. Finally, the worst part, is the helplessness. None of the other devs in the team were able to help in the outage simply because we weren’t allowed in. Feeling helpless really sucks.
Honestly, I don’t know how we could’ve handled this differently. Perhaps chase the right people harder? I really feel like we handled it as best as we could, but we were dealt a really bad hand.
With that out of the way, let me share a very important lesson I learned during my first remote project. And that is to…
Overcommunicate
If there is one thing that I learned, it’s this: in remote projects you must overcommunicate.
Overcommunicate, overcommunicate, overcommunicate!
This is non-negotiable. You must be proactive in your communications and you should try to send out roughly two to three times your normal volume of messages. At least that’s the rule of thumb I’m adhering to at the moment.
In remote projects it becomes very easy to just do your work and shut up about it. The problem with this is that you end up blending in the background. If you just do your work and happily chug along, this is what it looks like for other people: …
Nothing! That’s what it looks like! If you don’t tell people how can they know?!
In non-remote projects this communication is often handled by in-person chatter. You sit in the same room as your teammate so you know what is going on. You talk to your teammate over a coffee, etc. We are not used to remote work and this all new for us, we are in that sense, forced to figure this out and this is a lesson I learned the hard way.
I say that I learned this the hard way, because at the end of the project I asked my teammates for feedback. The majority of the feedback that I got was: “I wish you’d communicate more.” I was like “Reeaaallllyyy?!” I felt like I had communicated enough but as it turns out, I didn’t! Overcommunicate!
For this particular project we had a daily standup. There we updated each other on our work. I usually shoot out another message just after lunch what I’m working on and how it’s going (good, bad, stuck, etc.). Be proactive in your messaging. Let people know what you’re working on, whether you are stuck, or need help!
Overcommunicate!
Recap
Today I wanted to share with you some of my reflections of my first fully remote project. This is the first part of (what I guess) a two part series on this topic.
All I’m saying is: Overcommunicate. Why? Because you think you are communicating enough but you probably aren’t.
If you’re anything like me, you are used to non-remote projects, where a lot of communication happens casually, non-verbally, and subconsciously. Be aware of this and compensate by overcommunicating with your team, client, and key stakeholders.
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: