content/posts/2023-07-28-remote-journal-after-year.md: adding post

content/posts/2023-07-27-team-work.md → content/posts/2023-07-27-why-remote-daily-awful.md

@@ -6,7 +6,7 @@ categories: work
 ---
 
 One interesting article about daily meetings from [Marco "Efesto" Polita](https://github.com/Efesto).
-Here it's just copy-pasted article about his thoughts, which I found very interesting for mysefl.
+Here it's just copy-pasted article about his thoughts, which I found very interesting for myself.
 
 ---
 

content/posts/2023-07-28-remote-journal-after-year.md

@@ -0,0 +1,143 @@
+---
+layout: post
+title:  "Remote journal - A year after"
+date:   2023-07-28 09:00:00 +0800
+categories: work
+---
+
+One interesting article about experience with replacing daily meetings to daily journals from [Marco "Efesto" Polita](https://github.com/Efesto).
+Here it's just copy-pasted article about his thoughts, which I found very interesting for myself.
+
+---
+
+## How do you keep people connected if they don't see each other at the daily?
+
+This concern was present also at the introduction of the journal and is not related specifically to removing the remote daily itself but rather to the whole remote working approach.
+
+I think creating connections between the members of a team is a task that every team-lead should take, "team spirit" is an abstract concept but very much present and relevant to building an effective team, and is about connecting humans.
+
+For that reason, we introduced the developers-only chat and a recurrent "co-working call".
+
+The first, as suggested in the original post, worked amazingly not only as a place to communicate with the rest of the team but also as a safe space for expressing "humanity", the element that some value so much in the remote daily.
+
+The second can be resumed with "a daily, optional meeting that takes place every morning for the whole morning and where everyone is invited".
+
+### ☎️ Co-working call
+
+The original idea was to have a virtual equivalent of "the water cooler" or "coffee machine" where people could feel free to spontaneously meet and connect.
+
+The call is most of the time empty but is still the place where we can informally discuss between us and handle anything that should be handled synchronously.
+
+I think it partly achieved its goal of being a spontaneous space because often discussions there involve the culture behind decisions and "humanity", not having a definite time also helped in keeping things spontaneous.
+
+### 🙌 Working together as engineers: pair and mob programming
+
+Together with team chat and co-working calls, we also tried to adopt regular occasions for doing pair or mob programming.
+
+We miserably failed in being regular and the times we managed were too rare for helping build a team spirit.
+
+On the topic of pair programming remotely I'm still conflicted and maybe I'll write about it in the future.
+
+### 💻 Working remotely 🌴
+
+So after one year of experiments, my conclusion is that, by working remotely, you can build a "good enough" team spirit but it will never replace the full "in the office" experience.
+
+In a remote environment is better to organize, if possible on place, funny, people-oriented events and to rely on synchronous meetings only when necessary than keeping synchronous meetings hoping for people to connect at any cost.
+
+## How do people reach out to each other if they need help?
+
+> __The journal for us worked well to ask for help because a request is always visible, black on white (or white on black for those with a dark theme).__
+
+It makes it more difficult to avoid it and even if other distractions take over during the day, the journal is there to remind you that someone needs support.
+
+Having a daily update in the journal proved to be frequent enough to not let people be frustrated with requests that stay pending for days.
+
+And of course, if one needs help ASAP, the chat is always there and no one played the ghost in it.
+
+In addition to having continuous communication, the remote journal helps in those cases in which one is blocked without knowing it, I call it the "hidden blocker".
+
+### 🥷 The hidden blocker
+
+Engineers are proud creatures, and sometimes they are not even aware when they are blocked by a hidden blocker.
+
+> __Typically a hidden blocker is when someone is approaching a solution from an overly complex direction, because of inexperience with that specific problem or with the system or something else altogether.__
+
+Having the journal for wrapping up one's thoughts and additionally sharing them with others, like with a rubber duck, exposes the hidden blocker and allows others to tackle it.
+
+This helps keep the work smooth and reduces massively the frustration, especially for newly onboarded members.
+
+### 📢 "One talks and the others listen"
+
+I've been told that in the dailies, there's the good point of "one talks and the others listen" that makes it easier to call for help.
+
+I don't believe in that, but even if so, after my experience, I'd add "...but with the remote journal, one writes and the others read. And they can't miss the message"
+
+## Do you need a reminder for compiling the journal?
+
+It was a concern at the beginning, and I had set up an automatic reminder at the beginning of the day asking to compile the journal.
+
+With time, I've started appreciating the journal as the first thing to do in my working day, it helped to order my ideas and to wrap up, with a fresh mind, what I did the time before.
+
+> __It became a positive, solid habit and I like to think that it was the same also with my mates and because of that, we didn't need any reminders for doing it.__
+
+## How do you encourage people to read journal?
+
+This also revealed to be a non-problem for my team.
+
+My mates and I, more them than me in all honesty, are always aligned on what happens within the team and especially on what is in the journal. In my experience, team awareness is even stronger than with a face-to-face daily.
+
+The explanation I give to this is that the journal, with its persistence, can be kept in a browser tab to be consulted from time to time during the working day.
+
+Also, sometimes the information in it is useful for aspects of work that have to be executed in the day.
+
+> __It's a simple and useful tool, and because of that we use it without any need of "encouragement"__
+
+## The remote journal is another step in the direction of working asynchronously, without meetings. When do you think instead makes sense to have meetings?
+
+First of all, I think should be important to address how to have meaningful meetings and Gitlab does an excellent job [with its handbook](https://about.gitlab.com/company/culture/all-remote/meetings/).
+
+But besides how to have effective synchronous meetings in an asynchronous organization, I think deciding if something should be synchronous or asynchronous is more an art than a scientific decision.
+
+> __In my experience, a synchronous meeting pays more than asynchronous communication when is necessary a lot of back and forth between parties or when the human factor is more important than the practical factor. Retrospectives and 1:1s are examples of it.__
+
+However, I think the journal could be a good starting point for building awareness that synchronous meetings are not unavoidable.
+
+## Unexpected pros
+
+In addition to what I was expecting before starting the remote journal experiment, other positive effects popped out:
+
+### 📖 Code review efficiency
+
+As I've said before, having written in the journal that something is ready for review, in addition to the agile board, helps remind the team as a whole that something requires their attention.
+
+I have witnessed as an engineer in my team that code reviews rarely hang there for "too long".
+
+In support of that, Meta has an [interesting approach](https://engineering.fb.com/2022/11/16/culture/meta-code-review-time-improving/) of "poking" engineers for code review and I think the journal fits in the same approach as a softer, easier-to-implement version of it.
+
+### 🪟 Transparency
+
+> __I've been asked recently to invite additional managers to our dailies, as other teams do, and as answer, I've just forwarded a simple link to our journal (and handbook, but this is another story).__
+
+Having a journal indirectly brings transparency and lets the team talk for itself.
+
+There's no need to invite anyone to anything or explain how the team works because is everything written there: the feelings of the team, the way of working, the blockers and the progress; everything is perceivable from the journal and can be backtracked.
+
+Additionally, we can support an indefinite number of additional observers without the need of disrupting our processes with "guests".
+
+## Conclusions
+
+Since we adopted the remote journal we haven't looked back to the daily and there's no intention to.
+
+As I've invited in the last post, the best way to know if it's the right tool is to try it.
+
+If you fancy an exchange of opinions or knowing more about it, feel free to reach out to me.
+
+---
+
+That's all.
+
+## Additional links
+
+1. [Marco "Efesto" Polita](https://github.com/Efesto)
+2. [flow](https://www.psychologytoday.com/us/basics/flow)
+3. [Medium - Why Every Developer Should Keep a Daily Code Journal](https://blog.developerpurpose.com/why-every-developer-should-keep-a-daily-code-journal-fb83ab848c6)