In a time when project leadership is undergoing multiple revolutionary changes simultaneously, a wise project leader will make sure their leadership style matches the methods and tools that they apply to their projects.
During the industrial revolution, there was great upheaval in the world. Families were forced to move from their ancestral homes in the country to the overcrowded and polluted cities to find work. Their small, family enterprises were swallowed up by sweatshop style factories and mass production. People were forced to change the way they worked and it was extremely painful in many circumstances.
We are seeing a similar change in the way we work now. When I was growing up, my father was a military man. The culture I lived in was very “command and control”, as we call it. The officers gave the orders and knew best. The soldiers didn’t ask why, offer suggestions, or refuse to act. Neither did my friends or I. The correct answer was, “yes sir”, and then we would spring into action.
I learned to love the clear structure of command and control leadership. In fact, that is part of what drew me to project management in the beginning, when I was working on multi-million-dollar waterfall construction projects. So many times, I thought to myself, ‘if they would just do what I tell them, everything would work out’. It worked for me.
The command and control environment of the military and business in the last hundred plus years is alive and well. Successful and well-known tyrants such as Steve Jobs (yes, I love Apple products, and yes, he was a tyrant) and Elon Musk accomplish much. They change the world (regardless of who they destroy along the way). Work life balance is a joke. Steve pushed his people beyond reasonable limits. Elon sent his people to remote islands for years to build rockets. The goal was always the highest priority, and they drove their people ruthlessly.
Agile has become more popular over the last decade or so. It promotes speed, change, and the customer. In our world of complex technology, Agile seems to be in perfect competition. It applies beyond software as well.
Conflict exists, however, in the rise of the Agile work methods over the command and control methods. Agile principles focus on collaboration, trusting the team to do what is best, and servant leadership. Command focuses on a single point of leadership and having the right answer to start with. When leadership knows command and implementers are used to Agile, the conflict is unavoidable.
I have lived the command and control/Agile conflict. I was with an organization that was relatively new in their Agile transformation. One of the challenges we had was identifying what ‘done’, ‘done done’, and ‘done done done’ (if there really is such a thing) mean. In true Agile fashion, I assembled my team of Scrum Masters to solve the issue for themselves. We held kaizen events. We brainstormed. We discussed the needs of the stakeholders. After 3 months of work, we hadn’t made much significant progress on ‘done’, let alone even addressing the other forms of ‘done’. Preparing for another meeting to discuss done, I finally snapped. “This is the way we are going to do it. I’m the boss and that’s the way I want it done. We have to have some standardization”. I felt like I had finally made progress. At least until I delivered my commands in the meeting. The team became united against me (which was probably good, since they had great ideas). They were rejecting command and control.
More and more, especially as we rely on the Agile principles to govern our work, we as project leaders, will be challenged with being effective in getting things done fast and focusing, while letting the team, who have more information, lead. Based on my experience, there are some crucial pieces of the puzzle in transitioning multiple organizations from a command and control approach to an Agile culture.
Too often in an Agile transition, we do an introductory training to get everyone excited about Agile, presume they know what they need to do, and send them on their way. The focus is on the theory rather than the day to day. Overcoming old non-Agile habits is the biggest challenge to the transition. While it is easy to learn the principles of Agile, it is extremely difficult, especially that early in the game, to understand what that means for the individual. Phase your training in. Introduce the concepts. Discuss roles and responsibilities. Let them practice. Come back and discuss what worked and what didn’t. Discuss our best practices. Learning Agile needs to be, well… Agile.
Practice What You Preach
In my ‘done’ example above, when things got hard, and it took longer than I expected to come to a team decision on what ‘done’ means, I took it upon myself to decide for them. In no way did I have the insight into the issue that the team did, but I moved ahead based on getting the thing done, rather than doing the right thing. The impact was mutiny, frustration, and the sense that I really didn’t believe in the Agile principle of collaboration amongst the team to make the best decisions.
Let them Fail
If the team is going to truly own the work they are doing, they cannot have a safety net. One of my sons was around when I was fixing an old scooter. He was not yet old enough to drive, but I thought this would be a good opportunity for him to putt around the neighborhood learning some basic driving skills. He had never been on a scooter before, but I gave him the 30 second overview and told him to go take it for a spin, adding the admonishment to be careful with the throttle. It is not uncommon for new riders to get startled and pull back on the throttle, accidentally giving it more gas, making them careen wildly out of control. He drove to the end of the street and turned around. Sure enough, as he turned, he got startled and his throttle hand gave a jolt of acceleration. The motorcycle flipped out from under him, hit a curb, did two summersaults, and almost killed a tree. Luckily, he was still standing. The handlebar had hit his cheek, but no real damage was done. To say the least, my son learned a lot about scooters that day (and a bit about project management). He got up and tried again, never making the same mistake again.
So it needs to be with our projects. We will make mistakes. We will fail. The question is will the team learn from it? Will it become an investment or a true failure? Let your teams fail. Trust that they don’t want to fail. The assumption of the Agile principles is that people will do good without being driven. Do you believe it, or don’t you?
Mechanisms for Accountability
Part of letting the team fail is making sure they know what success and failure are. Once, I asked my team what success was for a certain project. Hesitantly sensing a teaching moment, one person dared to respond and stated that the project being released by the date promised was success. While meeting committed dates are important, success focuses more on why the project is being done and the benefits that are expected. Did handle time decrease to a specific target that translates into a specific dollar savings? Is customer satisfaction increasing by 5% in the test group compared to the control group? When success is focused on specific, rather than general metrics, you , and your team, will be successful. Make sure to have clear and available mechanisms for defining, tracking, and reviewing various project metrics. This will allow your team to drive themselves.
Deciding between command and control (fear) based leadership and Agile (collaborative) leadership is critical. The world is moving toward collaborative environments. Don’t confuse your teams more by mixing the two. My experience has been, when you go all in and truly buy in to collaborative principles, your team will begin to trust you, focus without fear, and be much more successful than if you drove them to success. During the adjustment period of the industrial revolution, the most pain was experienced by those who fought the trends. So too, will we experience pain if we continue to follow the path of the command and control tyrant that solves all the problems unilaterally. By adopting a more collaborative approach to leadership, we, and our teams, will be successful.
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
Reading this article qualifies you to submit a request for PDU's from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU's
For more information on registering your PDU's with PMI - CLICK HERE
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
Adam Tidwell is the Senior Manager over the IT Project Management Office (PMO) for Western Governors University, an online competency based university based in Salt Lake City. He managers a team of Project Managers and Scrum Masters to plan and execute all IT projects for the university. He also manages the annual roadmap for the executive leadership team.
Adam has worked at Kyazma Business Consulting managing enterprise-wide Salesforce implementation projects. He also spent 11 years at eBay managing various cross departmental process improvement projects and establishing the first PMO for the North American Customer Support organization.
Adam currently teaches Project Management for the MBA program at the Eccles School of Business at the University of Utah and has served in various volunteer positions with the Northern Utah PMI Chapter, including two terms as President.
Adam has a bachelor’s degree in Business Administration and a master’s degree in Computer Information Systems. He is a certified Project Management Professional (PMP), Agile Certified Practitioner (PMI-ACP), and Certified Scrum Master (CSM), and is currently preparing to take the Portfolio Management Professional certification exam (PfMP).