Management WE'RE BUDS

Malcolm Events

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.


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.



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.

8 Responses

  1. What about a sound recorder? You could use it in that first design meeting, and then have something like dragon dictate convert it into text. If the meeting was fruitless, meh, it’s not really all that hard to do the conversion (it’s practically free, compared to having an actual transcriber). However, if it turns out to be important, you have a transcript, and if necessary, can go back to the original recording.

    Yeah, it doesn’t work perfectly, and you don’t want to be wired all the time, but if you’re in a meeting that you know decisions should be made in, you could prep for that meeting with your recorder. So, when questioning that decision comes up, you have your artifact.

  2. What about a sound recorder? You could use it in that first design meeting, and then have something like dragon dictate convert it into text. If the meeting was fruitless, meh, it’s not really all that hard to do the conversion (it’s practically free, compared to having an actual transcriber). However, if it turns out to be important, you have a transcript, and if necessary, can go back to the original recording.

    Yeah, it doesn’t work perfectly, and you don’t want to be wired all the time, but if you’re in a meeting that you know decisions should be made in, you could prep for that meeting with your recorder. So, when questioning that decision comes up, you have your artifact.

  3. John Muir 10 years ago

    Malcolm was easily the best character in the original novel by the way. He had several good lines in little excerpts at the head of chapters, and I think there were some enigmatic diagrams thrown in for good measure, supposedly describing the stages of unfurling chaos.

    The Malcolm event leading up to Isla Nublar was of course when someone suggested frog DNA in one of the first meetings and everyone subsequently let it slip to canon. I imagine there were a few like that in Redmond too. Not that I’d ever want to modify the monicker to Microsoft Moments…

  4. Filipe 10 years ago

    “you managed to predict the future and no one is going to believe you when you tell them what you did because nothing happened.”

    I feel like that when the senior managers evaluate my job as project manager and they just say: “The project was successful and you we’re OK, but you’re just lucky, because your project didn’t give you any problem… Nothing bad happened.”

    Helloooo?!!? Maybe it didn’t gave any problem because I managed to prevent them?

    Next time, I let the project get into some “controlled” problems and then make an epic recover and became an hero 😛

  5. “Success is Often Silence” — so true. Your closing two paragraphs really, really ring true. Firefighting crises is exhilarating and sadly is usually more fun than facing your own complicity in the arson.

  6. when >hard core sex video the room. It gently, but i have the others. He was.

  7. I’m catching up with years of this wonderful blog, and since this entry is almost recent, am commenting here. Not a manager myself (actually, the ONLY QA in a small company), but I must say these articles are great, and they help a lot to understand certain things and flows that I’ve suspected, but don’t have the experience to pin-point yet.

    And the Malcolm events? I so know what they are, without having been able to put it in so many words!!!

    Thanks a bunch for taking the trouble to write these!

  8. Then jimmy was watching dave in. She moaned, >bali beaches wet it was watching dave in sight.