The daily standup as a crutch
When I first started at GitLab in November 2016, I wanted a synced daily standup over a video call. Just like any other new product manager, I was eager to get to know the team quickly, and kick off a close collaborative relationship with every engineer and designer. I thought that the daily standup was perfect to regularly get face time to establish rapport. I soon realized, however, that no such culture existed at all in the company, and there was resistance to start such a ceremony. I was disappointed that I couldn’t bring my supposedly great product management skills to bear in that setting.
Fast forward two years plus, I now know that at the time, and in previous product manager roles in co-located teams, I was relying on the daily standup as a crutch to collect status and be re-assured that the team was hard at work. I didn’t trust the team. The daily standup wasn’t an opportunity for unblocking problems and fostering collaboration more broadly, which as a concept it was intended to be. It had devolved into micromanagement.
Pushing and pulling
The daily standup, as original designed, is a tool to help teams collaborate. Being invented in a time of co-located teams, people were limited to physical spaces and a common work day. (Notice that I said that co-located teams are limited. That’s a theme in these articles. Remote teams are actually less constrained than co-located teams, not the reverse!) So it made sense that the daily standup was indeed daily, to promote frequent and regular collaboration in a setting that was built on synced communication.
But with remote teams and remote work in general, async communications should be the norm for the majority of interactions. And so it follows that collaboration should also be as async in possible. In practice, this means your team should follow a push-pull model. You should be frequently providing status of your work, pre-empting anybody asking it from you later on. You could hard push this information by pinging people directly in instant messaging. But a soft push of updating a single source of truth work artifact (such as a user story in an issue tracker or a pull request in a source control tool) is even better since teammates who care, can configure their notifications accordingly to receive that information automatically. And as the pusher you can avoid unnecessarily adding more noise if you are unsure of the intended audience. On the other side, you should be pulling information as needed. Soft pulls are ideal for on-demand self-service status updates. You can just review the changes of single source of truth work artifacts to get the latest information, without disturbing anyone else. You are unblocked immediately because you don’t have to wait for a response. A hard pull for information means actively pinging somebody for status (because you can’t find it from a soft pull). You should work together with your teammate to write down the acquired information afterward to make future soft pulls of the same information possible. Lastly, another type of hard pull is simply requesting for active collaboration. The request itself should be async (even if the actual planned collaboration work will be synced). Don’t wait until the next scheduled meeting to ask someone for input. Just do it right now in a work artifact or in an instant messaging tool.
Note that the push-pull model does require teams to be writing down as much as possible, and doing it at a high quality, to really reap the benefits. For remote teams, it’s a bit easier because you are writing much of the day anyways, so you tend to develop it as a skill over time.
This simple push-pull model means that you can operate much more efficiently in a team. You don’t have to wait up to 24 hours before the next collaboration opportunity. Yes, in a co-located team you technically don’t have to wait if everyone is already there in the same office. But I’ve personally experienced many cultures where “we might as well wait until the next weekly meeting” before bringing up a topic. Or “let me gather a list of asks and I can share them with you at our meeting next time”. In co-located teams, it’s very easy to tend towards waiting. In remote teams, if you are already communicating async, push-pull becomes second nature.
Efficiency doesn’t necessarily mean fast or frenetic, and that’s good. The push-pull model actually scales to your team’s need in this regard. If you need to do deep work and focus on a small number of tasks over an extended period of time, push-pull serves that well, since everyone can spend most of their time doing individual work or collaborating, whatever the case may be. If you still continue with synced daily standups or any other regularly scheduled status meeting, it actually becomes a waste of time, because you just don’t need those meetings if there’s nothing to update.
Regularly scheduled synced meetings are not inherently bad. But just be cautious that they serve an intentional purpose. If they become a crutch that slows you down or reduces collaboration, then it should be removed. For example, in my current product-development team (engineers and designers), we only have one regularly scheduled weekly meeting. There are no pre-determined agenda items. Folks are encouraged to add topics if they want a larger and more generic audience. The topics are typically more informational and broad. If team members need to collaborate on a specific feature, they just use the push-pull model, possibly setting up synced video call sessions as needed. They do not wait for the weekly meeting. And as such, sometimes the weekly meeting ends early or is even just canceled if there are no topics added that week.
As a rule of thumb, the synced daily standup shouldn’t be necessary. I’ve observed many teams in different organizations use async standup tools in instant messaging. I think these are great because it precisely fits inside the push-pull model.
Ownership through accountability and responsibility
Ultimately, this model of collaboration requires people to be owners of their work. Owners are very good at taking initiative, and optimizing for the benefit of the entire team, and the common outcome desired (which is typically a business objective such as delivering customer value by shipping a great product). Remote work and the push-pull model in particular, fail spectacularly if your team members are passive order takers. So as with many aspects of remote work, it’s a forcing function for you to do better. And in this case, it is to hire better people and continuously develop them to be better owners. In particular, ownership means team members should be empowered to make decisions and communicate them broadly, being accountable and responsible for their results.
As a remote work product manager, avoid synced daily standups.