Below is an article originally written by Hannah Henderson, Engineering Manager at PowerToFly Partner CircleCI, and published on March 31, 2020. Go to CircleCI's page on PowerToFly to see their open positions and learn more.
Communication is hard, communication on a remote team is harder. Fortunately, it can be as effective on a distributed team as it is on a colocated one, if not more so. This post delves into ways our team has learned to counter the two biggest challenges of remote communication: understanding tone and upholding a collaboration framework.
Although this post is written from my point of view of as an Engineering Manager, the practices described and templates linked are valuable for anyone on a remote team: they are the result of collaboration, ideas, and retrospective takeaways from people throughout our Engineering organization.
Getting to know a distributed team
Hyper-communication goes a long way towards ensuring that folks understand their peers' intent. This is especially true early in a groups' formation when trust, the hallmark of an effective team, is first getting built. To lay that foundation of mutual understanding, spend time getting to know the individuals on your team, and helping them get to know each other.
Do this by:
- Conducting asynchronous introductions to collect information and set expectations.
- Implementing these agreed-upon standards in synchronous sessions.
- Adjusting guidelines as-necessary based on input from the team.
Keep in mind that on a highly-distributed team, it can be difficult to find overlapping working hours on everyone's calendar. This overlap is synchronous time. Synchronous time is valuable, and should be treated as such. Know what you're hoping to achieve before entering synchronous interactions. Use your asynchronous time for focused individual work and to prepare for synchronous interactions.
When your team is forming, use asynchronous time to collect information, set expectations, and allow folks to define their own boundaries.
- Make sure you're familiar with the company's existing communication expectations. Stomping all over folks' toes is not a great way to build relationships. If you're new to a team, consider sending out a short message explaining that you'll be asking lots of questions while learning the ropes. If you use Slack, update your status to say something similar.
- Send out a detailed questionnaire to learn what the team needs (or, at the very least, what the members of the team think they need). If you're a manager stepping into a new team, I recommend sending out some variation of this form to solicit as much input as possible and to suss out the lay of the land.
- Define a team manifesto. Write this as soon as is reasonably possible. Broadly, this document should roll-up your understanding of what processes exist in order to codify healthy practices and value-signal. In the past, I've boiled this down to two sections:
- People (please make sure you're familiar with everyone's write-up) - I expect teammates to get to know each other as people with rich lives, curious interests, and priorities outside of work. I signal that I really care about this bit by populating my own profile first, and listing everyone's name as its own section.
- Team Process (you can skim this, it's good as a reference) - The frameworks defined in our team entente are important, and I sincerely hope we follow them. That said, process for the sake of process doesn't add value; I'm happy when we achieve our guidelines 80 percent of the time.
- Prepare for synchronous time. The logistics of organizing face-time on a distributed team can be difficult (especially during the month plus of global daylight savings misalignment). Ask folks to fill out a Team Schedule and remind them to populate their personal profile in the team manifesto.
Synchronous relationship building
Synchronous time is critical to the storming, norming, and performing phases of team development. Use this time to get to know your direct reports and to create space for folks on the team to get to know each other.
Note that asynchronous communication doesn't go away, it, along with synchronous communication, is further-established in your Communication Framework (below).
- Maximize your one-on-ones. Get to know your reports and drive alignment with this Getting to Know Each Other exercise. Consider grabbing some questions from this extensive set to round out subsequent 1:1s.
- Build in time for water cooler chit chat. Remote teams don't cross paths at lunch or in the hallway. Create space and synchronous time to connect. This may mean padding meetings with time for banter; it definitely means creating chat groups for shared interests (which are also async-friendly). We have #random, #wordnerds, #keyboards, #babies, and #bread, to name a few.
- Set up scheduled pairing. Randomly assign a pairing partner, and rotate partners once a week until everyone has paired with everyone else at least once. At the beginning of each matchup, the members of each pair should set up (best effort) three hour pairing blocks every day for the week. Sometimes, "best effort" only equates to an hour of pairing. Particularly on teams with a wide timezone spread, actually scheduling sessions ensures that folks are able to connect during their working hours.
For us, after a few rotations through the whole team, folks were comfortable reaching out and ad-hoc pairing. During one of our retrospective meetings, we decided to stop scheduled pairing.
- Make a team channel and share status updates. (This is also async-friendly.) We have a private team channel where folks post all manner of status updates: their good mornings when they hop online, notes about what they're picking up, lunch breaks, hot takes and random observations (debates about the plural form of "octopus" and whether or not an Xbox qualifies as an essential shelter-in-place item spring to mind).
We use JIRA and Namely, and have integrated Kanban board updates with the channel, as well as weekly updates from Namely about folks' PTO and birthdays.
Setting up a communication framework
On a remote team, it is especially easy for information to fall between the cracks. It is important to set up process that acts as a communication forcing function. There's no need to run around after folks trying to extract information and context, let your process be the heavy. Our team takes an Agile-inspired approach with a recurring two-week cycle of meetings.
Pro-tip: use the availability collected during asynchronous introductions to pick meeting times.
Meetings for knowledge transfer
Scrum-flavored methodologies are popular because they tend to work. That said, on a remote team the focus of each of these classic meetings is a bit different: they're all much more geared towards teasing out information disconnects and misalignment in advance.
Our standup is at the end of the day for our European teammates and in the morning for our West Coasters. These engineers won't overlap again for 20+ hours.
- Standup (30 minutes, daily). This daily check-in is our only guaranteed synchronous time on any given day. Instead of a 5-15 minute session, we block off 30 minutes so there's time to properly exchange context and also to chat. We review a Kanban board, and, importantly, the standup leader shares their screen and takes update notes on every card as an alignment forcing function. These notes often come in handy during cross-team collaboration and even during incidents (rather like a well-written git log that actually includes the "why".) Schedule standup back-to-back with other regular team meetings so that you can roll straight from one into another, and get out early if time allows.
- Planning (1 hour, weekly). We groom our backlog by Friday each week, and set up asynchronous points poker that everyone is expected to fill out by our Tuesday planning meeting. This allows us to spend the Planning meeting using estimates as indicators in deciding what treatment is appropriate for each card. Use this process to tease out context. Don't always ask the junior person to explain why they think something will be hard. DO ask a senior engineer that has given a high estimate to share what they know about the dragons in that space. Your goal is to expose information, not people. By the end of Planning, the cards in our Next Up column are ordered by priority and, we hope, are generally correct, and shovel-ready.
- Retrospective (1 hour, fortnightly). An excellent time to check in on team processes and to decide how they can be changed to better suit the needs of the team. We have a Slackbot reminder asking folks to add topics to the meeting agenda. As team-appropriate concerns are raised in 1:1s, I will often seed the retrospective document with them. These conversations have led to larger discussions on topics like when and how to give code review (at what point is asking for a complete overhaul OK? Not OK? How do we push back without escalating disagreement?) as well as pairing preferences and retrospectives of on-call escalations. As much as possible, the questions, concerns, and thoughts of the folks on the team should drive the content of this meeting.
- Big Picture (1 hour, fortnightly). This meeting reserves space for Product to keep Engineering in the loop about the grander vision of what we're doing and why. It should provide broader directional context for folks on the team so that:
- They understand the value of their work.
- They're better-equipped to make decisions that roll up into the company's goals.
For each of the above meetings, there's a more detailed breakdown in this Two weeks in the life of Foo Team meetings document, which is worth a skim. It includes recommendations on what to include in invite bodies (especially an agenda and a link to meeting notes stored in a single folder for improved discoverability), many examples of specific questions to ask, and several templates.
Calendar tips and tricks (because time zones are hard)
Configure your calendar to do some heavy lifting for you. I use Google Calendar, and have gotten tons of mileage from:
- Adding my working hours. This feature notifies folks that when they send invitations that fall outside of my office hours.
- Turning on world clock. Mine is configured to show the time in California, Japan, and Germany. When I click on a window in my calendar, the world clock displays local time for everyone at that window.
- Displaying secondary time zones. Mine are configured to show the time in Ireland and in California. My current team is spread across these time zones.
- Adding my Pagerduty rotation to my calendar. I do not want to be notified by Pagerduty unless I'm being paged. I live by my calendar, so this helps me see when I am on-call without the extra notifications.
- Adding the Zoom Scheduler to my calendar. Because 99.9% of my meetings are virtual, they all require a meeting room link. This annoying-to-configure extension puts a giant, handy "Make it a Zoom meeting" button on my draft calendar invites.
Effective remote communication requires intentionality. By adopting the practices in this guide, picking and choosing what works for your team, it's possible to establish the foundation of trust and communication framework that enable remote teams to flourish. The resulting communication will rival that of a collocated team, and will be inherently better for context-sharing and information discoverability.
Below is an article originally written by Rosalind Lutsky, Copywriter at PowerToFly Partner CircleCI, and published on March 19, 2020. Go to CircleCI's page on PowerToFly to see their open positions and learn more.
Remote work is top of mind right now for many employees, teams, families, and companies suddenly faced with a very new work situation. For many people, this is the first experience they've had working from home for an extended period while also trying to figure out how to establish a new normal.
On top of the standard challenges involved with switching to a fully-remote setup, many people are also dealing with a host of unexpected changes – kids who need to continue learning while schools are closed, pets jumping in to join meetings, partners and roommates talking from the next room. We're also worrying about the safety and health of our friends and families. It's a lot to deal with.
CircleCI has a fairly distributed workforce – about 40 percent of our company works remotely and several of our teams are completely remote – but we still work collaboratively every day, regardless of location. Over the years, many of our remote folks have come up with a host of useful tips on how to stay productive and happy as a fully remote employee.
These tips aren't meant to solve all of the new and challenging issues associated with working from home, but we do think that the strategies that our more experienced colleagues have developed can inform us as we quickly adjust to this completely new reality.
Here are the best reads by our employees about working from home:
- How to communicate on a remote team: tools and templates for engineers - Communication is hard, communication on a remote team is harder. Fortunately, it can be as effective on a distributed team as it is on a colocated one, if not more so. This post delves into ways our team has learned to counter the two biggest challenges of remote communication: understanding tone and upholding a collaboration framework.
- Maslow's hierarchy of remote worker needs - Remote work is an art and a science - it's iterative, and not necessarily something that can be perfected overnight. That being said, there are certain areas of focus that can help you figure out what works best for you more easily, which is exactly what Customer Engineering Operations Analyst, Liene Verzemnieks breaks down in this post.
- How my distributed team communicates so no context is left behind - A number of our engineering teams at CircleCI are mostly or fully distributed. One such team, led by Engineering Team Lead, Marek Nowak, has consolidated their four main tips for keeping their team productive and successful: overcommunication, pairing/collaborating, Slack usage, and meetings. This post describes how they've learned to use these tips to thrive as a fully distributed team.
- Tools for effective remote pairing - The Plans and Pricing team at CircleCI is 100% remote and pairs almost 100% of the time. While this might seem like a challenge, the team has developed a number of strategies that make them consistently successful at pair programming. In this post, we break down some of our best tips for remote pairing that other engineering teams trying this for the first time might find particularly useful.
- What it means to be remote-first vs. remote-friendly - There are tools and strategies that teams can use to keep everyone feeling supported, connected, and empowered - even at a distance. In this post, Product Manager, Rose Jen, details how CircleCI works to create a culture that puts remote employees first.
- What to expect as a remote CircleCI employee - We often get asked in interviews what it's like to work for a distributed team. In this post, we asked engineers from across the organization to describe their experience, and share some tips for working as a fully remote employee.
Below is an article originally written by Rosalind Lutsky, Copywriter at PowerToFly Partner CircleCI, and published on March 4, 2020. Go to CircleCI's page on PowerToFly to see their open positions and learn more.
Confidence is different for everyone – there's no one correct definition or expression of confidence. For one person it's built over time by successes and failures, and for others, confidence is natural but needs to be tempered and sharpened by time. It's also something many people struggle with that requires a lot of hard work and self-reflection for them to harness.
It's an abstraction that humans have to cope with every day.
We interviewed six CircleCI engineers at different stages of their career to find out what confidence meant to them and how it helps them succeed at work. A common thread we found is that confidence is a necessity for engineers. It's a requirement to make sure that they're not only building things that work, but that they also have the right systems, tools, and processes in place to make success repeatable.
"You want an engineering system that's basically the equivalent of a factory," said CircleCI VP of Platform Mike Stahnke. "You put in raw materials at one end, you get an output out the other end that is in a known shape and has known properties. That's one of the things that's always interested me about automation, and in particular CI. It's the factory floor for software building. The confidence you want in there is that I can make a change and it doesn't change the overall form of the thing I'm building on the other side, that it's still within all the quality measurements. And that's pretty much what CI is: a confidence-gathering process that's automated."
For CircleCI Software Engineer, Jacque Garcia, sharing knowledge and working through problems with others (and boxing) helped shape her confidence as an engineer.
"Pair programming is definitely really useful there too," she said "It's easy to want to solve something on your own, and just take hours and hours really trying to figure it out. When it could've been easily addressed by just asking someone, 'Hey, have you encountered this problem?'"
"Before pairing, I try to really understand what the problem is. Of course, there are times when you just have no clue. And that's fair, as well. I think that's also part of gaining confidence. You gain confidence by asking questions, and not being afraid to ask for help."
While it's impossible to land on a universal definition of confidence, there's no denying that it's key to building great software. We hope that these stories have shined a light on how others develop, sharpen and harness confidence while they code.
Below is an article originally written by Patrick Shields, Principal Software Engineer at PowerToFly Partner CircleCI, and published on March 3, 2020. Go to CircleCI's page on PowerToFly to see their open positions and learn more.
There's not a right or wrong career path for software engineers. Some find a natural niche as leaders and work into management positions where they end up leading teams and designing career paths for others. Conversely, some thrive and become leaders by developing their own paths as an individual contributor (IC). Pat Shields, CircleCI's chief architect, recently wrote about his experience growing as an individual contributor, including advice about how engineers on the IC route can succeed in their careers. We're reposting it here.
My first real job in programming started on July 5th, 2007, which means I have just over twelve years of experience as I write this. It's a lot more than nothing, but probably not much more than something. Ten years seems to be about the right amount of time to get good at something, though some amount of natural talent or sheer drive can make it go faster. But growth is not as simple as waiting it out and talent does not supersede the need for experience.
"Players get to that intermediate level where they can already play pretty good, and that's kind of a dangerous period because they tend to start playing only the things that they can play, rather than the things they can't." - Pat Metheny
In fifth grade, I went to a school where I was required to take a French class. I showed no particular aptitude or interest in the language, but was happy to pass through the lessons. After two years, my family moved and I started at a new school where I was able to choose Introductory French or Spanish. I chose French, effectively repeating the previous two years. I have little to no memory of these classes, but I believe I passed through them with ease. After those two years, we moved again and I started at a High School. I was offered a choice of languages to study and I elected for … a year of Introductory French. I was the star pupil of the class, having repeated "Je m'appelle Pat" and "Où est la discothèque" as required for the previous four years.
The following year I entered Intermediate French and the skill gap between myself and my peers immediately dwindled. Despite my five years of experience, I didn't advance much beyond a few simple phrases and a halfway decent accent. I muddled my way through the next two years, but squandered my experience and gave up learning the language after high school. Many of us make this same mistake in our careers. We optimize for a skillset that is easy to gain or stay within the confines of limited expertise. Quite a few folks just don't get the opportunities they need to grow. I have found a few strategies that have helped me grow, and I'd like to share them along with some ideas about how you might apply them.
Assume you are smart enough to understand
In my first job out of school, I worked with some of the most brilliant folks I've ever met. Most were affiliated with Yale via either its computer science department or its high performance computing lab. During my job interview, Nick Carriero asked me if I was familiar with Junit and I tried to pretend I knew what it was beyond a window in Eclipse. I was surrounded by very experienced, very educated, and very accomplished folks. The one benefit of this was learning that in those walls I would never, ever, be the smartest person in the room. To follow along alone was an accomplishment.
Those folks were much more than smart. They were mostly twice my age or more, had studied rigorously in academia or cut their teeth on hard industry problems, and all had a tremendous work ethic. I didn't have their innate talents or that experience, and I was in no danger of being able to do what they did. But that didn't mean I couldn't follow along and learn. So I tried to ask dumb questions and to restate things until I got them right. Being wrong or not knowing something hurt still, but it hurt a little less every time the light bulb finally went off.
Most of what you need to follow the work of those around you is just patience and curiosity. When you encounter things in your work that you don't understand, ask someone to help you figure it out. It could be a piece of code, a system design, or even a business concept like margin. You won't become a quick expert but you will gain a breadth of knowledge. More importantly, you'll learn how to ask questions and learn from those around you. Give yourself space to do good work
Real talk: everywhere you go there will be haunted forests, tech debt, and organizational challenges. Every opportunity comes with constraints. Often, those constraints lead us to choose the lesser of two evils or the best of a bad set of options. In my experience, it's easy to over-dramatize the evil or inherent bad-ness, but the point is that it feels bad. When you consistently do work that you don't take pride in, it's challenging to invest yourself in growth. Engineers in this situation often begin to imagine some panacea that would fix things. If only things were functionally pure or fully asynchronous or crash-only or written in Idris or Rust or actually Go would be preferable, then we could do things the right way. Or so the thinking goes. We convince ourselves that we are talented and great, if only we weren't limited by the things we cannot change.
Don't get stuck thinking that you can't do good work unless something you can't control changes. Find opportunities large or small to try to do something in a way that you are proud of. This can be as small as writing a few methods or functions that you think are great or running a larger project in an exemplary way. When I've done this, I've found that some of my great ideas were great and some were pretty sketchy. If I hadn't put them into action, I'd have missed the opportunity to figure out which ideas had merit.
Focus on the outcomes
As programmers, we spend most of our time living deep in the "how?" Programming is quite literally the process of filling in all the details. Many of us experience frustration in our jobs because we are forced to reckon with ambiguity that our coworkers and peers can shrug off. Earlier in my career, I used to say that there was nothing more terrifying than a meeting that ended in agreement because that just meant you hadn't figured out the details yet. That's a pessimistic extreme, but it's also a fear born out of experience.
By and large, the conferences we go to, the blog posts we read, and the conversations we have focus on the "how?" We talk about programming languages, databases, agile methodology, distributed systems papers, or GraphQL. But for most of us, those are tools to help us do something else. Our stakeholders don't care about the tools, they care about the outcomes. The earlier you are able to focus on outcomes, the more you'll be able to connect with your stakeholders, learn from them, and then help them succeed.
This is a huge topic and a never-ending quest, but you can start by always knowing the answer to the following three questions:
- What problems am I trying to solve for my stakeholders?
- How do I know when I'm done?
- How do I know if it solved the problem?
No matter what process you use, or don't, and no matter who your stakeholders are or how big your organization is, if you know the answers to those questions, they will guide towards a path that is focused on generating outcomes rather than just generating more details.
Do whatever you want, but do it loudly
I was a year or two out of school when I first heard the phrase "It is better to beg for forgiveness than ask for permission." It's an old phrase, sometimes attributed to Grace Hopper, but variations have circulated for many years. There are some organizations where creative thinking and empowerment are still frowned upon, but I think this quote misses the mark nowadays. It's still true that asking for permission will likely get you stuck in the mud. The receiver of your request will likely feel the need to do due diligence on the request before passing judgement and, well, it's not likely their top priority or they would've been asking you for the ideas. It's the request that slows things down, not the knowledge of the approach.
I've taken to using a variation of this phrase: "do whatever you want, but do it loudly." If you feel confident that you have a great idea and know how to complete it, go ahead, but first announce it to anyone who will listen. You want to avoid surprise and rumor. By keeping everyone abreast of your actions, you are giving them the knowledge they need to provide you with feedback and a mechanism to do it. I often provide a little space for feedback even, by saying "Unless I hear from you by the end of your day tomorrow, I'll be proceeding." I'm not asking you to vet the approach for me, but if you know I'm headed towards dragons, let me know.
Stay focused on growth
No matter what strategy you choose, as soon as you have the security to do so you should start thinking about your growth. "Where do you want to be in 5 years" is a great question, but sometimes it's impossibly difficult to answer. These strategies won't help you pick a direction, but they'll help you get the most out of wherever you are right now. If you find you can't use these strategies, either because you don't have enough support from your peers and management chain, or because the work model is so inherently broken, it's probably time to look for another opportunity when you are able. Along the way, be proud of your growth and what you've achieved, but don't give up on challenging yourself.
Below is an article originally written by Rose Jen, Product Manager at PowerToFly Partner CircleCI, and published on July 26, 2019. Go to CircleCI's page on PowerToFly to see their open positions and learn more.
Hi! I'm Rose Jen, a product manager at CircleCI. I've run a number of interviews here at CircleCI, and the #1 question I get asked is "What is your experience with the distributed culture at CircleCI?"
I have worked before in companies that allowed remote work. They've offered their teams access to tools to make remote working possible. I've also worked on teams which start out as colocated, but have become distributed by necessity as team members move. Often in these cases, the folks working remotely become increasingly left out and distanced from the rest of the team. Given those experiences, I was initially hesitant about working on a distributed team, specifically with concerns that communication could be difficult, or worse, that I might feel disconnected from my team. However, during my time here at CircleCI, I've noticed that the company's deliberate work on building an inclusive distributed culture put many of my fears at ease. And through this experience, I've seen the difference these efforts make, and learned that merely allowing employees to work remotely isn't enough.
While CircleCI has been a distributed team since the beginning, we do have an official headquarters in San Francisco. To support our teammates all over the globe feeling fully connected, included, and empowered, we work hard everyday toward building a "remote-first" culture. The difference between a team which allows remote work, and one which strives to be remote-first may sound like a technicality, but in practice makes a world of difference to our team members, regardless of where they are. Remote-first means that remote employees are not an afterthought. Being remote-first means being intentional about not just the tools that are used, but also how we plan a company culture to be as inclusive as possible of remote workers while allowing everyone to be the most productive.
For anyone considering joining us, or for those who are looking to foster a remote-first culture in their own organization, here are 5 ways of making it work:
Videoconferencing by default
We rely heavily on videoconferencing at CircleCI – it's quite impossible to go through a workday here without some sort of videoconferencing (we use Zoom). To be maximally inclusive, we are very specific about how we use videoconference tools. First, as a company we invest heavily in hardware and software that makes our reliance on vidoeconferencing work. Every single conference room at our office is fully video-enabled. On the flip side, we expect our employees to have access to high speed internet connections, and to work from a location where they can be clearly heard and seen – being unable to hear someone on a call won't cut it. The success of this tactic relies on everyone's participation. We also made the choice early on to grant every employee full access Zoom accounts – so every team member feels empowered to call meetings, whether large brainstorms or ad-hoc chats.
Additionally, we have practices about how we disseminate information from video meetings. We include a Zoom link with every event invite, so that no matter where the participants are, they can join. At CircleCI, we have a general rule that if there are team members in various time zones who won't be able to attend a meeting, we record the meeting and make it available for viewing at a later time. This gives folks in all time zones the flexibility to manage their day the way that best suits them.
Accessible, structured, and documented team meetings
At CircleCI, most product development teams have a variety of weekly get-togethers: planning meetings, daily standups, brainstorms, design reviews, and retros. These are all done via videoconferencing. Depending on the type of meeting, we also utilize digital tools (Google Docs, for example) that everyone has access to in realtime, through which we facilitate discussions and document decisions as they're made. For example, we use Google Docs to outline brainstorming or retro discussion topics. For planning meetings and standups, we go to our shared Jira board that shows our deliverables and progress, so that everyone is following along in realtime while the discussion is happening. For design reviews, we use Invision, a design prototype tool, that allows designs to be shared across the team and allows team members to provide comments. These have helped us have productive meetings anywhere the team is. I personally don't miss cramming an entire team into the same meeting room, and I'm certainly glad to be freed of the struggle to find available meeting rooms.
Document, document, document
Who doesn't love good documentation? In a remote-first environment, pay special attention to physical artifacts that may disadvantage team members who are not colocated with you. There will always be things that occur in realtime (quick sketches, Post-its) when a few folks are in the same room, but we take efforts to document and share the results of those IRL brainstorms with the team at large and take lots of pictures of any diagrams, roadmaps, and other outcomes, so that everyone can access them afterwards. Find ways to ensure that remote team members aren't just listening in, and look for ways they can participate in realtime. Zoom offers collaborative whiteboarding that you can do from inside a conference call. Even with the best tools, this process will often still be imperfect, and therefore requires mindfulness and some creativity from everyone involved.
No hallway conversations
This doesn't mean that you can't talk to your coworkers face-to-face or around the watercooler. But it does mean that if you have work-relevant conversations that are not digitally recorded, they should somehow get recorded after the fact: put a summary in chat, write up a short document, or find another way to make sure that information can be referred to by remote team members. We also encourage our team members to have impromptu "hallway" conversations over video, whether it's to ask a question or to quickly get the team aligned on a specific topic. Regardless of location, there are some things only a quick 1-on-1 chat can clear up.
Plan together time
Whenever possible, bring your distributed teams together! There's something really nice about being able to spend time with your far-away coworkers in real life. At CircleCI, we plan for teams to meet at a location together at least once a year. Departments do the same as well. It'll require serious logistical planning and a monetary budget, but it will be well worth it as a team-building investment.
What I've shared isn't a definitive guide to operating a distributed company – just some things I've noticed at CircleCI that have made a difference for me and my colleagues while working on a distributed team. It's important to mention: we are always re-evaluating our processes, and looking for places to refine. Things will change. For example, now that we are expanding more globally, it has changed the landscape of what being distributed really means (for example, getting a team together whose members are 1 hour apart vs. 8 hours may mean folks in San Francisco scheduling meetings earlier in the day to accommodate the schedules of team members across North/South America and Europe). These changes have pushed us to change the way we use our tools, and given us opportunities to continue to iterate and improve. Overall, if you're in an organization looking to become more remote-friendly, we encourage you to keep an open mind and experiment to find what will work best for you.