4 ms·
Well it sounds nice but I feel there are some parts left in the dark. Working this way seems to be over reliant on a single manager. The world is now smart enou
by Yokohiii 9y ago
Well it sounds nice but I feel there are some parts left in the dark. Working this way seems to be over reliant on a single manager. The world is now smart enough to know that we are continually misled by biases, focusing on a single person will emphasize and neither that topic nor a strategy for correction has been discussed by the author. I want my manager to be smart, but this is expecting the manager to be very smart at various levels and leaves very little room for mistakes.
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.
- hliyan 9y agoI 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".
- Retric 9y agoMost 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.
- Yokohiii 9y agoOf course there has to be a balance between the task at hand and decision making effort. People have to be good at it and that is a management concern.
- valuearb 9y agoTeams need to interact, but not in formal meetings. That’s a false dichotomy.