Promoted to Project Micromanager
Unless you started your career as a project manager, you most likely have to work your way into the position. You probably had a highly technical role as a software engineer or maybe a systems engineer. Whatever your role was, you were the person actually doing the technical work. In my world, the world of software development, many software engineers find themselves being asked to take the role of project manager.
First let's understand why you, an engineer, have been asked to take on the role of project manager. You have probably gained a reputation of being organized. You write solid high-quality code that passes all requirements. Your design documents are well written. You stay current with the latest technologies and methods of software engineering and you know when to apply them. You are known for finishing your software tasks on time and help out other engineers when requested. You have demonstrated that you have strong technical skills and you are a technical leader.
Now you have been asked to manage the next development effort as project manager. It makes sense to most people. There is a new project, someone needs to manage it. Why not appoint one of the best engineers to the role? It's an opportunity to grow and to enhance your skill set. It will be a career development opportunity. Makes sense right? Well, maybe… Project management does require a new set of skills that are not required as an engineer. Many of these are obvious. Scheduling, budgeting, and tracking the progress of work are all project management skills that can be taught and understood by a smart engineer pretty quickly. But the hard part of this new role is realizing YOU ARE NOT AN ENGINEER ANYMORE! ...well at least for this project anyway.
Here is why this can be tough. The number one talent that you have relied on in your career has been your technical abilities. Because of this, you will find yourself wanting to exercise these skills. During the project, technical challenges will pop up and your first reaction will be to jump in and solve it. DON'T! Let the engineers on the project solve them. It's their role now, not yours. Your job is to make sure they have all the resources and time to solve it. There is nothing worse as a software engineer than to have your manager telling you how to write your code. But that's exactly what can happen in these situations.
Utilize Empowerment
So how do you keep yourself from becoming a micromanager? The best technique I use is empowerment. There is no empowerment algorithm, an empowerment Java package, or an empowerment eclipse plug-in. You'll have to step out of your technical mindset to understand and implement this one. Empowerment can be a tool for motivation and for delegation. On tough projects you need a team of people who are motivated to take on hard problems and to put in the effort needed to get the job done. You can't solve all of these problems yourself. You don't have time. So you will need other team members to work on them. Here are a few ways to empower your team:
One of the main ideas in empowerment is the idea that people like to fill needs. When it is made obvious that no one else is the owner or expert in an aspect of the project, the person working those related tasks will take it upon him or herself to master those tasks. Your engineers will step up and fill the needed role. It becomes more gratifying to them knowing they mastered the challenges themselves and are not the expert.
Making the move from engineer to project manager can be exciting and a learning experience. If keeping out of technical issues is something you can't resist, then think of it this way. Upper management originally chose you for the job because of your technical leadership. Making sure your engineers are able to show their technical leadership will give upper management new candidates to manage the next project and you can go back to being an engineer.
Reference: http://blogs.ittoolbox.com/pm/sheeleytech/archives/promoted-to-project-micromanager-20578
Unless you started your career as a project manager, you most likely have to work your way into the position. You probably had a highly technical role as a software engineer or maybe a systems engineer. Whatever your role was, you were the person actually doing the technical work. In my world, the world of software development, many software engineers find themselves being asked to take the role of project manager.
First let's understand why you, an engineer, have been asked to take on the role of project manager. You have probably gained a reputation of being organized. You write solid high-quality code that passes all requirements. Your design documents are well written. You stay current with the latest technologies and methods of software engineering and you know when to apply them. You are known for finishing your software tasks on time and help out other engineers when requested. You have demonstrated that you have strong technical skills and you are a technical leader.
Now you have been asked to manage the next development effort as project manager. It makes sense to most people. There is a new project, someone needs to manage it. Why not appoint one of the best engineers to the role? It's an opportunity to grow and to enhance your skill set. It will be a career development opportunity. Makes sense right? Well, maybe… Project management does require a new set of skills that are not required as an engineer. Many of these are obvious. Scheduling, budgeting, and tracking the progress of work are all project management skills that can be taught and understood by a smart engineer pretty quickly. But the hard part of this new role is realizing YOU ARE NOT AN ENGINEER ANYMORE! ...well at least for this project anyway.
Here is why this can be tough. The number one talent that you have relied on in your career has been your technical abilities. Because of this, you will find yourself wanting to exercise these skills. During the project, technical challenges will pop up and your first reaction will be to jump in and solve it. DON'T! Let the engineers on the project solve them. It's their role now, not yours. Your job is to make sure they have all the resources and time to solve it. There is nothing worse as a software engineer than to have your manager telling you how to write your code. But that's exactly what can happen in these situations.
Utilize Empowerment
So how do you keep yourself from becoming a micromanager? The best technique I use is empowerment. There is no empowerment algorithm, an empowerment Java package, or an empowerment eclipse plug-in. You'll have to step out of your technical mindset to understand and implement this one. Empowerment can be a tool for motivation and for delegation. On tough projects you need a team of people who are motivated to take on hard problems and to put in the effort needed to get the job done. You can't solve all of these problems yourself. You don't have time. So you will need other team members to work on them. Here are a few ways to empower your team:
One of the main ideas in empowerment is the idea that people like to fill needs. When it is made obvious that no one else is the owner or expert in an aspect of the project, the person working those related tasks will take it upon him or herself to master those tasks. Your engineers will step up and fill the needed role. It becomes more gratifying to them knowing they mastered the challenges themselves and are not the expert.
Making the move from engineer to project manager can be exciting and a learning experience. If keeping out of technical issues is something you can't resist, then think of it this way. Upper management originally chose you for the job because of your technical leadership. Making sure your engineers are able to show their technical leadership will give upper management new candidates to manage the next project and you can go back to being an engineer.
Reference: http://blogs.ittoolbox.com/pm/sheeleytech/archives/promoted-to-project-micromanager-20578
1. Get them involved as soon as possible. Make sure the engineer estimates the durations for his or her own tasks. If they said a task will take three days, they will put in more effort to make sure they meet their own goals. If you set the task duration to three days, then their extra effort would be to meet your goals. And people like to achieve their goals, not yours.
2. Don't second guess their opinions. The engineer has been heads down in the problem. Trust their opinions. If you even slightly show mistrust in their opinion the problem and the solution becomes yours. Each time your opinion gets implemented, it becomes more your task and less of theirs.
3. Don't start tasks for them to finish. I once had a manager write the JavaDoc, define all methods, and parameters for me to help save time. He then expected me to fill in the code in each of his methods based on his documentation. I second guessed myself every time I had to change anything he did. I must have visited his office twice a day asking him why he chose to do things the way he did. The point I'm making here is when you start a task for someone, you become the expert and they will come to you to make decisions.
No comments:
Post a Comment
Dear blog visitor, Thanks for visiting my blog.