Re:One-on-one meetings are underrated, whereas group meeting...
by hliyan on Monday December 25, 2017 @09:13AM
(#16004130)
I too agree to a certain extent. I've experienced many problems that could have been avoided had decisions been communicated to wider audiences, and problems that were actually avoided because someone in a meeting (who was not a primary participant) said "actually if you do that change, you'll need to handle a dependency with our component".
Re:One-on-one meetings are underrated, whereas group meeting...
by Yokohiii on Monday December 25, 2017 @09:50AM
(#16004257)
Exactly this, small but important details can disappear.
Re:One-on-one meetings are underrated, whereas group meeting...
by shuoli84 on Tuesday December 26, 2017 @11:34PM
(#16012843)
Those kinds of thing may be better communicated through im, emails or even test cases?
Re:One-on-one meetings are underrated, whereas group meeting...
by valuearb on Monday December 25, 2017 @11:08AM
(#16004563)
Teams need to interact, but not in formal meetings. That’s a false dichotomy.
Re:One-on-one meetings are underrated, whereas group meeting...
by Retric on Monday December 25, 2017 @09:43AM
(#16004227)
Most choices are between reasonable options. It's Java vs C# not Java vs ASM. So, the cost of poor decisions is vastly less than often assumed.
That's not to say they are unimportant, but picking randomly is often a better choice than spending 500 hours to decide what color to use for your logo.
One on one meetings are underrated, especially with tech people and even among them. It is important that managers and tech people build acceptance and try to align their mindsets and share knowledge. But one on ones also leave room for manipulation and favoritism which can tear teams apart.
I agree that many group meetings are boring and badly executed, but a team needs sit at the same table once in a while, even if it is just there to detect conflicts and resolve them one on one. Group meetings suffer greatly from groupthink and dominance of invidiuals. Which is usually badly compensated, if at all. But the failure usually starts with a sloppy agenda and inviting the wrong people. There has been quite some work on that but I usually only see scrum masters randomly doing some of them without serious reflection.
Managers should take care of decisions and tasks that teams or invidials cannot make. Most importantly bring the right people together, get out of the way and cash in the results later. Being the single point of failure is not the solution.