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!