All Posts in Leadership

|In: Industry Commentary|Last Updated:

Imagine you’re about to launch the biggest strategic program in your company’s history. Who would you put in charge of it if you had your pick:

  • The best project manager currently in your employ?
  • The best project manager you could recruit using your usual internal and contract recrutiers?
  • NASA’s David Lavery, the Mars Science Laboratory program executive?

Me too.

Why has NASA been able to deliver such a stunning stream of successful projects … from the Spirit and Opportunity Mars rovers, to Cassini, to Chandra, to Odyssey, to, most recently, Curiosity?

Answer: It decided to learn from its failures rather than running from them by “holding people accountable” (ManagementSpeak for “finding a convenient scapegoat while making sure we never find out what’s really going on”).

In the late 1990s, the Mars Climate Orbiter, Polar Lander, and Deep Space 2 missions all went wrong due to easily prevented technical flubs. The Climate Orbiter mission, for example, used English units of measure for some calculations, which other calculations that used the results assumed were in metric units. This led to its entering the Martian atmosphere at too steep an angle.

In hold-’em-accountable corporate cultures, company executives would do their best to find out who screwed up and fire the sorry SOBs before they could do any more damage.

They would, that is, ensure that a new set of sorry SOBs would screw up future projects in different but parallel ways.

NASA, to its credit, performed thorough post-mortem analyses instead. The first is titled, “Mars Climate Orbiter Mishap Investigation Board Phase I Report“; the second is titled, “Report on the Loss of the Mars Polar Lander and Deep Space 2 Missions.”

While much in these reports is so deeply technical that only the nerdiest engineers would appreciate it, everyone involved in project management, sponsorship or governance in any organization should take the time to read Section 3 of the Polar Lander report, because that’s the section that discusses the management failures that underlay the missions’ technical mistakes.

The deep root cause turned out to be funding and schedule pressure: NASA tried to get these missions done quickly and on the cheap … too quickly and too cheaply. This prime root cause led to a number of project management failures, the most important of which were:

  • Inadequate staffing: Not only was the project team too small, but critical JPL experts weren’t part of the team – the project didn’t have sufficient depth of highly knowledgeable staff.
  • Excessive overtime: 60 hour weeks were habitual and 80 hour weeks were common for extended periods of time, because there just weren’t enough people on the team to get the job done on schedule any other way.
  • Insufficient communication and collaboration: Inadequate staffing and excessively long work weeks inevitably led to team members working heads-down and with blinders on. They weren’t in a position to help each other out, check each others’ work, or otherwise function as a team.
  • No system testing and validation, relying instead on analysis and modeling alone.

NASA isn’t alone in having projects fail, although unlike, say, an automobile manufacturer that releases a design flaw into production, NASA can’t issue a recall to fix the problem.

Still, just as recalls are more expensive than fixing a flaw during the design process (but less expensive than plowing into Mars at high speeds instead of landing on it), it’s a pretty good bet that your company would profit from managing its projects better, too.

So learn from NASA’s mistakes, just as NASA did. That avoiding the project management mistakes listed above makes a difference is hard to deny, given the string of successes that’s followed.

Even more important than learning from NASA’s mistakes, though, is adopting its technique for learning from its mistakes. NASA invested heavily in an independent review, didn’t duck its findings, and implemented serious changes in its procedures as a result.

I keep reading opinionators who extol the efficiency of private enterprise as compared to how gummint agencies do things. And yet, while I know of quite a few failed projects in private enterprise, I’ve yet to read of any companies that undertook equivalent attempts to understand how their management practices contributed to the failures.

It is, in the end, the difference between taking responsibility and holding people accountable. Because when executives hold people accountable, what they’re really doing is failing to take responsibility – not only for hiring and retaining the people they now need to hold accountable, but, far more important, for creating the circumstances that led to the failure and allowing them to persist.

It’s a great way to lose good employees while retaining bad managers.

Comments

|In: Career Management|Last Updated:

“When we promoted him, we lost a good engineer and gained a bad manager.”

It’s a common complaint. Engineering calls for a very different set of skills, aptitudes, and character traits than management, so there’s no particular reason to expect an engineer, no matter how smart and successful, to become a good manager.

Well, okay, there are actually two reasons to expect it, only one of them often backfires while the second one frequently fails to occur to engineers promoted into management roles.

The one that frequently backfires is that great engineers, like all great employees, have the habit of success: No matter what the assignment, they expect to get it done and get it done well, and they do whatever they have to in order to succeed in their assignments, too.

Including the assignment of being put in charge of a department. Too often, though, instead of this being a strength in their new set of responsibilities, it’s what does all the damage.

That’s because when an individual contributor does whatever it takes to succeed at something, it usually means figuring things out, picking colleagues’ brains, reading and learning, calling in favors, working more hours … you know, because you’re that kind of person yourself.

Managers, on the other hand, are supposed to keep things organized while delegating the actual work to the people who report to them.

The good ones understand that while they remain accountable for the results, they’re supposed to give both responsibility and authority to the employee to whom they’ve assigned whatever task or goal it is that they’ve delegated.

Too many engineers-turned-managers understand this only in their pre-frontal cortexes (cortices?), not their intestines — in theory, that is, but not when the rubber of that’s-how-I’m-supposed-to-delegate meets the road of maybe-the-assignee-won’t-get-it-done-right.

Worse, engineers being what they (we) are, “right” generally means “how I would have done it.”

Which is why so many engineers, when promoted into management roles, turn out to be lousy delegators, micromanaging, taking back assignments and doing things themselves at the first signs of trouble, or both.

They have the habit of success, which means that at the first sign of possible failure they do whatever it takes to prevent it.

On a task-by-task basis.

The second trait — the one that often fails to occur to them, is that they understand the form-follows-function principle and how to use it to design things that serve a well-defined purpose … and, for that matter, how to clarify the purpose of the thing they’re supposed to design, in order to put them in a position to design it properly.

Put in charge of an organization, engineers should be the best choice possible for designing the organization and the processes and practices it uses. They would be, too, except for two common blind spots. The first is that many engineers don’t think of organizational design as an engineering exercise in the first place. That’s easily fixed: Just call attention to it.

Their second blind spot, though, is themselves.

It’s all too common for engineers to organize information flows and approval processes so that everything has to loop back through them, and not just once, but several times.

Which brings us to a bit of communications protocol nostalgia (yes, KJR’s audience is capable of communications protocol nostalgia, and ain’t that grand?) — how the X.25 protocol was changed into frame relay, with an orders-of-magnitude improvement in both latency and throughput for the exact same physical connections.

X.25 assumed a high transmission error rate, and so included error-checking handshakes at every node of a multi-node transmission network. Frame relay assumes a low error rate, and so leaves the error-checking to the end points instead.

So we can call engineers-turned-managers who loop information and approval flows through themselves multiple times “worse-than-X.25 managers.” They’re worse than X.25 because, instead of relying on node-to-node handshakes as X.25 does, they pass all error-checking handshakes back to a central supervisory system instead (themselves). That slows actual transmission to a crawl.

They distrust both the links and the nodes, that is, and so they destroy both the cycle time and throughput (in network lingo, latency and bandwidth) of every process and practice they’re responsible for.

Were they to take off their succeed-at-all-costs hats and put on their engineer-the-organization hats, they’d recognize what they have to do: First, move to X.25, trusting their employees to recognize and correct errors without their having to personally intervene.

And second, establish the kind of staffing and level of trust among team members that reduces the time spent error-checking because there are fewer errors to find.

Comments