You Have To Let the Project Break So You Can Prove Yourself By Fixing It
Why do project managers have to create crises on projects to prove that the risk management steps you took are paying off? It’s very common in project environments. The project manager who scrambles to get things done, who stays late to get things fixed, who has problem after problem that gets the attention of management but who then gets things accomplished, albeit a bit late seems to get the promotions.
“There’s a go-getter who gets things done!” goes the cry from the executive office.
If you do your job as a project manager, you almost never have these issues because you balance the risks properly. But that will never get you promoted in most environments because your manager doesn’t think you’re doing any work/. Getting superior results is almost always irrelevant.
Similar problems happen in the military, too. A general who never actually fights because he prevents war is never considered as highly as the one who goes to war and then wins, even when the superior general wins before the fighting starts.
Bob Colwell touched on this several years ago in an article for IEEE Computer. (“Engineers as Soothsayers“, Computer, 37(9):6-9 ) He had been Intel’s chief IA32 architect for years and had a technical expert’s inner view of the workings of what you would think was a technical company.
Not as much as you would think.
In 1996, Colwell had successfully brought in a large effort that led to the Pentium P6. One of the things he did was anticipate problems that had plagued other chip manufacturers. He hired ten extra workers who had experience in it because he believed it would allow him to find the problems before they exploded and deal with them early. He sat down with an Intel executive reviewing the project, who pointed that Colwell had done the hired and that part “came out right.”
I thought, Yes, that’s right, you should praise my foresight. I saved you a lot of money, and you’re lucky you have me on your team.
But then he said, “Looks like you didn’t need them after all.” I was staggered. What? No! They are the reason it came out right! He just smiled. I wasn’t smiling.
Michael Raynor might say that Colwell was attempting to create strategic options (having the experts on staff) that might not be required to put into play.
There are a couple of issues in play here. One is the difference between what Warren Kinston calls the “Organizational Life” domain of work and the “Disciplinary” domain. One is normal organizational workers and managers. The other are experts in a particular technical discipline.
They just aren’t going to understand each other because they using words in different ways when they talk about work.
The other issue is one of time span of discretion of the job roles and time horizon of the individuals. Colwell was anticipating a problem that may not have displayed for a long time. He could see that this was an issue. The executive couldn’t. He lacked both the knowledge of the domain, because he wasn’t a technical expert, and the time horizon necessary to foresee what potential issues might be that would require options.
Of course, as Mark Van Clieaf once pointed out to me in an email:
we also need to distinguish between
Time-span for planning and
Time-span for decision discretion (accountability)
two separate measures
Elliott Jaques, who discovered Time Span of Discretion, said that delegating the planning function was anathema (OK, he just said it was stupid and shouldn’t be done). The late Harald Solaas (who is sorely missed) wrote about Jaques comments to him during the late 1990s about this issue. He said that Jaques was clear: someone who is only accountable for putting together a plan only requires a time horizon of the time-span of the task. They don’t need a time horizon of four years for a three year long project. Time span measures the extent of the freedom and accountability.
So what can you do when you encounter this at work?
This may sound mad, but people who are successful know how to play the game. And here the game requires things to break. You need to have crises that you then step in and solve, looking like a hero. (Yes, this does sound like organizational Münchausen syndrome.)
Think about the definition of success in reality. It’s not “get this project done on-time and within budget” but “show us that you handle emergencies”.
And if you’re a manager who is in charge of project managers, don’t be an idiot.
[I've replied to the comments is at "If Your Boss Doesn’t Want You Preventing Problems, What Is Ethical To Do?"]
Image credit: Men of Fort Story operate an azimuth instrument, to measure the angle of splash in sea-target practice. 1942. Via Library of Congress. (reversed)