Zoom Is Not the Problem – Our Meeting-Centric Workflow Is(blog.nuclino.com)
blog.nuclino.com
Zoom Is Not the Problem – Our Meeting-Centric Workflow Is
https://blog.nuclino.com/zoom-is-not-the-problem-our-meeting-centric-workflow-is
52 comments
"Meetings are not the problem, but our NUCLINO (tm)-centric workflow is" - People in 2029 after NUCLINO (tm) has raised $50 billion
Sounds like a huge SAP project I was involved in. Went from being "SAP is the solution" to "SAP is the problem" in less than 3 years.
You are not being too cynical. I think just yesterday there was a post about some person complaining about Google Analytics and it was a pitch for their product.
Yep, that post was likely why just seeing the title of this one made me suspect it was a stealth-pitch.
The meeting I find the biggest time waster is the "what I did yesterday, what am I doing today" meetings. Nothing better than sitting on a 45 minutes call while 15 people try to justify their existence to the pm on the fly.
I find a slack channel called #status-updates works wonders. It persists, it's much faster to consume, it's searchable, and you don't have to read it if you don't need to.
I find a slack channel called #status-updates works wonders. It persists, it's much faster to consume, it's searchable, and you don't have to read it if you don't need to.
We do daily status meetings and they are often productive. The thing is, if it's a daily meeting, it should last no more than 5-15 minutes. Also, sounds like you have too many people on the call.
Even 10 minute meeting is disruptive. Usually they are in the morning when most people are at their most productive and it takes you out of the flow. Even a 5-10 minute meeting will destroy 30 minutes of productivity from context switching.
Ultimately it's about maximizing the productivity of the team or engineering organization at large more than it is about optimizing the productivity of a single developer. This often means that it's worth creating a mild disruption for individuals if it prevents the team from falling into a dis-coordinated state that can take days or weeks to recover from.
What is being communicated that's saving the dev teams weeks of time?
I get it and to a large extent, I agree, but it's not a random phone call or interruption, it's a scheduled meeting, which is easy enough to work around.
Interruptions are frustrating (don't get me started on phone calls), but when you are working on a project collaboratively, touching bases and knowing what other people on your team is doing is important.
Interruptions are frustrating (don't get me started on phone calls), but when you are working on a project collaboratively, touching bases and knowing what other people on your team is doing is important.
I'm not against collaboration or communication. On the contrary I think it's critical to well functioning and productive teams.
I just think stand ups as I've experienced over 10 teams and 5 organizations haven't been especially useful. They have been a status update mostly for the pm and a little for the tech lead.
What is an example of helpful information you guys are sharing in your stand ups?
I just think stand ups as I've experienced over 10 teams and 5 organizations haven't been especially useful. They have been a status update mostly for the pm and a little for the tech lead.
What is an example of helpful information you guys are sharing in your stand ups?
At my current job, It's where pretty much all information about our project gets disseminated so without it, we'd be feeling around blind. Any priority changes; changes which might not be well defined in the wires or stories; deadlines; information about meetings with the clients. It's also the place where the dev team, design, and QA touch base so if an issue comes up where there are pieces missing in the wires or QA is struggling to test something, we can quickly bring it up.
A big chunk is actually most useful for the PM, but often enough other issues get addressed that our short status meetings don't bother me.
A big chunk is actually most useful for the PM, but often enough other issues get addressed that our short status meetings don't bother me.
Asynchronous communication--Slack, Discord, Teams, etc.--beats this every time. Why wait an entire day to bring up important topics? And then, if you aren't waiting an entire day, why have the artificial morning ceremony?
I love chat rooms, but they are their own kind of interruption and you can often communicate more in 2 minutes of conversation than in 45 minutes of back and forth on slack. And again, there are benefits to knowing when important things are going to be discussed and planning around that rather than have them happen at random in Slack.
A 15 minute meeting where the person doing the talking has to stand up. That quickly makes very short meetings.
That starts off broken and abusing the Scrum process. It's supposed to be "what I completed yesterday" and you move your tasks to done. Then "what I'm working on today" is you move your tasks to in-progress. And you raise any blocking issues that you need help with.
But it always devolves into "what I did..blahblahblah" because both PM/Managers want an accounting and people feel like they need to justify themselves (as you mention).
But it always devolves into "what I did..blahblahblah" because both PM/Managers want an accounting and people feel like they need to justify themselves (as you mention).
You'd make me use Slack?
Two problems immediately stand out here:
- 45 minutes: it should be 5-10 minutes, 15 on a bad day, and literally never 45.
- 15 people: this is probably just too many people in a single standup. Based on my experience, it's quite likely this can be split up into 2-3 teams that can have more autonomy, and meetings like standups will become far easier to run and far more efficient.
- 45 minutes: it should be 5-10 minutes, 15 on a bad day, and literally never 45.
- 15 people: this is probably just too many people in a single standup. Based on my experience, it's quite likely this can be split up into 2-3 teams that can have more autonomy, and meetings like standups will become far easier to run and far more efficient.
Last ~15 person team I was made up of the following 7 devs, a tech lead, 3 qa(1 automation, 2 manual), a product champion, a pm, and a deployment expert(devops) is 14.
14 doesn't seem crazy to me. And splitting this team up runs into some issues as well.
Do you now have 3 tech leads who acting as pm reporting to the head pm? Do you try to split up the code base? How do you split up QA/Production Champion/Devops? All these decisions seems to have drawbacks.
14 doesn't seem crazy to me. And splitting this team up runs into some issues as well.
Do you now have 3 tech leads who acting as pm reporting to the head pm? Do you try to split up the code base? How do you split up QA/Production Champion/Devops? All these decisions seems to have drawbacks.
It's impossible to say without knowing the product, technology, codebase, etc. In some cases, yes, absolutely -- you would have three separate teams with three separate leads. In other cases, there isn't a reasonable way to split it up. Either way, there's no reason for the standup to last 45 minutes.
Whether the codebase should also be split up is another question that is impossible to answer in general. I can speak from experience though and say it's easy to have two teams work on the same large codebase when they're focusing on different areas, different projects, different priorities, etc. I've seen 3-4 different web teams work on the same website with the same underlying codebase without any issues at all because it was clear in advance that their work wasn't going to directly conflict in any way. It would've been hugely counterproductive to force all those people into a single standup and a single team.
Whether the codebase should also be split up is another question that is impossible to answer in general. I can speak from experience though and say it's easy to have two teams work on the same large codebase when they're focusing on different areas, different projects, different priorities, etc. I've seen 3-4 different web teams work on the same website with the same underlying codebase without any issues at all because it was clear in advance that their work wasn't going to directly conflict in any way. It would've been hugely counterproductive to force all those people into a single standup and a single team.
Yeah, it's pretty dumb considering that not only is everyone on Slack, but most workplaces already have some system for providing status updates, yet management insists that we repeat to them in person the same info they could easily grab from Jira/Trello/Pivotal/Github.
"what I did yesterday" -- can't remember
"what am I doing today" -- not sure yet
"what am I doing today" -- not sure yet
> 15 people
seems like your standup team is too big.
seems like your standup team is too big.
Team size is picked for a variety of reasons and the least important of which seems optimal stand up size.
The entire reason teams exist as a concept is to improve management and coordination logistics. A standup is a daily meeting that every team member has to attend, and in order for it to be productive it shouldn't just be robotic status updates; each member should actually be ingesting and thinking about everything that's brought up. Making sure it can be run smoothly should actually be considered an important factor, and if it's not it does call into question the objectives of the team lead or project manager. Of course, there are other factors as well, as you suggested, and there are indeed cases where a standup of 15+ people can make sense. Even in those cases, though, it is a result of pure incompetence to let the standup run for 45+ minutes even a single time outside of perhaps a major disaster.
As a supporting datapoint, in the entire company I work at, there isn't a single standup with that many people.
As a supporting datapoint, in the entire company I work at, there isn't a single standup with that many people.
Hmm, my first thought for running a 15 person project isn't to run it as three different five person teams.
A couple of questions Was the company you work at a software product company? Are your teams cross functional? Do people exist across multiple teams?
My fundamental issue with splitting a 15 person team into three 5 person teams it seems more difficult to satisfy two other attributes I think are valuable in teams. That they are cross functional and flat.
A couple of questions Was the company you work at a software product company? Are your teams cross functional? Do people exist across multiple teams?
My fundamental issue with splitting a 15 person team into three 5 person teams it seems more difficult to satisfy two other attributes I think are valuable in teams. That they are cross functional and flat.
If it truly is a 15 person project for its entire duration then it's not worth splitting up, but you could still consider whether the whole team needs to be present for every standup. More often than not, though, when the team size reaches the 15+ range the project often can be broken down into smaller discrete deliverables that do not need 15 person teams to achieve.
Where I work it is all software. We can and sometimes do have folks on multiple teams but generally try to avoid that. And teams can definitely be cross-functional.
Where I work it is all software. We can and sometimes do have folks on multiple teams but generally try to avoid that. And teams can definitely be cross-functional.
but you don't need to have standups with all the team. That seems to be the problem. Thats why i said "standup team" not "team" in my original comment.
how many of those 15 ppl care about what you are doing on a regular basis. I am guessing not more than 5. I've never been in a standup with more than 5-6 people, 15 ppl standup sounds too ridiculous to me.
how many of those 15 ppl care about what you are doing on a regular basis. I am guessing not more than 5. I've never been in a standup with more than 5-6 people, 15 ppl standup sounds too ridiculous to me.
Like anything those meetings can be fine.
I do those every day, they rarely last more than 20 minutes.
I do those every day, they rarely last more than 20 minutes.
Some workflows require synchronous communications. Meetings, in person or virtual, are great for these.
Other workflows work asynchronously. E-mail, IM and the like are great for these.
Post-War America erred on the side of meetings, forcing asynchronous flows into artificial bottlenecks. Silicon Valley seems to have over-corrected, replacing ten-minute meetings with full-day Slack threads.
Trying to force asynchronous flows into synchronous constructs introduces unnecessary delays, as the slowest process sets the pace. It also increases overhead, since resource C is occupied while A and B sync. Trying to force synchronous flows into asynchronous constructs introduces mistakes through mis-communications. It also increases overhead, since an additional layer of verifying everyone got critical information is introduced.
Other workflows work asynchronously. E-mail, IM and the like are great for these.
Post-War America erred on the side of meetings, forcing asynchronous flows into artificial bottlenecks. Silicon Valley seems to have over-corrected, replacing ten-minute meetings with full-day Slack threads.
Trying to force asynchronous flows into synchronous constructs introduces unnecessary delays, as the slowest process sets the pace. It also increases overhead, since resource C is occupied while A and B sync. Trying to force synchronous flows into asynchronous constructs introduces mistakes through mis-communications. It also increases overhead, since an additional layer of verifying everyone got critical information is introduced.
Insightful. Was thinking about this recently. I find meetings are usually “make a decision”, “give updates”, or “show a demo”. For decision making, have been trying to optimize that workflow with teammates all over the world and not everyone having the time or not loving textual communication.
Seems like a master decision record in confluence, discussing finer points in a private slack channel, and demo and tie-breaking plus sync with busy or non text thinkers with ad hoc video meetings works well together. Another thing is quick prototypes of ux or architecture designs in codesandbox.
These all work well, but it would be great to have less overhead. Even on a small team though there are so many gaps it feels impossible to reconcile without all these.
Anyone have a team decision making workflow for spinning up new projects that is more efficient?
Seems like a master decision record in confluence, discussing finer points in a private slack channel, and demo and tie-breaking plus sync with busy or non text thinkers with ad hoc video meetings works well together. Another thing is quick prototypes of ux or architecture designs in codesandbox.
These all work well, but it would be great to have less overhead. Even on a small team though there are so many gaps it feels impossible to reconcile without all these.
Anyone have a team decision making workflow for spinning up new projects that is more efficient?
If your company is well managed then pretty much anything can work. Meetings can be short and to the point. Memos/emails can also be short and to the point. When everyone understands what the ultimate goals are and are allowed to work towards those goals communication is minimal.
Typically, though, goals are unclear and constantly shifting. From that flows multiple tasks that are all high priority up to the point they suddenly become irrelevant. In such an environment communication needs to be continuous. Continuous communication is by necessity synchronous.
Typically, though, goals are unclear and constantly shifting. From that flows multiple tasks that are all high priority up to the point they suddenly become irrelevant. In such an environment communication needs to be continuous. Continuous communication is by necessity synchronous.
It seems to me that you have found two problems.
How do we make our company look like an alternative to zoom when people look for that? I know, bash meetings and say that using another nondescript wiki/document tool is the right move. You waste so much more time having to write in a document and then going back to look at what other people have written as they do than just having a quick meeting. meetings are running long because people like social interaction and we are missing it.
i think zoom is also the problem
At the very least it would be odd to blame the existence of meetings for Zoom's security/privacy issues.
I agree that video calls are great when used to create human connections and to vigorously debate - but little else. I've survived my share of Zoom meetings that should have been emails but it got WAY worse since the lockdown.
How do you get people to write though? And more importantly - how do you get them to read?
Written/async communication sounds great in theory, but it takes the discipline most people don't have. Especially when working remotely.
At least during a call you can confront people directly.
Written/async communication sounds great in theory, but it takes the discipline most people don't have. Especially when working remotely.
At least during a call you can confront people directly.
Discord (or simply voice channels) to the rescue. You can make quick p2p alignments and prevent a lot of meetings. Assuming that using sync communication is necessary :)
I wouldn’t want to give up the morning scrum IMO, especially when isolated like this.
Two things can be true.
Bad meetings are a problem.
Zoom's technical details are a problem too.
Zoom's technical details are a problem too.
content marketing at its best.
It’s a shame because Zoom has good fundamental tech.
Source? All I hear is about how buggy and insecure the platform is.
Edit: source, https://www.buzzfeednews.com/article/pranavdixit/google-bans...
Edit: source, https://www.buzzfeednews.com/article/pranavdixit/google-bans...
For better or worse, it's really easy to get both small and large (i.e., very large -- hundreds of people) video calls going, and it possibly has the best cross-platform support out of every option available right now.
It's not buggy like at all. And afaiu the security stuff has solutions that just aren't default (passwords, SSO)
https://news.ycombinator.com/item?id=22814198
Security and privacy issues are clearly very real.
Security and privacy issues are clearly very real.
Post is flagged. What was it?
Oh that's unfortunate. It was a post providing proof & explaining that Zoom engineers set up an internal website to monitor certain people's zoom meetings, specifically women who were doing sexual things. I wonder why it got removed, it provided DNS registrar history evidence so it wasn't just hearsay.
Another criticism of a controversial tech that is actually a pitch for a product. It's a Hacker News staple.
Maybe I'm just getting too cynical.