Story: Using the Patterns of Myths and Legends to Build Better Systems

Posted by Les Chambers on June 18, 2012
Project Management, Requirements, Story

The current fashion of eliciting software requirements by collecting user stories is pathetically superficial. The educated use of stories has a much deeper purpose in systems engineering, and that is to reveal the fundamental principles that drive successful systems development. The story patterns of myth and legend hold eternal wisdom known since the fall of man into the field of time. Projecting these patterns onto technology projects leads to more insightful decision making in every aspect of complex systems development.

Knowledge, Belief and Insight

She embraces me and murmurs, “You engineers … know … don’t you?”

Hey hey. No point in arguing with a California girl, so lovely, with a notion so pure, so beautiful and so true.

“Yes darlin we know.”

Its a Sunday morning, 2am in 1976.  I’m at a party in the San Francisco Bay Area. It’s winding down and I’m on my way home … maybe.

That was then, a delicious thought on the night, but years later a more sober and wiser head tells me that pure knowledge is not enough. Technological advances are organized by lone mavericks who not only present knowledge but also instill belief. And to achieve this you need insight. The ability to create new realities that humanity comes to love even as it looks elsewhere.

What’s the secret? Did Steve Jobs, Bill Gates, Jeff Bazos and Mark Zuckerburg drink from some wellspring of genius? Or did they just know how the story was going to play out.  How did they do that – dictate reality for the citizens of planet earth.

In 2003 I read something that made me wonder: a Harvard Business Review article, Storytelling That Moves People [1].

Believing in Story

You might ask what would possess an engineer to study dramatic theory? In my case the inciting incident was the HBR story. It turns out that some American companies hire Hollywood storytellers to help them pitch investment opportunities to Wall Street bankers. On the meanest street in the world some of these guys have one hundred percent success rates. Why? Put simply while the traditional businessman peddles knowledge (of the business and future market trends), the storyteller sells belief. It seems that a business case wrapped around the emotional charge of an engaging story has a strange power to persuade.

Intrigued, I dug deeper into the tradition of myth and legend, the wellspring of all stories. I put principle into practice and became a believer. Now I put it to you that:

Understanding the fundamentals of a good story will make you a more effective systems engineer.

Story telling communicates and persuades because, regardless of language and culture,  human beings are hard wired to receive information in story forms.  These primal patterns, embedded in myths and legends, are the closest thing we have to a model of the real world. J.K. Rowling once mused, “Human beings can learn and understand without having experience. They can think themselves into other people’s places.”  The evidence is strong that storytelling can have a profound influence on human behavior.  Stories inform our belief systems and, some say, tell us how to live.

Meeting the Story Men

The storyteller in the HBR article was Robert McKee author of Story [2]. Robert trains Hollywood scriptwriters. His students have included the writers and directors of movies such as Forrest Gump, Erin Brockovich, The Color Purple, Gandhi and Monty Python and the Holy Grail. Intrigued by Mr One Hundred Percent and sensing a gap in my education I read Robert’s book and was impressed by his insights into human nature. His story metaphors projected effortlessly onto software engineering. I recognised story patterns in all my software projects and his character archetypes explained the behaviour of the every-day cast of characters on a project team. I followed up with Christopher Vogler’s The Writer’s Journey [3], Jay Parini’s Why Poetry Matters [4] and finally Joe Campbell’s Hero With a Thousand Faces [5].

Drilling down, I uncovered the canon of story together with its connections. Campbell’s work was informed by Aristotle’s dramatic theories. Campbell drew on everything from the philosophy of religion to bizarre Eskimo fairy tales. Vogler summarised Campbell in a few pages for Hollywood scriptwriters. George Lucas, the creator of the Star Wars, was a student of Campbell. Star Wars played out the mythic form with perfect pitch and eased words into the language with an alacrity not seen since Shakespeare: the dark side, the Jedi and the force.

The wisdom in myth and legend beckoned. I’d fallen down a rabbit hole into a supernatural world populated with strangely familiar characters, events and situations and they began to project themselves onto my life in systems engineering.

Life – the Ultimate Metaphor

In systems analysis and design we constantly seek out abstractions – metaphors. We model control systems with state machines, we represent business processes with data flow diagrams. We use models to make sense of a complex soup of process, data and state. Models allow us to classify and compartmentalise elements of a system so our feeble brains can deal with the complexity. Models also allow us to identify what is missing or illogical.

Our models are our metaphors. We need them to extend the boundaries of thought by extending the boundaries of expression.

Ha! This thought is not mine. I am channelling Jay Parini; but he isn’t talking about technology; he’s reflecting on the purpose of poetry. Does this qualify technologists such as Alan Kay, pioneer of object oriented programming, as a poet of our particular genre?

And so further on down I fell into the depths of the rabbit hole, into the field of time grasping insights along the way, weightless and wondering if, in the field of story, I’d found timeless practical wisdom.

Could story be the ultimate abstraction, the grand unified theory, the wisdom that makes sense of life itself?

Transforming Reality

The world of story is a parallel universe to an engineer. It is a place of unease with the unfamiliar but strangely logical. You meet with the psychological archetypes of Jung and Nietzsche and come upon fundamental truths like Robert Frost’s:

A person not educated in the operations of metaphor is not safe in the world.

You inhale Joe Campbell’s deliciously nondeterministic pronouncement that:

myth is the secret opening through which the inexhaustible energies of the cosmos pour into human cultural manifestation. Religions, philosophies, arts, the social forms of primitive and historic man, prime discoveries in science and technology, the very dreams that blister sleep, boil up from the basic, magic ring of myth.

True, this sounds like arty BS to most engineers … but then on the six o’clock news you watch an embarrassed politician whine, “Yes we spent $200 million on the payroll system. We did our best but it doesn’t work and we don’t understand why. Maybe we just asked too much of the technology.” And all you see is the modern incarnation of Daedalus, in a suit and tie, lamenting the death of his son Icarus who ignored his father’s advice and flew too close to the sun.

Time passes and you begin to believe in the hypnotic power of myth that is everywhere and through time always the same and most importantly you begin to appreciate the power of language to transform reality, stories told in the pattern of myth match our dreams and resonate with psychological truth. People engage with, remember and are influenced by – stories.

Steve Jobs must have seen this at Pixar as his creatives rolled out the Toy Story movies to commercial and critical acclaim. In this time he perfected his fabled “reality distortion field”, the presence that swirled around him transforming the reality of all in its sway. “No, it is not impossible. Yes, you can achieve my objectives.”

Applying the Story Pattern

There came a day when I had read enough. It was time to introduce story into my training and consulting. My functional safety presentations featured Les Chambers in jeopardy, holding a giant live crab, its lethal pincers seeking out the flesh of my arm, a potent metaphor for risk. More than eight years later the people who were in the room report, “I remember risk and the crab.” The crab, redolent with persuasive dramatic energy, became an international superstar featuring in my latest video on risk management.

Risk Metaphor

Metaphor for Risk

Encouraged by this initial and somewhat accidental success I looked for ways to amp up the dramatic intensity. And it’s borne fruit! My post on Extreme Review featuring naked babies in jeopardy and a clinical dismemberment of a project proposal by space shuttle engineers, resonated with many readers. At least one respondent reported that he had reinstituted a formal review process.

Man is the only creature that can wound from a distance, could it be that he can also persuade at long range – with a story?

In this arcane world, hither to the province of writers and poets, had I found a magical source of influence, had I discovered the user manual for the human race?

It’s worth looking into. Aristotle, McKee, Vogler, Campbell; these deconstructors of the mythic form have a rattling good tale to tell and it begins so …

Once Upon a Time a Long Long Time Ago

In ancient Athens the Greek philosopher Aristotle studied the form of drama, comedy, poetry and tragedy. In 335 BC he published the Poetics, the earliest surviving work of dramatic theory. The Poetics abstracts the story form in terms of mythos (plot), the sequence and arrangement of events and ethos (character), the behaviour patterns of protagonists.

Through history the Poetics was overshadowed by Aristotle’s more famous work The Rhetoric which was of higher value to law and politics – that is until modern times when movies became a multi billion dollar industry. Twentieth century writers and movie makers such as Lucas, McKee and Vogler set these forms to alchemy, fashioning rough ideas into characters and plots that fascinate people. The result: movie blockbuster gold.

But here’s the rub: stories are much more than entertainment, they impact audiences in deep and permanent ways and they help us see ourselves and the world around us more clearly. Stories encapsulate the truth of human nature. Instinctively we seem to know that myths didn’t happen, they just are.

Dangerous Persuasion

The persuasive power of the dramatic form was recognised even in Aristotle’s day. In 388 BC Plato, student of Socrates and teacher of Aristotle, lobbied the city fathers of Athens to expel all poets and storytellers. They are corrupting our youth, he argued. They deal with ideas but not in the open, rational manner of philosophers. They feed us ideas in the seductive wrappings of stories causing us to believe even the morally repellent. They are dangerous people. He was right.

How does the U.S. Navy convince thousands of young men to sign up for the most dangerous job in the world: flying strike jets off an aircraft carrier, day and night and in all weather? They use stories.

Take the movie Top Gun. They invited Hollywood aboard the aircraft carrier USS Enterprise and made available several aircraft from F-14 fighter squadron, Screaming Eagles. The result was compelling. The images were irresistible to young Americans. Picture this: Naval aviator Maverick (Tom Cruise) swaggers across a flight deck against a backdrop of F-14A Tomcats, strike jets trailing afterburners rip a flaming trench in the night sky and the clincher: Maverick high-fives his Radar Intercept Officer Goose (Anthony Edwards) with the war cry that went into the language, “I have the need, the need for speed”. “Where do I sign up,” they say.

Would that the energy released in us by compelling stories be projected onto our working life.

Would that the empathy we feel for a Maverick and a Goose be projected onto our customers.

Would that the sharp focus and intense concentration we apply to following the arc of a compelling story be applied to pursuing our customer’s needs toward a happy ending.

Why Engineers Need Story

What has mythology got to do with systems engineering? A lot.

Traditional systems engineers record customer needs in the requirements phase of a project. We look for overriding objectives and themes. We analyse, organise, model, prototype and present our findings. Then we ask, “Is this what you want? Sign here.” Caught like a rabbit in the headlights of a non-rushing project the client signs and we cross the threshold into design. Millions flow in sweat and treasure, our bright shiny new machine comes into being and along the way we learn more, but at the end , too often, to our horror we trip over Pixar’s third rule of storytelling:

#3: Trying for theme is important, but you won’t see what the story is actually about til you’re at the end of it. Now rewrite.

This is a repeating theme already preserved in software engineering myth. Fred Brooks coined it when he managed IBM’s OS/360 operating system development. “Plan to throw one away; you will, anyhow,” he said. Where is this written? In his book, The Mythical Man-Month [6]. Where else.

I’ve lived this story twice in my career. The resultant eye watering waste with developers on the street looking for a job isn’t funny. My personal view is that passive acceptance of throwaway systems is no longer an option and that the core of the problem is passive acceptance of the client as oracle. To be concise:

Documenting the customer’s stated needs is the starting point of the requirements phase not its end.

We must assume that some needs remain in the shadows, unspoken, repressed and buried in the collective subconscious.

The analysts’ job is to confront them and bring them into the light of day lest they turn into monsters and destroy us all.

Suppressed, unvoiced needs can be revealed by living inside the customer’s narrative. Story is the diagnostic tool. That’s why we need it.

Storytelling Trumps Oracle Worship

Oracle of Delphi

Oracle of Delphi

Oracle worship has gotten man into trouble since before recorded history. The ancient Greeks travelled to the temple at Delphi to consult with the oracle Pythia. They believed she spoke for the god Apollo. Pythia delivered wisdom in a frenzied state induced by vapours rising from a chasm in a rock. She spoke gibberish which the priests interpreted for needy pilgrims. One Pilgrim asked, “Should I join the Athenians in their war against Sparta?” The answer: “Go return not die in war.” Punctuation wasn’t big in those days and in its absence was born one of the first potentially lethal ambiguities, the forerunner of those that beguile us even today in the fine print of engineering specifications.

So what is a systems engineer today, Priest or Pilgrim? I say neither. Sure, listen to your customer but take a step back and look at the bigger picture. Put the customer’s requirements into the context of his overarching story. You may be amazed at what lurks in the shadows.

And to capture the story, complete and correct, in all its factual and emotional glory you will need empathy and a knowledge of the story form. Feel inadequate? Of course you do. Story telling was for the Arts Faculty but if you want insight it’s time to learn the basics.

Enter the poet engineer.

The Business Function of the Story Pattern

Approaching a project the poet engineer sees the client as a mythical being, a hero, expressing a unique mix of archetypes, fallen temporarily from eternity into the field of time.

Up until now the hero has been living a comfortable life in a normal world with all things in balance. Then something happens and the hero’s life is thrown out of kilter. It soon becomes clear that something must be done to restore balance and the hero, often motivated by some dramatic inciting incident, is called to adventure. The hero is launched on a quest for his object of desire, some kind of elixir that when wrenched from the clutches of an arch villain and borne back to the normal world will heal the wounded land and restore balance and harmony.

Bent on his quest the hero launches himself over a threshold into a supernatural world where he endures numerous tests and trials, culminating in an ordeal, usually mortal combat with the arch villain. He defeats the villain, takes possession of the elixir and sets out on the path home to the normal world with the villain in hot pursuit. Within sight of home the hero often endures a second ordeal were the villain takes one last shot before being destroyed. The hero often almost dies but is reborn and transformed by the experience.

The hero crosses the threshold back into the normal world and shares the elixir healing the wounded land.

Armed with this mythic form the poet engineer dismisses the notion of customer as oracle and projects the eternal story pattern onto his client’s business. Its a great ice breaker on the first interview. The opener is not, “What do you want?” it’s, “Tell me your story.” The story pattern helps you walk the customer through life as he knows it not missing a thing. You ask more insightful questions such as: tell me about your normal world; what disrupting forces upset the balance; was there an incident that convinced you something had to be done; what drives you on your quest; what is the elixir that will save your normal world; who are the arch villains arrayed against you?

This is where analysis based on story parts company with classical requirements elicitation. The poet engineer compensates, up front, for human frailty. We think we believe what we know, but we only truly believe what we feel. True engagement with a customer’s needs is therefore a two step process: one, get the feelings on the table; two, distil the truth.

Introducing story invites repressed feelings to boil to the surface. We’re not asking what do you want, we’re asking how do you feel. Effective questions uncover strong emotions, for amongst these shadows live repressed, unspoken requirements. So immerse yourself in the customer’s story, think and feel as your customer thinks and feels, forget about requirements for the moment and think about desire.

Desire

Case study:

A traditional analyst approaches a Medication Tracking System. She does an interview and documents an objective:

The Medication Tracking System shall ensure that all patients receive their correct prescribed drugs.

The poet analyst digs deeper:

Mary Rose was blond, beautiful and three years old.  On a Monday she was admitted to our hospital as a precautionary measure with a mild case of flu.  On Tuesday she was dead. The autopsy revealed she had been administered an overdose of insulin.  She had received the medication intended for the patient in the next bed.  The objective of the Medication Tracking System is to make sure this can never happen again.

Here is an idea wrapped around an emotional charge – a heartfelt outpouring of desire. It’s a story device that engages people and makes them care. Caring is the beginning of empathy and empathy is the beginning of understanding; the first step on the road to accurate requirements.

Desire is at the primal heart of all customer requirements. Desire can be conscious or unconscious. Desire is discovered by understanding the customer’s story at the deepest emotional level. We find desire in:

The back story is the “once upon a time” component of our tale. We meet the hero and learn the history of the normal world. The back story provides the necessary background and rationale for developing a new system.  We also use the back story to identify the supporting cast of characters. Facing the customer for the first time we ask her to describe her normal world before the coming of some disruptive inciting incident.

Example: It was wonderful. My newspaper was a fantastic business mostly supported by advertising income. I had a large staff of reporters and a foreign correspondent bureau.

The Inciting incident dramatically upsets the balance of forces in the hero’s life. Wealth to poverty, life to death, security to jeopardy, freedom to slavery, market domination to also-ran, customer satisfaction to customer indifference, technology mastery to yesterday’s company. In the movies a shark eats a swimmer (Jaws). In our business the inciting incident is often triggered by the arrival of some disruptive technology.

Example: The Internet destroyed my business. Google came along and provided cheaper and much more focused advertising. I lost thirty percent of my income overnight. I can’t just keep firing people to cut my losses I’ll have nothing left.

The inciting incident creates an imbalance in the normal world, develops desire in the hero and launches him on the quest for the elixir.

The Elixir

The elixir is the object of desire. It has the power to restore balance in the normal world. It can be money, fame, power, love, peace, happiness, health, freedom. It’s interesting to note that in myth and legend the most satisfying elixirs are those that bring wisdom and greater awareness. Physical possessions fare badly. In the movie Titanic, Rose (Kate Winslet), as an older woman, throws the priceless blue diamond Heart of the Ocean into the sea at the site of the Titanic’s sinking. It turned out that her elixir was not personal property, it was survival and the blessing of a long and eventful life. Her ordeal had transformed her from spoilt, superficial young woman to spiritual being.

The elixir is a must-have in all stories. Mythic theory tells us that unless the hero returns to the normal world with an elixir and shares it with its inhabitants there will be no healing. Nothing is learnt, there is no transformation in the hero and the adventure must be repeated.

Does this ring a bell? Organisations that do not learn from their mistakes possibly? Companies that do not hold post project reviews that formally recognise what has been learnt and what needs to be improved? Was this the origin of the saying, “Those who do not learn from their mistakes are bound to repeat them?”

The Strength of Desire

The strength of desire can be measured by the risks the hero is willing to take in pursuit of the elixir. The authentic hero is willing to die for it. Anything less and the story gets boring. What represents metaphorical death for a corporation? What are they risking for their elixir? In the software industry it’s usually money and credibility. On one of my projects the cash burn was $70,000 a day.

The insightful engineer measures that desire early as it represents the unifying force that holds the entire project together. Robert McKee calls it “the spine of the story”. Requirements calibrated at high desire represent the core benefit of a system. If you’re working on a project that is losing its desire, find a way to stoke the fires or bail out.

Empathy for Desire

Desire draws the audience into a story. To remain fully engaged the audience must understand what the hero wants and want him to have it. By the same token project teams that do not share the desire to achieve the project’s objectives are at risk of falling apart through lack of interest.

To search in the shadows for unspoken requirements analysts must have empathy, they must feel the client’s desire. Remember that empathy is not sympathy. Sympathy is feeling sorry for someone in a detached kind of way. Empathy is feeling what the customer feels, seeing what the customer sees crawling inside the customer’s skin. The “sympathetic” moviegoer walks out of Titanic commenting, “Shucks, it was too bad they didn’t have enough lifeboats.” The “empathetic” movie buff leaves the theatre in tears.

You can’t achieve empathy without understanding the customer’s story at its deepest emotional level. So, understanding the object of desire is pretty important, which leads me to methods of expressing desire: the concepts of premise and controlling idea.

Premise

The premise expresses the energy that inspires a writer to tell a story. Often expressed as a question, it describes the creative burst that got her going.

Steve Jobs premise:

“What if I could convince all the music companies in the world to sell their music, through my Internet music store (iTunes) so anyone could download it to a mobile device (iPod) song by song?

Everyone on a project should understand the premise and be able to recite it in a single sentence.

Controlling Idea

The controlling idea describes a story’s fundamental meaning. It expresses the principle that guides story design. For example, in the Dirty Harry movies justice is restored because the cop is more violent than the criminals. Deconstructing this statement we have a transition between two states of fortune – Justice/injustice and a reason for the transition.

What was the iPod’s controlling idea? Can we describe in one sentence the vision that created a billion-dollar industry?

The iPod grew out of a primal human desire to have music everywhere at any time. Initially developed by the Sony Walkman, public taste for mobile music was left unsated by the lack of integration of the music industry with technology. The states of fortune here where access to music and lack thereof. Steve Jobs’ multi billion dollar controlling idea was:

The world will gain access to all music everywhere because I will integrate the flow of music from music companies to an Internet store that allows downloads to a simple (and aesthetically pleasing) listening device via the Internet.

Jobs pursued his controlling idea relentlessly, befriending musicians such as Bob Dylan, negotiating with music companies and driving his design team to produce a simple and aesthetically pleasing iPod. Sony could have had that business but it lacked the desire and the controlling idea.

Yes, desire is a very human emotion that we often banish from our projects in favour of cold logic – to the detriment of insight. A project’s descent into disaster often starts on the first day of requirements capture when the analyst doesn’t ask or isn’t told what is really important.  The premise and controlling idea of the business story are lost in the noise of complex features and technological gadgetry.

As a remedy we can preserve important project objectives through strong controlling ideas wrapped around the emotional charge of the story.  In the case of Mary Rose it is logical that patients should get their medication but the image of a dead child will guarantee that the team will crawl over broken glass to make it happen. The poet analyst’s requirement statement also tells us much more about our target system:

  1. This application is safety-related.  Failure can cause harm.
  2. The system premise is: what would happen if we use technology to make sure that a patient cannot be administered the wrong medication – ever
  3. The controlling idea is: this system will prevent patient death or injury through incorrect medication
  4. The most important attribute of the system is safety integrity.  This system must improve patient safety not degrade it.
  5. The system must be available 24/7.

A developer reviewing the traditional statement: The Medication Tracking System shall ensure that all patients received their correct prescribed drugs could easily miss these five derived requirements.  This is the power of story.

Project as Story

Thus far I’ve applied story theory to requirements elicitation. But its applications are universal. All projects are a story. A project that acts out the mythic pattern is authentic – that is, more aligned with reality and therefore more likely to succeed. I illustrate with the following vignette:

Shadows in the Test Plan

A complex system is under construction at Zentek Systems Co. Confidence is high that the system requirements are correct, unambiguous, implementable and complete. The Engineering manager reviews the system test plan. Given the clean requirements the test team has had a dream run at figuring out the volume of test cases. Their estimates look good. Effort is allocated for test design, test case development, assembly of test equipment and data, test execution and test reporting. The manager approves the plan with little change. The next day he is squashed flat by a beer truck.

He is replaced by a funny looking guy named Jake. Jake’s got an MIT masters in software engineering but he wears a beret and jeans. A rumour goes around that he’s also got an arts degree. The software engineers move away from him on the bench.

Jake reads the test plan, shakes his head and calls the test team in for a review. Dolores, the test team manager, does the talking.

Jake: So tell me your story.

Dolores: Say what?

Jake: You guys have been living a normal existence where everything is right with the world. Now something has come a long and it’s thrown your world out of balance. It’s pretty clear you’ve got to do something to restore that balance. You’ve got to embark on an adventure. So tell me about it.

Dolores: Yeah. We’ve had a life of regression testing minor upgrades. It’s been a bit boring but hey, it’s a job. Now we’ve got this major system to test, its going to be a stretch but I’m sure we can get it done. I guess to restore the normal boring nine-to-five balance in our lives we’ve got to find all the bugs in the system and do our part in getting it delivered with the maximum defect removal efficiency.

Jake: So what are the challenges? What will test your mettle? Where is the “the shadow”, the villain of this story. What or who is setting out to destroy you? And what or who must you defeat to return to your normal world.

Dolores: Bugs are our enemy. Defect removal is our creed. Our job is to find them, all of them and then make sure they’re fixed in subsequent releases of the product.

Jake: Okay then let me summarise. You guys are the heroes of this story. Your quest is to remove the bugs from this product. To restore your world to normality you must grasp the elixir of high defect removal efficiency (greater than ninety-five percent I hope). You will attack these bugs in the belly of the beast (on the physical test floor and in the logical depths of the code body). But that won’t be the end of it. Your initial successes will mean the system will have to be bug fixed and regression tested. So on the path home there will be endless tests and trials to remove the additional bugs injected by the fixes that we all know will occur. Only then can you return to your normal world with the elixir. Am I right?

Dolores: Hallelujah brother. Praise the Lord and pass the test specification.

Jake: Okay but we’ve got a problem. That test plan tells me you’re trying to make reality conform to your expectations rather than seeing what’s there. Real life. You’re going to find bugs, were is the effort allocation for retesting after bug fix. Come to think of it I can find no evidence of effort allocated for bug fixing in the developer’s schedule. This entire project is acting like there is no enemy bent on its destruction. Real life is always a struggle against some shadowy villain. Where is Darth Vader in this tale?

Bugs are the unavoidable outcome of our humanity. We make mistakes. And what our humanity loves to do, it will do – even as we plan and wish it were otherwise.

How will you destroy you enemies? Where are your weapons?

Dolores (sheepishly): We’ll need more time?

Jake: Damn right! There’s your light sword. You’ll need more time in the belly of the beast and on the path home.  Expect an ordeal, not a walk in the park. Let your plan reflect this and resubmit it next week.

Their future duly reorganised in the more realistic mythic form, the team files out. First team member (whispers): Spooky.

Second team member (whispers): I think we’ve just had a risk management lesson.

[Room empties]

Jake (sighs – thinking):

Thus far, with rough and all-unable pen,
Our bending author hath pursued the story.

Deconstructing the Shadow

Failure to recognise and deal with the shadow archetype incurs billion dollar losses every year.

Swiss psychologist Carl Jung coined the term archetype to describe symbols, energies, relationships and personality patterns that inform the behaviour of the human race. Jung catalogued the archetypes that appear in our dreams and, to his amazement, found them in the myths of all cultures. Archetypes are described in all works on dramatic theory.

An understanding of archetypes gives you a deeper knowledge of the purpose or function of characters in a story and hence people in real life. Armed with these insights we make wiser decisions.

At Zentek the shadow projected the energy of the dark side – the forces that will cause something to go wrong. Buggy software and bug injecting developers. In general the shadow stands for the qualities we abhor, our darkest secrets, repressed feelings, things that haunt us from our childhood, self doubt, secret fears and evil habits we have – but deny. Our shadows appear to us as monsters, devils, vampires and evil aliens. Shadows can also stand for unexplored potential – “roads not taken”. At best they challenge us, at worst, demonstrating the power of suppressed feelings, they stop us functioning.

It’s interesting to note that the most dangerous shadows don’t think of themselves as villains they actually view themselves as heroes serving humanity. For example, Adolf Hitler thought the extermination of the Jews was a righteous service to the world. Religious wars have brought forth the bloodiest genocides in history, all combatants believing that God was on their side. And in the present, puffed up with hubris and infallible self-confidence (not to mention the robust good looks and the snappy suit) how many modern managers wreak havoc in their customer’s business by delivering untested systems too soon. Villains can be sneaky, they often present as heroes; dashing and worthy of emulation, but as the story progresses they express their darker purpose.

In real life shadows appear from within and without. Life is a journey in the countryside and a journey in the mind. The shadow within can be self doubt, the shadow without can be an external enemy bent on our destruction.

In story and in real life the dramatic function of the shadow is to challenge the hero. The resulting struggle brings out the best in the hero and transforms him through the arc of the story. The stronger the shadow the quicker and more profound the transformation.

And then there is the driving force that causes the hero to engage in mortal combat with the villain. The hero wants something: an elixir. Initially shadows always have custody of, or some power over, the elixir. That magical thing which can restore balance and happiness to the normal world. It can be a physical thing like money or the Holy Grail or an intangible like greater-than ninety-five-percent-software-defect-removal-efficiency.

Most important of all for the story to reach a satisfactory conclusion the hero must take action to vanquish the shadow villain. The shadow within his vanquished by bringing it into the light and dealing with it. The shadow without is physically destroyed or made impotent.

By now you will have recognised the shadows in any movie you’ve ever seen. Star Wars’ Darth Vader is a particularly stark example. But by far the more interesting question is how the shadow villain projects onto the real-life experience of the systems engineering project. Can projecting the story metaphor onto projects give us deeper insights into how we plan and execute? Does best practice expressed in story language have a mystical power to influence our audience in ways they might find impossible to withstand leaving memories which are strong and hard to efface?

We shall see.

Systems Engineering Shadows

Using the shadow metaphor Jake exposed its darker purpose – from this we can abstract a wealth of practical wisdom.

All projects have shadows – no exceptions. To deny the existence shadows is to tell a boring story, to live an inauthentic life and, at Zentek, to suffer a failed project. In modern project engineering parlance the term shadow translates to risk: inadequate requirements, unskilled developers, uncontrolled change, untested technologies and the like.  In Zentek’s case the shadow was unrealistic estimates emerging from an inability to accept that things will go wrong. The test manager Dolores had internal shadows of her own. Denial. The inability to accept that something could go wrong and the unwillingness prepare for it.

The hero must act to vanquish the shadow. Interesting stories are driven through their arc by the actions of the hero. No one else. Passive heroes who react to circumstances or do nothing are uninteresting. To act is to discover truth. Inaction leaves us static, stale and unevolved. Project managers that do not act against the threat posed by the shadow, fail. Jake has taken his first action: replanning testing. He has taken the first step toward truth and by so doing has set up his next trial. It’s a truth that his management will not enjoy. His next ordeal will be to sell them the increased cost of testing.

Managing Shadows

Hero, antagonist or villain – which one of these?

An understanding of the shadow archetype gives you greater insight into managing problem team members. The classic example in software development is the technical genius, indispensable in a two-man start up but often a liability as a business scales up.

Steve Wozniak (Woz) is a brilliant man and a sweet guy. The Apple I and Apple II personal computers would not have existed without him. It is also true that had Woz not teamed up with Steve Jobs he would still be working in his garage giving his work away to friends in the neighbourhood. As Apple grew Woz’s inherent shyness and lack of management skills meant that he could no longer participate at Apple.

As the Apple story played out Woz expressed more than one archetype. He started as a hero building brilliant hardware and software and driving the story forward with his actions. Monk like, he sacrificed his time and all else (including the company of women) to make great computers. But deep within Woz lurked shadows: inability to communicate and inability to collaborate effectively with other engineers. Finally when the hardware and software design exercise became too large for one man Woz’s shadows threatened to destroy the company; he had morphed into a villain (from the company’s perspective). At that point Steve Jobs had no choice but to take on the role of hero and act. Woz was metaphorically annihilated.

This is a common scenario in technical teams. Highly intelligent tech-heroes start out as assets but become team killers as the organisation grows. They terrify people with their intellect, extensive background knowledge and inability to suffer “fools”. Often their continued presence is justified by the extent of their knowledge. Managers are afraid to fire them because they know too much. This inaction never bodes well for team productivity for the behaviour of the tech-hero-turned-villain is guaranteed to stunt the creative growth of everyone around him – unless of course he is willing to do battle with his shadows.

Projecting story onto this scenario reveals lack of collaborative skills as a shadow within. The manager’s job as mentor is to bring the shadow into the open and assist the lone hero to destroy it. In a crisis a hero always sacrifices something he values for the benefit of others. It can be a valued possession, his life or, as in this case, something as simple as a strongly held belief.

At the climax of Star Wars in the battle to destroy the Death Star, Luke Skywalker surrenders his dependence on machines to launch his missiles. He shuts down his target acquisition system and uses “the force”. Back in the real world, if our tech-hero accepts that he can no longer do everything himself and must share information and power he remains a hero, if he can’t he morphs into a villain. The villain archetype seldom changes in the arc of the story. He remains equally evil as events play out and, unfortunately, he must be destroyed if balance is to be restored to the normal world.

I accept that none of this is politically correct, but neither is the stuff of myth and legend, our authentic pattern and infallible guide to real life. Stories with heroes that do not engage in mortal combat with the forces of evil lose their audience. Companies that do not aggressively attack their demons die.

Seizing the Elixir

The form, function and criticality of the elixir must be clear to all.

As we have seen the elixir is the hero’s object of desire. Without an elixir the hero has no quest and wanders aimlessly in the ether achieving little of interest (and most of the audience is gone before the credits). To her credit Dolores had a clear understanding of her elixir: high-defect-removal-efficiency. On return to her normal world this will create harmony through high customer satisfaction and low cost of ownership.

Non-performing projects often have no clear definition of their special elixir. Team members can’t state in one sentence why they’re there. I recently contributed to an online forum thread that asked for the top five reasons for having a quality management system. There were comments such as “[to have a] Managed processes helping to ensure consistency”. I don’t think I’d risk my life for that elixir.  How about: “Reduce costs by fifteen percent and double sales.” Now that’s more like it; a cause worthy of (metaphorical) mortal combat.

Here is another positive example: a NASA Space Station commander recently stated one of his mission objectives with clarity and great beauty, “When it’s all over, I want my people to look back on the next six months and think of them as the best time of their lives.”  A classical elixir, honest, useful and true.

All in all teams that have no shared concept of the elixir have low morale and poor productivity. The reasons can be found in a story metaphor. All stories revolve around a hero with a quest. For a story to engage an audience they must know what the hero wants and want him to have it. For a team to spend late nights fighting the forces of evil in the belly of a beast they must share desire. And that desire must be specific and strong.

So far so good. But how far can story metaphors be stretched? My view is that they go to infinity. I’ve seen it play out in all the projects I’ve ever joined. Take for example the secrets of rapid personal development.

The Ordeal, Death and Rebirth.

You can’t win Darth. If you strike me down I shall become more powerful than you can possibly imagine.

In Lucas’ seminal scene from the original Star Wars movie, Obi-Wan Kenobi yields to Darth Vader who kills him. But is he really dead? No. He is reborn as a spirit, the very incarnation of “the force” and continues in his role of mentor, always with Luke Skywalker, ever more powerful.

Variations on this scene are essential components of myths, legends and all well constructed stories. A struggle with the forces of evil is not authentic unless the hero almost dies in the act. Wimps need not apply. All the myths, legends and worthwhile real-life experiences that ever were feature the metaphorical (or actual) ordeal, death and rebirth of the hero. The best example is the basis of the Christian faith: the betrayal, crucifixion and resurrection of Jesus Christ. If the ordeal is omitted some primal judge within us senses that the story is not real and we lose interest.

Who could doubt the wisdom of the astronauts who, from the void of outer space, have gazed upon the pathetically thin blue layer of atmosphere that coats our planet; who could not be moved by their exhortations to nurture our environment? For these men and women are the modern shaman’s who have left earth and gone to a supernatural place, sacrificed the normal human need for a comfortable life, cheated death and re-entered our atmosphere to be reborn and forever transformed, their ordeal gifting them with the elixir of new insights. The word “sacrifice” derives from the Latin “making holy”. Could this account for the aura surrounding all astronauts  on their return?

In engineering projects people face ordeals in the form of challenges that they believe are beyond their capabilities. They are transported, sometimes unwillingly, into supernatural worlds and subjected to tests and trials. Most of them triumph over adversity and move on to higher levels of professionalism and achievement. Dolores’ team is currently a rag-tag band of maintenance test wonks. As they are consumed by the adventure of the Zentek project – deadline death marches, late nights on a test floor , so-called code base lines that evolve randomly under their feet, the loathing and denigration of programmers who will not admit to bad code, pitched battles with managers, panic’d and shrill, who want them to stop testing and deliver the product regardless – will harden and temper their skills toward their ultimate rebirth as professional test engineers (scars and all).

The takeaway?

If you want to train a team to the highest level of capability in the shortest possible time give them a job that almost kills them.

Reflecting on The Force

Use The Force Luke.

In Star Wars George Lucas invoked the force as a metaphor for timeless wisdom. Jedi Knights were chosen at birth and trained as exponents of the force in all aspects of life. They were beyond elite athletes; they were sages, supernatural beings capable of amazing feats. Obi-Wan Kenobi’s death at the hands of Darth Vader and subsequent rebirth into the spirit world implied that they were immortals come down from the stillness of eternity for brief movement in time only to return to their spirit form to watch over us all.

This is not so far-fetched. If you’re a Christian this pretty much sums up your belief in Jesus Christ, the Saints, God and Heaven. If you’re an Australian aboriginal have I not just summarised The Dreaming? Even if you’re an atheist you believe in something, don’t you; some eternal truth that guides your daily actions and to which you turn in times of trouble?

No one can say for sure that the force exists, but we feel it’s true (at least our personal version of it) and that’s all that matters. Feelings (not logic) make it a strong influence in our lives. The force of our belief system controls how we filter information, what we remember, what we learn, what we say and what we do. I find it amazing that Obi-Wan’s last earthly words, “I shall become more powerful” have remained crystal clear, fixed in my memory, even though I heard them only once thirty-five years ago (shades of the crab).

The force of story has too strong an influence in our lives to be ignored by the humble engineer. Understanding its power is all the better to listen and remember, to teach and learn and to drive our projects down paths of realism already laid, in abstract form, in the wisdom of myth and legend.

Project Diagnosis with Story

The story form is a wonderful container for all the important questions that should be asked about a project. Who is the hero; what is his quest; how strong is his desire; what elixir will heal the wounded land; what evil lurks in the shadows; where are the mentors; what are the ordeals and how will they transform us? Honest answers breed authentic successful projects. Not even asking the questions guarantees failure.

On the face of it these are puerile questions but woe betide the project that does not pursue the answers with the passion of a hero on a quest.

Richard Sargeant of the Queensland University of Technology conducted a study into the impact of the project management method PRINCE2® on project performance [7]. Put simply the question was “Does it work?” the answer was, “Yes it does if faithfully applied, but because management often underestimates the energy required to transform an organisation from undisciplined sludge into fully functioning project managed enterprise, it sometimes has little beneficial effect.” Having participated in many methodology implementations this rings a depressing bell. Organisations will not transform without a hero in the ranks of management. Projecting the story pattern onto a process improvement project we can understand why.

Process improvement requires transformation of the organisation and its people. Transformation does not occur without ordeal, death and rebirth. The ordeal is lost time on so-called productive work while people are taken out of the workplace and thoroughly trained. They are called to adventure but often waste time refusing the call and fighting the newness of it all. There are tests and trials. The new processes are implemented and some fail. Methods are tailored and they try again. Shadows appear. Questions are asked. “Why are we doing this when the old ways worked – sort of?” Projects using unfamiliar methods run late. The organisation may approach commercial death – non-delivery of important projects. But the hero manager presses on. Then with more efficient ways of working bedded in the organisation begins to see benefits, quality improves, efficiency goes up, costs go down and the organisation is reborn. Tom DeMarco got it right:

Quality is free but only if you are prepared to pay dearly for it.

This scenario simply cannot play out without committed hero managers prepared to sacrifice something they value (job security) for the benefit of others. They must be prepared to put their lives (read careers) on the line for what always will be, on crossing the threshold, a risky adventure. Indifferent managers have weak desire and therefore take a few risks. When failure looms they do nothing, the story is not propelled forward, there is no mortal combat in the belly of a beast, no elixir is seized and returned to the wounded land and, true to the mythic form, the adventure repeats in an endless cycle of failure until either the organisation dies or the worsening imbalance in the normal world throws up a hero with the guts to act.

The Rhythm Ever After

Light thickens; and the crow
Makes wing to the rooky wood:
Good things of day begin to droop and drowse;
While night’s black agents to their preys do rouse.
Thou marvell’st at my words, but hold thee still;
Things bad begun make strong themselves by ill.
Macbeth: Act 3 Scene 2, William Shakespeare

The setting sun spears shadows across my desk from the Golden Cane’s outside my window. The rhythm of the day beats into night and I have said enough – I hope – to help you across the threshold of a good beginning.

The crow finds its nest on the lines of the earth’s magnetic field. Man moves through time along the lines of story. It’s pattern delights us, it’s rhythm comforts us. Primal as the tempo of breathing; elemental as the beat of our heart.

And with it we make sense of our life inside the chaos
As with the marching song of the soldier
As with the chant of the poet engineer

This is the reason I was born
I come to live here till I die
I am the brush stroke on the dawn
I am the whisper in the sky

I hear you in the waking dawn
From far beyond the galaxy
I miss you, tears and heart forlorn
Dear one I’ll soon return to thee

To light the mind and feed the soul
The synthesis of dreams
To write the stories still untold
For systems in the human stream

Where workings of our heat’s design
Will keep life safe and true and full
With metaphors sustained in time
Because they’re simple and they’re beautiful

Cheers
Les
les@chambers.com.au

—————————————————–

References

  1. Storytelling That Moves People, Harvard Business Review, June 2003, pp. 51-55
  2. McKee, Robert (1999), Story: Substance, structure, style, and the principles of screenwriting, London: Methuen Publishing Ltd
  3. Vogler, Christopher (1998), The Writer’s Journey, Studio City, CA: Michael Wiese Productions
  4. Parini, Jay (2008), Why Poetry Matters, New Haven: Yale University Press
  5. Campbell, Joseph (1968), Hero With a Thousand Faces, Princeton: Princeton University Press
  6. Brooks, Frederick (1982), The Mythical Man-Month, Addison-Wesley Publishing Co Inc
  7. Sargeant, Richard et al (2010), Creating Value In Project Management Using PRINCE2®, Queensland University of Technology (QUT), [Online], Available: http://www.prince-officialsite.com/Resources/Resources.aspx [18 June 2012]

Comments are closed.