Kill your stand-up
How to redesign your meetings if your team is falling asleep
For a while, this is how stand-ups were for the engineering team at TimeSaved:
- People are bored
- The updates sound the same every time
- You can’t remember why you do it
- It feels like a chore
Why were we even having stand-ups?
Stand-ups are so baked into modern engineering culture that we never really considered an alternative. We had been in teams that did it, and when I joined TimeSaved the team was already in the habit. It stayed that way for months, until one day we got particularly tired of hearing some variation of “Today I’ll be debugging a bug” and decided to question the meeting structure. It was getting too repetitive, not very informative, and it sucked for the late-night programmers 🦉 to have a 10 AM meeting every single day of the week.
We applied the same problem-solving process we use when building products to come up with something better for us.
How to design your meetings
First, we broke down the reasons that we like stand-ups. For most teams, it goes something like this:
- We need to stay in touch with each other. Especially now that we all work remotely, we’d feel lost without it
- How else can I know what my team is working on?
- We need it to unblock people
- It kickstarts our day
- It motivates people to have progress to show every day
Now, that looks like a good set of reasons to have a stand-up, so let’s figure out how we can achieve those goals without the downsides of boring, repetitive stand-ups.
Staying in Touch
We refocused on pair programming and code reviews, and added new meetings like Show-n-Tell and Friday Happy Hour. We try to work in a mixture of meetings to bring about discussion and alignment, productive sessions to get stuff done, and fun times to hang out together. It’s been way more fun for the team and gives us a variety of ways to connect.
Staying Aware and Informed
Although we don’t work asynchronously, we have a strong culture of documenting our work. We use Notion as our “team brain” — where we keep all our research, project docs, task trackers, notes, and documentation.
Since Notion is where the permanent record lives, Slack is freed to be more ephemeral. It’s not meant to hold information for the long term so we don’t have to deal with the hassle of sifting and filtering through thousands of messages to get specific info or assets. To structure the firehose of messages generated by real-time chat, we keep our channels organized into groups like so:
Whenever we have an important meeting on Zoom, we record it and share the link after so anyone who missed it can watch it. Even better, we usually also share a few bullet point notes so you don’t have to watch a full recording to get the gist of what was covered.
Unblocking
One of a traditional stand-up meeting’s main objectives is to unblock people as soon as possible. Surprisingly though, we found that we were getting more blocked using the stand-up format because people tend to wait until our next stand-up to raise an issue, rather than alert the right people right away.
We had to dig deeper to see what the patterns were behind when blockers arose and how we usually solve them.
Sometimes, a blocker could have been easily prevented by better project management or design. When use cases and edge cases are not clearly defined and scoped, the project devolves into a constant back-and-forth of “Hey, what should happen if the user deletes this then edits that?” followed by an ensuing scramble to figure it out.
At other times, the blockers are perfectly natural and unavoidable, so then it just becomes a matter of lining up parallel streams of work so we can still be productive even when one stream is blocked. Of course, context-switching becomes more and more of a cost with every stream you take on, so we have to continually fine-tune that balance.
Lastly, we had to empower engineers to communicate directly to each other rather than playing telephone through a PM. For that to be possible, we put in a little organizational work to make it extra clear who was responsible for each project, who was most familiar with each feature/section of the codebase, and how much spare capacity each person has at any moment. That way, engineers can more seamlessly work together to accomplish their respective projects without so much management overhead.
Put together, this decentralized, real-time, organic approach has yielded huge benefits to our ability as a team to maintain productivity, get things done on time, and avoid blockers as much as possible.
Kick-start the day
This is the bad news – there aren’t really many great ways I know of to replace this great team-uniting aspect of daily stand-ups. If you really value that as a team, that might be enough of a reason to do stand-ups for you.
For us, we asked ourselves how often we wanted to do certain kind of meetings and ended up with “no stand-ups.” We still had our company-wide syncs Monday and Thursday at 10am, and we added Show-n-Tell on Friday at 11am (so we can sleep in if we want to).
One idea that Sean van Wyk recently floated is adding a “Coffee Kickstart” meeting on Wednesdays — quick Zoom chat to start the day, attendance optional. It keeps the fast pace and team-bonding aspects of stand-ups, but makes it a purely social time for the team. We just tried it today and it was really fun! It’s likely going to be our new Wednesday morning tradition.
Have Progress to Show Every Day
This is really just a bad manager’s fear, because they’re worried people will slack off if they don’t have to answer “What Did I Do Yesterday?” and “What Will I Do Today” every day at 10am, religiously.
It perpetuates a belief in extrinsic motivation, that you’ll be motivated by being put under pressure or by competing with your colleagues.
I believe in freeing people to find their intrinsic motivation. If someone isn’t finding it, you can coach them towards it, or at some point, make the decision that they’re not right for your team. If you and your team value that highly enough, you can fit your hiring process to screen out people who haven’t developed their sense of intrinsic motivation.
I was nearing completion of this article, and then Nathan, our new Director of Engineering, replied to a discussion in Slack about a communication problem some team members were feeling with a suggestion to use standups.
His comments kicked off a new round of great discussion that gave newer team members a voice and all of us a chance to reevaluate the challenges we face with the larger team we’ve grown into.
What are our communication problems these days? Are they situational, or is there a deeper underlying issue? Should we try stand-ups again? What else should we consider adding/removing/changing?
The recent discussion ended up reinforcing our earlier learnings: we’ve got a lot of different ways to design our team communication, and we’ll keep tinkering and adapting to solve any problems that come up. There are some times like when we’re nearing the release date on a project that we’d consider doing stand-ups in smaller teams, but we don’t want to commit the entire team to a daily stand-up forever.
A stand-up is a tool that was designed to solve specific problems around alignment and efficiency, but often it’s treated like the holy grail of engineering management even when it isn’t working. With a little creativity and work, you can also find a way to solve your team’s communication needs and problems in a way that doesn’t tend towards repetitiveness.
Need some help figuring out your team communication? Just leave a comment and I’ll do my best to play advice columnist.
– AK
