# Practice inclusive scheduling **TL;DR:** Small scheduling choices go a long way toward making distributed teammates feel included. Write dates unambiguously, include time zones, and build breaks into the schedule. Published 2023-05-19 ยท [View on Ben Balter's site](https://ben.balter.com/2023/05/19/practice-inclusive-scheduling/) --- Time zones are one of the harder parts of software development, but they don't have to be one of the harder (or exclusionary) parts of working as a distributed team. Here are a few habits I follow to make scheduling more inclusive on a remote team: - When discussing dates, consider writing numeric dates in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) (YYYY-MM-DD) or other month/day unambiguous formats. - When referring to a time, always include the timezone. - Avoid location-specific language like "tomorrow", "this afternoon", or "in the spring". - Be mindful of holidays, weekends, and working hours, especially across time zones. - Consider "speedy meetings" (end 5 or 10 minutes early, or start 5 or 10 minutes late) to allow for time to be human between meetings, and be strict about ending at that earlier time. - On that note, meetings should start and end on time. If you finish early, consider using the remainder of the time for informal conversations and to connect as humans. xkcd comic describing ISO 8601 as the one true date format A small nod to inclusivity goes a long way toward creating belonging and reducing ambiguity. When you work with global teams, schedule and communicate with a global (and remote) audience in mind.