For the last six months, I worked on The X-Factor USA’s website as the lead developer of one of X-Team’s global teams. Being a lead is a much different role than being a developer, and I learned five lessons on leading a productive remote dev team that I’ll take with me on all future projects.
1. Let them do what they do best
Although X-Factor was based upon something we had already built, there were still things that could be improved upon.
The team spent most of the initial part of the project perfecting what we already had, taking into consideration all of our experience from past projects.
This, however, meant that from an outside perspective, we weren’t accomplishing a lot; but in reality, it’s one of those cases where focusing on quality at the start means we save a lot of time in the future.
Taking this approach meant that, towards the end of the project, the workload was less than anticipated because of those wise decisions made at the beginning. Ultimately, this is accomplished because we can hire the best, no matter where they are in the world.
Some companies hire based on how much that person costs; we hire on how much that person knows, how good of a team player they are and what new qualities they can bring to the team. Let them focus on what they do best.
2. Shield them from outside pressure
Of course when you have clients, they expect to be able to see something after a while. They’ve given you the requirements and the PSDs, so they are obviously excited to see them come to life.
This means that the client will pressure the team to show results early on, which goes against the ‘let them do what they do best’ theory, because if you give in to the pressure, the work will be rushed.
This means that while I was taking some heat because we missed a lot of our first sprint goals, the team was not fully aware of this and continued to work at their best rhythm.
3. No one said remote was easy
Having a team where someone is working at any time of the day is not for the faint of heart.
There will be times where you need to be up at 2 a.m. so that you can have a chat with a particular person.
You also need to see and understand the code your team is producing, so that when something conflicts during a merge, you’ll be able to pick the right piece of code.
You will also need to explain that dev’s code and be able to debug it if something goes wrong and the person that built that particular piece of code is sleeping.
4. Start QA as soon as you can
After an initial burst of coding, we included their QA team very early on in the process.
This meant they would often find bugs that we knew and were working on, but it also let the client feel where the project was headed and change accordingly, instead of working until it was our vision of done, only to find out that that wasn’t really what they wanted or that it was full of bugs.
5. Don’t be a bottle neck
A lot of people in a leadership position tend to want to route all the communication with the client through them.
This in turn means that when a developer needs something, they have to wait for the dev lead to ask for them and eventually respond with an answer (which might be delayed with a remote team). The same goes for if the client wants to ask a developer a question. This creates unnecessary stress and wastes time.
My belief is that our developers and our partners should be able to talk about doubts they have in specific tickets as long as they keep me in the loop. This way I know what’s going on, but no one waits for me to do anything.
“Empower people based on the highest level of competence, not authority,” says the CEO of Rogers (one of our biggest partners).
This also means that the kind of people we hire have to be able to communicate with our partners in a way that respects them.
Ultimately, empowering your team is what makes remote teams work — it makes timezone challenges less relevant, bottlenecks nonexistent, and allows everyone to focus on doing what they do best.