First Who...Then What

Jim Collins’s book, Good to Great, has sold over 2.5 million hardcover copies, and has been translated into 32 languages. According to Collins, one of the principles practiced by the most successful companies is: “First who… then what.”  Collins explains: “The executives who ignited the transformation from good to great did not first figure out where to drive the bus and then get the people to get them there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it.… The old adage ‘People are your most important asset’ turns out to be wrong. People are not your most important asset. The right people are.”¹

In this month’s story, Terry Little, a former US Air Force project manager, highlights the importance and the difficulties in adhering to Collins’ rule: “People are not your most important asset, the right people are.”²

“Uh-oh, this can’t be good,” I remember thinking as my boss’s boss opened the door and walked quickly to my desk, his face unsmiling. “Come with me,” he said.  I got up, my head down, as I followed him out the door. His name was Colonel L.

It has been almost 40 years since that day and I remember it like it was yesterday.  As I walked behind him down the hall, my mind was racing.  What have I done now?  I was pretty accustomed to being in some sort of trouble since I was a cofounder and president of the local professional employees’ union.  It would be fair to say that a lot of the senior civilian and military supervisors were wary of me and considered me a trouble-maker.  I was a very vigorous and assertive employee representative and I figured some higher-up had complained to Colonel L. about my disrespectful behavior; it had happened several times before.

I was surprised to see him head downstairs instead of to his office on the same floor.  When we got downstairs, he headed to our high-security vault.  We entered and went to a room inside where he invited me to sit down.  I had no idea what was coming.  Colonel L. started off by telling me that he and the general (his boss) had decided that they wanted me to head up a highly classified new program to develop and field a new capability as quickly as we could possibly do it. The estimate to complete the program was well over $1 billion.  He went on to say that I could select whomever I wanted to work with me and that I would have the freedom to ignore all rules and regulations; the only stipulations were that I had to obey the law and keep the team very small. 

“Can I ask questions?” I said.  Colonel L. replied: “No, not until you tell me that you will do it.”  After pondering a minute or so, and warning him I had absolutely no project management experience or training, I agreed to do it.  Little did I know the learning, heartbreak and exhilaration the next five years would bring.  I cannot write about the thrills and heartbreak because of security, but I can write about what I learned and unlearned.  This blog and those to follow will highlight those learnings that I think are pretty universal and can help other project leaders.

(I should say as an aside that the project was wildly successful, exceeding everyone’s expectations.  Otherwise, why would I be writing this blog?)

My first task was to pick the people who would be on the team. I had people work for me before in the military, but I never had the luxury of picking them. I immediately began interviewing candidates whom I thought might be suitable for the project office.  About half were civilian and half military. I was able to eliminate some interviewees immediately. They were the ones most interested in whether or not they would get promoted and those who were eager to tell me how bad their current boss was. I also eliminated anyone whose primary concern was how hard they would have to work.

After passing my initial screen, my major criteria were to pick people who: were very experienced in project offices, understood the complicated acquisition processes in the Department of Defense, and were skillful in their respective function.  That turned out to be a critical mistake.  Many of those I picked using these criteria were very poor performers. Most left voluntarily (this was easy because I had a policy that anyone on the team could leave anytime for any reason; too, I made sure poor performers knew they were not doing well and why).  Why they were poor performers is informative.

One of the most salient reasons was that some cared more about following the processes and avoiding risks than they did about achieving the project’s objectives.  I am not sure why this was.  My hypothesis is that some people need clear rules and are hypersensitive to the potential of making mistakes.  It was as if the limit of their accountability was process accountability and not project outcome accountability.  I concluded that some people are simply unable to adapt to an ambiguous, rapidly changing project environment.

Another key, related reason was that some poor performers were simply not team players.  A couple spent enormous energy criticizing the contractor and bloviating, but did very little work.  They became anchors.  A few, very experienced team members seemed to have been unable to apply that experience to a different situation. They appeared to be handicapped by their experience rather than helped by it.

In retrospect, the most successful team members shared some common traits.  They were mostly younger.  They remained positive and enthusiastic even during project travails. They were very agile, willing to change direction whenever the situation dictated.  They were able to subordinate their personal and functional goals to the project’s goal.  They treated others on the project with respect and were not into blaming others when something went wrong.  They were constantly learning and adapting their behavior as a result. They were willing to do anything to make the project successful, including working outside their functional area and working long days when necessary.

I do not know how to identify people who will not work out with an interview; perhaps others are better at that than I am.  What I do know is that poor performers disrupt team function and are intolerable over anything longer than a very short term.  One of the project manager’s most critical jobs is quelling those disruptive influences. In the next blog I will describe how I did that.

¹ Collins, James Charles. Good to great: Why some companies make the leap... and others don't. Random House, 2001.

² Terry Little is one of the co-authors of an upcoming book, Becoming A Project Leader: Blending planning, agility, resilience and collaboration to control and deliver projects in the real world, to be published in early 2017 by Palgrave Macmillan. The other co-authors are Alex Laufer, Jeff Russell and Bruce Maas. Little was the Department of Defense’s most seasoned manager of major programs, with more than 25 years’ experience leading major weapons acquisitions. Little served as executive director of the Missile Defense Agency—the senior civilian in an organization of approximately 8,000 employees—while also directing the $14 billion Kinetic Energy Interceptor Program. Previous to that, he was the first director of the Air Force Acquisition Center of Excellence. An honorary professor at the Defense Systems Management College, Little has presented case studies to every program manager class at the college for the past 15 years.