Our jump to a remote friendly team
Five months ago, Appaloosa partially became remote. We realized the impact of this organizational change would have on the team, so we prepared for it by reading a lot of articles, and the reference on the subject: Remote by 37Signal . We also reached out to other startups (TigerLily and Algolia) to inquire on their habits. Of course, even after all this preparatory phase, we knew we would have to adapt and enhance our processes as we go. Every company is different, and what works for a team does not necessarily work for another one. But five months later, we wanted to assess the success of our shift to a remote friendly environment.
State of the Remote
Currently, we have three types of remote work:
- Convenience remote: the employee stays at home for the day or half the day. It’s often to stay with a sick child or to open the door to the plumber. We call it “convenient” because we’d rather be on-site to enjoy the presence of our colleagues than staying alone at home (no kidding, we really enjoy working together).
- Temporary remote: the employee is going full remote for a short period of time (a couple of days or weeks). It’s usually to enjoy being in another city or country. We started experiencing with this mode last June and for now we are very pleased by the results. When your work day is over, you get to enjoy a vacation lifestyle. It enables one with the possibility to live the life of a local. It’s not only for pleasure: it helps a non-remote worker to get in the shoes of a full-time remote colleague and experience his joys and frustrations. As a result, a non-remote worker will help changing inadequate processes for full-time remote workers.
- Full-time remote: the employee lives in another city. Two of our devs are currently working remotely. They are on-site a few days a month.
Rituals and meetings
Stand-ups
At first we used appear.in for its ease of use and Slack integration, but we got some network latency issues, especially when there are more than 2 people connected. We jumped to Google’s Hangout and it has been better since. Our mic and speaker is the Jabra Speak510.
Pair Programming
When we want to pair program with a remote colleague, we use Screenhero for its double-cursor capability and audio/video quality.
Each member of the dev team has a “Pairing session” slot scheduled on Thursdays so that when pairing is needed, it takes over as a top priority during this 2-hour period. Pair-programming outside of that slot is strongly encouraged as well as scheduling meeting during it is avoided.
We bought a Plantronics RIG 500HS headset to make calls in noisy open space.
Retrospectives and sprint meetings
Retrospectives and sprint meetings take place every two weeks. During a retrospective, the team reflects on the elapsed two weeks. We celebrate successes and discuss issues we encountered, the idea is to always improve as a team. A sprint meeting on the other hand is dedicated to synchronizing the different teams. Sales detail the potential clients, devs list all the features that were shipped in the last 2 weeks. Remote workers try to attend these meetings in person but it’s not mandatory.
Retrospectives are the meetings we are experiencing the most issues with when some colleagues are in remote. Indeed, providing good audio to remote attendees when the on-site team is roughly 10 behind the mic is challenging.
General communications
We are huge fans of Slack: Appaloosa currently has 57 channels for 24 users. Some channels are short-lived: to write every blog post, we open a new channel to discuss particular points and give feedbacks and then archive it when the post is published. We also have broader purpose channels for dev and sales teams, with their own third-party integrations (GitHub hooks, Intercom, elCurator…).
We have channels to help day to day interactions between on-site and off-site team members; #hello-goodbye helps us keeping touch with remote people when starting or finishing the day. This gives a more “human” feeling to Slack and also encourages a polite gesture from both ends when we can’t shake hands.
Project management
As a team used to working in the same office, switching to a distributed team was challenging. We were used to discussing the user stories when a question arose. We spent less time estimating the user stories and more time discussing them when a developer started working on one.
Having some people working remotely has made this more difficult, so we try to add as much details as possible to the user story during the estimation. Recruiting a product designer made that process easier as it’s always easier to work with real designs instead of mockups.
On culture
Our culture is all the things that make us, us: our core values and our private jokes, our processes and the way we interact with one another.
That is why we ask new candidates who intend on being remote most of the time to spend a few days per month on-site. We take advantage of them being physically with us to spend some quality time together drinking beer and having fun. It’s usually during beer time that we share the detailed story of Appaloosa, the events that shaped the team, the origin of some of our expressions or Slack emojis…
Knowing each other is essential, because written or video conversations are hard. Who never felt hurt by something said on chat? But knowing your colleagues helps you mitigate that: “I know him, he uses that expression to make an impression of Tom, not to be hurtful”.
Recommendations
For the remote worker
1. Logistics:
- Prepare for your remote session, whether it’s for a few days or few weeks.
- Inquire on the Internet connection.
- Bring all the devices and equipments you may need.
2. Communications:
- Don’t try to reproduce communication the same way it’s done at the office. You have to adapt the way you’re exposing issues. Be patient about getting answers right away, but don’t hesitate to politely inquire about your question if you still don’t get an answer after a while.
- Feel free to speak to other remote workers about stuff not related to work like after stand-ups when only remote workers are on Hangout. (Note: the on-site team did not know about this and missed out on a lot of fun! :) ).
- Make extra effort to be responsive on Slack and take advantage of demo time slots to showcase your work.
- Because your peers don't see you struggling on a complicated problem or dancing like crazy when finally fixing a bug, share your successes and failures with them: we are all in the same boat!
- Remote worker should connect a few minutes before the stand-up's beginning to the same video channel every day and wait for the team at the office to join in.
For the on-site team
When meetings are temporarily delayed, it can be frustrating to wait without knowing why it’s not starting. A simple Slack message can smooth that wait: “Hey remote guys and girls, we will begin the stand-up in 3 minutes, the janitor is nearly finished with the vacuum!”.
For everyone
Make extra effort to keep in touch with the persons who are not physically with you.
When receiving a DM from a remote colleague, make sure you answer quickly.
Work in progress
Although we are quite happy with our beginnings in remote work, we have issues we need to address.
Relational issues
The main issue remotees encounter is missing the on-site team. It’s a bittersweet feeling because we feel good around each other, this is something we are very glad for, but it also means we are missing a way to keep in touch.
We need to limit the feeling of isolation one can experience. That feeling can both be experienced on-site and remotely.
Onboarding
We don’t know for the moment how to onboard people locally and make them feel comfortable with remote co-workers. Some companies make online onboarding session with remote people one by one but this can also be done at the office when the whole team is on-site. “Think remotely” isn’t easy when you’re not that well acquainted with your peers.
Technical issues
The issue we face the most is due to a limitation of the way microphones work: when more than one person talk at the same time, there is no way to focus on only one voice, resulting in plain noise. That problem can be resolved by asking for discipline to all of the participants to remote meetings: only one person can speak at the same time.
One key element to take into account when going remote is the bandwidth dependency. You simply cannot collaborate with a remote colleague without a high speed Internet connection. But you should also choose wisely the tools you’ll be using during your video calls. We started off with appear.in, but abandoned it when we realized it was too bandwidth hungry. For now, we use Hangout, but we are constantly experimenting with new tools.
Conclusion
As of today, we have mixed results about our new remote working policy.
Working remotely is not as simple as saying “hey, what if I worked from home today!”.
There are some serious subjects to tackle, especially on the long term: isolation, communication (for project management or knowledge transmission) and corporate culture being some of the main ones.
We know some things do not work properly and we do not have an answer yet, but we’ll keep on working so that there is no frustration whether you work remotely, or you work with remote people at Appaloosa.
If you have questions, remarks or advices, please leave a comment!
This article was written by Appaloosa’s dev team:
Benoît Tigeot, Robin Sfez, Alexandre Ignjatovic, Christophe Valentin
Want to be part of Appaloosa? Head to Welcome to the jungle.
