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 voilà! 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

Data

To Johanna it was a milestone she missed because her odometer lacked the resolution to let her know she was getting close. The entire last mile looked like 99999. It’s really difficult to pay attention looking for the next increment AND drive safely at the same time. If the odometer displayed to .1 of a mile, she’d have a better chance to drive safe and notice when she’s about to achieve 100,000 miles in her vehicle.

Doing things

To Jerry 100,000 miles means it’s time to buy a new vehicle. I don’t get the sense that 100,000 itself is so important, as it is to do something to prevent having problems in the future. Mechanical systems wear with use and will eventually fail. Based on his experience, Jerry avoids the eventual impending failures by purchasing a new vehicle.

Tipping Points

Using the cybernetic model

the controller (manager/team leader/whatever you call the person) continuously gets feedback data from the the development system. Most of the data most of the time don’t matter. People marvelously capably compensate for variation in information and actions. But when you get to a critical range, small changes in the data become incredibly important. Without intervention the project/team/person hits a tipping point and difficult times ensue.

The critical range varies based on what feedback data you’re getting. Is it sprint velocity? Team camaraderie? Personal behavior? Each has different parameters and context. All have different time constants. You need to have an idea of reasonable behavior for each so you can detect data lying outside “normal”, what ever normal is for that data set. That way when data approaches a tipping point, you’re aware and (hopefully) have a plan of action to keep performance/behavior in the “normal” range. Unfortunately at this time the only hard and fast rule I have is: There are no other hard and fast rules.

Make sense? Drop me an email or leave a comment.

Bad Matters Worse

The bigger and more complex object we try to describe, the more problems we have accurately doing so. So what happens when we try to describe something that doesn’t exist using words that don’t really exist? Sort of a meta-non-existence if you will.

For example, how about the word “software”? What comes to mind? I can’t show you a pound of software. I can’t hear running software like I can a running engine. I can’t feel software like the resistance of the keys as I type this sentence. About all software can be is mind stuff.

Since we’re using mind stuff (words) to describe mind stuff (software), can we expect to have anything but confusion?

Sliding Down the Slippery Slope

But that doesn’t keep us from trying. So we borrow words from other activities and use them. Words like “software engineering”. Mary Shaw’s original paper is titled “Prospects for an Engineering Discipline of Software” but somehow the “Prospects” got lost, and software engineering/engineers is/are everywhere.

The difficulty arises from the mental image created with the word engineering. Engineering disciplines have centuries of use, most prior to the mathematical models and physical understanding we now have. Engineers use standard repeatable techniques to build real world objects with specified characteristics in predictable time frames. If the time frame needs to change, it’s because of phenomena visible to all (such as it rained for 40 days and we can’t build while it’s raining).

This same mental image can’t apply to creating software since the field:

• is still young (less than 100 years).
• we’re still learning how to do what we do.
• there is no physical basis.

but we use it anyway.

Since we have the engineer mental image, it naturally follows that software projects should be managed using the same techniques as other engineering disciplines creating the next mental image, software project management. And how well has this worked? Take a quick peek at Kelly Waters’ post on Most IT projects fail. It doesn’t look good from here.

So Why Don’t We Change?

The first reason we don’t change is mind share. We have organizations like the Project Management Institute and the Software Engineering Institute proscribing how Things Should Be Done, and certifying those who pass certain criteria as PMP® or a certain CMMI® level. Disclaimer I am not anti PMI or SEI. All things have their place. But we’re dealing with meta-mind-stuff and management often confuses certification with both the ability to deliver the project and suitability of the certification to the actual problem at hand.

Another reason we don’t change involves inertia. In this case I compute inertia as:

inertia = mind share * time;

The equation’s time component involves how long we’ve thought this way, and a second order effect on mind share as people who believe this way get promoted to positions of management, then upper management.

The third model lock in involves cognitive dissonance. Data says the way we current run software projects isn’t working. But mind share tells us this is the way to run software projects. Common ways to resolve the cognitive dissonance include:

• Admitting it didn’t work, but we’ll try harder next time.
• Ignoring the project failure data (could this be why we don’t do a good job with metrics?).
• Chastising those lazy, incompetent programmers.
• (insert your favorite here).

Perhaps the greatest barrier to change revolves around the question “Who loses?” Change always comes from below. No one dealt four aces asks for a re-deal. Anonymous.

Guiding the Runaway Train

We need to be aware and accept that we’re working with the wrong analogy or metaphor. Software involves some aspects of engineering, but it also involves aspects of art. Rather than latch onto an existing mental model, we need to create a new one for dealing with meta-mind-stuff. We start doing this by changing the words we use to describe what we do, why we do it, and for whom we do it. The current counter position to “Command and Control” project management is “Agile”. Unfortunately this creates dichotomous thinking when we’re really dealing with a continuous spectrum of management options.

But what I’ve heard, read, and experienced, Agile (hereby defined by me for the rest of this entry as incremental/iterative software development) has a better chance of working since it uses a different management model. Rather than working with single pass logic, agile methods advocate breaking a project in several pieces, completing each piece in a fixed period of time. This would change a single 12 month project into 12 one month projects. This provides the following advantages:

• The customer gets value every month, starting with the most valuable parts first.
• The team can review and learn from the previous month’s work prior to starting the current month’s work.
• Plans can be adjusted monthly as new information becomes available.
• The person in charge (customer, product owner, whatever name you like) can see how the project progresses.

The section “Loops All The Way Down” in A Multi-use Model contains a simplified model depicting this. You could expand the Daily Standup/Team combination into feedback loops as well, one for each team member. The loops center around:

• What did I do yesterday? (feedback)
• What’s blocking me? (environmental information)
• What will I do today? (set point for tomorrow’s stand up)

This helps answer everyone’s primary concern: What’s In It For Me (WIIFM)?

• Developers can focus on immediate tangible results.
• Customers know every iteration how well the team understood what the customer wanted.
• The person in charge has progress visibility unparalleled in Command and Control environments.

The words we choose to use when we propose changing will determine how successfully we create the new software development reality.

Kurt Simmons asked this question in ProblemsVersusOpportunites. He shared some (what I think) are valid thoughts. I agree with them on at a cursory level. But in keeping with this blog’s theme, An Alternate Reality, what would it mean if problems and opportunities are actually the same. What would that look like? Sound odd? Hang with me for just a minute.

Once Upon A Time

Problems represent a difference between what we have, and what we’d like to have. Using Kurt’s example, “wrasslin’ alligators” is a problem for a handful of reasons:

1. The alligators may win.
2. If I win, PETA (and possibly law enforcement) will be after me, making the alligators look tame.
3. We play to a draw, leaving the swamp full of water AND alligators.
4. I really wanted to take the opportunity to drain the swamp, thereby creating an alligator free environment.

Oh that’s ugly. Pursuing an opportunity created problems. Who’d have thought? As Andy Grove said, “No problem is so complicated that you cannot make it more complicated.”

So what’s an opportunity? An opportunity represents a difference between the extrapolation of my current state/rate/progress and some idealistically better, hoped for, potentially possible other state. What limits my opportunities?

1. My current state. This includes all of the decisions and actions that got me into the swamp with the alligators. Where I am potentially limits where I can go. Someone wrasslin’ alligators isn’t likely to ponder running the Boston Marathon.
2. There is no such thing as a free lunch. If I decide to pursue the Boston Marathon opportunity, I’m probably not going to be to work on getting the Nobel Prize in Economics (or Alligator Wrasslin’). Now the problem becomes selecting which opportunity to pursue.
3. The illusion of opportunity. While the grass looks greener from the swamp, human history contains an incredible number of fixes that failed. So many in fact, that General Systems Thinking has an archetype cleverly named “Fixes that Fail”. It’s been said that “Today’s problems are yesterday’s solutions.”

So a problem is an opportunity who’s time is now, not in the future.

So What’s Your (view) Point?

Kurt alludes to the second proof that problems and opportunities are the same. He said, “Whenever I got injured playing sports I used to go in a deep funk. I think I grew up when I started looking at sports injuries as great opportunities to catch up on my reading.” This points to the same event being both a problem and an opportunity. In fact, Kurt says that “being up to your keister in alligators … is a great opportunity to practice alligator wrasslin’.”

I believe Jerry (Gerald M.) Weinberg was channeling Virginia Satir when he said “What happens isn’t important. It’s how we respond that’s important.” So it’s our viewpoint and response that determines if something is a problem or opportunity.

The Practical Application

Here’s a quick test. The AYE Conference super early discount period ends April 30, 2007. The price if paid in full is 40% off the at-the-door price. Based on what you’ve just read, would you consider this to be a problem or an opportunity? Need more information about the conference? You can check out the current schedule. Need to ask some questions? Drop me a note.

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. Basically the setpoint getscompared to the actual value. The error value goes to a controller, that then takes a corrective action. If the temperature is to 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 generic sprint cycle looks like:

The outside loop is the sprint cycle (usually 30 days or less).  Every sprint the product owner sees new product functionality. This allows him/her to compare the current product state with the target. A subset of the remaining stories gets selected by the team and becomes the current spring backlog. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal by completing the stories in the sprint backlog.

I’ve left some feedback loops out of this drawing:

1. The team assigns stories relative weight/size/difficulties to the stories.
2. The sprint planning meeting occurs in the arrow labeled “Priority Stories”. The team uses the information from its previous sprints to determine how much they can accomplish in the next sprint.
3. The many interactions that happen each day as the team works towards the sprint goals.

I chose not to include them since I’m working from an overview position. If these areas presented difficulty for the system, I’d focus on them and leave the other loops off.

A Rose is a Rose

In Quality Software Management: Systems Thinking Jerry 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. Here’s a list of models I’m aware I’m using.

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.

Based on the domain, I may choose to use other models to help resolve the difference. 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, it’s everywhere, Cybernetic Model.

Being older gave Jessica advantages, but that didn’t stop Nikki.

Know Where You’re Starting, and Where You’re Going

Nikki saw Jessica climb the “chain/pipe” ladder and decided to follow her sister. She trundled around the jungle gym to the foot of the “chain/pipe” ladder. I’m absolutely she didn’t stop and say: “A problem is the difference between what I have, and what I want. I’m at the bottom, and I want to be at the top. Therefore I have a problem. I need to hire a consultant. I wonder what Pop charges?” It went more like, “I want to be up there.”

Straightforward differences can usually be solved with straightforward action. But “differences with two or more possible solutions of unequal value to the problem solver” (Ackoff’s definition of a problem) will require more explicit statements of where you’re starting and where you’re going. The more detailed the information you collect, the better you’ll understand the the difference.

What Do You Want to Keep?

Nikki is incredibly observant and tactile. She noticed and picked up a small branch with long pine needles just before she decided to climb the “chain/pipe” ladder. This complicated her task since it only left one free hand for grabbing and stablizing.

As we solve problems, what do we try to keep? Parts of the current system are valuable and worthwhile, and we might want to keep them. But keeping something from the current reality affects our possible solutions by limiting the degrees of freedom available to us.

Be Willing to Change

When Nikki started up the ladder, she had her right hand on the rail. She made the first step, and realized she wasn’t going to be able to hold on the rail with one hand, the pine needles with the other hand, and NOT fall as she made the move to the next rung. She stopped, thought, and moved her right hand to the rung two above the current rung. This allowed her to climb the ladder.

Part of problem solving involves analyzing feedback, asking ourselves, “Is this working?” or even “Does this make sense?” I worked with a client once and had a simple solution to the task. The bad news was it would require 8 repetitions. As I was manually editing the first file, the client was attempting to use Excel macros for string manipulations. When we compared notes, I noticed his solution made more sense than mine, he was simply using the wrong scripting language. I changed what I was doing, wrote a straightforward script that did the substitutions we needed automatically. It made more sense.

What Doesn’t Matter Now, May Matter Later

It rained the night before our trip to the park. Nikki decided to go down the slide, and over Karol’s objections, I let her. I mean, what’s so awful about a wet bottom? During the kilometer walk back to my daughter’s house, Nikki’s legs gave out, and guess who got to carry her home!

When we choose a course of action, we “un-chose” other courses. To help think about what could go wrong use the following rule of three. “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.” [Secrets of Consulting, Jerry Weinberg pg 81] If I’d have thought about the trip home, I could have guessed what was going to happen. When you find bumps on the project path, take a moment, reflect and ask, “Could I have foreseen this would happen?”

Seen anything interesting lately? Drop me a note.

I talked with a friend today who regaled me with the problems they’re currently experiencing at work … teams being assembled, and then reassembled, departmental barriers, resistance and unwillingness to collaborate. It sure looked like they had a lot of problems at the team level.

Then I heard about the management. Words like control freak, micro-manager, feels comfortable yelling at managers in front their peers, doesn’t recognize people.

I don’t know enough about the situation yet, but it looks to me like the leaders (who have the gold) have defined the problem to be the team’s problem. That way they don’t consider what they may be doing to contribute to the problem.

But as I think about what I understand involving force ranking, the logic behind it makes some sense. If I remove the lower performers (by some criteria) from my team, the overall average team performance (of that criteria) goes up. [Let me know if you'd like to see the math behind this thought.]

Here’s my idea of what a DoE looks like for force ranking

Force Ranking Dyanmics

Force ranking creates competition between individuals. As competition increases, more effort will be put into increasing (at least the appearance of) individual performance. As individual performance increases, it appears that force ranking is working, and force ranking gets used more. When this goes on long enough, the people who excelled in being force ranked get promoted and force ranking becomes institutionalized. After all, it worked for them.

But after a while, the secondary loop starts to apply pressure to the system. The competition between individuals reduces the team’s performance. This happens since time and energy spent “improving one’s self” comes at the expense of time and energy working toward the team’s goals. It probably creates conflict and tension between the team members, and quite possibly internally in the team members (not everyone enjoys competition). Since the overall team performance has gone down, we need to do more force ranking to get the performance up to where it used to be, there by invoking _Weinberg’s First Law of Bad Management_ If what you’re doing isn’t working, doing more of it won’t help.

But It Appears to Work!

For a while anyway. This happens because people will sacrifice for some period of time. This creates the delay before the secondary “team loop” starts to function. During this initial period of “working” observers notice the shiny new management technique and proceed to implement it. However …

Why does it fail?

Force ranking fails to consider (at least) three principle systems concepts: emergence, cause-effect and optimization.

It’s that old-timey synergy thing: “The whole is greater than the sum of the parts.”

Cause-effect comes into play by separating the effect (poor team performance) from the cause (force ranking) in time. When management notices that team productivity has declined, force ranking will be institutionalized, and the primary thought will be “find the low performers and move them out.” It will take a catastrophic calamity before anyone will stop to consider that force ranking may have caused the problem.

Force ranking optimizes the organization at the individual level. As each individual optimizes their outcome, the larger systems (teams, departments, and organization) will be sub-optimized due to the conflicting goals between individuals. If the original reason to force rank is to improve performance, then in the long run, force ranking is dysfunctional as it returns less value to the client than the original state.

Another way to blame?

Without actually saying it, force ranking seems to be a blaming activity. People are identified as “not as good” and removed from the team. Here’s a DoE that shows blaming’s effects.

The Blame Game

What did I miss? Send me an email.

Why I Can Agree

Jerry’s example of here-now-us related to a client’s problem. Through the magic word “snow”, one person transported themselves to “there-then-them”, and applied the emotions and feelings from the “then-there-them” to the current “here-now-us”.

Willem’s example of “there-then-them” shows that reflecting on “there-then-them” (“me“ in his example) provides insight that may allow him to change his behavior (if he wants to).

Neither example precludes or excludes the other when thinking about “there-then-them” and “here-now-us”. So what good is it?

A Useful Tool

The “there-then-them” / “here-now-us” tool can be used tactically or strategically. Tactically it helps problem solvers keep track of WHICH problem they’re trying to solve. When the solving the current problem suddenly vectors off in a surprising direction, be suspicious that someone went “there-then-them”.

Strategically, “there-then-them” can be used to reflect on how we got here, and what we might want to change.

Do you have useful tool for systems thinking? Drop me a note.

So many books, so little time! When Steve recently recommended The Art of Problem Solving by Russell L. Ackoff, I promptly ordered it from my friends at Amazon. Originally published in 1978, this book retains its relevance. The book has two parts: The Art and Applications.

The Art section provided smiles and provoked thinking. For example, I’ve stated that a problem is the difference between what I have, and what I want. For Ackhoff, problems arise when a choice exists. No choice, no problem. Hmmm. And how about the three possible outcomes, solved, resolved, and dissolved? This section includes anecdotes from Ackoff’s experience which are summarized with “Morals” such as:

• The end of one problem may be the beginning of another.
• It is easy to blame others for our own mistakes, but it is hard to correct them doing so.
• There is nothing so deceptive as an apparent truth.

The Applications section contains case studies amplifying the Art section contents. Other than the chapter “On Keeping Problems Solved”, this section didn’t do much for me.

I recommend this book to anyone involved with systems thinking. It discusses fundamental ideas that will aid in better thinking, which can only improve systems thinking.

Got a good book to recommend? Add a comment or send an email.