Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: Leadership
Leadership
This gets to be a hairy area of discussion, trying to define what makes good leadership. I have no doubt there are many project managers who think they are fantastic leaders that I would classify as lousy, and many might say the same of me if we don't agree on the definitions.
I am heavily influenced by Drucker and Deming on this topic as well as some influential managers I've worked for in my career (thank you Tim and Jodi).
Strategic Planning
A project manager who isn't looking ahead isn't doing a good job leading. Not just schedules, but also making sure the right staff and materials are available when they are needed.
Risk management is part of this too. If you aren't leading the team to uncover and proactive handle potential issues on the horizon, who is?
No one. That's your job.
Continuous Improvement
Maintaining status quo is not leadership.
If you think your project organization has reached the limit of what is possible, please call me. I want to fly out to wherever you are and see it for myself.
If you aren't continuously getting better personally, as a team, as a project organization - you aren't leading.
Know the Work
Part of this is being at least moderately capable with the work your project staff are doing.
Some people claim a project manager can effectively lead a project in any domain regardless of their domain knowledge.
I say that's complete hogwash.
If you are managing a technical project and you have no technical understanding of what your staff do day to day, there's an automatic barrier to your ability to lead.
If you can participate in code reviews and facilitate technical discussion to give the team direction, you have a leadership-enabler at your disposal.
If you don't have a foundation of technical knowledge in the domain your project teams work, you'd better develop it quickly.
Trust, Not Fear
This failing is rampant.
Project managers don't want to hear bad news. They make a big fuss about problems or deadlines that are going to get missed, essentially blaming it on the team.
Here's what happens.
The team will stop telling you the truth, and instead just tell you what you want to hear.
They'll then go have their own conversations after you've given them direction - but they won't follow your direction because you no longer know what's really going on with the project.
They'll go do their best to get things done without you - or more to the point, in spite of you.
That's a project culture of fear, and Deming would be disappointed.
Treat Project Staff as Volunteers
Relying on formal authority of your title is not leadership, it's the opposite of leadership.
When you treat project staff as if they were volunteers, you have to create an environment where they WANT to work with you on this project.
You empower them by employing techniques to enhance the pride they have in their work. You give credit publicly for your staff's acheivements whenever it's sincerely warranted.
This is servant leadership, and without it you're just a manager. A warm body just punching the clock.
Systems Solutions
Mistakes are usually caused by flawed systems, not bad people.
This is why the project manager should take responsibility for mistakes and problems. Each one usually contains a lesson learned about how your project environment and systems should be improved to prevent this kind of mistake again (continuous improvement).
Customer Focus
The PMBOK used to say that a project was successful if the requirements were verified, regardless of whether or not the customer was happy with the product.
That's not leadership either.
A leader must have a focus on the customer, and frankly that's why I think it's so difficult to be an effective leader in (nearly) any project environment without doing iterative releases of your product and engaging your customer in a feedback loop on a regular basis.
This is why I believe Lean and Agile methods of delivering products are superior to any traditional method with long lag times between project phases.
What do you disagree with, and what you add? Leave a comment below and let's discuss.
The Problem With Project Management Series:
The less frequency with which your customer is directly involved in the project, the bigger barrier to true leadership you face.The Problem with Project Management
Leadership
This gets to be a hairy area of discussion, trying to define what makes good leadership. I have no doubt there are many project managers who think they are fantastic leaders that I would classify as lousy, and many might say the same of me if we don't agree on the definitions.
I am heavily influenced by Drucker and Deming on this topic as well as some influential managers I've worked for in my career (thank you Tim and Jodi).
Strategic Planning
A project manager who isn't looking ahead isn't doing a good job leading. Not just schedules, but also making sure the right staff and materials are available when they are needed.
Risk management is part of this too. If you aren't leading the team to uncover and proactive handle potential issues on the horizon, who is?
No one. That's your job.
Continuous Improvement
Maintaining status quo is not leadership.
If you think your project organization has reached the limit of what is possible, please call me. I want to fly out to wherever you are and see it for myself.
If you aren't continuously getting better personally, as a team, as a project organization - you aren't leading.
Know the Work
Part of this is being at least moderately capable with the work your project staff are doing.
Some people claim a project manager can effectively lead a project in any domain regardless of their domain knowledge.
I say that's complete hogwash.
If you are managing a technical project and you have no technical understanding of what your staff do day to day, there's an automatic barrier to your ability to lead.
If you can participate in code reviews and facilitate technical discussion to give the team direction, you have a leadership-enabler at your disposal.
If you don't have a foundation of technical knowledge in the domain your project teams work, you'd better develop it quickly.
Trust, Not Fear
This failing is rampant.
Project managers don't want to hear bad news. They make a big fuss about problems or deadlines that are going to get missed, essentially blaming it on the team.
Here's what happens.
The team will stop telling you the truth, and instead just tell you what you want to hear.
They'll then go have their own conversations after you've given them direction - but they won't follow your direction because you no longer know what's really going on with the project.
They'll go do their best to get things done without you - or more to the point, in spite of you.
That's a project culture of fear, and Deming would be disappointed.
Treat Staff as Volunteers
Relying on formal authority of your title is not leadership, it's the opposite of leadership.
When you treat project staff as if they were volunteers, you have to create an environment where they WANT to work with you on this project.
You empower them by employing techniques to enhance the pride they have in their work. You give credit publicly for your staff's acheivements whenever it's sincerely warranted.
This is servant leadership, and without it you're just a manager. A warm body just punching the clock.
Systems Thinking
Mistakes are usually caused by flawed systems, not bad people.
This is why the project manager should take responsibility for mistakes and problems. Each one usually contains a lesson learned about how your project environment and systems should be improved to prevent this kind of mistake again (continuous improvement).
Customer Focus
The PMBOK used to say that a project was successful if the requirements were verified, regardless of whether or not the customer was happy with the product.
That's not leadership either.
A leader must have a focus on the customer, and frankly that's why I think it's so difficult to be an effective leader in (nearly) any project environment without doing iterative releases of your product and engaging your customer in a feedback loop on a regular basis.
This is why I believe Lean and Agile methods of delivering products are superior to any traditional method with long lag times between project phases.
The less frequency with which your customer is directly involved in the project, the bigger barrier to true leadership you face.z`The Problem with Project Management
Leadership
This gets to be a hairy area of discussion, trying to define what makes good leadership. I have no doubt there are many project managers who think they are fantastic leaders that I would classify as lousy, and many might say the same of me if we don't agree on the definitions.
I am heavily influenced by Drucker and Deming on this topic as well as some influential managers I've worked for in my career (thank you Tim and Jodi).
Strategic Planning
A project manager who isn't looking ahead isn't doing a good job leading. Not just schedules, but also making sure the right staff and materials are available when they are needed.
Risk management is part of this too. If you aren't leading the team to uncover and proactive handle potential issues on the horizon, who is?
No one. That's your job.
Continuous Improvement
Maintaining status quo is not leadership.
If you think your project organization has reached the limit of what is possible, please call me. I want to fly out to wherever you are and see it for myself.
If you aren't continuously getting better personally, as a team, as a project organization - you aren't leading.
Know the Work
Part of this is being at least moderately capable with the work your project staff are doing.
Some people claim a project manager can effectively lead a project in any domain regardless of their domain knowledge.
I say that's complete hogwash.
If you are managing a technical project and you have no technical understanding of what your staff do day to day, there's an automatic barrier to your ability to lead.
If you can participate in code reviews and facilitate technical discussion to give the team direction, you have a leadership-enabler at your disposal.
If you don't have a foundation of technical knowledge in the domain your project teams work, you'd better develop it quickly.
Trust, Not Fear
This failing is rampant.
Project managers don't want to hear bad news. They make a big fuss about problems or deadlines that are going to get missed, essentially blaming it on the team.
Here's what happens.
The team will stop telling you the truth, and instead just tell you what you want to hear.
They'll then go have their own conversations after you've given them direction - but they won't follow your direction because you no longer know what's really going on with the project.
They'll go do their best to get things done without you - or more to the point, in spite of you.
That's a project culture of fear, and Deming would be disappointed.
Treat Staff as Volunteers
Relying on formal authority of your title is not leadership, it's the opposite of leadership.
When you treat project staff as if they were volunteers, you have to create an environment where they WANT to work with you on this project.
You empower them by employing techniques to enhance the pride they have in their work. You give credit publicly for your staff's acheivements whenever it's sincerely warranted.
This is servant leadership, and without it you're just a manager. A warm body just punching the clock.
Systems Thinking
Mistakes are usually caused by flawed systems, not bad people.
This is why the project manager should take responsibility for mistakes and problems. Each one usually contains a lesson learned about how your project environment and systems should be improved to prevent this kind of mistake again (continuous improvement).
Customer Focus
The PMBOK used to say that a project was successful if the requirements were verified, regardless of whether or not the customer was happy with the product.
That's not leadership either.
A leader must have a focus on the customer, and frankly that's why I think it's so difficult to be an effective leader in (nearly) any project environment without doing iterative releases of your product and engaging your customer in a feedback loop on a regular basis.
This is why I believe Lean and Agile methods of delivering products are superior to any traditional method with long lag times between project phases.
The less frequency with which your customer is directly involved in the project, the bigger barrier to true leadership you face.
Posted on: November 29, 2012 12:36 PM |
Permalink