Do you know about smokejumpers? They’re brave, self-sufficient firefighters who parachute into remote areas wearing eighty pounds of gear and ready to fight a forest fire. If the jump goes well, they land safely. After extinguishing the fire, they may have a ten-mile hike out. It’s not a job for the faint of heart, slow of mind, or weak of back.

Have you considered that you may be a smokejumper? Think about it: Many of you join software projects midstream because sometimes a project needs additional contributors – some add brains, others brawn. Sometimes mentors are needed to improve project performance. Sometimes management needs an outsider’s view of the project status.

No matter why you join a project after it begins, you will encounter challenges. To be successful you must:

• Determine your role
• Build trust
• Learn the territory
• Gather information
• Do your job
• Declare victory

Determine Your Role

“If you don’t know where you are going, you’ll probably end up somewhere else.” – Laurence J. Peter

Smokejumpers work on well-defined teams. Everyone has a job to do and knows how to do it. Before jumping into a project you should determine your role. Ask:

• What specifically is my sponsor asking me to do?
• How can I demonstrate to my sponsor that I have been successful?
• What will my relationship be with others on the project?

Knowing what my sponsor wants keeps me focused. Difficulties arise when the sponsor has trouble explaining the problem. He knows the project is late and he wants better quality, but he can’t say exactly why the project is late or what’s creating sub-standard quality. Generally, the greater the pain (lateness, poor quality), the less articulate about the problem the sponsor becomes. When this happens, I like to use the SMART acronym Johanna Rothman describes in “Release Criteria: Is This Software Done?” (STQE magazine, March/April, 2002). SMART reminds me to get a problem definition that is: specific, measurable, attainable, relevant, and trackable.

Next, I need to know what “done” means. Knowing how I’m going to demonstrate “done” gives me information on what to track so I can provide my sponsor the information needed to prove the fire is out. A good question to ask is “What will you see, hear, and feel when this problem is solved?”

I often use a simple reporting format when I check in with the people for whom I’m working. I describe what we’ve done since our last discussion, what we’re currently working on, and any barriers to progress we’re encountering.

Last, but not least, I need to know who I will be working with and in what capacity. Based on what I’m being asked to do (brawn, brains, mentor, or project review), I’m going to relate to the team in different ways. I may be a coworker, a coach, or an investigator. Knowing which role I’ll be in guides me as I work on getting a demonstrable “done.”

Currently, I’m working with a client whose staff has been trying to solve a problem for a month. In our kick-off meeting, we established that my job was to get the project “done,” and they don’t care how. On this project, “done” means all the applications have been switched to the new server and tested and the old server decommissioned. I’m going to function primarily in the brains/brawn role, as a coworker helping solve the problem. Along the way, however, I’m going to be asked, “Why couldn’t the team solve the problem?” which will put me in an investigator/reporter role.

Build Trust

“The first thing to build is trust.” – Brad Appleton

Smokejumpers work in integrated teams to put out small fires before they spread or to provide additional manpower on larger blazes. As a project smokejumper, it’s likely you’ll be joining a pre-existing team. So when your boots hit the ground and your chute is secure, you’ll need to hook up with the team. Your success in working with this team will depend on how well you understand them and how much they trust you.

Building trust is a relatively straightforward activity. If you say you’re going to do something, do it. If you say you’re not going to do something, don’t. The team – and its management – will be looking for discrepancies between your words and your actions. Building trust is an action-based activity. When I hear “Trust me!” from someone I do not know well, that is a red flag that throws me into the “Put up or shut up” mode. So make commitments and meet them.

Keeping activities, information, and decisions visible helps build trust. It’s not always possible to achieve immediate success (however minor it may be). Keeping things in the open helps allay fears, enhances communication, and enables better decisions. On one of my jumps, a team member heard me discussing a spreadsheet I was using to keep track of assets, current status, and needed changes. He asked for a copy of the spreadsheet and later returned it to me with the names and phone numbers of the key people I should coordinate with at each plant. By sharing the information I had, I received more.

Asking questions opens the door for team members to share what they know about the fire. Listening to and understanding their answers creates rapport and builds trust. This also helps you learn the territory and gather information.

Learn the Territory

“You gotta know the territory.” – Meredith Willson in “Rock Island” from The Music Man

“I know the territory.” – Meat Loaf in “I’d Do Anything For Love” from Bat Out of Hell II

Smokejumpers work in an ever-changing environment where understanding the territory can be the difference between putting out the fire and not making it out alive. Their territory includes fuel types, wind direction, and the topography where they’re working. Changes in any of these can change the possible outcomes quickly.

Project smokejumpers also work in highly dynamic environments. Personality differences fuel the project flames. Some team members may be more equal than others. Who’s really in charge? Even though someone can’t help me, can he hurt my ability to succeed? Changes in any of these can quickly change the possible outcomes.

In all my years of jumping, I never have landed in a situation that lacked energy. Most situations follow the pattern of a jump I did a couple of years ago. For reasons no one could determine, a stable, proven process suddenly started generating a 25 percent defect rate. The Big Boss flew in from the home office to handle the situation personally. On Saturday, I got the call to jump. When I arrived Monday morning, I surveyed the situation, listened to the management screams and the worker apologies and decided it was a good time to be calm. I took a deep breath and started asking questions.

In her book Communication Gaps and How to Close Them, Naomi Karten lists my three favorite questions:

1. How did you happen to come here?
2. What do you expect will happen here?
3. What do you hope to accomplish here?

She also says, “Notice that the first question elicits information about events from the past; the second, the present; and the third, the future. All three questions provide a starting point to help you determine what’s important to the person or group with whom you’re trying to communicate.” These questions represent starting points for learning the territory.

The responses to the questions indicate how safe the person feels. Short, simple answers may be a tip that the person isn’t feeling safe. Perhaps there’s a blaming corporate culture and whoever’s holding the blame when the music stops gets fired. It could be personality conflict on the team. Unresolved conflicting management agendas can cause a “CYA” environment. If the environment isn’t safe for the employees, it’s not going to be safe for the smokejumper, either.

The key to success and survival hinges on the smokejumper’s ability to ferret out information about why the person doesn’t feel safe. If I haven’t created a trusting relationship, I won’t get the information I need to learn the territory. I talk to as many people as possible, which allows me to draw a more accurate map to help me navigate the territory.

Do the answers’ content and delivery style agree with each other? I remember one project manager yelling at me about how well he had done on a previous project and how this project wouldn’t fail. I wondered why he chose to do this project differently, but decided to keep

my mouth shut. He was partially correct. The project didn’t fail, but he and his company (the management team) were terminated six weeks later. It took us another year of development to complete the estimated twelve week project.

Gather Information

“As a general rule, the most successful man in life is the man who has the best information.” – Benjamin Disraeli

Smokejumpers receive information about the fire before they board the airplane. How big is the fire? What are the weather conditions? Which way is the fire headed? Are there obstacles to overcome? Where are the safe zones? As soon as they land, their first action is to verify the information and determine if anything has changed. Project smokejumpers start gathering information during the first conversation with the client. What’s the nature of the problem? How long has it been going on? What already has been tried to solve the problem? You need to gather information about the technical fire you’ve been asked to put out.

I once jumped to solve a “three systems quit working” problem. After listening to the problem description, I thought about the symptoms and several possible cause/effect scenarios came to mind based on other successful jumps. I continued to ask questions, and one by one

ruled out the possibilities. When I jumped, all I knew for sure was a problem existed. (For the curious, the software quit working because someone created separate IP subnets, and the computers couldn’t talk to each other because the inexpensive routers couldn’t bridge the subnets.)

Project smokejumpers compare this information against their past experiences. What appears to be the same? Is something new or novel? This provides the project smokejumper with an initial problem assessment. This is both good and bad.

The difficulty with this initial assessment comes when it leads us to ignore new data. Since we have an idea of what the problem is, we may believe we have the answer. As Lee Copeland points out in “Believing Is Seeing” (Better Software magazine, December 2006), the Bruner-Postman experiment shows that our experience can blind us to reality. Keeping an open mind and being willing to change conclusions go against our own biology, but both are necessary when you’re jumping into complex situations.

Try to find both positive support and negative indicators for the problem you’re trying to solve. In my career as an emergency medical technician, I was taught to evaluate data and revise my understanding using the following checklist:

• I expect to see something, and I do.
• I don’t expect to see something, and I don’t.
• I expect to see something, but I don’t.
• I don’t expect to see something, but I do.

We can use this new data to modify our problem assessment. This forces a rethink and possible restructuring of our problem assessment. It takes time but opens the door to a better assessment and solution. The other choice is to ignore the information or modify it to fit our problem assessment. This doesn’t require rethinking and restructuring our assessment. It also opens the door for high-impact learning when the information we ignore comes back to burn us.

The technical problem could be something as simple as finding that the computers are on different subnets and thus cannot communicate. Maybe it’s helping the team come to grips with the “process du jour.” Perhaps the team’s engineering practices need modification to achieve the project goals. Whatever the technical problem may be, expect that it will be difficult to solve. If the problem had been easy, the team most likely would have solved it already.

Do Your Job

“For every complex problem, there is an answer that is clear, simple, and wrong.” – Attributed to H.L. Mencken

Smokejumpers use different tactics to extinguish fires. If the fire is small enough, they may directly confront it. For other fires, they may use an indirect approach of control lines and backfires to deprive the main fire of fuel. When the fire really gets going, they may have to wait for something to change – the type of fuel, the weather, the topography – before they resume fighting the fire.

As a project smokejumper, how you attack the problem is affected by your role in the project, your ability to build trust, your understanding of the territory, and the information you’ve gathered together with the problem’s complexity.

A brain/brawn role and a straightforward problem generally lead to direct action. This is how I dealt with a “software quit working” jump. I sat down at the computer and started checking settings, properties, and configurations. When I discovered two network cards, I started investigating more, and voila! There were the two non-mappable subnets.

Mentoring or complex problems often require indirect approaches. I once spent three months helping a hardware team as it worked to get a hardened mobile router into beta production. Since management complained about not knowing where the team stood, I created a burn-up chart in the engineering space so everyone could see what remained to be accomplished and when we anticipated that it would be completed. The semiweekly status meetings asked the basic Scrum questions: What have you done since our last meeting? What are you going to work on? What problems are you having? I made sure I had the necessary equipment, so if there was a question, I could go in and work with the team. We made the target date with a few days to spare.

Each style of doing things has natural consequences. If I decide to take control and work directly, I’ll miss an opportunity to let others learn through experience. If I let others learn through experience, what happens to putting the fire out? I like to use the following questions to help me understand the implications of my (mentally proposed) actions:

• What will happen if I do?
• What will happen if I don’t?
• What won’t happen if I do?
• What won’t happen if I don’t?

The process of understanding your role through doing your job goes on the entire time you’re fighting the fire. It’s a continuous refinement process as the project smokejumper learns more about the technical problem, the team, and the interactions between them. And it’s not a linear sequence. Other than starting with determining your role, the rest of the activities happen randomly, simultaneously, and continuously.

Declare Victory

“The Lone Ranger Fantasy: When the clients don’t show their appreciation, pretend that they’re stunned by your performance – but never forget that it’s your fantasy, not theirs.” – Gerald M. Weinberg

After they ensure the fire is out, smokejumpers head back to base, clean up, and repack their gear, getting ready for the next jump.

Prior to heading out, project smokejumpers need agreement from their sponsors that the fire is out. This task combines defining a specific goal at the jump’s start and keeping progress visible. If you don’t know what you’re shooting for and when you need to hit it, you’re probably going to miss the target. Hitting the target gets you praised and paid.

Declaring victory creates the opening to review your contributions to the project. Project smokejumpers often make technical contributions on a project. These are generally obvious, and most people would agree to them. Often more important are the less-obvious personal contributions. No one but the smokejumper may ever know the many little bumps, nudges, and guidance provided during the jump.

I’ve just finished working with a sponsor who a week ago said, “Again, today, the reports did not get sent out. I guess all of our work was for nothing.” I reminded him that the problem involved two different systems, we had only corrected one, and that things would get better when we solved the problem with the second system. Today I heard the happiness in his voice as the second system came on line.

The Smokejumper’s Life

“You live and learn. Or you don’t live long.” – Robert Heinlein

The smokejumper’s life consists of:

1. Qualify for smokejumping
2. Train
3. Go to the fire
4. Put out the fire
5. Go to 2

Over years of jumping, the training will change as the jumper becomes more practiced at current skills and learns new skills. Smokejumpers use all their skills, all the time. Being able to call on their training when they need to can mean the difference between an extinguished fire and an unhappy outcome.

Project smokejumpers follow the same pattern. Somehow, somewhere, you start solving problems, and then someone asks you to jump in to help them.

Project smokejumpers need to train continuously. Your technical skills may get you started, but it’s your people skills that help you solve the problem and keep it solved. In addition to reading magazines and books, I recommend attending experiential conferences or training courses where you’ll be able to learn new skills and practice them in a supportive environment.

Jumping isn’t for everyone. Over the years I’ve missed birthdays and anniversaries. I once left a weeklong vacation after only two days to make a jump. Fortunately, my family loves me. It occasionally gets tense, so a sense of humor works to my advantage. Being an adrenalin junkie helps too. And it’s all worth it when a client says:

“You know, Don, a couple years ago I watched you ‘join a team’ and help them work together better, when your charter was actually to get something shipped. You weren’t there to ‘fix them.’ But, you ended up helping that team and another team be better together.”

That still gives me goose bumps.

This article was originally published in Better Software, September 2007

Here are a half-dozen criterion to consider:

• Limited attendance. AYE is limited to 75 participants to ensure high-quality interactions. It’s not a huge event where you’ll be like one of thousands of struggling through crowded halls to get to the next powerpoint lecture.
• Interactive, experiential sessions that focus on your learning, not the presenters ideas of what you should learn.
• High caliber presenters. The AYE hosts have years of experience with experiential learning and are all published authors. We don’t rely on unknown or untested presenters to fill out topic tracks.
• Ample time and space for networking, one-on-one coaching, and meeting new people. You’ll meet lots of interesting people at AYE. Our participants are thinkers and learners, not warm bodies sent to simply swallow powerpoint bullets.
• No sales pitches masquerading as learning opportunities. We aren’t here to sell you the latest tool (though we will happily sell you our books!).
• No canned presentations. We aren’t dialing in the same lecture we’ve done dozens of times. Even when we do repeat a session, it’s different because the people are different and bring different dynamics and insights.

We hope you’ll choose AYE. We love to meet new people and enjoy our old friends.

Take advantage of the Summer Discount $1500 per person, $ 300 less than the full registration. Read more about the discount below!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Tenth Annual AYE Conference will be November 8 – 12, 2009 in Phoenix, AZ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can see the schedule and session descriptions on our Program Page.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Summer Discount Ends July 31, 2009
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From May 1 to July 31 conference registration is $1500. After July 31 the standard registration of $ 1800 applies.

If you have any problems registering, call and discuss them with our registrar, Susie Brame at (503) 799-5132. You can also contact Susie at susie.brame@ayeconference.com or register online at http://www.ayeconference.com/register . We’re committed to helping you come and thrive at AYE, regardless of the obstacles.

Team Registration Special Continues
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Right now you have two ways to save money while attending this year’s conference:
When you and your teammates register and attend together, you qualify for our team discount. That’s $1200 per person for 3 or more, $300 per person less than the Summer Discount price and $600 less than the full fee.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meet and learn with the AYE Hosts at these events:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jerry will be participating in CAST 2009, in Colorado Springs, Colorado, July 13-16. On July 13, he will be presenting a tutorial: Ensuring Testing’s Proper Place in the Organization

Don will lead the Agilely Delivering Business Value simulation at agile-knoxville on July 14, 2009.

Esther and Diana Larsen will be leading Secrets of Agile Teamwork July 21-23 in Redmond WA.

Johanna will be part of a panel discussion on Agile Teamwork: The People Issues on July 23 at the Agile Bazaar in Boston, MA

Esther and Johanna will be at AgileRX in Phildelphia July 30-August 1.

Don, Esther, Jerry and Johanna will be presenting at Bizconf August 20 – 21, 2009. Part two of Jerry’s interview with Obie Fernandez is posted here. (Read the first part of Jerry’s interview about consulting, dealing with clients and permanent employment.)

Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

“Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

The Tangled Web

It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

We can see in the following diagram that Engelbert had at least three options available to him. He could:

• Respond negatively, looking for reasons, usually blaming someone else) for the results.
• Decide no difference exists by ignoring the results and do nothing.
• Respond constructively, learning from what happened and improving at getting the results we desire.

Choices for a poorly ending project.

Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a “success”) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

Let the Game Begin

Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

Blame affects organizations on multiple levels creating different problems.

• Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
• If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
• Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
• Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.

Results of blaming

So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

An Ounce of Prevention

The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

• Observe what’s actually happening. Are people doing what they say they’re doing?
• Listen to the language people use. Do you hear blaming?
• Does it feel like there’s an elephant in the room that no one acknowledges?

No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like “It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

Multi-level Blame

Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

What’s A Girl To Do?

At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

When things go wrong, we feel trapped, just like Engelbert in this week’s new article, No Exit. (You might want to read Liar’s Contest to see how Engelbert got trapped).

©2005 – 2009 Don Gray, Gerald M. Weinberg

“The thought that disaster is impossible often leads to an unthinkable disaster.” – The Titanic Effect, The Secrets of Consulting, pg 95

Engelbert, the Software Engineering VP, sat quietly in his office pondering the current state of UberDenke’s next UDCRM release. Slowly he had realized the release wasn’t going to ship on time. There were many more errors than he planned for, and over half of the code had not even reached the testing group.

The more he thought about it, the more he felt trapped. The more trapped he felt, the more he wanted out. The more he wanted out, the more he felt trapped. And around, and around his feelings traveled in a vicious circle of trapped and wanting out. But there wasn’t anyway out.

Or was there? Engelbert’s thinking and actions have trapped him in a reinforcing feedback loop. His feelings are creating an emotional downward spiral that will continue until some system limit is encountered. The system limit may be the when he finally admits to others the release won’t ship on time. Perhaps his health (mental or physical) may break first. Or maybe he’ll change jobs.

We can all sympathize with Engelbert’s plight, because at some time or another, we’ve all been caught like this–a trap artistically summarized by Jean Paul Sartre’s depressing play about three people trapped in Hell, No Exit.

Engelbert set up his own No Exit hell right from the beginning, because he, like Sartre’s victims, had no exit strategy. An exit strategy is a planned set of activities to initiate when one party suspects that a relationship isn’t working, activities that should prevent the situation from becoming a hellish trap.

Dynamic Basics – Getting Started

The no-exit dynamic generally begins when two (or more) parties agree to work jointly on some project. Sometimes the agreement is not explicit, as often happens when the work of one party depends on another party’s output. This joint work could stem from a voluntary relationship (such as co-authoring articles) or perhaps from a management mandated decision. In Engelbert’s case, his manager told him to use a new process to build the next generation of their software product.

The parties start merrily to work under the agreement, and all goes well for a while. Next, life happens.

Perhaps the person with whom you agreed to write an article falls ill, changes jobs, or takes time away from the joint project to deal with pressing family problems.

Perhaps the other team at work discovers the problem is more difficult to solve than anticipated. Possibly another higher priority project siphons manpower from their team.

Or perhaps the dynamic starts up when the levels of commitment and interest are unbalanced, or when there is a different understanding of the agreement.

Locking In

The first slip or two may not create a problem. We use explanations like these:

• It’s only happened one time. (Not noticing prior behavior on the part of either party).
• Things are bound to get better. (Seeing through rose colored glasses)
• I’ve made a commitment, so I’d better not say anything. (The team player problem)
• They’ve got a plausible story. (Just one more chance).
• I’ve already invested so much, a little more investment and I’ll have what I want. (Good money after bad)

Whatever the reason–and there are hundreds of variations–the slips soon become the norm, not the exception. Since the slips happen individually, separated by days or weeks, the cumulative effect isn’t noticed until it’s too late to do anything reasonable about the slips. The more we become accustomed to the slips, the more tolerant we become as new slips occur. It’s not that Engelbert is stupid. It’s just that he lacked foresight, or was too optimistic. If he had known when starting development that the project would slip several times, he could have planned differently.

Failing to take early action sets the precedent for continuing failure to act. Failing to act causes negative feelings to accumulate. The negative feelings are there from the first slip, but they are ignored or suppressed until the accumulated value becomes greater than we can tolerate. When we finally surface the negative feelings, we feel trapped by our previous actions. We’ve become locked in the reinforcing feedback loop of simultaneously wanting out and feeling trapped.

In this dynamic the system continues accumulating more negative feelings until the system experiences a catastrophic collapse. Engelbert may be fired, or quit, or get sick, or ship a system that drives his company out of business.

Setting up the Exit

So, what’s the solution? The first step to exiting the reinforcing feedback loop is to become congruent by balancing the factors of yourself, the other party or parties, and the context in which the dynamic is taking place. Most commonly, in this type of a feedback loop, the other becomes lost. As you try to cope with the situation, you start blaming the other person for the problem, and that only tightens the loop. Responding incongruently like this creates stress and does nothing to improve the situation or help find an exit from the loop.

Becoming congruent allows you to be centered in your actions. Being centered opens a range of responses you can use to change your view, each of which might break the trap. By changing your view of the situation, we can see possible interventions that will change the loop dynamics. Among such interventions are these:

• Changing how you see your contribution to the problem.
• Determining why you feel like you’re trapped.
• Obtaining a better understanding of what you heard during the “agreement” process.
• Bringing in a third party who adds a compensating loop. Sometimes you do this by just letting the loop escalate until someone else is affected, often by not trying so hard on your side. This is an example of:
• Doing the opposite of what you’ve been doing. This personally applies Marvin’s Fourth Great Secret, “If what they’ve been doing hasn’t solved the problem, tell them to do something else.” The Secret of Consulting, pg 41

Exiting the Loop

No self-reinforcing loop can last forever. Sooner or later, one way or the other, the loop will exit. If no action is taken, the reinforcing loop will continue its downward spiral until some other part of the system collapses:

• Personal health (mental / physical) will deteriorate until the exit happens. (This is breakdown of the self.)
• The interpersonal relationship will decay and animosity replaces the original camaraderie. (This is breakdown of the relationship with other.)
• A third party starts to be affected and intervenes. Of course, this is the result some people are hoping for (if we make enough noise, Mommy will stop the fight). But, you can also encourage it. (This is where the context intervenes.)

Another exit option is to become centered, congruent and work on changing the loop dynamics. The key here is to recognize the No Exit dynamic early, and take corrective action quickly. Your plans and strategies must be flexible. While the goal can be constant (exiting the loop), life continually changes, so fixed plans inevitably become obsolete or, even worse, counter-productive.

When the loop finally exits, there are several possible outcomes:

• An intervention works and the joint effort continues
• The “healthy” participant becomes “sick” and the effort ends due to lack of effort
• One person takes over the entire effort

This applies to multiple party systems (two or more). In addition to software development this could include:

• marriage and other long term interpersonal relationships
• business ventures
• article or book writing
• sports or other activities you are doing “for fun.”

An Ounce of Prevention

Next time, Engelbert should consider prevention interventions. Prevention interventions can be used to prevent the No Exit dynamic from happening in the first place. Or if it starts anyway, they provide an agreement among the parties as to how to handle it–if you like, a meta-agreement, or agreement on the limits of our agreement and what we’ll do when we reach them.

In a crisis, it’s much easier to stop and think if you have provided time in your plan for stopping to think. If you haven’t, one party will say, “Here you tell me that we’re behind schedule, but you’re adding this thinking-bit to the schedule. That doesn’t make sense.” With that easy dismissal, everyone quickly hurries back to their unproductive panic.

Examples of advance preparation of exit strategies include:

• Periodic check-ins
• Gate points where either party can exit the activity, if they’re not perfunctory so you can really exit at these points
• Better understanding and more explicit statement of each party’s expectations, along with a process by which expectations can be modified along with the plans that were based on them.

A well-designed system will set some limits at the beginning, limits that are not vulnerable to a buildup of tolerance.

Third Party Interventions

Most parents have learned some dos and don’ts about what to do when they witness such a no-exit loop. If you find yourself on the outside looking in, you might apply one of these principles:

• Know when to enter (never do unless you’re asked for help, though you can encourage the parties to ask you).
• Prevent damage (whatever that is) to others.
• Decide it’s not your problem and walk away, letting the nature of the no-exit loop take its course.
• Avoid creating addiction (co-dependent) dynamics.
• Avoid using fixes that accentuate the dynamics, unless you want to make it worse so it will crash more quickly or lead to enough pain that the parties will work out their own solution.
• Be careful not to prevent natural learning.
• Look for interventions that remove barriers and/or increase resource states.

Exit Levels

In deciding about intervening, choose which of three Exit Levels you’re seeking:

• First exit is when participants realize how much pain the feedback loop is causing and figure out a way to break out for themselves.
• The second exit is out of the situation (as when the parties concur that the agreement has failed). This may lead to a new agreement, or an exit agreement where they continue the relationship with each other.
• The third exit is where one party opts out of the system by ending the relationship.

Of course, the best exit is the one you have planned for before you ever get started. Unfortunately, there’s a prevalent romantic notion that real relationships shouldn’t need a pre-nuptial agreement. As Engelbert’s boss argues when he tries to set up some exit strategies before his next project, “Thinking of possible failure is negative thinking. It’s just that kind of thinking that guarantees we’re going to fail. Just like you did that last time.”

Of course, the last time, they had no such exit strategy, so their failure was much more costly and painful than it need have been. That’s The Titanic Effect: The thought that disaster is impossible often leads to an unthinkable disaster–”Why would we need lifeboats on an unsinkable ship?”

Three of my favorite quotes about change and translations:

“The only person who likes change is a wet baby.” This change corrects a problem so I’m OK with it.

“Everyone likes change, when someone else is doing it.” I’m OK with the status quo. You do the changing.

“The only universal constant is change.” Get used to changing. The universe constantly changes so you need to change too.

If change is so inevitable, why do people, teams and organizations experience so much difficulty changing? We should be good at it!

In fact, we are good at change, but in our own particular way. Any given change carries two factors. The requested change, and how we feel about that change. Recently while cooking, I grabbed the handle of a pan that had been in a 350 degree oven. It didn’t take long before I let go of the handle. I had no trouble accepting the need for this change.

Not all changes, though, are as universally accepted as dropping the hand of a hot pan. Suppose everyone were required to shave their head. This change wouldn’t bother me and I’d readily shave my head. Johanna Rothman assures me she’d have a big problem with this change and be very slow to change. This typifies “You go ahead and change. I’m happy with the status quo.”

Change Quotients

If we ignore neurologically requested changes (like letting go of the hot pan handle), we can view the ratio of the change/willingness to change as a quotient. As we average all the quotients over many situations for one individual, we arrive at a statistical value I’ll call that person’s Change Quotient. The Change Quotient relates to how open a person is to change.

Change Quotients vary from 0 to 1. Values close to 0 indicate a preference for slow changes and value approaching 1 indicate people who readily change. We each have a unique change quotient. 0 doesn’t mead “bad”, and 1 doesn’t mean “good”. The values simply indicate a preference.

People with lower change quotients often view those with high change quotients as chaotic and “flighty”. I was once asked to “make up my mind” when in fact I’d already made my mind up and shared the results twice while the other person was still thinking.

Conversely, “glacial” describes low change quotients to those having change quotients approaching 1. These people seem to reject instantly any suggestion to change, even something as simple as removing their boot from your bare toes.

Several things contribute to our Change Quotient. Any proposed change runs a gauntlet of survival rules, self-esteem, and personality/family checklists. The gauntlet forms our “willingness to change.”

Survival rules perform as “mental reflex actions”, the things we do, the thoughts we think, and feelings we have, that we don’t consciously think about. We build most of our survival rules by repeated assertion, usually by our parents or respected adults, of things to keep us alive. “Never make a decision until you have all the facts.” “Don’t be wishy-washy–make up your mind.” “Be your own man–don’t let others push you around.”

Self-esteem reflects how we currently feel about ourselves. This fluctuates based on our physical state (rested/tired, healthy/sick), our mental state (happy/sad, exited/bored) and how we feel others view us.

Our family creates our initial world view. Some families view consistency and slowness to change as admirable qualities. Others feel adaptability and responsiveness are desirable attributes. Each one of us starts with our family’s view of change start with this view.

Personality builds on this foundation. We add our experiences, successes and failures, to build new rules about change. Which kinds of change we can accommodate (or welcome) quickly, which changes we need to consider, which changes we want to avoid.

Responding to Change

Some years ago I found out that I was not really in charge of everything, and actually in control of very little. This led me to

Don’s Dismal Dilemma: How will I achieve my goals, when I’m not in charge or control?

Physical systems follow patterns established eons ago. Friends do what suits them. My clients determine when and where I’ll work with them.

As time progressed, I found the one thing in the universe I have complete control over: me. And so I found

Don’s Delightful Discovery: I can’t control what happens to me, but I can control me, and how I respond to what happens to me.

As Virginia Satir said, “We can direct our efforts to change what we can and to work out creative ways to live with what we can’t change.” [New Peoplemaking, pg 7]

When we quit changing with our environment, we face extinction. We need to update our mental models so they conform to current reality. As we grow and mature, our realities change. Our mental models need to reflect the changes. Mental models formed in childhood and not updated make for interesting adult behavior. Dad warned me about getting “Hardening of the Attitudes”. (Notice the survival rule that affects my change quotient?)

Changing allows me to achieve my goals. If the goal doesn’t change, and external events (by definition beyond my control) change the situation, I need to change my actions (I control these) to bring the results in line with achieving my goal. Or perhaps my actions aren’t producing the results needed to achieve the goal. Again change becomes necessary to realign with my goal. If I don’t change what I’m doing, my actions will take me away from my goal.

“Insanity: doing the same thing over and over again and expecting different results.” Albert Einstein

Occasionally I need to change my goals. As I learn more, what used to be important may not be important now. Changing goals allows me to work on what’s important to me.

So what to do? The answer depends if you are the changer or the changee.

For the changer …

Asking other people to change can appear as “Inflicting Help.” Insisting other people change borders on foolhardy. Think about the following:

1. You’ve already thought through the change, they haven’t. Allow some soak time.
2. Are you really solving a problem? Check out “Solving Other People’s Problems.^“1
3. Expect people to react differently at different times to different change requests.

For the changee …

Rhonda’s Second Revelation: “When change is inevitable, we struggle most to keep what we value most.” – Jerry Weinberg

1. Remember everyone has a different Change Quotient. What you see as change, they may view as stable.
2. The Helpful Rule reminds us “Regardless of how it looks, people are trying to be helpful.”
3. Share with the changer what is most valuable to you.

I’d like to share my favorite quote about change:

“Change happens one person at a time.” Virginia Satir

And you can always change your mind about how you change.

¹ Amplifying Your Effectiveness: Collected Essays, Dorset House, ISBN 0-932633-47-1, pages 17 – 21

Man’s achievements rest upon the use of symbols. – Alfred Korzybski

Why is our field struggling in its efforts to become and engineering discipline? The answers lies in our heritage as symbol processors and the patterns of evolution from craft to science.

“Higher order abstractions of lower order referents.” This is not recognized as a sentence. If fact, it is not recognized at all! This is something we learn to do as soon as we learn to speak. When we utter our first “Ma-Ma”, we’re not really referring to the organism that conceived, nurtured and gave us birth (although all of this is true). We refer instead to this object that floats into view when we cry, feeds us when we’re hungry, and changes us when we need it. It even makes funny faces and keeps uttering the incoherent phrase “Ma-Ma”. And whatever it is, it gets obvious delight when we form and utter “Ma-Ma” back to it. We are clueless about what a symbol is, but we know how to use it to our advantage.

The process of abstraction (in language) was introduced by Alfred Korzybski, and is demonstrated by the abstraction ladder[3]. The abstraction ladder can be used to show how we progress from the physical (atom/molecule level known as process level) through various abstractions layers to the actual use in language. For example, a “cow” ladder may include the following layers:

8. Wealth – The word “wealth” is at an extremely high level of abstraction, omitting almost all reference to the characteristics of Bessie.

7. Asset – When Bessie is referred to as an “asset,” still more of her characteristics are left out.

6. Farm Asset – When Bessie is included among “farm assets,” reference is made only to what she has in common with all other salable items on the farm.

5. When Bessie is referred to as “livestock,” only those characteristics she has in common with pigs, chickens, goats, etc., are referred to.

4. The word “cow” stands for the characteristics we have abstracted as common to cow₁, cow₂, cow₃, . . . cow_n. Characteristics peculiar to specific cows are left out.

3. The word “Bessie” (cow1) is the name we give to the object of perception of level 2. The name is not the object; it merely stands for the object and omits reference to many of the characteristics of the object.

2. The cow we perceive is not the word, but the object of experience, that which our nervous system abstracts (selects) from the totality that, constitutes the process-cow. Many of the characteristics of the process cow are left out.

1. The cow known to science ultimately consists of atoms, electrons, etc., according to present-day scientific inference. Characteristics (represented by circles) are infinite at this level and ever-changing. This is the process level.

In most cases, if we work diligently, we can work our way back down the abstraction ladder to “what the user ‘really’ means”. If we step back though, and look at the higher order abstraction “software”, what do we find when we get to the bottom of the ladder?

Even though I’ve wrestled with this question, in relation to software I still keep getting the same answer, “Nothing!” There is no lower order referent at the ladder’s lowest rung. There is no object, no “atoms, electrons, etc., according to present-day scientific inference”. Representations of the software exist, but I’ve never seen a “handful” of software.

Any sufficiently advanced technology is indistinguishable from magic. — Arthur C. Clarke

This leads me to the conclusion that software is the “brain stuff” which executes on a computer, doing something useful for somebody. This brain stuff has no mass, no energy, nothing. Yet it transforms inputs into outputs, as if magic.

This is not the first time we’ve come upon things that we didn’t quite understand. Physical phenomena have been observed for centuries before the underlying principles were divined. After a couple more centuries of scientific inquiry, the principles were organized and engineering became possible.

Perhaps this then is the start of the confusion about software being part of engineering. Both activities lack low order referents. Both activities involve “brain stuff”. Both activities involve mathematical proofs, explanations and derivations.

To say however that creating software should fall under the engineering profession makes no more sense than to say accounting, or the actuarial mathematics should be part of the engineering profession. Some day when we better understand what this is all about, we may find that engineering and software are simply two branches of “brain stuff”. A better analogy is to say that software is like engineering in that there are many branches sharing a common trunk.[1]

The discussion about adding software to the (professional) engineering disciplines is understandable, if misguided. No other technology has become as pervasive as fast, or has the impact on our lives that software has. The stuff is everywhere after only 40 years.

Similar to the evening news, it seems the bad news gets the majority of the air time. For every Denver Airport Luggage System, there are successes that never get air time, yet we take for granted. In my kitchen, only the can opener and toaster don’t have keypads and readouts. My car’s anti-lock brakes depend on software. In fact, if the main processor goes out, my car won’t even run. I’ve never heard a story about these (or similar successes) on the news. Is it a wonder society is nervous about the quality of the software that pervades their life?

In her report, “Prospects for an Engineering Discipline of Software”[2], Mary Shaw makes several key points.

1. Activities generally start as crafts.
2. When there is sufficient experience and demand, the steps of the craft become more formalized, and the production/commercial phase of the activity is entered.
3. As science foundations are determined for the activity, professional engineering becomes possible.
4. Professional engineering and science exist in a symbiotic relationship with engineering providing new problems for science, and science providing new techniques for solving the engineer’s problems.
5. As for software engineering “Unfortunately, the term is now most often used to refer to life cycle models, routine methodologies, cost estimation techniques, documentation frameworks, configuration management tools, quality assurance techniques, and other techniques for standardizing production activities. These technologies are characteristic of the commercial stage of evolution; software management would be a much more appropriate term.”[2]

Software management issues are addressed by the Software Engineering Institute’s “Capability Maturity Model” and the ISO9000 series of standards.

The Journey of a single step begins with a thousand miles.

So what should we do? To include software as a professional engineering discipline is doomed to failure since:

1. Creating software is still in the craft/production stage. As the primary resource is “brain stuff”, I’m not convinced we’ll ever move beyond this stage.
2. Finding a common core of knowledge applicable to all branches of software will result in abstracting up a step and result in those activities that Mary Shaw refers to (correctly in my opinion) as “software management”, not software engineering.
3. Education in the field at this time seems somewhat disjoint from science and current practice.

At this point in time, it looks like the next step is one of education.

1. We need to teach software creators about best practices, models, and algorithms (and here might lie the eventual basis for engineering activities in software).
2. We need to teach software managers that “brain stuff” is:
   • Not compressible in time. (Most late software is the result of bad date scheduling, not bad programming).
   • Not necessarily easy to rework. Changing the structure of a program or system may be very costly. (as in time and dollars)
   • Quality must be built in from the start, not inspected in at the end.
3. We need to teach society what are reasonable expectations with regard to software.
4. We need to teach ourselves what it means to be professional, and then start acting that way. [4]

Notes

[1] Check “Will There Ever Be Software Engineering”, Michael Jackson IEEE Software, Jan/Feb 1998

[2] Prospects for an Engineering Discipline of Software, Mary Shaw SEI-90-TR-20

[3 ] Language In Thought & Action, Fourth Edition, S.I. Hayakawa, page 155

The “Abstraction Ladder” is based on “The Structural Differential,” a diagram originated by Alfred Korzybski to explain the process of abstracting. For a fuller explanation both of the diagram and of the process it illustrates, see his Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics ( 1933 ), especially Chapter 25

[4] Three organizations I’m aware of that are involved in the issue of professionalism are:

• Association of Computing Machinery (www.acm.org)
• Independent Computer Consultant’s Association (www.icca.org)
• IEEE (www.ieee.org)

“Repeatedly curing a system that can cure itself will eventually create a system that can’t.” - Marvin’s Second Great Secret, Jerry Weinberg

“Don, the software’s locked up again! Can you come up here tomorrow and fix it?” George was on the other end of the conversation. George and I had started working together when his employer moved a production line from Florida to Virginia. This move created all sorts of problems¹.

The daily struggles getting the hardware, software and process playing nicely together had become a weekly check-in with an occasional on-site visit. This made the request seem a little odd.

Taking a deep breath allowed me to work through some quick thoughts². The software was running on 15 different computers. There wasn’t any way they could all lock up at the same time. And what does “lock up” mean anyway? What’s going to happen different between now and tomorrow, or now and next Monday? And if I drop what I’m currently working on to rush up there tomorrow, am I really helping George? What long-term consequences result from this?

Solution #1 – The Quick Fix

Accepting that a problem is an undesirable difference what we want and what we have, George had a problem. Since I helped George with several other problems, it seemed natural that I should help with problem also. Using a causal loop diagram, the situation looks like this:

The more the computer locks up, the more Don gets called. The more Don gets called, the more problems he solves. The more problems Don solves, the less the computer locks up. This is a balancing loop that brings stability to George’s process. It’s also a symptomatic solution, a quick fix to make the pain go away. But following the steps in B1 only solves the immediate problem; it does not solve the underlying fundamental problem. Think of it as treating the symptom, not the disease.

Solution #2 – George Learns to Solve the Problem

There’s another possible answer. What does it look like if George solves the problem without calling Don? First George needs to learn “C” much better than he currently knows it. That takes time. This time delay gets represented by the “||” mark on the line. Then he needs to figure out where in the 5000+ lines of code the problem resides. That also takes time. Finally George can solve the problem, but by now something else is broken worse somewhere else, everything gets put on hold, and when George finally gets back, he’s lost his train of thought, and has to start solving the problem again. Diagrammatically we represent it this way:

This is also a balancing loop bringing stability to the system. B2′s advantage over B1 is B2 represents a systemic solution. The more the loop executes, the better the system gets at solving the problems. This reduces the system’s dependence on outside interventions. The disadvantage of B2 is the time delays involved in learning “C” and understanding the application code. The time delays do get less the more the loop executes,

Solution #3 – Combining the Symptomatic and Systemic Solutions

Since B1 and B2 both contain “Computer Locks Up” we can combine the two causal loop diagrams into a more complete problem-solving picture.

This shows the how the event “Computer Locks Up” can trigger one of two responses: a symptomatic response to make the problem go away quickly (B1), or a systemic response (B2) where the system becomes more capable of solving problems without external influence. This pattern occurs often enough that systems people have given it a name, “Shifting the Burden.” I’d been aware of this archetype, but preparing for my “Deja vu” session³ with Diane Gibson sharpened my awareness of what could go wrong.

An Unintended Consequence – Too Much Help

There happens to be a long term reinforcing loop that can show up with this archetype. This occurs when the symptomatic solution (B1) gets all the action. Don becomes better at both “C” and knowing the code base. This makes it easier and quicker for Don to solve the problems, and Don becomes indispensable.

This means the system’s ability to “cure itself” becomes atrophied. George loses his ability to persuade management to give him training. Production becomes accustomed to “great customer service” from Don. The ability to tolerate “pain” goes away, and the quick fix becomes the only fix.

Invoking the symptomatic solution not only starts B1, it initiates R3. Calling Don reduces the need to learn “C”, thereby weakening the system’s problem solving ability. Carried to the extreme, this becomes an addictive response, and cripples the system.

And The Final Answer Is

Either balancing loop can be chosen to a given problem occurrence. Handled properly B1 can be used to alleviate acute problems, while invoking B2 to solve chronic problems. This pattern of selectively, consciously choosing how to deal with each problem has resulted in George’s ability to solve more code problems and start making enhancements to the code base.

I appreciate Stuart Scott and Jerry Weinberg for their suggestions about this article

¹http://www.ayeconference.com/Articles/Howdidthishappen.html

²http://www.ayeconference.com/Articles/Dontdosomething.html

³http://www.ayeconference.com/wiki/scribble.cgi?read=SessionFour022 and http://www.ayeconference.com/wiki/scribble.cgi?read=SessionFive005

Models are like kitchen utensils. You need a variety of them, and you should know when and how to use them. They should be useful for more than a single task. I recently started exploring the first explicit model I learned years ago.

The Cybernetic Model

One of my more interesting college classes was feedback control. The class was based on differential equations, Laplace transforms, and a single model that looked like this:

This model is the basis for most of the process control in the world. The controller compares the setpoint to the actual value.The controller uses the error information to take corrective action. If the temperature is too hot, the corrective action might be to reduce the heat in the temperature jacket. After a while, things cool down. All processes have a time lag between the corrective action and when the change arrives at the output. I “borrowed” the “delay symbol” from Causal Loop Diagramming to show this. If it gets too cool, the controller will change the action and add more heat.

I didn’t realize at the time how powerful and versatile this diagram is.

Personal Problem Solving

With just a few word changes, the model can be used to describe how people can solve their problems.

A problem exists when a difference exists between what we want, and what we have. We can solve the problem by changing our actions, and seeing if the world at large responds with results that are closer to what we desire.

I’m trying to lose a few pounds. I can change what I eat (calories, fat, carbs, pick your favorite fad diet). I can change how often I exercise. If I continue with these changes, eventually I should lose the weight.

Project Management

Change a couple of more words, and now we have a project management tool.

In this drawing, I’ve used a dash line connection between the manager (in this case synonymous with leader) and the team. I made this distinction since managers don’t have a direct linkage to the team. Managers can ask, cajole, threaten, and perhaps fire team members who don’t perform the tasks they’ve been asked to do. But the team member always has a choice.

Loops All the Way Down

It is possible to nest the cybernetic model. Consider the Scrum sprint cycle. The sprint cycle overview looks like:

The outside loop is the sprint cycle (usually 30 days or less). Every sprint the product owner sees new product functionality. They compare the current product state with the target and prioritize the remaining user stories. The product owner and team select a subset of the remaining stories which becomes the current sprint backlog.Completing the sprint backlog is the goal (setpoint) for the inside loop. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal during the daily standup meeting.

A Rose is a Rose

In QualitySoftware Management Volume 1, Systems Thinking Jerry (Gerald M.) Weinberg presents the model in a slightly different picture (page 62).

Jerry says, “The feedback model of a software development system requires feedback of information about the system’s performance, plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 from Patterns 0, 1, and 2. It is also used by Patterns 4 and 5.”

This presentation highlights two systems aspects:

1. Randomness. All systems interact with their environment. Changes in the environment create changes in the system whether the changes are planned or not.
2. The software development system creates “other outputs” that the controller can use to improve the overall system performance.

A Good Place to Start

Like kitchen utensils, you need many different models. I keep a list of models I use here. The list includes:

• the Cybernetic Model
• Diagrams of Effect
• Behavior Over Time Graphs
• systems archetypes
• the Satir Interaction Model
• the Satir Transformation Models
• MBTI (and temperaments)
• abstracting (Korzybski)
• abstraction (Hayakawa)
• the NLP Meta-Model
• meta-programs
• intake modalities
• the Rule of Three

I didn’t consciously start the list with the Cybernetic Model, but that’s where it belongs. Any time I start with a difference between what I want and have, I’ve already started using the Cybernetic Model. I may choose to use other models to help resolve the difference between my desires and perceptions.For instance, if I’m involved in a conversation that doesn’t make sense, I may use the Satir Interaction model to find out why the conversation doesn’t make sense. If a co-worker’s actions don’t make sense, maybe I’ll use MBTI types to shed light on the problem.

But it all starts with the multi-use, handy-dandy, Cybernetic Model.