In many companies, the performance review season for the second half of the year has started. Performance reviews often bring stress, anxiety, and uncertainty. However, performance reviews also offer opportunities for growth, self-improvement, and a clearer path to success. For software engineers, the definition of “good performance” varies depending on factors such as company culture, business and personal objectives, role expectations, and attitude toward work. Many of these factors have a qualitative nature, which can be difficult to objectively measure, leading to friction.

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.