There is a long-standing perk for working at high tech companies. If there is a nerd-relevant movie coming out, it is the obligation of management to get a sneak preview for the engineering team. An opening day morning showing works, but has significantly less morale impact than the sneak preview earlier in the week as it denies the engineering team critical bragging rights within their nerd community.

When Borland sent the engineering team to see the original Jurassic Park TWO DAYS before the opening, they created the single largest improvement in engineering morale in the history of the company. Intellectual candy and bragging rights, folks, that’s all you need to hand out.

The nerd frenzy around the movie was significant and was lead by the promise of “life-like computer animation”. So, it’s a win-win for engineers. Not only do we tap into our primal dinosaur love, but we also get to watch the first movie where dinosaurs actually show up and, by the way, using THE TOOLS WE WROTE. Ok, so Borland was writing programming languages and applications in the early 90s, but those ILM GUYS ARE JUST DOWN THE STREET. WE’RE BUDS.

Strangely, thirteen years later, the memory that has stuck with me from the movie was a quote by Jeff Goldblum’s character, Ian Malcolm. He was sitting in the Jurassic SUV, busily hitting on Laura Dern, trying to explain chaos theory to a paleobotanist, when he made a comment that burned itself into my brain.

He was demonstrating chaos theory by placing drops of water on the top of her raised hand and asking, “Which way is it going to fall?” (Smooth, really smooth, Jeff) The drops fell in a different direction each time and Malcolm attributed this to, “… the principle of tiny variations — the orientations of the hairs on your hand, the amount of blood distending in the skin, [they] never repeat, and vastly affect the outcome…”

For you nerds out there, go read about the butterfly effect. But for me, the quote encapsulates an essential part of practical software design. It’s been years since I saw the movie. In that time, the quote has mutated. It’s now “Seemingly insignificant events which are intent on screwing you in an unlikely way.” These are Malcolm Events.

We’re in a Hurry

We’re always in a hurry in the Silicon Valley. If we’re not making new stuff, we’re making stuff to help us make new stuff. Our stuff building process varies from company to company, but it usually follows a cycle that looks like:

Design: Think up new stuff to make, talk a lot, throw a lot away, talk some more

Development: Less talking, more doing. Engineers are heads down and manager’s are wondering what they’re supposed to do

Deploy: More talking, some yelling, managers are busily keeping everyone from killing each other, and then it’s suddenly… done.

We’re in the design phase right now, you and I. I’m the manager, you’re the senior engineer and we’re brainstorming our next release. We’ve each got a fuzzy picture of what we want to to do in the next release, but it’s not clear. There’s nothing that defines the picture, so we’re just throwing ideas against the wall to see what’s going to stick.

Nothing appears to be sticking until you say something off the cuff; I take the idea, riff on it, write it on the white board and WHAM… that’s The Feature. It’s the piece of work, the design, that will define your release. We know it is because we both sit there staring at the white board at The Feature knowing that this moment will define everything after it. Doesn’t happen often, savor it.

This is not a Malcolm Event. This moment is akin to a Holy Shit moment when you first understand a marvelous newtechnology. You must have these moments to have an inspired release, but this isn’t where you’re going to screw up.

Let’s keep moving.

Great, so we’ve got The Feature. Now, the frenzy begins. We can’t keep our paws off the white board because we know that in the next fifteen minutes, the rest of the features are just going to come pouring out. Now, during the frenzy, a whole pile of decisions are going to be made and while we’re valiantly going to try to capture them on our white board, we’re going to miss a few.

I want to pick one of these missed decisions. At first glance, it’s not a big decision. In fact, in the creative frenzy that is the discovery of a release, it’s a really small decision. When the meeting is over, we forget that it was made because we’re digesting the mental high imparted by this discovery of The Feature.

Problem is, this decision does matter. What you don’t know is that this decision clarifies The Feature in critical way for those who weren’t in the first meeting frenzy. By the way, THAT’S EVERYONE.

This is a Malcolm Event. And, right now, it’s a failed one.

Understanding Malcolm Events

What — whoa , whoa — wait a second Rands, we failed? We just designed a killer feature and we failed?

Yes, we did.

It’s a month later and development has begun and more folks are involved. Someone asks you a question about The Feature and the answer is the decision that was forgotten. No big deal, you answer the question and move on. A week later, you get asked the same question by a QA guy. Haven’t you already answered this question? Yeah, you did. Ok, no big deal. Here’s the answer.

Another month passes and by your count, you’ve been asked the same clarifying question ten times and you’re wondering, “Don’t people get it? Isn’t it obvious what the answer is?”

No, they don’t. They weren’t in the religious experience that was your original design meeting and, more bad news, these people who are asking the questions — they aren’t the problem. It’s the people who aren’t asking. It’s the ones who are assuming an answer to the question and not asking. They’re thinking, “Well, if it was important, someone would’ve told me or written it down, right?”

A failed Malcolm Event is when a seemingly insignificant event screws up your release in an unlikely way. In the case of this clarifying decision, it’s a poor communication tax. Everyone is wondering about this odd aspect of The Feature and in that confusion they are wasting time and they are wasting money.

The release might go swimmingly. The failed Malcolm Event might just be an annoyance where, in every meeting, someone asks THE SAME LAME QUESTION. Or maybe you’re not so lucky. Maybe the documentation folks never bother to ask a clarification question and your documentation describes your feature poorly. Even worse, maybe the developer responsible for The Feature spends a month developing to his version of reality before you install a build and figure out that people can’t read your mind.

There is a wide spectrum of cost for failed Malcolm Events, so let’s not let them fail.

Artifacts

Someone who has been reading this piece has had their hand up for most of the article. Ok, what’s your question?

“Rands, you’re talking about specifications! Functional specifications! Interaction designs, visual designs, and wireframes! Who doesn’t love wire-”

Ok, hand down.

No, this is not a piece that is going to describe the many benefits of writing stuff down and, yes, there are many benefits, but this is a heavy handed approach for building successful Malcolm Events.

Remember, we’re talking about the little stuff here. I’m not talking about the broad strokes of a release, I’m talking about the seemingly inconsequential details that are intent on screwing you. A well-written specification will document all of your details, but do you have time to write and maintain specifications? I don’t. I’m coming up on a decade and a half of working at fairly successful companies and I can count the number of useful specifications I’ve read on two hands. Really.

The issue isn’t that specifications are a bad idea, it’s that they are time-consuming and, remember, we’re in a hurry. Still, something does need to be captured because the first thing we need for a successful Malcolm Event is an artifact.

An artifact captures an essential piece of knowledge. Yes, it can be a specification or a blurb or a picture or a priority or even an owner. The key is you’ve got to know it’s essential to capture this artifact because you’ve been here before and you know that if this piece of knowledge is not well understood across the organization, you’re screwed.

I learned this the hard way during the second release of our product at the start-up. In an early brainstorming meeting, our VP of Sales spent a good hour explaining the need for better performance. We all nodded knowing that a future release we were moving to a new application server that would improve our performance issues. The problem was, no one ever told the VP “No” and, worse, when the product shipped, the performance was slightly worse. When the VP found out, he was in my office yelling for a solid thirty minutes.

In our next release, we correctly decided to hold off the application server for another six months and every single feature list I wrote had the following line, in bold, at the top of the list, “No performance increases in this release”.

Malcolm Event detection is simply the hardest part of your job because it’s the art of identifying the significantly insignificant and I’d like to provide some great advice here, but my advice is simple and unfortunate. The only way you’re learn going to identify potential Malcolm Events is by going through some horrible, horrible experiences.

Sorry.

Binders

Great, so using your past horrible experiences, you’ve captured an artifact. Let’s say it’s a semi-scribbled drawing of a brilliant UI design. Congratulations on your foresight to write something down. Now what? Where do you keep that drawing? In your Moleskin? Well, that’s fashionable and useless. An artifact stuff in your notebook is akin to not writing down at all.

Successful artifact management is the key to successful Malcolm Events and the key to successful artifact management are the three As. These are:

Availability: Your artifact matters. You already know that, but does everyone else? It needs to be sitting somewhere where anyone who cares is going to trip over it. It’s a wiki page, it’s a email sent to everyone, it’s a presentation. I don’t know what your organization communication patterns are, but you’ve got to stick your artifact in the middle of it. “Folks, this scribble is our future”. This leads us to:

Agreement: The reason you created your artifact is because you believe you’ve identified a critical piece of information where critical could mean novel, controversial, or just important. By making your artifact available to the team, you’re saying, “Pay attention to me” and this a critical juncture. This is when you consign a Malcolm Event to oblivion because you’re making it common knowledge. It sounds like I’m just describing availability again, but I’m not. I’m talking about the hallway argument that goes down when Phil reads your weekly status reports and it reads, “We’re not doing Phil’s favorite feature.”

So, you and Phil have it out. You debate pros and cons, he gives a little, you give a little, and suddenly, it’s ok. We don’t need to do Phil’s feature because we’re doing this other feature and Phil understands why.

Accuracy: This is the easiest part of the three As. As your artifact soaks through the organization, it’s going to change. Folks are going to tweak the scribble, Phil is going to request a minor change, and your artifact is going to evolve. Take the time to revise the artifact as it evolves in the hallway because you never know what minor change might set-off some random person who was fine with the first version of the artifact.

Availability, agreement, and accuracy. I call these nouns binders because they bind people to the Malcolm Event. If they see, read it, and comment on it, it becomes bound to them. It’s no longer an insignificant event, it’s common knowledge.

Success is Often Silence

A successful Malcolm Event is completely unsatisfying and here’s why: you know what failure sounds like, but success is silent. It’s when the release goes well. It’s when you don’t have to release an immediate update to your major release. A successful Malcolm Event is when you managed to predict the future and no one is going to believe you when you tell them what you did because nothing happened.

Management is the care and feeding of the invisible. You’re doing your best when it appears the least is happening. I love the thrill of the last month of a release as much as the next guy, but I suspect the reason we’re yelling at each other, working weekends, and feeling the depressing weight of compromise is because we’re surrounded by failing Malcolm Events.