 Many of us have been introduced to remote work over the past year, but some folks are still struggling to make it work for them. George Shielus, a GitLab Core Team member and a designer at Gitpod, is here to help. In his talk, he'll share many important tips on becoming a more effective remote worker from communication to workflows and tooling. While those who have studied GitLab's all remote guide may think they have conquered remote collaboration, George adds depth, context, and fresh ideas that will inspire you. You can also share this great talk later with any colleagues who may need a refresher. This talk also features my favorite Easter egg on the open stage. Let us know in the chat if you find it. Enjoy! Hi everyone. I wanted to talk a bit about scaling collaboration for remote teams and remote work in general, as I've been passionate about this topic for a while and have been practicing this for a few years. Many of you watching this now have probably switched to remote work during the last year or planning too, but you've probably also faced some challenges while doing so. This talk is not about advocating for remote work or listing the benefits that come with it, but rather going through some best practices of senior action during the last years while collaborating with remote teams like GitLab, as well as sharing how a remote team at Gitpod planned and shipped a productive design and single creation. Ultimately, after this talk, you should feel slightly more confident answering the following question. How do you scale remote collaboration? I'm George, speaking from Athens, Greece. I work on product design at Gitpod and I'm also a core team member at GitLab. I've been contributing to GitLab for almost four years and recently joined Gitpod where I had the opportunity to also help shape our remote culture as a team. Speaking of GitLab, let me first forward a few years back when a colleague and friend of mine asked me if I was interested in joining a new team but working in a remote environment. Back then I remember being quite skeptical about remote work as an extrovert person, especially after having seen the benefits of working close with a team, per programming with others and more. I ended up saying no, but I knew I had to try this somehow to see if it works in action. A couple of months later, I ran into the GitLab project and saw that the team behind the project was successfully working remotely around the world and they also had this public handbook on how they work and collaborate. So I decided to take a deep dive by contributing to the project itself. For me, contributing to GitLab has been a catalyst for shaping the way I work with remote teams. I've been contributing to GitLab since their team size was just over 200 people and till this day I'm still learning so many things from the transparent design and engineering workflows behind GitLab, a team that currently surpasses 1200 people. So let's go through some best practices that could help a team successfully collaborate remotely. Before moving on, I think remote work has two sides that can be worked on in order to be able to work remotely efficiently. The first side includes you as a person and things like boundaries you set in work hours, discipline you need to demonstrate for planning your work day and more. This talk will focus on the other side which is about the remote organization you may be part of and how some simple guidelines can help your team collaborate effectively. We'll go through the following three aspects of remote collaboration including documentation, communication and workflows. You may have heard before the phrase documentation is called which is great as it advocates that documentation is equally important as the code you write. Similarly, documenting your team's processes and tools is a fundamental piece for shaping a remote culture. This includes also documenting the always evolving shared knowledge within the team as well as guidelines you can refer back to anytime. One of the first things you can do to help improve your team's remote collaboration is to establish a shared handbook and use it as a single source of truth for all the shared knowledge including guidelines, processes and more. This way you can refer back to these guidelines or processes anytime. You could start with writing down some values you want to align with that you can link back to anytime something goes off the track. And then you can add guidelines around how to work as a team including your take on meetings, chat guidelines and more. Now here's one key takeaway I always find critical to make this work though. Try to make small and progressive changes. This can really help the team digest new information as it comes in and make it easier to spend time reading these small updates. Additionally, having a dedicated handbook channel for broadcasting these small updates can also improve awareness and increase contributions to the handbook itself. In general, lowering the entry barrier for contributions to code, documentation or handbook can significantly help increase the quality and quantity of contributions to from your team. And here are a few things you can do to make this happen. Try using tools that make read write frictionless. Improve the developer experience for contributing including contributing to documentation and celebrate every contribution regardless the size of it. Now before moving on to the communication aspect of remote collaboration let me ask this. Did you know that interpersonal communication is mostly non-verbal? This brings us to the next important question you'll have to answer once you take away the largest part of communication after switching to remote work. And this is, what's your favorite emoji? Emojis can seem unimportant but they can carry so much valuable context, meaning and communication bits that can significantly improve communication in a remote work environment. Remember, interpersonal communication is mostly non-verbal. You can use emojis for expressing a point of view on a topic, create polls for the team when you need help deciding something, broadcast awareness or transparency on an issue but also make others feel included and welcome. Now someone may also wonder how many chat channels are enough for a remote team? We just need these 50 chat channels, right? Well, the answer is that you probably need much more than you may think. A synchronous remote work can benefit a lot from having more specific chat channels per topic which we can safely ignore when needed to focus on something else and come back later. Using only a few chat channels can easily make signal-to-noise ratio worse for most team members as messaging being sent in central channels like a development channel could be interesting or useful only to a few team members. So using public channels instead of private group chats can be really beneficial as transparency can be key for scaling collaboration. Always prefer using a public chat channel to make communication transparent, avoid information overlapping or duplicate work and foster collaboration and transparency within the team. This can also help make team members feel more comfortable sharing ideas or working in public. You can start by creating some common channels for a product area or a team, use naming conventions to group channels better and increase channel discoverability or even create channels for fun outside work. Sending a direct message to someone about work can be okay but it can also add some psychological pressure to the message receiver, especially if you're not familiar yet with the asynchronous style of working. What you can do is start moving these private conversations about work to public channels. When someone sends you a direct message with a question about work, feel free to answer the question in a public channel. This can help others who may also have the same question. Also, you might actually be contacting the wrong person and in case that person is unavailable, your question is blocked until they come back online. However, when sending your question in public, you could get the answer faster and also help making the benefits of posting in public more obvious to everyone. The graph you see here include the percentage of messages sending public messages at public channels versus direct messages for our team a couple of months later after bringing up the benefits of using public channels in a recent all-hands meeting. It's far from perfect but it was so good to see public messages taking over direct messages so fast. Now, there are only a few things more transformative than being kind and grateful for someone's behavior and contributions. Giving credit where credit is due make people feel more comfortable with sharing ideas, participating in discussions and more importantly, taking action. And this one can be fairly simple to practice. Just create a public thanks channel and start saying thanks. It is said that this was written on the entrance of Plattus Academy and literally means that no one who does not know geometry should not enter. However, there is an alternative meaning that is not directly related to geometry itself. This was also to remind people that when having a conversation it's important to have an analytical and inductive way of thinking, be rigorous about judgment and conclusion drawing as well as be accurate and confident about what is true and correct. I've added this here not to prevent anyone from starting new discussions, asking questions or adding their thoughts on a topic, but when you are working remotely and especially asynchronously, most of the communication consists of text messages you send or videos you record and upload for others to see later. So thinking twice before sending a message can really help improve the signal to noise ratio in a chat. You may have heard this before, but easy reading is hard writing. There are always some draft messages sitting in slug for me waiting for a second pass before sending or even discarding. Sometimes it really helps to write down something before sending and reading it twice. Also, using emojis and simple words for documenting a shared knowledge can help make the content easier to read, faster to parse and lead to action as well as be more inclusive for everyone to understand. Plus, sending small instructor messages can be really helpful. For example, have you ever received a message like this with more than 1000 words in a single paragraph in the middle of the day and thought, oh, no time to read this now. I'll add a reminder to respond later. However, what usually happens is that you get back to it much later than you would expect, delaying also any action you will take. It can be really helpful to send small and structured messages with a clear problem statement or even action items you can easily extract to or refer to without having to respond or comment on every point mentioned. So be more like Bubba on the right. And last but not least, being able to get your thoughts in a paragraph or two in a clear and actionable way can get you far than you would expect. Actions are much stronger, better and faster than intent, and it is actions that actually help accelerate the innovation of your team. Now let's move on to the workflow aspect of remote collaboration. Sometimes your team can fall into a never-ending spiral of sipping a flawless feature in a pursuit of a perfect product. This can sometimes significantly increase the implementation scope or cause you to lose track of what matters most, which is sipping value to the users as soon as possible with every iteration. If you fall into this loop, remember this code from Salvador Dali. Have no fear of perfection. You will never reach it. In other words, learn how to become a professional imperfectionist. Sipping value to users sooner than later is invaluable. This could mean that picking the most boring solution is the best way forward as this can help increase the speed of innovation of your team and product. And this leads us to MVC, which stands for minimum viable change. MVC means sipping the smallest change possible. And this is a best practice I've learned while contributing to GitLab, and you won't believe how much it can be done in the long run by simply breaking this down into smaller pieces. Smaller changes mean faster code reviews and better workflows. This means that your team can ship faster, plan better, but also revert easier. I still find it fascinating that reverting a merge request is usually the best way forward when something is broken instead of spending time for finding a fix on top of it which actually slows you down in the long run. Now getting used to MVC in your everyday workflow takes time, but once you get used to it you will also need a way to iterate in smaller steps and figure out what to do with appending discussions or technical depth that could be introduced in a merge request. And this is where follow-up issues come into the scene. When something seems blocking or requires more back and forth between the author and the reviewer most of the times opening a follow-up issue to address this in a future iteration is the best way forward. Practicing code reviews enables knowledge sharing and this is probably one of the most, if not the most important benefit of code reviews. There is so much you can learn from doing a code review or having your code reviewed besides the technical side of it. Code reviews also psychologically promote team ownership and force consistency across code base and much more. Practicing and requiring code reviews is a fundamental piece for your team's remote culture. If you need one more reason, remember this when one teaches to learn. Last but not least, I like to describe asynchronous remote collaboration as the holy grail of remote collaboration since it requires a specific way of working which can probably be new to many of us. Async means multiple time zones where you can work efficiently with a team member in different time zones without the need for both to be available at the same time. Async means flexible work hours in place where people build their work around their life not the other way around. And last but not least, async means thoughtful communication where people mindfully process information and reply in a non-real-time manner. Of course this also means getting used to the feeling of being comfortable keeping chat notifications like this staying around for a while because when everything is important nothing is important, right? Now let's bring everything together and sum this up by taking a short glimpse of what happened behind the scenes when we decided to redesign our product in a single month using an MVC approach. Although the redesign aimed to keep the same functionalities intact we knew we wanted to spend some time beforehand on product discovery to set some foundational design patterns that we could build on top later on. To do this we had to set the scene. At Gitpod we start with a shared document that helps us make decisions, share ideas and think together on the page. Documents for us include projects, RFCs, design docs and more. A couple of months before our sprint in March we spent some time writing down the context and goals of the desperate redesign including some tasks that could fit into the same iteration. Following our docs we moved forward with a process close to the double-diamond design process where we followed a similar flow for product discovery. Our designs followed this pattern for visualizing user flow steps as well as layout and component variations. Repeating horizontally allowed us to iterate and improve the designs without being attached to the previous ones. We ended up with quite a few design files with iterations like the ones you see in the screenshot before splitting the designs. Once the design patterns were strong enough to support our product design we split its product area into a separate design file so that design specifications could be accessed separately. The same also applied for issues while planning our effort of our team. We split its product area into an MVC task so that our engineers could pick up and tackle a single issue in one shot at a time. During the spring we were also using a new public search channel for aggregating all relevant communication but also improving the signal-to-noise ratio to other channels like our main development channel. So once the specs were split into smaller design files and the issues for its task were created we posted a public message that the specs were in place so that our engineers could pick up the issues for development. We also knew that we wanted to try out utility classes for this dashboard implementation so we also spent a couple of days working on a draft prototype. Being familiar with the utility classes after using this while contributing to GitLab's design system it significantly helped us perform code reviews with really fast turnaround times. To raise the awareness and educate team members about the concept of MVC months before the spring in March we did the following. We discussed the concept of MVC in an all-hands meeting. We expanded the acronym every time it was brought up in chat and we became advocates for MVC by working on smaller issues as well as congratulating people when working with MVC tasks. Naturally we had to reuse some components that gradually evolved to a list of patterns like filters, tabs and more. To support all the layouts we knew beforehand that we needed a spatial system to build upon. Along with this a color scale and type scale evolved creating a shared component library that could be reused for layout and page creation. Although the screenshot may seem a bit chaotic there is some structure behind all these elements that helps us iterate faster and better. Finally, to sum up all these I'd like to paraphrase this quote from Heraclitus to stress that the only constant is change. By the time you read this our team has probably already added new or improved existing parts of our processes and guidelines in our handbook and we are already working on adding the next features with our team. This continuous growth through small iterations is what can make you move faster in the long run. Thanks everyone for tuning in hope to see you online.