Sometimes, you have to break the rules to get things done!
As we go through our lives we are subjected to numerous rules – as kids, as students, as workers and as adults living our everyday lives. As program managers and leaders, part of our responsibilities is to lay down some rules by which to guide projects, by which teams work together and by which products are built, tested and released. However, let’s not forget that the reason we have rules is to get us to a destination. There is a favorite quote of mine which I invoke to remind myself of this principle:
Hell, there are no rules here – we’re trying to accomplish something. Thomas Edison.
The program manager needs to know when to go by the books and follow the TL9000 (or your favorite development) process and when to let loose and have the team go off and run as fast they can. I once worked with a program manager (let’s call him Joe) who could not tell the difference. He was a ‘by the rules book’ type of leader – and that actually got in the way of us getting our jobs done. We ended up getting to our destination despite Joe. Here is the story.
Joe was responsible for leading a project on which I was one of the engineering managers. We started out with a reasonable plan, and had regular program meetings, with status, minutes and action items that Joe would track. Along the way, two things happened. Our management wanted us to adopt a new development process. And, at about the same time, we also had the inevitable ‘technical bump’ in the road that required our attention. The new process rule required a detailed unit testing plan be documented, and signed off at completion prior to handing off to the QA team. Joe was focused on tracking this new process requirement and getting the test plan documented. The engineering team was very concerned about the bump. Without addressing the bump, there would be no substantial development or unit testing to speak of. However, Joe had it in our project schedule that the unit test plans would be done by a specific date and tracked that religiously at each meeting. Joe also had very little domain knowledge and despite the team’s efforts to educate him on the criticality of addressing the problem asap, he continued to focus on the dates and the schedule. Joe was following his rules book – the established project plan. The engineering team decided to take matters into its own hands, and we held shadow program meetings without Joe to address the bump and quickly fix the key technical issues that were hampering our progress. Joe’s rules were getting in the way of work being done. When the crisis was over, I gave Joe some feedback that he needed to be able to adjust his plans when bumps came along, and bend the rules to meet our most critical goals. To do that, he needed to learn more about the domain and understand the business of what he was program managing. However, I hear he still manages the same way. Sigh!
Focusing on the rules and mechanics of program management helps keep things going. But a good program manager needs to have at least a basic understanding of the domain and be prepared to apply rules or break the rules in order to get things done. At the end of the day, the customer will not pay if we don’t have a good product, but followed all the rules!
I’ll take a risk … and guess I’m a risk-taker. I’ve found that getting a project idea started usually takes a while, and during that time there can be a lot of “beat down”. But each opinion has to be factored by its source. Some ideas deserve to be pounded! And most benefit by the discussions.
In some cases I’ve started a new company to get an idea underway. In others the executives have come to support the ideas. Once underway, the arbiter of idea success is its customers, internally or externally. At best the next beat-downs will be from competitors, internal and external. These critiques have to be met with salesmanship – the ability to shape the evaluation function to your advantage. It is said that a mediocre idea succeeds with salesmanship, and a great idea will fail without salesmanship. So I guess the beat-down can’t be blamed.
Thanks your your insights, as always.
You are so right Loyal. Risk takers do get beaten up – especially by folks who are insecure and don’t like to see risk takers succeed. My experience has been that you are more likely to be supported if the environment around you is filled with confident people who recognize that risk taking is important and are prepared to reward it. My neck has been chopped a few times. These quotes are like the stem cells that help me regenerate:).
I would really like to hear about other people’s experiences on taking risks, and how it was supported or beaten down. Anyone willing to stick their nect out?
Absolutely terrific stories! Thank you for sharing, Mala. I’ll bet most of us have experienced at least one ‘by the book’ manager at some point in our careers. They are just trying to do their best and have had success in the past by following process, so they continue. Each success they have following the ‘process’ builds their commitment to it. It takes great courage and conviction to stick one’s neck out and take a risk. Unfortunately, most risk-takers get that fantastic trait beat out of them after being punished a few times for risks taken that failed.