This is part seven in a series of posts about how we're growing as a company. In this post I'll talk about some of the decisions we've struggled with when trying to decide whether to only hire locally, or to hire remote team members.
- Developer career paths
- How we work
- Compensation and career progression
- Interview process
- Laptop program
- Anti-harassment policy
- Local or remote?
Remote vs. REMOTE
When people talk about working remotely, one detail they often leave out is that they're usually still working with people in similar timezones, just not from the same office. Consider these two scenarios:
- I live in Chicago and work remotely with a team in New York. Sometimes I schedule a call at 2:00 PM and they forget to turn up.
- I live in Australia and work remotely with a team in New York. I was awake until 2:00 AM and they forgot to turn up.
There's a world of difference (literally!) between these two.
That was the case for me: I was in South Australia, working with teams in Victoria and NSW, and it worked just fine. Scott Hanselman has great advice for working remotely, but he's in a similar situation: he's in Portland, and most (I assume) of his team are in Seattle. Modern technology solves all the hurdles of remote work, unless the person on the other end of the call is asleep.
When I lived in London, and our team in London had to work with a team in Tokyo, it was a completely different story. When time zones don't overlap, it's too hard to have lots of conversations, so people are left out. Trust is very hard to build over distance; it's just too easy to assume that those people, who are impossible to contact and never around when you need them, are the villians, acting out of malice or incompetence (or both!), while you're the ones trying to do the right thing. Phil Haack gives an excellent explanation of this:
Everyone is the protagonist of their own narrative. And in this narrative, it's only natural to see ourselves as the proverbial "good guy" of the story. We tend to rationalize our own actions as necessary or positive, much like Walter White until (spoiler alert) the end of Breaking Bad.
When you're in the USA and considering hiring remotely, you get the whole population of the Americas before you really need to worry about timezones. Things are a bit different from Australia. There's pretty much no time that a person in Australia can talk to a person in New York between 9-5 in their local time zone, so someone will always need to be around at odd hours.
I liked working remotely, so I always planned to build a remote working company. But I lived in Brisbane. When it was time to bring on someone full time, it was just easier to find someone locally. Then we found another person in Brisbane, and another. When you bootstrap, those first hires are so critical; adding a remote aspect adds a whole new level of difficulty and risk.
Resistance is futile
Until now, we've concentrated our efforts on finding team members in Brisbane. Yet, Australia accounts for only about 15% of our customers; the vast majority are in the USA and UK. At some point, we'll need a US and UK presence to be able to provide deeper support to customers in those time zones. Eventually we're just going to have to do it.
Working with people in another timezone requires big changes to the way we work, and it's better to do this now, while we're small and it's easier to effect changes to our communication patterns before the way we currently work becomes more entrenched. We're already part-way there - most of the team work from home most of the time - but to work across timezones will be harder still.
We're hiring in the USA/Canada!
As of today, we're now looking for remote team members who live in USA or Canada, as well as in Australia. A few thoughts we have so far:
- We're limiting the countries so as to limit the legal work involved, and to make basic things like paying people easier. We might look for contractors initially, but at some point I imagine we'll need a legal US presence. Better if there's only two countries to deal with than 10.
- We'll fly new team members to Brisbane for a month to work alongside us. The hope is that this will help get them productive and build that initial understanding and empathy, before we add the remote aspect. We'll also bring them here once every 6 to 12 months to keep it up.
- We'll go big: instead of just one person, we'll probably look to bring on 3-4 in a short time period, just so that they can form their own team and be more autonomous (and have people to talk to during work hours).
Octopus Deploy is used by thousands of developers across the globe, from small companies to large enterprises. Find out if it meets your deployment automation needs by taking advantage of our free 30-day trial. You can spin up an instance with just a few clicks!