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.

I was going over the books that I managed to read in 2021 and realized that this year was a bit special compared to my experience in the past years. This year, I was very quick to put away books that I picked up but did not enjoy reading, or did not find valuable for the given point of time. This gave me a chance to reflect a bit on my past readings and I thought to compile a short list of all time favorites.

Manager READMEs are a good way to introduce yourself as an Engineering Manager (EM). When I transitioned into Engineering Management, I created one for me and just writing things down helped a lot to reflect on my career and learn more about myself.

EM responsibilities vary between companies, or even might be different between teams within a company, so my README is always changing. I do my best to reflect and update it at least every month. While the change is always in progress, there are few things which change very rarely, particularly my values and beliefs, and this is the part I thought to share in this post.