How many times have we said this to ourselves, or worse, to someone on our team? How many times have we thought it would be less stressful to just do the task/project ourselves instead of trying to explain the problem to someone else?
Now be honest.
Often? Yeah, me too.
This is a common anti-pattern, especially in the global context when explaining a task with little overlap in time zones. This is where it feels like it will take more time and energy to explain the task then to actually do it yourself. You rationalize this in the name of efficiency. You are being more efficient. Efficiency is good.
Now be honest.
Often? Yeah, me too.
This is a common anti-pattern, especially in the global context when explaining a task with little overlap in time zones. This is where it feels like it will take more time and energy to explain the task then to actually do it yourself. You rationalize this in the name of efficiency. You are being more efficient. Efficiency is good.
Don't fall for this trap! It is an anti-pattern. You cannot be more efficient then a high calibre, well motivated team.
This anti-pattern will have a negative effect on your team's morale as they will see you as a micro-manager. Or worse, they will perceive that you don't trust their abilities. Furthermore, if you don’t take the time to mentor your team members, or provide new and interesting tasks for them to improve their skills on, they will never get better at their jobs, and their morale will suffer. The team will never improve and you will be stuck in a rut.
As a manager your job is to ensure the task is completed as efficiently as possible. Your job as a leader is to look out for their well being, and do what you can to inspire them. A simple rule is to try very hard not do things that will affect your employee's morale; a well motivated and happy employee is a productive employee. A productive employee is an efficient employee. Efficiency is good.
Another part of this anti-pattern is that if you are heads down implementing features, who is leading and managing? Who is looking out past today, or maybe this week? Who is reporting status to the customers, identifying potential risks, building relationships with the customer, or even looking out for the next opportunity? No one is, since you are now focused on the tactical instead of the strategic.
You are creating “project debt” by “doing” instead of leading. Sure it might feel good to make progress on your project, to contribute to the critical path. Maybe get it out the door sooner, perform some technical kungfu. However, you are incurring a lot of “project debt” to do this. At some point “project debt” comes due, and it might be paid for with a missed opportunity, or an unhappy customer due to a mismanaged relationship.
So we recognize that this is an anti-pattern, how do we assign and explain tasks efficiently?
- In a push task management model, assign tasks several days in advance, and instill a mindset that the team reviews their tasks as soon as they are assigned, even if they don’t plan on starting the task right away. This will allow the team to look at their tasks and seek clarification or answers ahead of time, before they are actually trying to perform the task. Sometimes their questions will flush out missing requirements that might need to be thought about with the customer or product owner as well.
- The same thing applies in a pull task management model, encourage your team to pull the tasks ahead of time, so they can ask any questions they may have before they are blocked for a day waiting for you to answer their questions, or in some cases, wake up.
- Explain the tasks in person, or over video/voice. Follow up with a written explanation. Email works, but a wiki is better. There will be more transparency to the rest of the team, and it will be easy to keep the wiki up to date when things change. We all know things will change right :)
- After you explained the task in person, ask questions to make sure they understand, especially around requirements and any time sensitive pieces.
- In some projects, we use a concept of a “design patch”, in it the developer explains their development approach, basically how they will implement the feature, and how long they think it will take. This isn’t to micro-manage, but often will highlight any lack of understanding. It also has the benefit of improving the teams planning skills and ability to do top down design.
No comments:
Post a Comment