Shogun is a globally distributed company in the ecommerce SaaS space.
When our cofounder, Finbarr Taylor, and I started Shogun back in 2015, we didn’t plan on becoming a remote company. It kind of happened like Shogun did: through a very happy accident.
Shogun was originally a page builder for frameworks such as Rails, Laravel, Node and Django. When that didn’t work, we integrated with Shopify on a lark — that’s since turned into a business with 11,000 clients.
None of this would have been possible without our incredible team all over the world.
So, how did we build a remote company? Here’s how we tackled three main parts of putting together the business, including processes and tools we still use today.
Part 1: Talent Acquisition
Shogun was basically a side project for about 18 to 24 months. During this time, we knew we needed some help, so we went the freelancer route with the path of least resistance: Upwork.
We knew we wanted the best possible Rails and React engineers, so we just dialed the controls up to the max.
We ended up getting pretty incredible talent — some of the folks we found on Upwork are still on our team to date.
But we didn’t know how incredible they were in the beginning (after all, we had just met them). So, we made sure to hedge our risk with paid trial periods for hourly work.
For this, we used consulting agreements similar to this one from Orrick. The site has a whole library of forms if you’re on a budget and can’t afford lawyers.
This is how the paid trial period played out for candidates across departments (Note: None of this should be construed as legal advice; it’s a retelling of what we found worked for our organization):
- Engineers and Support: Generally, we would do a one-to-four-week "contract to hire" trial period and let contractors stipulate their hourly rates. We settled on this time frame because some candidates could only do part time, whereas others had open schedules and could commit to a full-time trial.
Support was thrown into the mix, shadowing and then taking tickets, while engineers were given modular projects. We could usually tell by Week 1 if there was a fit. It rarely got to Week 4, unless they were on a part-time basis or we had reservations.
- Designers: We would do a paid design test. Again, candidates would stipulate their hourly rates for the trial. We would try to do this over the course of one week.
Our Design Director, Greg Beldam (former Design Director at Shopify), was initially put off by this, given his bad experience with design tests at other startups. However, after I took this approach, he changed his mind and even wrote about it.
- Business Roles: These roles (marketing, operations, sales, etc.) are much harder to do a paid test or trial period for. While engineers and designers might be accustomed to freelance work, and even welcome it, business roles are generally looking for a smooth transition from one permanent employment opportunity to the next. If you can create a small, modular project for the role, that’s ideal.
For example, if you’re hiring for a content manager, have them write a 1,000-word blog post. For a growth marketer, have them set up and run an Ads campaign. If a paid test project isn’t possible, make sure to ask them what KPIs or Key Results metrics they are most comfortable with, and set clear expectations for what you would expect in the first 90 days of employment.
During trial periods, we always made sure to compensate generously, and when something wasn’t working, we would cut it quickly and pay in full.
As Shogun grew up, so did our talent-sourcing skills. We reserved Upwork for short project-based contract work and virtual assistance, and started using these outlets for talent:
We would run the same process of short, well-paid trial periods, followed by longer term engagement and employment. Now we have a full-time, in-house people operations team to help scout talent, but we still implement many of these processes.
Part 2: Communication and Culture
For any company, communication is imperative to success and it often becomes more of a challenge at scale. With remote, it can be even harder — but, I think there’s a silver lining.
Remote work relies on a system of asynchronous communication.
What does “asynchronous communication” mean? It’s a fancy way of saying that conversations, meetings, etc. need to be written down so that everyone in the company can join the conversation, regardless of which time zone they’re in.
The following tools make it possible:
- Slack: This is Shogun’s virtual office. Pretty much all communications default to Slack.
- Notion: This is our internal Wiki. We ask ourselves, Is this communication something that should live “forever”? Is it a process or policy? If so, then it goes in Notion.
- Gmail: Not permanent enough for Wiki, but too important to risk getting lost in Slack? Does it require an action item? Send an email.
- Zoom: OK, OK — Totally not asynchronous, but sometimes you need face time. Teams at Shogun check-in for 30 minutes each week on a face-to-face call. Managers check in with reports once per week or once every two weeks.
In addition to the aforementioned core modes of communication, these two Slack add-ons have been very helpful for us:
- Geekbot: Creates automated asynchronous “daily standup” reports. You can calibrate for daily, weekly, monthly, etc. meetups.
- Donut: Helps match team members for short 1:1s (great for culture building) AND helps automate the whole onboarding process, which is imperative for getting started on the right foot with new team members.
I mentioned a silver lining earlier.
Because communication can be more of a challenge with remote work, it forces companies to over-communicate: Write everything down, make sure to set clearly written action items and take thorough notes during meetings.
Companies that have offices can get lazy and rely on meetings instead of strong communication hygiene, which can suck up a bunch of time unnecessarily. This is where remote work can surpass a traditional 9 to 5, as long as the right tools and processes are in place.
Part 3: Management
Some companies have a culture of bearing down on team members with micromanagement and strict office hours. I would never advocate for that kind of management system, and in my opinion, it would be pretty much impossible to execute that strategy with a remote organization.
Shogun doesn’t really have operation hours, with the exception of the support team. We actually don’t really care how many hours team members work per week.
Hours worked isn’t really an important metric to the success of our business. Here are some metrics we do care about:
- Conversion through trial
- Review score (NPS score)
- Feature adoption rate
- Retention rate
- Average revenue per user
- Number of new features shipped this month/quarter
- Number of plan upgrades
You get the idea. The list goes on.
So instead of worrying if our team members are working hard or playing Halo, we just give them Key Results to hit. If the results are hit, we’re all good. If not, maybe we need to look into why.
Never heard of Objectives and Key Results? It’s a great framework created by Google, and it’s well-summarized in this article.
Also, if you’re new to management or new to remote management, I highly recommend investing $9.99 in “Influencing Virtual Teams: 17 Tactics That Get Things Done with Your Remote Employees” by Hassan Osman. I’m not affiliated with this book in any way, it’s just a really handy book.
A-Team Players vs. B-Team Players
One of the most important things you can do to ensure management success is to hire A-team players at the start.
It’s easy to settle for B-team players, especially if you’re trying to save money, but here are a few things to keep in mind:
- B-team players can take a ton of time to manage, do things in an inefficient way or make mistakes, which costs you money.
- A-team players may be expensive, but they can generally hit KRs and should pay for themselves.
- B-team players de-motivate your A-team players.
Just pay extra for the A-team players — you’ll save yourself a lot of money and agony that way.
If you find that your new hire is a B-team player, put them on a performance plan immediately (one defined with KRs). If they don't hit their goals, work with them to figure out why, and if you can't find a resolution, it's probably not going to work out.
And remember to be polite and pay in full when you’re issuing a termination.
Why track my own time? Sometimes it’s hard to tell how much I’ve actually worked in a week.
It goes both ways: Some weeks I feel like I haven’t worked enough, but then I’ll look at the hours and it gives me the reassurance I need. Other times, I feel like I’ve been getting distracted at my home office, and then I’ll look at the hours and realize I’ve been slacking off that week.
Additionally, when you’re starting the OKR framework, assign KRs to yourself — as you grow, your OKRs will essentially become the company’s OKRs.
I’d love to hear your thoughts and questions about remote teams. Do you have a remote team or disagree with the concept of remote work altogether? Have any questions about making the change to one? Reach out to me on Twitter.
Disclaimer: This article is for informational purposes only and not for the purpose of providing legal advice. You should contact your attorney to obtain advice with respect to any particular issue or problem. The opinions expressed at or through this site are the opinions of the individual author.