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

1. The AYE Conference schedule contains several sessions involving systems thinking. Two sessions, Experience the Diagram of Effects and General Systems Thinking obviously involve systems thinking. Several other sessions will include systems thinking principles, without necessarily naming them as such.

You can receive emails about the conference by signing up here

2. I recently received an email related to Force Ranking. It said … “I am currently working at [a company] for few yrs, and yes, I am suffering in the “forced ranking” system. After 1.5 yr from your article which talked about forced ranking, today is 2007- 5 – 27, our team is breaking down into a mess, ppl started to protect themselves, fighting each other rather than helping each other; poor management team : political competitions happen anytime anyday, and kissing boss’s ass will get a better position; The [company] stock price drops, always hear the rumour of [larger company in Redmond] will buy [our company]. Our so-called “innovations process” never reached the outstanding result as [a competing company], it is just a way for ppl to getting a better KPI (annual review), to avoid falling into the bottom 10%. Let’s see how/what [this company] will turn to be…u bet?

I have a pretty good idea how this is going to turn out. Maybe not soon, but if the system forces don’t change, it’s only a matter of time.

3. In Multi-use Models I mention how the feedback control loop model can be used for personal problem solving. I used the example of losing weight. It works! I’ve lost 30 pounds since I wrote the blog entry. Another 4.5 kilos and I’ll be at my goal.

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.

I want to recognize I’ve been using two words interchangeably: systems and organizations. In this context, I view an organization as a specific type of system.

Systems contain three basic components: reinforcing loops, balancing loops, and time delays. Reinforcing loops cause growth or decline. Balancing loops interact with reinforcing loops and create stability. Time delays separate cause and effect by days, months, possibly years. These delays determine how quickly a system responds to a change.

Delays occur in several places for organizations.

Transport delay involves the time required to move information around the organization. Information that development needs to know may enter the organization in customer support. “Oh no! The Frammin module appears to be broken! It’s reformatting the customers’ hard drives and displaying Elbonian profanities on their monitors!” The standard hierarchical organization communications path would be up the chain to the common node, then back down the development change to the managers who decide what should be done, and then to the programmers who actually do the work.

Decision delay results from the time required to decide what to do. I used to believe that inside every complex system, there was a simple system trying to get out. I still largely feel that way, but some software systems are complex, and that’s that. We’ve been writing software for 50 years. Most of the easy programs should be written. That leaves the difficult and complex programs. Quick decisions can spell disaster if the long and short term ramifications aren’t considered. When the development managers learn the Frammin module causes problems, it may take a while to determine the circumstances surrounding the problem event, exactly what part of the Frammin module causes the event, and what to do about it.

Implementation delay is the time required to do the work. The classic line here: “You can’t produce a baby in 1 month with 9 women.” Some work is separable and can be done in parallel by multiple workers. Some isn’t and must be done by a single person. Quick thinkers will try to create separable work. While work can proceed in parallel effort, communications (and gaps) and interfaces become issues. These issues are avoided when a single person does the work. So which answer is better?

Time delay relates to a system parameter called time constant. When the system output reaches 63.2% its next value, one time constant has passed. The following graph shows a system with a time constant of (approximately) 4.5.

By reducing any or all of the delays, we can achieve a result in a shorter time period as demonstrated by:

We’ve moved the time constant to (approximately) 3, or reduced the time it takes to respond by 1/3.

How do we remove delay from the system?

Transport Delay: All organizations have informal networks that pass information to where it should go. These networks are usually called “friends”. Some organizations explicitly encourage this by “cross assignment.” A developer works in customer service. A tester may spend time in development. Besides broadening the skills and creating an understanding of what the other person does, this creates the informal network that keeps information flowing.

Decision Delay: “Empowerment” bothers me. I actually think it’s a great idea, but in many situations the idea gets morphed into an evil double bind event. Nonetheless, we’re talking about empowerment. Move the decision making authority to the person closest to the information (reducing transport delay) and work effort (possibly also reducing implementation delay). The management problem resides in authority to make a decision can be delegated, responsibility for that decision can’t. Maybe this causes the standard empowerment double bind.

Implementation Delay: Better people make better products. I can’t put my hands on the data, but I seem to remember that Jerry Weinberg, Tom DeMarco, and Capers Jones have all released studies showing that individual performance varies by an order of magnitude. So get better people. Read Johanna Rothman’s book: Hiring the Best Knowledge Workers, Techies & Nerds. Improve the skills and abilities of the people where you work. Send them to the AYE Conference. Improved workers will impact Decision Delay by allowing true empowerment.

Can you think of other delay causes? How can we mitigate them?

Agree? Disagree? Add a comment.

A problem can be a lot of things; perhaps a struggle, a puzzle, or a task. As a consultant, I find it useful to define “problem” as the difference between what is, and what is wanted. From that point of view, learning to solve other people’s problems means learning to connect with your client, understand what they think they have, what they think they want, and what they would like to do about it. The experience of living teaches each of us a lot about this kind of problem solving, but the lessons are often murky. In recent years, I’ve been trying become more conscious of my own process so that I can control and accelerate it. Here are some basic principles that I’ve found helpful.

The Pause Principle
When you receive a problem, pause before trying to solve it.

The problem solving starting point should be “Don’t just do something, stand there!” This principle is especially important in the case where there are strong emotions involved. It’s downright critical when those strong emotions belong to you. Pausing creates space for a lot of things: to breathe, to center yourself, to let more information come to you, to notice that the problem is different than you first thought, or to notice a solution sitting in plain view. To pause is not to stop everything. You can be doing a lot of things while you’re pausing. One of the most important is to pay attention.

The Pay Attention Principle
Critical information about the problem will hide in plain view.

I often find that what I need to know to solve a problem is not explicitly stated. But I also find that it’s not always easy for me to hear information that I am told. Communication is a complicated process. One tool I use for checking the process is the Satir Interaction Model. This model decomposes communication into four parts: Intake, Meaning, Significance, and Response. Intake is what we physically see or hear. Meaning is the sum of ideas we think are conveyed by the message. Significance is our how the message impacts us; our emotional reaction to it. Response is what we do in reply or reaction to the message. What I like about this model is that it helps me be aware of a lot of ways that good communication can go bad. If any part of this process goes wrong, the whole communication will be distorted in some way. Certain personality types may be more prone to mistakes in certain steps than are others. I occasionally jump too quickly to into Response, before I’ve sorted out the other three parts of the process. Knowing that, I find the Pause Principle to help me give the process time and ultimately pay better attention.

Communication is also important because of the next principle: partnership.

The Partnership Principle
When I make the problem my problem alone, that makes more problems for all of us.

The problem I’m presented with isn’t really my problem. I am not in the middle of that problem, the other person is. So there are risks whenever I try to help. By helping I may:

1.  Deprive that person of a learning opportunity.
2.  Take time from my work to do their work.
3.  Encourage an ongoing co-dependency between my client and me.
4.  Find a “solution” that my client feels no connection with.

The Partnership Principle reminds me to keep my client involved with the solving process. Ideally my client will solve the problem and I will support them as they do so. The worst case is when I find myself solving a problem so much by myself that by the time I unveil my wonderful solution, the client has forgotten about the problem and moved on. This situation relates to the next principle: passion.

The Passion Principle
Don’t care more about solving the problem than the other person does.

I once worked with a company that I believed had a problem. Their training material was sub-standard, their trainer had never used the software, and they were losing money because the sales channel wouldn’t promote the class. We (the client and I) initially set out to solve this problem. But less than a week after we dove in I woke up and realized I was the only who cared about solving this problem. They would not commit the resources to deal with the problem. My visions of better training and a better training business notwithstanding, I had to scale down my own enthusiasm to match their level of caring. A client who has no passion about a problem doesn’t really have a problem. And when something’s not a problem, it’s also not a problem not to solve it.

Passion does not belong to the intellect, so you can’t solve important problems with intellect alone. You also have to connect emotionally, in some way. You have to see the people involved and find a way to enter their way of seeing the world.

The Person Principle
Every problem is a problem for some person.

Each of the principles above is a reflection of this one. To solve a problem well, you need to discover whose problem it is, and find a solution that works for them. This is not so difficult if you are both the owner and the solver of the problem, but it gets tricky when you’re acting as a solver of someone else’s problems. Often there are many more people involved in the problem than just the particular person who brought it to you to solve. Furthermore, you aren’t only dealing with the people themselves and the problem itself, but also how these people feel about the problem, about each other, about you, and about the attributes of whatever solution you come up with.

And that is your problem.

This article was originally published in Amplifying Your Effectiveness:  Collected Essays,  Doset House Publishing, ISBN 978-0-932633-47-7