In today’s world of shrinking distances and wiped off boundaries it becomes easier and easier for businesses to develop and spread services or products. More and more companies open their offices around the globe looking for lower taxes or stronger markets, and feel completely comfortable with that many locations.
But what if we are talking about a small distributed company with that many locations? Is it possible to manage this type of organisation successfully?
To answer those questions we decided to write this very article and share our own experience. First of all, let me introduce our team. Railsware is a company of 45 people who mostly work from one of our two offices situated in Kyiv, Ukraine, and Krakow, Poland. Despite those two offices, one third of our employees prefer to work remotely, which adds 8 more cities in 5 different countries to our list. So…
Why distributed company?
We have noticed advantages of the distributed team model long ago. To be more precise, having a remote team has been a part of our corporate culture for 11 years already.
Huge geography can seem scary from the management perspective. But during those many years it proved to be very helpful instead. It’s pretty difficult to hire truly brilliant people when you stick to one or two locations. Since we were always interested in Ruby engineers only, it narrowed our search even more. Let’s be honest here: you cannot reach all the cool guys of the city and they are not a limitless resource. That is why searching for candidates from remote locations raises your chances to find the right people for the company.
At this point it is important to mention that we do not force our employees to choose between remote or office. We offer possibility of both. Any Railswarian can work from home even if there is an office in the city, as well as everyone working remotely can come to the office and work from it as long as s/he wants. Or even relocate. Still we are not limited to any locations. That’s why some of our guys often travel to work from another place for a change or because winter is coming, you know :) As you see, we give each employee freedom to choose the most comfortable environment for work.
How do we actually manage?
Won’t surprise you if I say that communication is essential, especially when part of your team works remotely. Luckily, today many tools are available to make this communication smother, no matter how many miles away you are from your colleagues. Among many others at Railsware we use:
Slack with its possibility to create various channels to communicate and update your mates on different topics so everyone interested knows who is working on what at this point
G Suite, mostly Spreadsheets and Google Doc which provide possibility to work with different data as we do rely on data-driven approach rather than assumptions
Screenhero – Railswarians work mostly in pairs, and it’s not about engineering only, but also marketing, finances and other activities; these tools help heaps if we need to collaborate from different locations
Mural – great tool to substitute or digitize the whiteboard project; can also be helpful when you have a limited number of flipcharts in the office, but many teammates are willing to work with them
Invision – a tool for designers to collaborate not only with each other but with the client and engineers; can be a good place to store design projects.
Obviously, no tool will help if there’s no healthy approach to the team management. As we understood pretty soon, the main thing in the distributed business is always to stay informed and synchronised with the rest of the team. And here comes another important part of our working culture – documentation.
We create a log for almost every meeting we have: daily standups, calls with clients, new features discussions, implementation plans of big tasks, etc. Each discussion we wrap up with defining next steps and those responsible for them. All this information is stored in GDrive folders and shared with everyone involved. This approach helps us to stay on the same page and always have access to details needed, no matter what time of the day or part of the world it is.
Next thing to mention – syncs. First of all, syncs of the team working on the same product. Quite often all engineers allocated to the single project are based in different cities. That is why whenever we start with a new one we start if from a 2-3-day session together with the client. It is called Inception during which we state goals, go through issues, benefits and risks, and build the Roadmap. This session requires onsite presence of each participant since this is the only effective way to have everyone fully involved. Afterwards we leave to our comfortable workplaces and start to build the product. If we have a long-term project with a client, it makes sense once in awhile to gather again and review next steps. After the release a lot can change and often it is a client who insists on annual or biannual meetings.
But besides clients’ we have a lot of internal issues which need the whole team’s awareness and consideration. With a distributed team it’s pretty difficult to drag everyone’s attention to your point. Even more difficult it is to involve everyone into discussion. Few years ago we found a great solution to this problem: Railsware team events.
Every year we take a pause in our regular work for a week and travel together to some nice place. Previously, when almost all of us worked in Ukraine, we usually went to the Carpathians in winter. After opening an office in Krakow, we decided to travel further. Thus, last year we skied in Austria and this year we finally decided to switch to summer and checked hot Crete. We have already wrote a post about the last team trip which you can check out here. But I brought it here again just to mention the importance of those team events not as a whole-team fun but from the management perspective. On Crete we decided to try something more than just random talks here and there about various issues. This time we’ve successfully experimented with internal conferences. Every day a new interesting topic was brought up to a discussion (level of interest was defined through voting prior to the trip) and we spent 2-3 hours daily to generate solutions and proposals. As a result, all the Railswarians became aware of what’s currently going on in the company and what are our next steps. Moreover, it is a great chance for those new to the team to meet everyone in person, better understand internal processes and thus integrate faster.
So, answering questions opening this topic: yes, it is possible to build a distributed company and manage it successfully. Unfortunately, there is no general recipe on how to organise your team correctly. Each team is an individual organism requiring its customized set of tools, company culture and processes. In our case, a hybrid of both in-office and remote models works out well. For this approach to prove its efficiency, you need to have a mature team of professionals able to decide, whether it is better to either work on a specific issue alone remotely, or face-to-face with a team. The key to success is the right balance. We do hope this post will lead you to some innovative ideas on how to organize your team and work environment.