As a remote, asynchronous team scattered across the globe, we are able to offer support 21 hours of the day. To make sure that support shifts are fully covered, while also ensuring no one team member has to provide support for too long at a time or outside of their self-specified working hours, we use a constraint-programming scheduling algorithm.

The scheduling algorithm is itself a piece of the balena puzzle which embodies our first principles approach. While the most obvious solution to scheduling support shifts may be to assign a team to manually create the schedule every week, at balena we believe that anything that can be automated should be and, as such, we have just one (incredible) team member working on an algorithm that itself does all the heavy lifting while the person assigned to it is responsible for iterating on and improving it.

There is an important point here relevant to considerations of organizational design. The process of matching the time zones and scheduling preferences of almost 70 people with the ever-fluctuating number of inbound support inquiries in a way that doesn’t overwhelm any individual team member, while also making sure we are able to deliver timely and thorough help to our users is a convoluted optimization problem. Such a task would prove tedious for even the most passionate abstract math theorist, especially if it was all they did week-in and week-out, as it very well may be if scheduling were assigned to a human.

We believe that the best use of our human capital in this case has been to focus on creating a scheduling algorithm that does these calculations for us and generates an optimal schedule on a weekly basis. Initially, creating such an algorithm takes a lot longer than just having a person do the scheduling. Many weeks have to pass while this algorithm is being created, during which support scheduling will have to be done manually. However, front loading this work is certainly worth it in the long run as, eventually, the scheduler runs automatically, and the human behind the code has an engaging problem to work on, rather than being ground down by the repetitive work of scheduling. This philosophy of doing the scaleable thing up-front, even if it takes more time is an example of the maxim “Short term pain for long term gain” — perhaps the single most quoted phrase inside balena.

Furthermore, not only does a scheduler make this work less tedious, it also allows fewer people to be responsible for it, and makes sure the work that they are putting in goes to actually improving the process, rather than just maintaining it. Put another way: whereas a manual solution would require hours of work every week just to generate the next week’s schedule, every hour put into the scheduling algorithm goes into improving the process as a whole. The baseline work is automated.

We’ve written extensively about the nuts and bolts of how our scheduling algorithm works in the past, however the high level summary is that every week, all of the engineers in the company update their availability for the following week on Google Calendar. The algorithm then does the rest: assigning support shifts within agents’ preferred work times, scheduling only when calendar availability exists, and making sure not to schedule a single agent for an excessive period of time. The scheduler even takes into account historical contributions and ensures that team members who have contributed more to support in the past get a lighter load in the future, and vice versa.

You can find out more about the scheduling algorithm from our aforementioned whiz engineer, Alida, by reading the blog post she wrote: https://www.balena.io/blog/the-unreasonable-effectiveness-of-algorithms-in-boosting-team-happiness/