How to Make “Remote” Work
My experiences with building 3 successful remote teams for our SaaS product.
I am a big believer in working as a team in a shared office space. Great products are created by jelled teams who work together closely, usually in the same room. A single idea, or a statement of a problem should be able to ignite a heated discussion in front of a whiteboard. The constant idea exchange and discussions about the product is the environment needed for finding a constant stream of new ideas, nurturing and developing them and implementing them with excitement. Great teams continuously find and improve ideas via constant constructive discussions.
Here is the interesting bit: While I am a big believer in co-located teams, I am also a big believer in remote teams. A combination of co-located teams and remote teams is a successful recipe.
First, lets make this clear: Your core product should be developed by a co-located team. The face-to-face high bandwidth discussions are needed to re-shape your product. If you switch to remote development, things will start falling apart:
- The continuous improvement of ideas will slow down
When you are working in the same room, small frustrations are great opportunities for discussion, and every discussion is an opportunity to develop ideas further. - Good ideas will prematurely die out
Every great idea was once a fragile weak idea. The core product should be developed by a core team who breath the same air, trust each other and support each other. That’s where people can safely express new fragile ideas and improve on them with the support of others.
But, here is the cool part: Your product has many non-core parts that need constant attention. And, you can move these supporting roles to remote employees. That will allow you to prevent bloating of your co-located teams while still getting things done. Let me explain it with 3 examples.
The first remote team I started was our Support Team. In the first years of JotForm, we had no support employees. I provided all the support myself. It wasn’t so bad when it took half of my day. I was learning a lot by constantly talking with our users. After a while though, things started getting worse. The support started taking my whole day. So, I hired some good people on oDesk. It turned out well. Today, our 20-strong support team is completely remote on oDesk. Having remote workers all over the world allows us to provide fast support 24 hours of the day, 365 days per year.
Letting remote employees take over the support allowed me to spend more time on the core product.
The second remote team we started was the Maintenance Team. Just like support taking over my whole day, increased growth of JotForm created a constant stream of bug reports and feature requests. We had a problem: Our core product development slowed to a crawl. The core team was spending most of their time doing busywork for small wins. The constant context switch between core product development and bug fixes was killing us. So, I turned to the remote magic again. I hired people to work on the bug list. It worked out well.
The core team, suddenly freed from these tasks, started building up momentum again.
Today, the Maintenance Team has 5 developers. Some of them are traveling the world. We are sometimes envious of them. They will spend their time traveling or doing whatever they wish, and then fire up their laptop and take on the next bug or minor feature request on the list.
The third remote team I started was the Widgets Teams. JotForm Widgets are an accidental feature that has grown like wildfire. Since, the beginning of JotForm, people requested different form field types. While we wanted to give them what they want, we were worried about making the product bloated with too many fields. While building our API, we accidentally came up with this idea of making form fields just like an API, and we called them “form widgets”. A widget can be a signature pad, a photo taker, or a phone number verification via SMS. Currently, we have 377 widgets and the development and maintenance of these widgets are handled by a remote team of 4 developers and 1 manager.
I have previously written about how I hired developers for our widgets team here, and how to manage remote teams effectively here.
The core team working together in the same room, came up with the idea of widgets, developed the idea further with face-to-face discussions and executed it extremely well. That’s what core teams should do. Then the Widgets Team has taken over the maintenance of existing widgets and the development of new ones. And, that’s a great example to how to use remote teams with success.
Most good ideas will fade away silently. They need the support and encouragement of other team members. That’s only possible if the team members trust each other and know each other well. You need to be co-located to have that. This is not a case against remote teams though. Good remote teams not only work well, but also allow the core teams to spend more time working on the core product.
There is a lot of discussion about remote these days. Some teams swear by it, some don’t believe in it. The truth is somewhere in the middle. You should probably use both. If you try to do everything in-house, your teams will start getting too large, and in turn, you will lose all of the advantages of having a co-located team. If you try to do everything remotely, you will lose the amazing things that come out of the high bandwidth communications of a jelled team. If you are only co-located or only remote you are probably missing out the possibilities. I hope this post has helped you see them.
