Zoom Is Not the Problem – Our Meeting-Centric Workflow Is(blog.nuclino.com) |
Zoom Is Not the Problem – Our Meeting-Centric Workflow Is(blog.nuclino.com) |
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.
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.
- 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.
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.
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).
"what am I doing today" -- not sure yet
I do those every day, they rarely last more than 20 minutes.
seems like your standup team is too big.
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.
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?
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.
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.
Zoom's technical details are a problem too.
Edit: source, https://www.buzzfeednews.com/article/pranavdixit/google-bans...
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.
As a supporting datapoint, in the entire company I work at, there isn't a single standup with that many people.
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.
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.
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.
Security and privacy issues are clearly very real.
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 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?
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.