"Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity."
—General George S. Patton
One of the most abused words in business today is empowerment. The concept of giving people the power to do their job is sound, but it is frequently not well implemented. Often senior management claims to empower their employees, yet the power is overly restricted. Nowhere is this more obvious than on IVD product development teams, where the concept of management oversight can quickly become micro-management. But if you want your teams to meet their objectives and be successful, empowerment is the key.
General Patton was famous for his battlefield successes and colorful speeches. In the quote above, he nailed the concept of empowerment. Here are some points to consider when assembling a project team:
- Training is essential, not optional. Patton could depend on ingenuity because his soldiers were very well trained. Often companies will form a project team and watch it unravel with no idea as to why. In the majority of those cases, it is because some or all of the team members are not adequated trained for the job they've been asked to do. In IVD product development, this means training your team members on quality systems regulations (including design control), and also in how to work as a team (communications, conflict resolution, critical thinking, etc.). Even if you hire people with experience on project teams, don't assume that they all know how to work on a team. If they were never properly trained they could have some very bad habits.
- Give team members the authority as well as the responsibility. The classic mistake that companies make is giving someone the responsibilty of being a project team member, but not the authority, thereby not truly empowering them. Let's say you have a bright, motivated young employee that you want to grow professionally. What better way than to put him or her on a project team? They have the domain knowledge, maybe even the training, but do they have the authority? Again, look at Patton's quote and remember the context. The people he's referring to are his commanders, who have the authority to direct soldiers in battle. They are empowered by the chain of command to make decisions and take actions. If your junior team member doesn't have the resources and tools to do the same, they are doomed to fail. On a project team there will be peers that have this authority, and they will quickly become frustrated with the junior team member that constantly has to go back to consult with his functional manager. This can destroy the team dynamic by shifting the balance of power, making the junior member less effective. Functional managers should either give the team member the authority, or sit in the chair themselves.
- Shared leadership is an oxymoron. One of the strangest ideas on project leadership is the notion that more than one person can lead a team. There are a number of instances where companies have both project managers and project leaders on the same team. One is responsible for the administration of the project (schedules, design history file, etc.), while the other is the visionary that leads the team to acheive its goals. Huh?! This never makes any sense to me. If you have a product that is moving through development under design control, you need to have one person, and only one person, that has the authority to lead the team. That's not to say that they make all the decisions. You still need team members that are responsible for the quality of their individual areas of expertise, be it scientific, regulatory, manufacturing or marketing. But the project leader must have the responsibility for the overall quality of the project, and thus the authority to act if a project is off track. This is especially true under design control, where the design outputs must ultimately align with the product requirements. Failure to fully empower the (singular) project leader is one of the major reasons why IVD development projects fail.
- Agree on the plan, then step aside. The other trap that companies fall into is what I call excessive management oversight. Some senior managers look at the executive oversight portion of the qaulity system regulations and interpret that to mean that they must track every detail of a project. That's a great way to demoralize a project team and increase your development costs and time to market. Go back to Patton's quote. Do you think for a minute that he didn't know he was on the hook for the overall success of the US Third Army? He understood that if he wasn't successful, Eisenhower would remove him from his command. That didn't mean Patton had to oversee every detail of each battle. He did have to make sure his commanders were well trained, capable, and had the resources they needed to do the job. He got regular reports from them on their progress, issues, resource needs, etc. And if someone wasn't doing the job, he didn't hestitate to replace them with someone else. The same is true for IVD product development. Senior management and the project team need to agree to the product development plan, including the requirements (business and regulatory), risks and schedule. Once they've agreed, management will need to have regular updates from the team (via the project leader) as to how things are going, what the issues are, etc. If a team member isn't performing, management needs to make a switch. But ultimately management needs to recognize that they have the right people, and must trust that the team will do a good job.
When it works, empowerment is about making sure that people are well trained, that they have the authority to do the job, and that they are given the chance to do it. A truly empowered team can do great things, even during extreme pressure. Just ask George.