Does the following situation sound familiar?
A colleague or team member has just assigned you a new task, but they've already done all the investigation into the underlying issue, spec-d out a solution, and explained why going down this path is the correct choice. The work that remains? Going and implementing the solution.
You've just been, what I would call, "half-assigned" to a piece of work.
Why is this a bad thing? The team member that was assigned the work has lost the ability to investigate a problem without prior influence. They've been told exactly how to fix a problem. There is almost always more than one way to solve the same problem. What if the underlying problem could have been solved by handling another piece of code or situation upstream slightly differently? If the person who has been assigned the work feels like a decision on the "best" solution has already been made, what is their incentive to spend time looking at alternatives? Most importantly, the person that has been assigned the work has lost the feeling of autonomy within the team to make their own decisions. That's a huge problem.
Every member of a team should feel like their perspective and voice are both heard and valued.
Now - there are rare situations where being half-assigned to work can't be avoided. Having to fix a critical issue in a production environment that is causing customer downtime comes to mind. These "half-assignments" should be few and far between.
Am I saying that you should not raise concerns or comments that you might have about another team member's solution to a problem? Absolutely not.
There is a time to raise concerns - during a code review. If a colleague asks for help understanding a concept or section of code - maybe that is another time to throw in some advice. But leave it at that. Let that person (or team) investigate solutions, hit hidden complexities, and explore avenues of various solutions.
During a code review raise your thoughts, and you might even learn that the team tried your solution and there was hidden complexity. Maybe you learn that their solution is a substantially better idea that yours. Or maybe they learn that your idea is in-fact superior.
Bottom line - avoid giving out half-assignments. Let your team or colleagues show you what they are made of.
A colleague or team member has just assigned you a new task, but they've already done all the investigation into the underlying issue, spec-d out a solution, and explained why going down this path is the correct choice. The work that remains? Going and implementing the solution.
You've just been, what I would call, "half-assigned" to a piece of work.
Why is this a bad thing? The team member that was assigned the work has lost the ability to investigate a problem without prior influence. They've been told exactly how to fix a problem. There is almost always more than one way to solve the same problem. What if the underlying problem could have been solved by handling another piece of code or situation upstream slightly differently? If the person who has been assigned the work feels like a decision on the "best" solution has already been made, what is their incentive to spend time looking at alternatives? Most importantly, the person that has been assigned the work has lost the feeling of autonomy within the team to make their own decisions. That's a huge problem.
Every member of a team should feel like their perspective and voice are both heard and valued.
Now - there are rare situations where being half-assigned to work can't be avoided. Having to fix a critical issue in a production environment that is causing customer downtime comes to mind. These "half-assignments" should be few and far between.
Am I saying that you should not raise concerns or comments that you might have about another team member's solution to a problem? Absolutely not.
There is a time to raise concerns - during a code review. If a colleague asks for help understanding a concept or section of code - maybe that is another time to throw in some advice. But leave it at that. Let that person (or team) investigate solutions, hit hidden complexities, and explore avenues of various solutions.
During a code review raise your thoughts, and you might even learn that the team tried your solution and there was hidden complexity. Maybe you learn that their solution is a substantially better idea that yours. Or maybe they learn that your idea is in-fact superior.
Bottom line - avoid giving out half-assignments. Let your team or colleagues show you what they are made of.