Pre-Launch Checklist

What follows are some observations and ideas that are inspired by “Project Hail Mary”, both the book by Andy Weir and the movie it inspired. If you haven’t read/watched them (and I highly recommend you do!) and you don’t want it spoiled, you should probably stop reading, bookmark this page, and come back later.

Countdown

As someone who has worked in I.T for over 30 years, I long ago got comfortable with the idea that part of my job was to be a “lifelong learner” – someone who routinely picks up new skills and information in order to keep working. Most of the time, that learning happens at the shoulder of a colleague, taking a course, watching a video, or reading a blog.

All of which are deeply technical types of content. There might be a Star Trek reference or two, but otherwise high adventure and thrilling plot twists are in short supply. Which is too bad, because it can all get pretty dry.

Maybe that’s why, over the years, I’ve looked for (and found) lessons for I.T. practitioners in more popular forms of media – everything from SpiderMan to The Lord of the Rings. No, you probably won’t discover command-line options for kubctl in the midst of the battle at Helm’s Deep, but in the midst of the banter between Gimli and Legolas you just might find an idea or two to better leverage what you know about kubernetes.

And so, in that same spirit I am sharing some of the I.T lessons I found in the story of Grace and Rocky and their heroic adventure among the stars.

Launch

Never Give Up

If there is one lesson I think IT practitioners can take away from the story of Dr. Ryland Grace (who I’m referring to as “Grace” from this point forward), Rocky and the planets they’re trying to save, it’s that you should NEVER give up. I know that sounds cliche’d and overly simplistic, but it still holds true: In the face of a dying sun, humanity chose to come together and first gather information about the threat, then bring the best and brightest minds to analyze that threat and create a plan that might save everyone. In doing so, false obstacles were removed (like considering a junior high school science teacher to be part of this planet-saving operation). The only thing that mattered was both willingness and competence.

And that theme continued throughout the story. Despite a series of challenges that would overwhelm many of us, the characters in the story chose to believe there was a solution, and continued acting as if there was one, they just didn’t know it yet.

In tech, I think the same attitude serves us well. Whether it’s code that won’t compile, or a cluster that won’t build, or an application interface that users find confusing, there is always a solution. Sometimes it’s hidden; sometimes we need to bring in another expert with a different point of view; and sometimes we need to ask whether the problem is even real, or if it’s a manifestation of our own fear or insecurity.

To elaborate, I want to share an experience from almost 20 years ago:

I’d gone to a week long technical “boot camp” – a program designed to help teach me the skills I needed to pass a certification test. The week culminated in the actual test, for those who felt they were prepared enough.

I was in the room with one other student. The exam was proctored, with an observer in the room to both help in case the technology had a problem and also to ensure there was no cheating. As the test progressed, the other student became increasingly more agitated – grumbling, slamming the keyboard, pacing the room, etc. The proctor gave him a little latitude but at a certain point reminded him that there were test rules that had to be observed.

As the clock ran down, this other person gave up. He said there was no way he was going to pass, and he didn’t want to see his miserable score. He got up and left the room. The proctor went to the testing station and clicked through the remaining questions to force the test to end.

There were 10 questions left. He missed passing by 3 points. The reality was that he could have just randomly guessed at the answers and probably squeaked by.

I will admit to having felt the exact same way during certification exams: the absolute certainty that I’d missed every single question, that it was mathematically impossible to pass. In those moments, memory of that other student has kept my butt in the seat and my head in the game. And in almost every situation, I passed by a much wider margin than I had thought possible.

To come back to “Project Hail Mary”, there are times when – like Grace – we’re braver, more resourceful, more capable than we give ourselves credit for. Keep going. Never give up.

Have Someone You Need to Be Brave For

Continuing on that idea of bravery: When it becomes obvious that the mission to Tau Ceti will be a one-way trip, Grace tells mission commander Yáo Li-Jie that he could never do what they’re doing, that he doesn’t have that bravery in him. Yáo replies that Grace just needs someone to be brave for.

Much has been made of the moment near the end of the story, when Grace turns his ship around to save Rocky, even though it means he will never make it home. And that was brave, and it was because he’d found someone he needed to be brave for. But to be honest, Grace shows innate courage throughout the story – from telling Rocky he’s OK with dying (even though he’s terrified of it); to repeatedly taking risks in order to collect data, complete a task, and even to face and learn to interact with a completely alien entity.

The lesson for us is this: Working in tech is neither simple nor stable. We are going to be lifelong learners – the tech doesn’t stop changing and therefore neither can we. It demands (or seems to demand) long hours and sudden interruptions. There’s a certain culture of heroic firefighting that permeates the industry, even though many of us have acknowledged how unhealthy it can become.

For many of us, a career in tech can either burn us out or burn us up. Few are the leaders who keep track of our efforts and say, even in the middle of the work day “You know what? you’ve done enough for one day. Pack it up and hit it again tomorrow when you’re fresh.” That boundary has to come from within ourselves.

And for many of us the strength to find, set, and hold that boundary comes from whoever “we’re being brave for” – meaning whatever greater goal or relationship we’re working for.

Eva Stratt is the quintessential tech leader

Eva Stratt is something of an enigma, both in the book and the movie. She weilds a vast amount of power, seemingly without anxiety or ego. She is single-mindedly driven by the mission to identify the threat to the sun, then to find a solution, then to execute that solution. She’s extremely clear-eyed about what is likely to happen once the existential threat is over, or when the inevitable fallout of the current situation becomes too great to ignore. But until then she is willing to do whatever is needed to save as many people as possible.

Why do I think that’s similar to a great IT leader? I’ve long said that, to be a good manager of techical folks, one doesn’t need to be the best technician. Instead, it’s important to:

• surround yourself with good people.
• tell them the goals of the organization.
• ask them for the best way to achieve those goals.
• BELIEVE WHAT THEY TELL YOU.
• Clear a path for them to do the work.

This is precisely what Eva Stratt does.

IT managers who understand (and do) this are the ones that enable their team (and the larger organization) to achieve spectacular results. Obviously no result is guarenteed, but managers who follow this model succeed far more often than those who do otherwise.

One other thing that Eva does is makes the stakes for both success and failure clear to the team. She doesn’t hide it or sugar coat it. Far from upsetting or distracting the team, doing so provides critical context for their choices. Early in my career I had an experience that demonstrated exactly how important that context could be:

I was working in a manufacturing facility, and one of the Zebra printers (a case of perfect brand naming for a device that created barcode labels) wasn’t working. I took a look and realized it was going to take me a bit of time to figure out the issue. The problem was that it was coming near the end of my shift, and I needed to get home before my kids got off the bus from school. I told the manager in charge of the production line that I could get to it first thing the next day.

“That’s absolutely understandable,” he said, sounding completely sincere. “You’ve got to take care of your family. But before you go I just want to make sure you understand the situation so you’re not blindsided: None of the parts were’re making can ship without that barcode. And that’s the only zebra we’ve got. And each board is about $5,000 of profit for us.”

I looked at the backlog and realized there were close to 100 boards already waiting for labels, and more coming off the line.

I made a couple of phone calls, re-arranged some things, and stayed on the line until the problem was solved.

The point isn’t any heroics on my part. It’s that I would have made a bad choice without realizing it until tempers flared and everyone was caught up in the typical cycle of blame, justifications, and attempts to cover respective backsides.

Eva Stratt does the same thing, over and over throughout the story.

And the final thing that Eva does that makes her such a great role model is that she takes the time to honestly assess and understand the real strengths of her team – beyond what they say (or believe) about themselves. This, of course, lies at the crux of one of the major twists in the story, in that Eva understands how Grace will rise to the occaision even when he himself is certain he doesn’t have it in him.

Our Journey to the Stars Has Only Just Begun

Like science itself, there are many more lessons for IT professionals waiting to be discovered inside “Project Hail Mary”. In the coming posts, I’m going to explore more of them. In the meanwhile, if you have observations or insights of your own, I would love to hear about them in the comments below.

Until then, ad astra, hopefully without the per aspera.