A lot of energy has been expended over the last few months debating the merits of remote work. Unfortunately, not much information is shared about how to setup remote work so that you and your team can be successful.
After we posted our job for a content marketer, I got a lot of questions about remote working and how our team manages to make it work, so I thought I'd explain here.
Now, if you want to debate what's best: remote work or co-located work, this post isn't for you. But, if you want some ideas on how one team has setup their team to be successful at remote work, then stick around. This post is for you.
From day one, (October 2011) Zapier has always been a distributed team. Even though Bryan, Mike and I lived in the same city, we had different schedules and were bootstrapping Zapier on the side of our day jobs and school. We worked on Zapier in every spare moment we each had, but those moments didn't magically line up at the same time when we could work in the same room, so by necessity we became a remote team.
In June of 2012, we were accepted into Y Combinator and moved into a shared apartment in Mountain View, California. The next three months were the only period in our company's history where everyone has been in the same city at the same time.
In August of 2012, Mike moved back to Missouri while his girlfriend was graduating law school and in October of 2012 we started hiring. And since we were already a distributed team it made sense to keep moving that way since we could hire people we knew were awesome, but just didn't live in the places we lived.
Over the course of 21 months, we've learned a few things about building and managing a remote team. There are others with more experience at this than us. I'm not sure how large it will scale, though companies like GitHub, Automattic, Citrix and others have proven that it can be done. But if you're a small team and want to dip your toes into remote work, consider this your crash course.
It's highly unlikely you could just pluck any random people, at any random moment in history, dispersed around the globe and expected them to build something amazing.
We've found there are three important ingredients to making remote work, well, work: Team, Tools, and Process.
By far the most important of the ingredients is the team. Not everyone can work in a remote environment. Not everyone can manage a remote environment (though I suspect with a bit of time and learning that a lot of managers could figure out how to make it work). Therefore, it's important to assemble a team who is capable of executing in a remote environment. Here's what has made the best remote workers for us:
1. Hire Doers
Doers will get stuff done even if they are in Timbuktu. You don't have to give doers tasks to know that something will get done. You'll still have to provide direction and guidance around the most important things to be executed, but in the absence of that, a doer will make something happen.
2. Hire people you can trust
Remote work stops working when you can't trust the person on the other end of the line. If you continually find yourself worrying what someone is doing, then you are spending brain cycles focusing on something other than the product. Trust is key.
3. Trust the people you hire
The flip side of this is you also need to exhibit trust with the people you hire. As a manager, you need to learn to manage by expectations rather than by "butts in seat," so make sure you can show trust in those you hire.
4. Hire people who can write
In a co-located office, a lot of information is shared in-person. In a remote situation, everything is shared via written communication. Communication is one of the most important parts of remote team. Therefore, good writers are valuable.
5. Hire people who are ok without a social workplace
It'll be important to try to create some social aspects with a remote team. But the truth of the matter is that remote workplaces are usually less social than co-located ones. People on remote teams need to be ok with that. And the best remote workers will thrive in this type of environment.
Tools are really important in a remote workplace because they enable you to better organize the team and keep everyone on the same page.
In a co-located facility you can always round up the team for an all-hands meeting to steer everyone on track. In a remote team, you'll need the right tools to make sure everyone stays on the same page and can continue to execute without a physical person standing next to them.
Here are some tools we've found handy:
Campfire is our virtual office. If you're in Campfire then you're at work. A group chat room like Campfire is also great at creating camaraderie.
Depending on your team size, you'll want to make use of rooms in Campfire as well. At a certain size it can start to get noisy, so it makes sense to section off rooms into things like "water cooler", "engineering", "marketing", etc. I would hold off on this as long as possible though.
Sqwiggle is a persistant video chat room, but instead of having a live video feed on all the time like you might do with Skype or Google Hangouts, Sqwiggle takes a picture of you every 8 seconds. It's a great way to see everyone at their workspace while they are working. And whenever you do want to chat with a person you can just click a button and you'll have a live video chat up in less than a second.
Everyone likes to hate on email, but in a remote team it's still immensely valuable because, no matter what, you aren't going to take email out of someone's daily routine.
We have email setup with lists that let you easily ping the whole team if you'd like. This makes it easy to involve the whole team in discussions and it's documented for reference should you need it. A great example of a company using email effectively is Stripe. While they aren't a remote team, the process could easily be replicated in a remote setting.
Trello acts as our default roadmap. Anytime we have something we'd like to do, we add it to a to-do list in Trello. In most situations, you'll find yourself creating way too many cards trying to do too many things. The trick we use to avoid getting card overload in Trello is that in order to create a card you also have to write a detailed description of what the feature is, why it's important, and what the results of a successful implementation of this feature should look like.
This works great for remote teams, because if anyone in the company is looking for something to do, they can just go pick a card off the Trello board and know that it's going to be a positive feature for the product/company.
Issues and pull requests are used quite liberally. Much how GitHub uses GitHub to build GitHub, we use GitHub to build Zapier. The beauty is that all the discussion is documented in pull requests and issues and it's logged for reference later if we need.
iDoneThis helps us replace our daily standup. When we first started hiring people we tried doing a daily standup via Google Hangouts, but it ended up being too heavy and distracting for the team. iDoneThis replaces this.
With iDoneThis you send the things you do each day to them and the next morning iDoneThis sends out a digest of what everyone on the team has been working on. Then the whole team is able to comment and discuss items that are relevant to the team. So instead of trying to coordinate a 15-minute chat with multiple people across multiple time zones, we can just use iDoneThis.
iDoneThis is great for personal use as well, because it can help build habits. They also have a great set of addons that make it play nice with other tools.
7. Chrome Profiles
Many of us use multiple profiles to keep a distinct "work environment" separate from personal browsing. With Chrome Profiles you can have two sets of bookmarks, extensions, lastpass accounts, google accounts, even search engine keywords that enable you to work in a manner you're used to, while still being able to use the same machine and browser for both work and personal matters.
Since we have logins to hundreds of services it's helpful for anyone who walks into the company to be able to access any of them without having to fire off an instant message or wait for an email reply. With LassPass, any teammate can login to any of the services we use or integrate with without having to know the login credentials.
You're bound to do a lot of writing at any company you work for. At Zapier, it's no different. Whether it's a blog post, an important email, copy for the site, or documentation for the product it's important that we put a lot of effort into crafting our words. Draft is like GitHub, except for writing. Draft lets you easily version your post and then get feedback from teammates asynchronously.
10. Google Docs
For almost any other documentation Google Docs is great. We share spreadsheets for ad hoc analysis of key metrics. We share spreadsheets with team info and other vital info that might be used later. We share documents for contracts and records. Anything that might get used multiple times should be documented and Google Docs is an easy, shared environment to make that happen.
11. Hello Sign
Every now and then you and your employees might need to sign something. Spare yourself the hassle of printing out the document, signing it, scanning it back onto your machine, and sharing the document with the next person that signs and instead just use Hello Sign. It'll make your head hurt a lot less.
12. Google Talk
The last major tool we use is IM via Google Talk. This is perfect for quick questions that teammates can answer almost instantly.
The third ingredient in a powerful remote team is process. I know most people don't like to think about process, and process feels boring and rigid. But if you think of process as "how we work" it starts to feel more powerful.
Good processes let you get work done in the absence of all else. It provides structure and direction for getting things done.
That doesn't mean processes should be rigid, unchanging or pointless though. Process, at a small company, is more about providing a feedback loop so that you can measure progress for both the company and the people in the company.
Here's a few of the processes we use to make Zapier run. Or is I like to call them: How We Work.
1. Everyone does support
The customer is our lifeblood. We strive everyday to solve our customers' problems and help make their job just a little bit easier. When everyone on the team does support, everyone gets to hear the voice of the customer.
Also, the people who build the product also end up supporting the product. If a customer is angry about a bug, then the person who introduced said bug is going to hear about it and fix it right away.
2. A culture of shipping
Since everyone does support, we've built the dev schedule so that each developer spends three weeks on product features, followed by one week on support. The three weeks on features gives a developer enough time to ship something sizable. At the end of those three weeks ideally you'll be able to present your shipped feature.
This also has the side effect that every Friday someone has shipped something important which is great for morale and creates a habit of progress in the company.
3. Weekly Hangouts
Every Friday at 12pm PDT we get together for a weekly Google Hangout to summarize that week's events. Each team member goes over what they are working on and what roadblocks they are running up against (if they haven't already been raised during the week). Then the person who shipped something gets to show off their new stuff.
4. Weekly Learning
Right after our weekly hangout, we take a quick 10-minute break and then come back together for a short presentation. Each week one person in the company presents on any topic of their choice for about 10 minutes. This can be something related to the company (I've talked about how our internal life-cycle email tool works) or more about a cool piece of tech (Cooksey recently gave a talk about web workers). These talks are recorded so that people joining Zapier in the future have access to this information. In addition, many times the talks get turned into blog posts that end up being marketing for Zapier. Cooksey's talk about web workers ended up becoming this Intro to Web Workers post which brought in over 20,000 visitors to Zapier.
5. Monthly One-on-Ones
In every job I ever had (even co-located ones) there wasn't enough feedback between me and my supervisor. So at Zapier, I setup a recurring monthly event with each team member where we both jump on Skype or Google Hangout to chat about three things: what's one thing I can do better to help him with his job, what's one thing he can do better to improve at his job, and what's one thing the company can do better to make everyone's lives easier.
The first question teaches me how I can help my team be better at their jobs. The second questions helps my team members get better at their job. The last question helps the company become a better place for everyone.
We specifically limit it to one item per question. One item is easily achievable for a person each month. But over time, being able to fix one issue a month adds up.
The answers to each monthly session are logged in a Google Document so that the next session we can reference the previous month's information and check on how we did.
These review sessions are especially great at revealing how we are doing as a remote team, since it lets me get feedback on both small and big things we can do to make the company more enjoyable. For instance, I found out that Cooksey and James occasionally co-work downtown in Columbia and ended up paying for parking on their own dime. So now we're in the process of setting up credit cards for everyone with reasonable spending limits. These types of small things go a long way toward improving the experience for everyone.
6. A culture of daily feedback
As I mentioned in the tools section above, we use iDoneThis to help stay on top of what everyone is actually getting done on a day-to-day basis. This helps eliminate blocks as they come up and keeps everyone up-to-date on what everyone else is up to.
Many of us also automate our iDoneThis to make it iDoneThis more of a habit. For instance, I instant message the Zapbot with my iDones. The devs have their GitHub commits go to iDoneThis and others make their Evernote diary notes go to iDoneThis.
7. Building culture in person
In person interaction is valuable for any team. There is definitely something unique that happens when teammates can work on something in person. As a result we strive to bring the team together two to three times a year somewhere cool.
This August everyone is getting together in Seattle at a big AirBnB place with this awesome view.
In addition to the all-company get togethers, small groups of us might get together on an ad hoc basis throughout the year to coordinate the start of a major project or feature. Usually this is just one person jumping on a flight to visit another person.
If this seems expensive, that's because it is. But the great part is that you'll likely have the money to cover this plus more since you don't have to pay for a central office that everyone is working in.
8. Automate anything that can be automated
The core of Zapier is automation. There are a couple reasons why we automate things. One, it allows us to keep the team size small since we don't need people on staff to perform repetitious, mundane and boring tasks. Two, it lets teammates focus on high impact work nearly all of the time rather than figuring out less impactful things, like the proper deploy commands.
9. Random Checkins
One thing we've been experimenting with lately is random checkins. A random checkin is usually a quick message to a random person on the team asking for input on something or checking to see what they are up to. The idea is that this helps everyone learn what each other is doing and also creates some interesting ideas at the intersection of the two peoples expertise. We haven't been doing this for long, but so far so good.
A lot of this has been knowledge built up from others. Unfortunately, not many people write about the topic of remote working and how to manage it. Most articles dive only a inch deep with light weight suggestions like "use Google Hangouts" which isn't super helpful.
The best way to learn about remote working is to ask other people who do remote working. I've learned a ton from people like Lance Walley at Chargify, Joel Gascoigne at Buffer, the entire 37Signals team, Zach Holman at GitHub and a slew of other founders and remote workers.
If you are looking for other great resources here are some that are worth checking out:
I'm also pretty excited about the upcoming release of 37Signals book Remote.
Hopefully this article can give you some deep insights into how one team manages a remote team. Don't take this as universal truth though. One of the beauties of a remote team is that because remote work feels more like an expriment everything else feels like it can be more experimental. So go ahead and experiment! The biggest wins aren't usually found in a blog post, but in what you discover on your own.
If you work on a remote team or manage a remote team I'd love to hear what you do to make remote working work for you. Please feel free to share in the comments. :)
In the tech world we tend to get self centered. When B2B startups talk about customers, many times they mean the unfunded startup down the street. Not the business that has been running for decades and is just trying to keep up with the times.
These are the companies that power the backbone of America and abroad. These are the companies that only the biggest of tech companies have been able to sell to (think Salesforce and Intuit). Part of it is because we don't know how to reach out to these customers. But another part is that we don't understand how they adopt technology.
With that preface here's an unscripted response I got yesterday from a user asking him how he uses Zapier. But unlike most of these emails it's not just about Zapier. It's about how his centuries old company tries to stay ahead of the curve with technology. And how technology gets adopted. With that I'll let the rest stand on it's own.
I run a very old fashioned business that hasn't changed much for 100 years. Back then we'd get telegrams from China and Japan ordering steel plates. We'd read the requirements and then send a telegram back. Sometimes we'd get an order and then we'd put some big steel plates on a ship - some plates are 40 tonnes each - and they would be delivered 8 - 10 weeks later.
Move forward a 100 years and not a lot has changed. The plate quality is better, we use email instead of telegrams and the ships are bigger and sail faster.
Like most small businesses we have a cobbled together patchwork of systems with most of the transmission done manually. Amongst others we use - Wufoo, Salesforce, Xero, Google, HelpScout, Wordpress and more. So when I cam across Zapier I was initially in Geek heaven. This is cool and it will solve all my problems. Well not exactly.
When you're running a small business the most important resource is time. Specifically the boss's time.
Unlike most tech start ups we don't have bright enthusiastic peeps who will rapidly adopt the latest cool idea. Change is slow and grudging because familiarity with the old systems is far better than the short term disruption that the new brings. So you can't dump software on the team - you need to set it up - then play with it yourself, then iron out all the bugs, then brutalise a victim and make them be the guinea pig.
Then you need to find a way to stop them telling everyone how shit it is whilst you fix the new bugs and then start trying to implement the darned thing. Moving from Outlook to HelpScout has taken us 8 weeks so far and will probably take another 8 for everything to be bedded down and working smoothly.
Limited time and lots of resistance means that this is the life of small businesses. The gains are worth it though. I want to give one example of how we have thought of using Zapier and the issues that we have faced with it. We have some data that we receive regularly that we want to get into Salesforce. For various reasons we use Force.com so most of the integration is to standard objects - i.e. Wufoo's - don't work because we don't have them. Zapier lets us create new custom objects - which is totally cool.
Now this task - is something that we should do daily - it's repetitive and boring - but unfortunately we can't pass it back up the supply chain - and because the data is unstructured it can't be obviously automated. Parsing it may be possible - but that hits the management time trade off again. So we thought - lets create a Wufoo to Salesforce Zap. We'll then hire a virtual assistant via Elance to process the data for $3/hour. (Won't give them direct access to Salesforce as that costs too much for another licence and we're not really sure how to lock everything down to keep them where they should be). We'll give them a HelpScout account - and forward all the information to there. They'll then transcribe it into a Wufoo form which then zaps it across the ether into a new Salesforce custom object.
Proved the technology in 5 minutes. Got it all set up in about 30 (45 fields to move across). That is the easy part - Now I have to define the process in a structured way that gives me an output that delivers reliably and which I have high confidence in - but which does not require me to spend as much time doing quality control as it took to do the process to start with. Oh - and then we have to start worrying about data security, operative reliability, standardisation.
There's always the thought that this might be another failure - Experimentation means failure as Seth Godin points out. When you are small the costs seem higher. Then there are all the little tweaks.
We get it 80% right on the first run through. The trouble is that as we work through this there are so many little exceptions and rules and caveats that we had never written down that what had seemed like a simple process has become a twisted thorn bush dripping with blood.
And yet as we do this we have the vision that this is yet another part of the jigsaw that will enable us to scale. So going back to the Steel - not a lot has changed on the surface - but under it lie hundreds and hundreds of little zaps ready to be implemented - each helping us to structure and organise our data faster - and that translates back into customer happiness and support. That's why I use Zapier.
Oakley Steel Limited
Helping You Build Better Boilers
About Denis: "Denis runs Oakley Steel, Asia's leading supplier of carbon steel pressure vessel plate, and BeyondTransition.com - the worlds best triathlon guide."
It hasn't been that long ago when I installed my first Python build. In fact, the earliest record I have of an earnest attempt at coding is dated April 19th, 2009 (an autogenerated Django manage.py). Of course, PHP had preceeded that, but only hacking on top of existing packages. I wanted more control over the site.
My first real project was LetsJ.am, a specialized forum for musicians where you'd create "jams" (IE: threads) and upload an MP3 of your playing. Someone else would come along, download it, slap it into Garageband, record another track with it, and upload both their isolated track and the mix. Rinse and repeat.
Like many others, I didn't even consider hiring someone to code it for me, I just Googled around and found Django (the fact that it was written in Python meant nothing to me). Rails seemed cool, but, Django seemed cooler (being a jazz guitarist myself).
So I installed Django and proceeded to bang my head against the wall. Though the wonderful Django tutorial softened each blow, the suffering was noteworthy. But, after a week or two, something interesting happened...
I figured out just enough Python and Django to do what I wanted to do. Namely, I figured out:
(?P<some_id>[\d]+)meant dynamic numbers in URLs that let you get records from the database. (What is a regex?)
And to be honest, that was it. But, once I had those three pieces of the puzzle, it was good enough. What had previously been a mysterious and confusing world suddenly started making a little bit of sense. In my mind, URLs just mapped to an HttpResponse which grabbed Models.
Armed with that knowledge, I just coded and coded some really repetitive (and horribly maimed) code and, to my surprise, it worked.
And that was my tipping point. Once I got past that, my learning of "proper things" accelerated, but I could always fall back to the really hacky solutions to "get things done". And I never knew enough to feel guilty about it.
This is one thing I think a lot of the "learn to code" sites get wrong (though they get a lot right). To me, it isn't about achievements, challenges or whatever. It's about hacking a way to a solution, however rudimentary it may be.
If you don't have a problem that code can solve, what are you hacking for?
Finding early customers is hard. Finding early customers with clout is even harder. Finding early customer who will pay you is hardest - especially if you're three mid-twenties tech founders from a small/midsize college town in the midwest.
The bottom line is that sales in the earliest stages of a startup can be overwhelmingly difficult. Especially, since many times you won't even know where to start.
The odds of us landing one of the most influential individuals in the startup world as our first customer seem pretty crazy, but here's how we did it and some tips for how you can do it too.
We started Zapier with the idea that integrations between all web apps should exist. After our initial Startup Weekend beginnings we had a barely functioning prototype and no clue what people wanted. So step one is finding people who need integrations and figuring out which ones seemed most popular.
For us that meant trolling as many SaaS service forums as we could find and lots of Googling for different integration combinations.
We'd go to 37 Signals forums and find people begging for Google Contacts integration. We'd go to Salesforce and find people begging for Evernote integration. It was literally a gold mine.
That's when I Googled Highrise Paypal and found this gem.
Yep that's Andrew Warner himself asking for PayPal data to sync into Highrise. After my initial excitement I work up the courage to send Mr. Warner an email and find out if we can help. Unfortunately the article at the time was about 8 months stale. Odds are he's found a solution already, but I decide to take a gamble and fire off this email:
I just noticed a few months ago you were looking for a solution to auto-import Paypal addresses into Highrise.
Have you found a solution for this yet?
If you have, what did you do?
If you haven't, would you be interested in a service that let's you do exactly this for you without having to hire a developer or write a single line of code?
Keep kicking butt with Mixergy. I listen to at least one new interview every week.
I hate being cold emailed with a sales pitch so I intentionally try to avoid selling him on anything. I just trying to find out if this is still a problem for him. After writing up the email I hit send and wait.
Three days later Andrew emails back saying he already found a solution, but was curious if we had built a PayPal Highrise bridge (which ironically at that point we had not).
I'm a little bummed he's found a solution, but he left a small door open so I give him the pitch and let him know what we're working on.
As luck would have it Andrew is in need of a Wufoo AWeber integration.
Unfortunately we don't have Wufoo and AWeber integration built so I tell Bryan and Mike we need to build this.
In a few days the integration is done. And I email Andrew and let him know it's ready and here's his response:
This is freakin' fantastic.
Andrew asks how much he owes us and we quote him $100 gets him into the beta period. Andrew immediately says yes and asks where to send the money.
At this point we don't have a bank account or any way on the site to accept payments so we start to scramble. The last thing we want is to lose him because we can't take payments.
So at the last minute I tell Andrew to send it to my personal PayPal account and we decide it's time to open that bank account.
Before we head to the bank though I set up a quick PayPal to SMS Zap that would send me an SMS when I got paid. I did not want to miss Andrew's money coming through.
As luck would have it right as we walk into the bank I feel my phone buzz and sure enough there's a message from Zapier saying:
Check PayPal: Andrew Warner just paid you.
And with that text message Zapier became a revenue generating company and two hours later I see this Tweet go out and Zapier gets more traffic in an hour that we'd ever had before.
Unfortunately just because you make a sale doesn't mean your done. Over the course of the next few weeks we worked with Andrew to make sure he got Wufoo to AWeber set up correctly and we even built the filters feature specifically for him.
We even did a walk through on Skype to help him get things working since our interface was absolutely atrocious at the time. I'm honestly a bit surprised he put up with it.
It just goes to show you what people are willing to go through if you solve a big problem for them.
With customer one in the bank it was time to find out if this was a fluke or not. So I started this process from the beginning all over again. I'd find someone in a forum who had a need, send out an email asking if it was a problem or not. And occasionally it would be and they'd choose to join our beta program.
And that's how we got traction with our earliest of customers.
(P.S. I'd love to hear from other folks how early sales went down at their startup. These always seem to be the most fascinating stories to me)
On Repeatable Sales: Clearly this is not a repeatable sales process - especially at the $100 price tag, but when you are first starting with an untested product it's essential to do everything in your power to get someone to like what you have and pay you for it.
On Getting Lucky: You might think we got lucky by happening to stumble across Andrew Warner and him having a need for our stuff. You might be right. But the thing is, there are lots of people with a soapbox like Mixergy who talk about problems and solutions all day long. In fact, I bet if you picked any random Mixergy interview out of a hat you could find an idea for a piece of software or a business idea that could have helped that specific founder out.
If you're running an early stage startup the most important thing you can do is get the idea out in front of as many potential users as possible and find out if they would use what you are building and if they would pay for it.
So if that means trolling forums, cold calling businesses, emailing potential users then go for it. And once you have someone interested in what you're working on don't be afraid to do things that won't scale. Provide more support than is necessary. Build features only for that person (within reason). Write hand written thank you cards.
If you do all these things early on you'll learn way more about your customers and your business. Don't worry about scaling. Don't worry about being inefficient. After all if you don't make sure there is a today; you won't have a tomorrow.
Get new articles about productivity, company building, process delivered to your inbox once a week.