(no title)
senzilla | 3 years ago
We do meandering sync calls[1] for 1 hour, four times a week. Plus a weekly demo call.
It's a matter of how much your management cares about developer experience and efficiency. Get another job :)
[1]: https://www.honeycomb.io/blog/standup-meetings-are-dead/
imiric|3 years ago
Whatever works for your team and company, but this sounds excruciatingly inefficient and disruptive. This means that your entire team is interrupted for at least an hour every day, to be part of a meeting that may or may not be productive.
IMO meetings should be anything but meandering. They should have a clear agenda, a strict start and end time, and everyone should be clear on what the outcome was and what was agreed.
Addressing some of the points of the article you linked:
> No one reads async stand-ups.
> If you dig into the “everything async” world you will find the teams that do it best are actually lying.
That might be your experience, but is not objectively true. In my company we use Geekbot, and while I can't speak for everyone, most people do read the async updates.
Let's keep in mind what standups are: quick meetings (15m tops; that's why they're done standing up), where the team can synchronize on work in progress, and address any blocking issues. If there are no blockers for my team members, do I really need to know what they're working on? That should be obvious from regular communication over Slack or GitHub.
So the whole concept of daily meetings, even quick ones, is not strictly necessary. Extending this to an hour daily, and repurposing it for general banter or other regular meetings, seems very unstructured and chaotic.
> Creating a daily social space for the team builds trust and compassion. We get to learn about each other’s hobbies, interests, and lives outside of work.
Ah, so you're using these meetings for social activities. Personally, I don't think knowing my coworkers on a personal level is required to have a professional and cordial relationship. Everyone is different, and I appreciate that others do need that sense of connection, but I wouldn't enjoy forced social activities. At my company we do optional one on one and group sessions specifically for banter and getting to know each other. These can be fun, but the good thing is that they're entirely optional, and are scheduled precisely for this one purpose.
In addition to this, there can be game sessions and, preferably, physical meetups that can serve to create this personal connection, but again, I don't think any of it is strictly necessary to work with someone. There are completely distributed teams that have never met in person, that have established sufficient rapport and trust between them to do great collaborative work. "Teams will always work better when they know one another" is objectively wrong.
The entire concept of forced social activities is reminiscent of large corporate environments where management thinks team building exercises are what makes teams do great work. This always felt cringy, fake and ultimately didn't result in anything. Trust is built naturally by working with someone; not by being forced to learn about their personal lives. The fact our working environments have shifted to being mostly online doesn't change that fact.
> Finally, it actually reduces meetings and interruptions for the team. When we have a team retro, we do it during the sync. Weekly, monthly, quarterly planning—it all happens during the sync.
Frankly, this sounds awful. This means that people are never sure what the purpose of the meeting is and how long it will last. Doing these daily would absolutely interrupt any activity that requires long periods of concentration, such as programming. I would much prefer to have days without any meetings at all, and have scheduled meetings for a specific purpose.
Also, you have quarterly, monthly and weekly planning meetings? That sounds overly excessive.
But again, if all this somehow works for you, then by all means, keep at it. But most of these would be deal breakers for me to work in such an environment, and you shouldn't present this advice as something that will work for all teams and companies.