Engineering management

Most of my friends engaged in management (and marketing) carry a common perception about engineering positions. They believe that when it comes to people versus computers, a job that involves engaging people is always harder and more complex than engaging machines.

For discussion, I assume hard to indicate a class of problems where acheiving a goal appears challenging and uncertain, and often the stakes for success are not trivial but high.

Fernando Alonso - Williams Renault

I thought back to a long time ago. Back then the designers, engineers, and scientists who built the fastest race automobiles on our planet inspired me. As I stared into the pictures of drivers Alain Prost, Niki Lauda, and Ayrton Senna taking hairpins, chicanes and straight-runs at insane speeds – I more than anything coveted the opportunity to behind one of those machines. I thought “what does it take to make these cars go that fast?”. I knew then that I wanted to be an engineering success.

Fast forward a couple of decades and I find myself speeding up machines of another pedigree. Sure, my position is not as coveted as an engineering position on team Ferrari or Renault. One truth remains universal, engineering is damn right hard.

Be it competing on a race track, or in the Internet space, or elsewhere – engineering is a complex and never-ending process. If it comes down to understanding the properties of a machine to leverage and optimize it, your understanding will remain incomplete until you day after day get out on that race-track and push the car to its limits. On race day, while a success can be spectacular and breathtaking, an engineering failure can be equally foreboding in magnitude. A coveted engineering position can then quickly turn into a position no one would want to hold. Space Shuttle Columbia

Space shuttle Columbia. On February 1st, 2003, the space shuttle disintegrated on re-entering the earths atmosphere killing all seven crew members on board. It was also a huge public relations disaster for NASA since investigations revealed NASA did not do enough to prevent it. During takeoff, foam from the external tank of the Columbia struck and damaged the left wing. Going by previous experience, damage assessment photographs, reports from the crew, and other information a team of engineers and scientists from Boeing had concluded that the Shuttle could land safely despite the damage.

From the Columbia Accident Investigation Board, press release (August 26, 2003), highlighted that the accident was the result of an engineering and management failure to ensure the safety of the shuttle.

The CAIB report concludes that while NASA’s present Space Shuttle is not inherently unsafe, a number of mechanical fixes are required to make the Shuttle safer in the short term. The report also concludes that NASA’s management system is unsafe to manage the shuttle system beyond the short term and that the agency does not have a strong safety culture.

The BBC BlackBerry bug. Imagine getting e-mail delivery wrong when your customer specifically pays for security and delivery! Research in Motion did exactly that with the BBC in the UK. They were managed to avoid a tremendous amount of bad press simply because the bug was a known bug and that information had been conveyed to all customers with the option to upgrade their systems. If things had gone terribly wrong, no management person I know would want to trade places with the engineer who had the distinction of shipping that bug.

I am sure you have heard of the Y2k problem, what a dud that was! But have you heard of the year 2038 problem on Unix?

What do you think? While failures can be uncompromisingly purely engineering, I cannot think of a single instance where success was purely engineering. Similarly, I am convinced that there is no such thing as a management success. While I try to keep the references to Bill Gates on this blog to a bare minimum (I truly feel Microsoft can be evil at times) he undoubtedly is the biggest business, management, and engineering success in my field of work.

Ever since Bill wrote Microsoft Basic and later commercialized Microsoft DOS (edit: dan pointed out that Bill did not write the original DOS that later formed the basis for MS-DOS, but Bill did write the BASIC interpreter with Paul Allen and Monte Davidoff), people have written better programming platforms than Basic, better operating systems than DOS ;-), only did he actually make it to the Time 100, Builders and Titans.

References.