Moving projects forward and wrapping them up in the end is one of the most satisfying feelings for any software developer. It’s extremely rewarding to see your product being used by hundreds of thousands of people, especially if your maintenance of the code is ongoing. I’ve been on the inside of many software projects even before my time at Two Tall Totems. Some of them were failures, some successes, but almost all of them took place in a “controlled environment”.
What do I mean by “controlled environment”?
In the vast majority of the projects I’ve been involved with, the team members operate in the same city/location, same time zone, and more importantly, the same work culture (even in teams with great diversity). I’ve worked with clients that were awesome, clients that have been slightly more difficult, and on occasion, clients that were unreasonably demanding. In any case, I’d take the feedback, implement a couple of iterations, and we’d have a completed product. It’s all just part of a Developer’s job (uncertainties included).
After almost 10 years of building software, I thought I had seen it all, until about 6 months ago.
About 6 months ago, I was assigned to a project that was worked on by 3 different teams. These 3 different teams worked in 3 different locations across 3 different time zones. Now….remote work teams are nothing new. In fact, it’s something that has become incredibly common nowadays. The difficulty didn’t come from the big technical challenges, or the complexity of the components involved. The biggest challenge that came with this project was the huge difference in work cultures.
The things I was once certain of, I now questioned because of this project. My intention with this three part series is to share some of the things I’ve learnt during this process, and to provide some best practices for development teams that are separated not only by location, but also by languages and workflows. For the first instalment of this series, I am going to focus on communication.
It’s perfectly fine to have multiple communication channels but keep one source of truth
With so many different channels available to us, it’s hard to keep track of communication these days. There’s traditional email, Slack, JIRA, Asana, Basecamp, and hundreds of project management and communication tools. Ironically, the more options we have, the more complicated it gets. Every team has their own platform preferences and things can get out of hand very quickly.
I remember getting email messages which would show up as JIRA tasks but the conversations and decisions would be made on separate email threads. There were even times where we had duplicate tasks because some team members read email faster than JIRA tasks. There being multiple channels made it counterproductive for communication.
I’m not saying that the project teams should limit themselves to just one way of communicating. It’s perfectly normal to use email, Slack and JIRA (more to come on why JIRA was chosen as a project management tool). What I’m getting at, is that any project should have one source of truth, one platform where all actionable items are communicated. That way, all members can benefit and track the latest state of a specific chore or task.
Have meetings twice a week with a proper agenda
I’ve never been a big fan of meetings, especially if they’re long and lacking a clear agenda. However, due to there being three different teams, we definitely needed them. The 3 teams were each introducing different tech components and it was difficult to sync them together. There were times during development where not much progress was made because of this. At these meetings, I would recommend that a “core” team be assigned. Main “actors” and decision makers from each of the 3 teams should be chosen to be present in every topic discussion. The “core” team should be the people everyone can go to for the most updated information.
Be flexible at times
I have yet to be in a project where all conditions are 100% perfect, so flexibility is key. That’s just the reality of client work.
In this case, if an email reply late at night would help the other team to move forward, I’d make it happen. If another person in the team does not follow your same work style, be open to meeting them in the middle.
Also, while being flexible, take advantage of the special conditions of the project. In my situation, the late night meetings gave me the chance to spend more time with family and have more productive time in general.
The right players are easy to find… if you search properly
When a project begins and you’re being presented with your teammates and introduced to everyone, take that with a grain on salt. The “right players”, meaning the people who have the power and commitment to move things forward, are sometimes hidden. These people are the ones who need to be a part of meetings and communication overall. I think in general, they’re easy to find but you need to know to look for them. Not having these decision makers can lead to confusion, wrong expectations and lack of task completion. This maybe the ONE thing that turns an “ok project” into a “great project”.
Avoid hitting a wall, speak up and teach
Three different cultures will lead to three different ways of doing things. I bumped into situations where I definitely didn’t agree with the way things were being done. These disagreements on my part came not just from a work culture standpoint, but from a decade of experience working on projects.
At times, you will run into situations where it’s appropriate (and even necessary) to step up and propose a better way of doing things. It’s important to be okay with speaking up, and offer suggestions for better communication. You’ll get great conversation starters and eventually, you’ll find some hidden truths of how or why things were being done a certain way in the first place.
Having to deal with 2 extra teams is a huge struggle. Miscommunication and frustration are common foes, and things get lost in translation. I believe the points above were big compromises and decisions which led to a better overall project velocity.
A lot of other aspects worth noting were omitted in this post, so I’ll make sure to catch up and write about technical and project management learnings in parts two and three of this series. Stay tuned!