Recently I’ve started leading a small engineering team of 4.

This team was formed anew and in a remote working context and given the novelty of it, I took the occasion for rethinking some team-working approaches including the infamous remote daily.

For having a common ground, the remote daily is the transposition, in form of a video call, of the classic daily or standup.

Why remote daily sucks

Collaborative messaging systems

Dailies require people to interrupt whatever they are doing for attending a meeting to explain what they are doing.

This made a lot of sense when our workflows didn’t include collaborative messaging tools like Slack or MS Teams.

Those tools allow us to stay connected constantly to a flow of information from every corner of an organization and to asynchronously communicate with whoever just by dropping a message.

With such tools and approaches to communication, having a synchronous meeting where people should not discuss things but just report states seems quite a waste of time and concentration.

Fear of missing a meeting

In a remote organization, it’s easy to imagine that someone is not doing his part.

And because of that, it’s even easier to imagine that someone else is thinking the same about us.

The statement “you don’t have to attend a meeting if we don’t see value in it” has a different meaning depending on the hygiene of workplace culture.

Somewhere and/or for someone a meeting can be perceived as a way to report in, despite any good intention.

And this one happens every day.

Time management

People doing creative jobs know the importance of flow.

By setting a meeting not only the flow is damaged by an interruption but it requires an additional recovery time for regaining it.

One of the reasons for which dailies are usually planned at the end or the beginning of the working day is to be as close as possible to a time in which people didn’t reach flow.

But in a remote environment, the differences between individual working habits are even more enhanced, making the flow interruption even more probable.

You can have a shared agreement but that would still feel like a compromise for the sake of a meeting and not something in defense of flow.

Lost information

Remote dailies usually are not recorded and the information transmitted there stays only between the sender and the recipient and only if the headphones/microphones worked fine and the recipient was giving attention.

It could easily happen that people misunderstand or need to communicate information in different ways, having to rely on the previously mentioned messaging systems.

Additionally, only the attendants to such meetings can benefit from it, leaving whoever wasn’t able to attend in obscurity, needing further communication and creating more frustration by the need of repeating things that have been already transmitted somewhere else.

In the Tech world, a lot of importance is given to documentation of any kind, why should the daily be exempted from it?

The value of synchronizing a team

There’s value in having a synchronized team that shares visibility on what each other is doing.

Someone might be blocked on a problem that someone else can solve or that someone is working on the same thing as someone else.

As a person responsible for allowing my team to do their best job, I wanted to find a way to keep the synchronization strong without all the problems that a remote daily introduces.

Introducing Daily Journal

In the past, I had the pleasure to work with an amazing eXtreme Programming team that used to journal at the end of its working day.

We needed a way to communicate with other people other than ourselves, Slack didn’t exist back then and publishing our journal on an internal wiki worked perfectly for that purpose.

I’ve decided then to propose a similar tool to my new team in the form of a single, collaborative, Google document.

Each team member fills their entry at the beginning of each day by answering the following questions:

• What did I do yesterday?
• Am I blocked with anything?
• What will I do today?

The advantages of such an approach became quickly evident:

Recording history

Having a single, searchable document allows recalling of what happened on any day, simplifies radically the “recovery time” after a holiday or a sick leave and prevents losing information.

Not being blended with a chat simplifies this mechanism without any real cost.

Ordering ideas

Journaling is an excellent way for ordering ideas and the daily journal helps the writer and the reader as well.

No need for “a quiet place”

The daily journal doesn’t require interrupting whatever one is doing or changing wherever one is working from for connecting in a meeting.

It helps to keep the flow, which is an important thing that a team lead should defend.

Allows more detailed information

By having a document dedicated to collecting daily insights, it can be also a space for triggering conversations on other channels and for sharing information.

Also, hyperlinks are pretty neat.

Transparent

Being a shareable document means that whoever is interested in the state of the things of a team can simply open it at any moment and read the evolution of the work.

Our stakeholders weren’t ever interested to such a degree in our internalities, but if necessary, the document is public and reachable from our channels.

Our experience and conclusions

Since the very first days of adoption, the team preferred the daily journal a lot over the remote daily.

It helped us in quickly onboard our first new team member because it served additionally as a tool for transmitting our team working culture.

To those who might think that avoiding having a daily meeting face-to-face might yield to team alienation, I can suggest focusing on different tools for keeping people connected other than a meeting conceived with the goal of status synchronization.

In our case we have a private chat for developers only where everyone is free to write whatever might cross their mind, it’s a nice way to vent out and keeps the team cohesive.

If you are responsible for defining an engineering team process or simply a member, I’d invite you to give it a chance for some time and see how it works.