Star Trek and Engineering Management

Star Trek has inspired huge numbers of people to become scientists, engineers, and programmers. I’m one of them. It often inspired me to work hard, build quality systems, and never give up when looking for the root cause of a tricky bug.

When all you do as a kid is watch Star Trek, you get really excited about science and engineering. That’s huge. But you can also absorb some pretty unrealistic ideas about how engineering happens in the real world.

Those ideas might be somewhat successful when acting as an Individual Contributor, but are pretty bad when acting as an Engineering Manager, especially at an organisation as large as that shown on the fictional starship.

Let’s take a look at some of these.

The senior managers in Star Trek know everything

The commanders and captains in Star Trek — basically senior management — know every technical detail. And they use this technical information to repeatedly solve problems. Take Geordi La Forge. He’s mostly shown fixing the engines, or almost instantaneously coming up with exactly the right technical solution to whatever ails the Enterprise at the given moment.

It’s exciting, but oh-so unrealistic. The problem is that it can give you an unrealistic picture of what is expected of you as an Engineering Manager.

In the real world his job would be to hire and manage the senior engineers in his organization. Geordi would be using his technical experience — even though it would be going stale — to evaluate his senior staff, to guide them through their careers. He would set standards, and make sure the culture was healthy. But performing research new Transporter technology? If only.

Problems always solved with a single key insight

This is one of the most romantic, exciting elements of Star Trek. But it’s completely unrealistic in the real world of software and systems engineering. Real problems are almost never solved with a single key insight.

Almost no, deep, real-world problem has a single technical answer. Solutions are often sub-optimal, with real-world constraints such as lack of time, resources, and skills being painfully obvious. Solutions  are often changes to how people work, the processes, and sometimes even the people themselves. Most problems aren’t solved by technology alone, but by changing the interface and relationship between the technology and the people.

Command-and-control is unrealistically effective

As a TV show that is often about solving problems by brain power, it’s too focused on command-and-control. Too many decisions come from the top, whereas serious technical decisions in a software firm usually emerge after prolonged discussion and debate amongst the developers working on the problem.

Of course, Star Trek is often about battles, conflict, and military decisions. Then command-and-control makes sense. But, in Star Trek,  too many times a technical decision is made at senior levels and pushed down into the lower levels. It doesn’t work like this in real world. But the problem again is that it gives you the idea that you, the Engineering Manager, must find the technical solutions — instead of hiring, developing, and helping your staff solve those problems.

Promotes heroics

Of course, Star Trek is about heroes. And the heroes are often engineers and scientists. But long term software engineering is not about heroics. It’s possible to do amazing work when operating as a hero — particularly at a startup where it’s often the default mode of action. But any valuable system, built for the long term, can’t rely on the heroic actions of a single person.

Designing for heroes, relying on heroes, is a pretty clear sign of failed design, and failed management.

But pretty good people management

The people management on Star Trek is different though.

The senior people in Star Trek trust the people around them, hold them to high standards, and admonish their team when they violate the shared code. And those  same leaders are people of principle, inspiring their teams to do better.

Those are the lessons to learn. And enjoy the engineering stories, but don’t let it influence you about how engineering should be managed.

Leave a Reply

Your email address will not be published. Required fields are marked *