Replacing standups

After transitioning to an Engineering Manager, the first change I made was to replace our daily standup meeting with weekly sprint checkin meeting. To set the record straight, I do not hate standup meetings. I even pitched our team to have standups a year prior while I was still an engineer. Nevertheless, I am oblivious to standups. Meetings, in my opinion, are a means to an end. So I set out on an incredible journey to make sense of standups and to do away with them.¹¹ I was much more confident in replacing standups after asking myself what could go wrong.

The standup we loved

I joined the team as the third engineer. Each one of the three of us had a different project. I, as the newest engineer, understood little of what my teammates were working on. We ran two-week sprints, didn’t have standups, and met once every two weeks in a combined sprint retrospective and planning meeting.

I felt like I was lacking a lot of context. I would love to know what was going on outside of my immediate project, but there did not appear to be a proper place to satisfy my curiosity. I would gently ask my peers what they were working on in the first week, but I was too shy to repeat that question every week if not every day.

I also needed help with my own project. I generally pride myself on my ability to self-teach, but, as Confucius put it, I find my teacher walking among three people. The problem was not whether, but when and how, to ask my questions. Each one of us seemed fixated on our screen all the time, and I learned to time my interruptions with subtle body movements. Slack was another way, but the async nature was less than ideal.

That was why I pitched standup meetings. We did not have to literally stand up. All we had to do was to turn around, look at each other, gloss over project updates, and ask/answer quick questions. Anything that requires longer discussion and/or research would effectively end the meeting. All three of us were morning people, so we would meet for 5 minutes at 9am to begin the day. There were only three of us, which made it super efficient. We unanimously decided to meet on Monday, Wednesday and Friday mornings, and that became the happy cadence for us.

The standup we hated

By the time I transitioned to an EM a year later, the same standup meeting became at best controversial. The team had grown to nine engineers and split. It was very difficult to run the standup for nine people, but it did not get too much better with the five of us after the split.

To start with, there did not seem to be a good time slot to have the standup meeting. Some people were simply not available at 9, while 10 o’clock was the most productive hour for others. 11:45 emerged as the favorite since it precedes the lunch break. Nevertheless, one person on the team did not like going to the cafe at 12. Moreover, we could no longer turn our chairs to meet. It required a full-size meeting room with Zoom setup to support remotes.

That was only the tiniest problem. An even bigger one lies in the content of the meeting. It was not clear what level of details we should go into during the meeting. Some people would use 10 seconds, while others would spend 2 minutes. This applied to questions as well. People did not know whether it was appropriate to ask questions during the meeting, nor did the persons being asked know whether it was better to give answers async. To make matters worse, the meeting often degraded to a 1:1 when someone asked a question, as the topic might not be particular interesting to other people.

The most severe problem, according to my own observation, was that people spent first few minutes of the meeting preparing their tiny speeches in their heads before their turns. That was quite an intensive mental burden. If you went first, you would relax and maybe temporarily check out. If you went last, you would be too busy thinking to pay attention to other people.

Some changes were due.

Understanding why standups failed us

In searching of a new solution, I started by writing down the goals we would like to accomplish with the standup:

1. To provide status updates among team members for collaboration opportunities;
2. To provide status updates to the EM who would then represent the team in roll-up communications;
3. To seek help if there were any impediments.

I then discussed with my team individually in 1:1s over the next week. It became apparent to the entire team that the existing standup meeting was not fulfilling its promise at all:

1. Team members were too busy thinking of their own speeches. As a result, they were not able to catch up on status updates from other people. Even when they did listen, chances were they lacked necessary context to fully comprehend.
2. I, the engineering manager, was not able to memorize everything said in the meeting. I found myself reaching out to people afterwards to confirm or correct my recollection all the time.
3. Since we had standups every other day, it was too infrequent for any impediments to wait that long. People usually resolved them via in-person discussions or Slack chats.

Look, people found their own ways to solve the third problem, and we suffered with the first two goals. Increasing the frequency of the standups would obviously not move the needle at all.

Designing the sprint checkin meeting

The first two goals and their pitfalls share a common core. Status updates are dense information, and they present an immense challenge to people’s attention spans. As the proverb goes, the faintest ink is better than the best memory. The most important feature of my next solution would be the ability to persist status updates. What better tools did I have other than the Google Docs? The collaborative authoring and reading experience was the perfect fit for the sprint checkin meeting:

• Every Friday morning, all team members would write down their status updates in the same living Google Doc.
  • Updates were limited to a summary of five bullet points per person. People were encouraged to link texts to artifacts, including project briefs, pull requests, tickets and emails.
  • They could optionally fill in discussion items. The team would go over them in order, but there was no guarantee that we could cover all.
  • An optional “free” meeting block was reserved at 10am each Friday for people to put in their updates, but they were also welcome to do it at any other time prior to the meeting.
• At 10:30am on Fridays, the team would meet to read and discuss the updates.
  • We would dial into a Zoom meeting, but no one should be presenting by default. Team members would take turns to facilitate the meeting.
  • The first 15 minutes were reserved to read the updates, to share praises, and to ask clarifying questions. The remaining 15 minutes²² The sprint checkin meeting is the sole non-speedy meeting on my team. were meant for optional discussion items.
  • As the meeting went, the facilitator would update Action Items, which captured things to follow up after the meeting.

We tried this out, and it was overwhelmingly better than the standups:

• People were finally able to decouple the mental workload of producing and consuming content.
• The summary with linked artifacts allowed team members with little context to get up-to-speed. Everyone had a different level of understanding for every project, and they could do the reading async. That enabled the team to use precious in-person time for topics that are interesting to all parties.
• The engineering manager was able to reuse much of the updates for weekly roll-up communications with confidence.
• A bonus was recognized when it came to performance review season, as everyone was able to look back over their weekly updates to create performance reviews.

Closing thoughts

Meetings are a means to an end. Daily standups are more so. I am immensely happy that I replaced them with sprint checkin meetings, no matter how daunting the task appeared to be for a rookie manager.