Engineering a Global Team Learning Solution

By Dana Jones of Fractured Atlas"Andela works with companies around the world, scaling their engineering teams with full-time devs - Fractured Atlas is one of those companies. Dana, Software Engineering Lead at Fractured Atlas talks about their experience as a 100% remote team.”At Fractured Atlas, our Engineering team is 100% remote. While we have a few developers who live in the same city (Baltimore, Maryland, USA), even they usually work separately from homes, coffee shops, co-working spaces, or the occasional front porch. That's why incorporating Andela engineers into our team was not a major difficulty, despite the time and location difference.Staying connected is a major focus of our engineering leadership, along with deliberately creating opportunities to share knowledge and grow the skills of our team members. Remote teams present particular challenges in achieving these goals. Since we don't have the luxury of sitting down in a room together with a whiteboard and a corporate trainer, or of simply leaning over to ask a question of a neighboring engineer, or of popping in to our CTO's office to get clarity on a priority decision, we have to purposefully create opportunities to share virtual space and information amongst engineers.We're constantly evolving our processes to fit our changing team, but our current approach is a complement of regularly scheduled meetings and training sessions on the one hand; and variable, ad-hoc meetings on the other. To make this work, we rely very heavily on shared Google calendars, awareness of team members' time zones and locations, and a commitment to a work-life balance. This means we don't schedule meetings very early or late in the day, or over typical lunch periods wherever possible. It was a conscious decision to spell out which meetings are optional, so that team members could choose not to attend if they are feeling short on time or "people'd out."We are a "lowercase agile" company, meaning we make use of the agile methodologies that work for us. Our product teams operate in two-week sprints, with kickoff meetings at the start and retrospectives at the end. The kickoffs are intended to assess the state of work from the previous sprint, identify any staffing challenges (especially vacation time and commitments to other teams or projects), and set a goal for work to be accomplished in the upcoming sprint. Retrospectives are a time for reflection, celebrating victories, and acknowledging and learning from mistakes. Retros are scheduled for twice as long as kickoffs so that we have more time to dig into any problematic areas.Once a month, we have an hour-long "Lunch and Learn" session. This is a chance for anyone on the team to share something they've been learning about or working on that they think will benefit the whole group. Topics have included Team Communication, Empathetic Team Interactions, Elm, GraphQL, PR Review Tips, and more.Something new we will be starting is a monthly Show and Tell. This is a chance for non-lead team members to present their product to the broader engineering department. These presentations are meant to be short (less than 15 minutes per team) and can include progress on code development, a demo of a front-facing feature, or crowd-sourcing solutions to tricky programming problems. In addition to de-siloing between product-specific teams, Show and Tell is an opportunity for junior and mid-level engineers to practice some presentation and leadership skills.If there is a small-in-scope topic we want to cover with the whole team, we will schedule a "micro-training". These are usually 15-30 minutes in length. Because any unscheduled meeting is a disruption, we try to limit these in frequency and in topic. They might be course corrections in process, introduction of a new performant syntax, or team member introduction.Of course, our team is on chat throughout the workday. In addition to the typical use case of generally staying in touch, we also use chat to share links to articles, tutorials, and tools that help us do our work better and more efficiently. Coupled with this is our reliance on Confluence for documentation of all types. Here, we document our team meeting schedules, PR review procedures, deployment processes, setup instructions for each of our repositories, coding standards, and style guide, and more. Having this information documented in a place that is centralized and accessible to all of engineering impacts knowledge persistence in a very tangible way, and removes the burden on individual engineers.At Fractured Atlas, our mission is to build products and offer services that help artists run their businesses efficiently and effectively. As the company's engineering team, our commitment to learning and knowledge sharing - despite our global distribution - is a key part of how we achieve that mission.Fractured Atlas empowers artists, arts organizations, and other cultural sector stakeholders by eliminating practical barriers to artistic expression, so as to foster a more agile and resilient cultural ecosystem.