More than money people, especially makers and creators, want flexibility when it comes to work. They want the freedom to work from wherever they want, and whenever they want. This is the credo of a freelancer, and it works well with a team of one. But how can you retain this sort of freedom and flexibility in a team of multiple people--especially as it grows bigger and bigger?
For a young startup that is still putting processes in place and proving itself, giving employees flexibility seems like a recipe for disaster. That’s how I felt a few years ago when my BizeeBee cofounder Alex Notov suggested that we get rid of our office space in downtown Palo Alto altogether and go remote. He had a legitimate reason--he didn’t want to commute two hours a day to meet with all of us--and he suspected that people could work just as well on their own.
While I understood the pain he experienced sitting in traffic, I immediately cringed at the thought of having a remote team for a startup that was less than two years old. I had limited experience dealing with a remote team, and my mind was filled with doubts. How were we going to keep up the momentum when it came to shipping product? How were we going to resolve communication issues? How would the culture of our team change and attract new employees?
Alex assured me that there were other companies that were successfully building products and fostering a collaborative culture, but I was still skeptical. However, I trusted Alex, and also wanted to create a company that would be conducive to his needs.
So I listed out all my concerns in priority: keeping the barriers to communication low, consistently shipping product, and keeping up the collaborative culture despite not sitting next to each other.
Communicating clearly is always a challenge. Having to communicate purely through text such as e-mails and IMs adds to the confusion, because it’s hard to read people’s facial expressions and understand their intent. Knowing that we’d experience this more as a remote team, we established four simple rules.
The first rule was that all meetings required all participants to share their video. This made it easier to see how people were reacting to what was being discussed in the meeting.
The second rule was that any serious communication shouldn’t be conveyed via text. Whether it was a conflict situation, the production server was on fire, or we had an important decision to make, we needed to use video to talk it out. Once again this was to gauge people’s emotional intent.
The third rule was to use Campfire during the day to stay connected with each other. This made it feel like we were literally sitting next to each other. We set up topic rooms like: deployment, customer support, and general discussion. People would hang out in the rooms and chat with each other based on the topic of the room. Since the transcripts were stored, it made it easy for people to review conversations that happened before they entered the room.
Finally, we knew that people would want some flexibility in terms of work hours. But, we were a small team and everyone had to help when it came to servicing customers. So we set up one last rule, which was that everyone had to be reachable 9 a.m.-5 p.m. PST. Meaning they had to respond to a text message or phone call regarding a customer ASAP. Only customer-related issues would receive this kind of priority of acknowledgement.
Founders and managers who suffer from micromanaging will find running a remote team really hard. So if you suffer from it, don’t bother signing up until you get over it!
If you want to know how to get over it, then you’ll need to learn the keys of delegation: trusting employees, communicating milestones clearly, and having a check-in based system rather than polling people constantly.
The first requires hiring competent employees, and backing off to let them do their work. If they fail to produce it will be obvious. The second means that you have to be clear setting up priorities. I say priorities instead of deadlines, because deadlines can be elusive. Employees fall sick, the scope of projects increase, or you might have to fight a fire, all of these cause deadlines to slip or be missed altogether.
At BizeeBee we setup a simple system. We’d aim to ship weekly, but we’d only ship product once we had one or more quality features. A quality feature was defined as one that is complete enough for the customer to use without confusion, there weren’t any outstanding dependencies that needed to be built, our tests cases passed, and there were no obvious bugs or errors.
Setting up this criteria and putting it into practice took time, but after about six months we went from shipping every two months to shipping every two weeks. The real key to making this happen was having engineers break down features that were complex into smaller stories, and then recording each of those as stories in a tool like PivotalTracker.
Ticket-tracking systems like Pivotal’s let everyone on the team see what is currently being worked on, and what is done. This prevents people from “polling,” or interrupting to ask the annoying question, “What are you working on?” Whatever is in the current queue and has someone’s name on it is what they were working on, and if they stop they put it into the backlog queue. When it’s time to check in at the end of the week, everything that is marked as done can be shipped!
Silos and startups don’t mix. Once we tackled putting a process in place for engineering the next step was to collaborate across departments. We’d have a weekly all hands meeting online, but when it came time to talk about company direction or brainstorm on major product revisions we realized we needed to meet in person. This happened every three to six months.
We also took this as an opportunity to spend quality time with each other, putting work away, and just getting to know each other. We’d organize a fun activity or a yearly retreat.
Making in-person time a priority kept the team collaborative and caring.
Finally, we anticipated that new hires might not like our remote working culture. We highlighted it while initially screening candidates, to avoid it causing a problem after someone came onboard as an employee. Most candidates would be honest and say they were disinterested in working remotely and needed to be with an in-house team. Others who were curious would want to know what it would be like. In that case we’d have a couple practice co-working sessions to see if they really did fit into our remote culture and understood our processes.
Highlighting it helped us find people who fit well with our culture, and as a result made us a happy, productive, and collaborative team.
I was wrong to think that a remote team for a young startup wouldn’t work. Part of it was just my inexperience. What I ended up learning was that it can actually afford employees a lot of freedom and flexibility, especially if you hire the right people. But just like other aspects of a startup, you have to highlight what is and isn’t feasible, listen to employee concerns, and put in place processes that are reasonable and their benefits or drawbacks can be clearly measured.
[Image: Flick user Rusty Clark]