3 ms·
Once you do lead a team, which I'm sure you will do in the future if you're so inclined, It can be a bit harder than you would think! Even a team of all A playe
by jakejake 11y ago
Once you do lead a team, which I'm sure you will do in the future if you're so inclined, It can be a bit harder than you would think! Even a team of all A players can flounder and never produce anything if you're not careful.
For me the thing is that you just have to constantly adapt your plan as things develop. I don't think deadlines are inherently bad. But if you do set deadlines, the team needs to be a part of that process and the goals need to be based on reality rather than just arbitrary. If you have hard external deadlines, then that may dictate the features you can deliver. I find that developers (myself included) appreciate being able to focus on their individual tasks, knowing that the manager is making sure the ship is heading in the right direction.
- nostrademons 11y agoI've found that teams (and individuals) function best when tasks are either scope-delimited or time-delimited. Not both, and not neither. If the task is concrete enough that the desired outcome is crystal-clear and there's not much risk in completing it, then just say "It's done when it's done" and let someone work at it. If the task has fuzzy success criteria - "Make this UI better", for example, or "speed this up as much as you can", or "explore new approaches for this module" - put a deadline on it. It's possible to spin your wheels forever if you don't have a clear destination and clear timeframe.
- holografix 11y agoThis. So obvious and so right.
- deleted 11y ago[deleted]
- s73v3r 11y agoI would say proficiency makes motivation even more critical, because proficient people know they can go wherever they want, so they're less inclined to put up with bullshit.
- segmondy 11y agoHe didn't say "A players", he said, "Focused teams".