Rock Theory of Management

In Execution, Anecdotes by Steve Sliwa

Early in my career, I was assigned to be an acting program manager at NASA Headquarters in Washington DC. Turns out getting a 1 to 2-year rotation through a headquarters slot was a valuable milestone for mid- to late-career senior managers at the NASA research centers. I wasn’t yet 30, but this opportunity provided a great perspective of NASA, Washington DC, and office dynamics.

In that role, I was frequently tasked with preparing pitches (the equivalent of today’s PowerPoint presentations), writing position papers, drafting correspondence, reviewing program plans, and assessing technologies for various senior executives in that department. The workload was quite heavy as the assignments were challenging, sufficiently complex, and the quantity was significant.

This workload was further exasperated by the culture that permeated the department. No work was trusted to be correct, and all work assignments were continuously iterated. It was a pretty frustrating process whereby we, myself and fellow program managers, were constantly told our product wasn’t good enough, and we were asked to keep working on it. What was particularly frustrating was that we were basically told, in effect, that “I don’t know exactly what I want, but I know that isn’t it.”

After a few weeks, patterns in this frustrating process began to emerge. In fact, it all came together for me when I spent a weekend with a friend who had a 3-year old. We played a game I invented for the occasion called, “Get me a Rock!” We played it for hours and the 3-year-old never tired of trying to give me a rock I liked. I had various reasons why what he found wasn’t exactly what I wanted, but he merrily kept searching for rocks. When I tired of the game, I said, “That’s it! I love that rock!”

When I came back to work, it dawned on me what was happening. The particular manager would say, “Get me a rock!” I would dutifully go and get a rock. He would insist on seeing it. He would say, “That’s not a rock, that looks more like a stone. It needs to have sharper edges. Go get me a rock!”

I would diligently work on the product and bring it back. “That’s not a rock, that’s a pebble. It’s too smooth and small. Go get me a rock!” And so forth.

So now, the game was afoot. I decided to systematically study and model the culture of working with the division directors. I noticed, for example, that if I took the exact same Rock #7 to the manager as Rock #1, I received different responses. Rock #1 was too long, and Rock #7 might be too short. There was no consistent response in virtually all cases.

However, it seemed to me that when the deadline was reached the manager would say, “Hey, this is a pretty good rock! Thanks!”

A key observation in the proposed model was that what separated a good rock from an unacceptable one was what time it was delivered. If the deadline were upon us, the manager would adjust his aspirations and accept the product.

Now that I had a model for the situation, I could build a control law to optimize the process. I wanted to (a) deliver a good product and (b) minimize the number of cycles needed to achieve that goal. Clearly, I needed only to deliver a reasonably good product at the deadline and avoid as many of the intermediate reviews as possible.

The problem was, how do you implement this strategy? I picked an opportune time with a key product that I thought I could implement well that was assigned by two of the senior executives. I created a good product and then locked it in my desk drawer.

The next day one of the executives was looking for me to review the first rock. I told him that I needed more time. He was frustrated. The same thing the next day and the next. He was getting pretty annoyed. “You know how much I have to review your rocks in order to get a new one!”

Then, I used the executives against each other. When one came to review, I told him that the other one wanted to be there for the review and vice versa. That bought me a couple more days.

Finally, we are down to the last day before it was due. I had to keep dodging the executives by going to a different floor, going to the library, going to the lunch room in the FAA HQ, etc. I was told by my office mate that they were frantic, but I was nowhere to be found.

I kept this up until about 15 minutes before the pitch, I mean rock, was due. I then unlocked the drawer and gave the rock to the waiting and agitated executives. They looked at it and looked at me … “Good rock!” Off they went.

By variations of this plan, I successfully weaned them off the frequent reviews of my rocks. As a result, I could generate more rocks for the rock pile and received generally good reviews. This completed the testing phase of my control law, yielding the following [theorem]: 

[blockquote type=”left” cite=”Steve Sliwa”]Rock Theory of Management: In some organizational cultures, the perceived quality of a management deliverable depends less on the actual product and more on the proximity to its deadline.[/blockquote]

Everything went well for me after I fully implemented the strategy and tactics resulting from the Rock Theory of Management. However, after several months, I was put in an awkward position. The department head called all the program managers together for a meeting. After several topics, he ended with something to the effect of:

“We have a real problem here. I keep asking for rocks from each of you, and the only one who consistently delivers good rocks with few iterations is Steve. I am going to leave the room now and want Steve to spend a few minutes coaching you on how he is such a good ‘rock finder.’”

Needless to say, I was embarrassed and could tell by the expressions on my colleagues that I was suffering the wrath, disdain, and envy of my colleagues. However, once I explained the simplicity of the Rock Theory of Management, the tension eased, and laughter could be heard emanating from the conference room.

At that point, we made a pact to not reveal the Rock Theory of Management to the senior executives in the department for fear they would see that we used stalling tactics to train them to accept our rocks with fewer iterations.

Performance for the department improved as more rocks were created with less iteration, and as expected, the morale and job satisfaction for the program managers greatly improved.

One remarkable result for me was that I only worked in the department for six months, but since I had such an impact, most thought I served two years or more. I had my ticket punched for a ‘long’ headquarters rotation and returned to the research center where the ‘real’ work was done.

Epilogue

One of my protégés took the same assignment about five years later. The department had been reorganized, and NASA headquarters had even moved locations. Nonetheless, he told me that shortly after arriving, one of the senior program managers pulled him aside and told him about the “Rock Theory of Management” and how to work with the culture within that department. My protégé just grinned, as he knew the true story of its origin, which had long been forgotten. For more on behavior, see the Gorilla Conditioning Experiment.

 

Rock Theory of Management
Print Friendly, PDF & Email
[share title="Share this Post" facebook="true" twitter="true" google_plus="true" linkedin="true" pinterest="true" reddit="true" email="true"]