As of recent, the idea of working from home or working on the road (people who do this are often dubbed digital nomads) has become exceedingly more popular. Most of what I see on the internet about remote work are by independent content creators who self-publish or contract out their work. Many of these individuals use sites like Medium or YouTube to host their content, or have gigs as graphic designers, web developers, or digital marketers. Less commonly do I come across other companies who work primarily, or entirely, remotely.
I currently work at Inca Digital (Inca), a small company that provides data and analytics on cryptofinance to financial institutions (you can check out my post on our products). We are a remote company. Over the last year I have worked out of air-bnbs, coffee shops, airports, hostels, public parks, and even tea houses in the Himalayas.
Friends and family often ask me how our company manages to coordinate on projects and meet deadlines without physically working together. In this post I will share a bit about our work philosophy, the technologies we use facilitate our work, and my personal experience over the past year and a half.
Work Philosophy and Culture
In my mind, there are a few core ideas that make Inca distinct from more traditional companies. When new members join the company, one of the first documents they are given to read states:
Our Remote Work Philosophy
Hire from all over the world, instead of from a central location
Offer flexible working hours, over set working hours
Write down and record knowledge, over verbal explanations
Share information, over creating need-to-know access
Every document is open to change by anyone, over top-down control of documents
We emphasize the results of work, over the hours put in
Formal communication channels, over informal communication channels — we will shame you for using one-to-one chats and sending each other emails over commenting in relevant GitLab issues and contributing to open channel discussions on Keybase
Our CEO, Adam’s, blog post about how he and his co-founder, Evgeny, chose a remote only business model explain how they started down this path.
No Red Tape
Most people who join Inca do so in a limited capacity initially, as either a student, a full time employee elsewhere, or a contract worker with other projects. When I started off at Inca I was working at a clinical genetics lab, and only helping out a few hours a week; gradually, as I became more and more interested in the projects, I took on more responsibility and became more vocal in company debates. At Inca we try to value each opinion by its substance, and often will end up going with a first-week intern’s idea over a senior core-member’s.
This culture of open debate, heavily inspired by open source development communities and Adam’s experience in law, is a breath of fresh air for younger generations who often find their voices unheard within large chain-of-command abiding organizations. Disagree with any of our policies? Have a suggestion to improve our development process? Dislike any of our choices of technology or business strategy? — Well then all you have to bring it up on a call, submit a merge request to documentation, or start a discussion on our messenger channels.
No Logging of Hours
Not only do we allow everyone to manage their own schedule, but we don’t keep track of hours at all. As long as goals are being met, you can work as much or a little as you want on any particular day.
Having such a flexible system of operation allows everyone to work how they want and spend their free time how they want. Some members prefer to work in small chunks throughout the day, others like to work through the night and take long weekends. While it requires more discipline to self-manage one’s time, it completely removes the formalities of punch-in punch-out systems, and (at least for me) makes every hour that I spend “at work” a productive one.
To accommodate for timezone differences, we rely on asynchronous coordination methods. While there are a few particular aspects of work that require fixed hours of availability (such as client calls, and a single company-wide weekly meeting), everyone manages their own schedule.
Overall, we want people to communicate in open channels, and avoid one-to-one meetings or messages. We prefer having a record of what was said, both for future reference, and so that others have a chance to weigh in and debate.
We use Keybase chat channels to share news, coordinate for meetings, address real-time issues, or socialize. We use GSuite for our group video chats & client meetings, as well as for document management. For DevOps, project administration, and substantive discussions, we use Gitlab.
While meetings are particularly useful for updating groups, and making sure everyone is on the same page, we try to avoid verbal meetings for actual decision making without also documenting the discussion points. Due to our “work whenever and wherever” policy, it is critical everything is recorded and easily available — we are not fans of waiting until the morning to post updates on meetings from the previous day, as we have people working all hours of the day and days of the week.
We use Gitlab to manage our code repositories, like many other businesses. Perhaps more interestingly, however, we also use Gitlab for internal documentation, business development, and customer support/engagement.
We have separate projects for our clients, various code repositories, as well as for all of our business operations. Doing so allows our tech and business teams to follow each-other’s progress communicate efficiently. This also allows a client request to be discussed directly with the client and allows them to track progress directly where our developers are working.