|
Hello! Welcome to Lyncredible's digest for the week.
Here are the blog posts I wrote this week.
A list of just the links:
And the full content of all the posts, if you want to
read everything in this email.
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.
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 the meeting. Some people would use 10 seconds, while others would spend 2 minutes. This applies 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.
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:
- To provide status updates among team members for collaboration opportunities;
- To provide status updates to the EM who would then represent the team in roll-up communications;
- 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:
- 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.
- 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.
- 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 are limited to a summary of five bullet points per person. People are encouraged to link texts to artifacts, including project briefs, pull requests, tickets and emails.
- They can optionally fill in discussion items. The team will go over them in order, and there is 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 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 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.
I am an introvert. As much as I enjoy talking to and learning from people, it only takes a couple of back-to-back meetings to completely drain my mental energy. My first few weeks were hectic. I was exhausted all the time. I showed up late to every meeting, and skipping bathroom runs didn’t help. Thanks to my then manager Brian Delahunty, I was able to leverage speedy meetings to save my sanity.
I was warned
I knew being an engineering manager meant lots of meetings. I did not think it would be a big problem though. I enjoyed going to meetings as an engineer, and happily facilitated many meetings in the past. I also learned some useful tricks from my peers, like creating Do-Not-Schedule blocks, and reserving time for commuting and lunches. I felt prepared, yet I was completely devastated merely after a month.
Until I went to my manager and vented my frustrations.
The 1:1 with Brian
Here is my rough recollection of how the 1:1 went:
Yuan: I am getting exhausted by all the meetings. It feels like I cannot keep up.
Brian: That is understandable. What makes you feel like that? It is not like you are new to the team or the projects.
Yuan: It is a really good question. (Pause). I think it is because I don’t have breaks between meetings. That creates two problems for me. For one, there are lots of Slack pings and emails to respond to. I cannot wait until the end of day to do that. But I lose track of what is happening in the meeting as soon as I split my attention to those. For two, even if there are no distractions, I don’t have time to prepare for the next meeting. I don’t even have time to run to the bathroom!
Brian: Have you tried speedy meetings?
Yuan: Most of my meetings are already speedy meetings, but they run over every time. I thought speedy meetings were meant to reserve buffer time for potential overruns that always happen?
Brian: That is a misconception. Let’s say you hold true to speedy meetings. Would it solve your problems?
Yuan: I think so. I would have time to make bathroom runs and to prepare for upcoming meetings. I don’t think there would be enough time for me to meaningfully reply to Slack or emails, but at least I would know what is going on without distractions. I can even quickly say something like “I will get back to you by 3pm today”.
Brian: Excellent. Now would you commit to running truly speedy meetings next week?
Yuan: Yes.
Brian: How do you plan to do it?
Yuan: I will start with 1:1 meetings with my team, my peers and you. I will tell everyone about speedy meetings at the beginning of the next 1:1 meeting with each of them. I will make sure to end the meetings 5 minutes before the half or 10 minutes before the whole hour. I will use the time to catch up on Slack / emails, and to prepare for the next meeting.
Brian: Sounds good. Tell me how it goes next week.
Rolling it out
I followed what I committed to in the roll out of speedy meetings. The most pleasant surprise was that everyone was super onboard with the idea, and each one of them watched the clock for me. By taking 5- or 10-minute breaks throughout the day, which I had been doing all the time in my school years, I took control of my time and my sanity again.
|
