In a remote-first company, most of the communication and collaboration happens asynchronously. Software engineering retrospectives is one of the cases where you can leverage synchronous meetings as it gives the best chance for the teams to come together and learn from the past within a structured meeting.
In the book Making work visible, Dominica DeGrandis exposes time-wasting activities at work and demonstrates how you can achieve flow efficiency by making work visible. Optimizing workstream management for effectiveness and efficiency is always something I think about. I’ve used many tools in the past to plan and track workstreams, and recently had a happy realization that GitHub Projects developed enough to call my number one and only tool for making work visible. I thought to apply some of the learnings from the aforementioned book and leverage GitHub Projects to make work visible. For the sake of measuring and improving, I’ve used Grafana to visualize few aggregates from the GitHub Project by using Grafana GitHub datasource.
Going through a change is a fundamentally complex process for humans. Often change introduces uncertainty, whereas our brain prefers and wants predictability. Speaking from my own experience, even when the impact of a change is completely under control and consequences known - my first reaction is to resist the change with all the power I got. In the context of organization (for simplicity, I’d use organization as a term to describe a collective of people working together), the impact range of a change is even bigger, and often beyond any individual’s control.
In my previous post I have talked about how we do collaborative programming in a remote-first environment in our team at Grafana Labs. Since we practice Continuous integration, the code changes get merged to the main branch several times a day, and part of the process is a mandatory code review. Most of the code reviews happen asynchronously, with the help of GitHub pull requests. Recently we have started to practice synchronous collaborative code reviews in our team and this post talks about some of the advantages that we are observing while experimenting with the process.
Grafana Labs is a remote-first company. We hire and work with people from all over the world. The team I am in is a 10 person team is distributed across 5 countries (you can read more about our team here. Sometimes we leverage benefits of synchronous communication and collaboration, however as an all-remote company, most of the work happens asynchronously. Recently we started experimenting with synchronous collaborative programming and I was putting together a guide for our team to use as a reference and I thought of turning it into a blog post.