Remote Native: Big 3 lessons learned

We have been running a fully remote team since we first started experimenting with some of the key aspects around Archimydes in the summer of 2017. Back then, it was just 3 people: two developers, one based out of Melbourne, the other based out of Perth, and myself based out of New York City. Since then, the core team has scaled to approximately a half dozen developers and a similar number of designers, QA analysts and product folks. The team now stretches from Melbourne to San Francisco. We have achieved some decent success in that time frame, including:

• Attracting $1M in pre-seed funding last year

• 100% customer retention from early 2018 through to late 2019

• Great initial response to our core offerings from the developer community

We like to think of ourselves up to this point as a relatively successful remote-native story and wanted to share with you some of the things that we have learned along the way. These lessons are useful regardless of whether you, like us, consider yourself remote-native, remote-first, remote-friendly, or are considering going remote at any level. Below are what we consider the Big 3 lessons learned.

• Minimize communication friction

• Develop a hub and spoke staffing model

• Conduct auditions, not interviews

  
  

MINIMIZE COMMUNICATION FRICTION

---

This one sounds fairly obvious, but the devil is in the details. What is the #1 cause of communication friction in managing a remote team? By far and away, the award goes to unclear requirements. In our experience, most of the challenges in software development can be attributed back to unclear or ambiguous requirements, not poor developers. This results in all kinds of delays, back-and-forth and, quite often, failed projects. Let's illustrate this with an actual example of where we were when we first started and where we are today in terms of requirements:

Sample Requirement (circa 2017):

User Story: As a user, when I click "submit" on the landing page, I am navigated to the first page of the intake application and my account is created in the background.

Detail: As a user, when I am coming through the landing page into the intake application

• My account, against the email that I provided on the landing page, is automatically created.

• An email is sent to me, with a link, in case I want to access my non-submitted user stories.

Sample Requirement (2020):

User Story: As a user, I should be able to view a single comment

Story Category: Design | Frontend | API

Authenticated: Yes

RBAC: Any authenticated user that has permissions for that entity

API Description: Any authenticated user is able to get a comment against comment id

Architecture Requirements:

• Implement using Type ORM -- refer to existing implementations for reference

• Typescript to be used through the development

Datastore Requirements:

Refer to reference table structure identified here: URL to reference table structure

Unit Test Cases:

• Able to get a comment against a comment id

• Test against if entity is private or user does not have permissions on that entity (e.g. a project that is owned by someone else should not be able to fetch the comment)

• Admin role type can fetch any comment

• if user is the comment creator, then should be allowed to fetch the comment

API Reference Documentation: URL to swagger hub API documentation

Implemented API: URL to implemented API

Success Criteria:

• Able to get a comment by comment id

• If entity type has view permissions then authenticated user needs to have those permissions in order to get comment against that entity type and id

• Admin can get comment on all entities without permission checks

• Author of the comment should be able to get the comment

We will get to the nitty-gritty of how we write out user stories and acceptance criteria in a later post, but for now let's look at some of the common criticisms that one might hear, including:

• This requires too much effort: Yes it does, but so what? What is the job of your solution architect, product manager, and business analysts if not to make requirements explicit and clear? Developers, remote or otherwise, are not sorcerers -- they cannot guess what's in your head. If you can't talk to a machine in its language, at least communicate to those that can in the clearest manner possible.

• But we are an agile shop!: Where in the Agile Manifesto does it say that you need to work off of unclear and/or ambiguous requirements? The purpose of agile is to release software quickly and iteratively, and to communicate clearly and throughout the development process, not to be unclear about what is required.

• This takes away from a developer's creative agency: A developer's job is to be creative in his/her solution for a given requirement, not to be inventive in creating the requirement. Yes, developers, will occasionally question the need for a particular requirement, but it's the job of the solution architect and product manager to prioritize requirements.

All-in-all, the #1 thing your team can do when working remotely to minimize communication friction is provide clear requirements. If they are not as clear as the sample above then that's fine, but a good rule of thumb is that any questions arising from a requirement should be addressable within 1 or 2 Jira comments or in your daily stand up.

This goes beyond communicating software development requirements, we adhere to these same principles even when communicating other types of business requirements. More on this in later posts.

DEVELOP A HUB AND SPOKE OPERATING MODEL:

---

When we first started we had the team spread across 2 countries and 3 different time zones. Today we have a team spread across half a dozen countries, and across 7 different time zones. Have you ever tried organizing a scrum call that works for everyone in Melbourne, Bangalore and San Francisco? In a 24-hour time window there is literally only 1 somewhat normal working hour, 7 PM San Francisco time (8:30 AM Bangalore, 2 PM Melbourne), where a scrum call is possible across these time zones:

Credit: thehtime.com

Now, lets add Lagos, Nigeria, a very really realistic scenario for our team, into this mix and see what we end up with:

Credit: thehtime.com

Suddenly there are literally zero time slots that work for everyone involved. How did we solve for this? We took a page from the airline industry and went the hub-and-spoke model. We now consider ourselves having 2 hub locations -- New York and Bengaluru and try to center teams around these locations. This is what a time intersect between NYC, San Francisco, and Lagos looks for us:

Credit: thehtime.com

In the above example, NYC is the hub location. We now have a 2-hour time window that works well, in relatively normal working hours, for everyone across each city:

• San Francisco: 8:00 AM -- 10:00 AM

• NYC: 11:00 AM -- 1:00 PM

• Lagos: 5:00 PM -- 7:00 PM

It's even better in the case of Bangalore, Melbourne, and Dubai (see below), where there is a 4-hour time zone overlap between the three cities.

Credit: thehtime.com

Note: Htime in particular is a great tool at a remote team's disposal. It's objective is to develop a new clock concept that eliminates time zone math. It utilizes UTC and rotates based on your location. It unifies the reading of time everywhere, as a result no more time difference calculations are required.

CONDUCT AUDITIONS NOT INTERVIEWS:

---

When you are working with developers or other resources remotely it is not good enough to know that they have the appropriate skill. What's as critical is to determine if they can execute their job with minimal communication friction and with an appropriate level of responsiveness in a remote manner. In order to accomplish this, our on-boarding process looks something like this:

A few salient points that need further explanation:

• Do a quick screening audition prior to a skills interview. In our experience, developers with only limited or theoretical knowledge of concepts can generally pass a skills interview, however, those same developers might struggle with real-world work. To avoid this problem we reverse the order. We give them a very real-world screening audition upfront and test how they perform. If they perform well, then we move them to a skills interview. This also preserves the valuable time of on-boarded developers in executing interviews up-front.

• Make sure that the auditions are as realistic as possible. In particular, test them with as-close-to-real-world-work as possible. We use pre-designed simulated projects for the screening audition and a real project for the extended audition. Requirements are communicated to auditioning developers in the same user story and acceptance criteria format as they will be expected to work in so that there is no ambiguity in terms of how requirements will be communicated and what the criteria are that need to be met for a requirement to be considered complete.

• Do an extended audition even if the developer passes the screening audition and the skills interview. In some cases, we have found that developers get through a screening audition and skills interview fine, but then you run into problems with them that you cannot pick up in a relatively quick screening audition or skills interview. A very common example here is around developer responsiveness. A remote developer might be very responsive when going through a 4-8 hour screening audition, however it is very hard to fake responsiveness over an extended period of time.

In summary it is critical that remote teams account for extremely clear communication, a hub and spoke operating model, and an audition process instead of traditional interviews. In our experience, these three tweaks make for a better company regardless of your remote work policy.