©2007 Don Gray

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

convert this post to pdf.

©1999 Gerald M. Weinberg

External consultants are seldom sent to classes by their customers, but often pay for their ownprofessional development. As such,they’re eager to get full value for their time and tuition.

Moreover, external consultants often find themselves as instructors in classes, in which case, they’re also interested in making sure the class goes well.

But not all classes go well, and often it’s because the mix of participants isn’t ideal. Or, to look at it another way, it’s because the instructor doesn’t know how to handle certain kinds of participants.

Our Problem Solving Leadership workshops are designed for professional development – specifically, to develop leadership abilities in the participants. Because leadership means so many things to so many people, our participants arrive with different expectations, so one of the first things we must do is clarify why each participant is in the room.

Over the years, I’ve seen students who fall into four categories – Customers, Learners, Visitors, and Complainers.¹
Each type of student requires a different approach from the instructor.

A Customer is someone who arrives with a particular problemto solve, for themselves or concerning some other person(s) or situation.If a student is a Customer, it’s possible to gain a relatively cleardescription of this problem. Here aresome examples of Customer problems brought to our PSL Workshop:

“I want to communicate better with my customers when they are trying to tell me
their requirements.”

“I want to do a better job facilitating meetings.”

“I can’t handle my boss when she criticizes my work.”

“My teammates often don’t listen to my ideas,so that they misunderstand them and reject them.”

“I’m putting together a new project team, and I want to do it without making the
same mistakes I made last time.”

The participant as Customer quite clearly wishes to do something about this problem and is seeking help from the class and the instructor. All the instructor has to do to satisfy the Customer is offer a high-quality class. Most instructors wish for a class composed entirely of Customers, but it’s never that easy.

A Learner is someone who comes in without a particular problem to solve, but just wanting to learn whatever the class has to offer.Typically, Learners may state their objectives in ways such as these:

“I heard this was a neat class, so I wanted to learn what you had to offer me.”

“I’m interested in teamwork and how to build teams.”

“My best friend at work took this class and wouldn’t tell me anything about it except that I should come and learn whatever I learn.I like that idea.”

“I’d like to improve my problem solving skills (without mentioning any particular situation).”

Learners are fun to have in class, because they gobble up everything the instructor has to offer. They never ask that hard question the Customers may ask: “What’s the relevance of what we just learned to so-and-so.”

Nevertheless, they can be a danger to the class because they may drift off in any direction just because it catches their fancy.If the instructor gets distracted by Learners, the Customers start getting angry because they’re not getting what they came for.

A Visitor is an uncommitted participant, often involved in the class under some kind of duress, implicit or explicit, and usually because of the concerns of some other person. Typical statements by Visitors might be:

“My boss told me I needed to learn whatever this class teaches.”

“My company bought three seats in this class, and someone cancelled one of them, so they sent me to fill the empty seat.”

“Everyone in our department has to go to this class.”

“I can’t get promoted unless I’ve taken this class.”

The Visitor has no agenda to participate in class discussions, and works on any exercises in the most minimal way. Attempts by the instructor to improve the Visitor’s participation are likely to be fruitless or to lead to “resistance” that can be disruptive to the whole class.

Trying to capture the interest of a Visitor can easily distract the instructor from paying attention to others in the class who are not Visitors.

Instructors need to treat Visitors respectfully, always being open to their contributions, should they decide to start making them. If Visitors do contribute, honor their contributions with complimentary (but not effusive) feedback.Until they volunteer to contribute, however, avoid soliciting their participation or trying to assign them tasks.

They have to make their own choice to transform themselves into Customers, or at least Learners.

A Complainer does have a particular problem (or list of problems), specific or vague, either concerning themselves or about some other person(s). The Complainer’s problems may resemble the problems brought by the Customer, but it’s not clear that the Complainer actually has any wish or hope that these problems be solved. Often, the instructor can distinguish the Complainer from the Customer by the whining, helpless tone in which the Complainer presents these problems – often repeatedly.

Complainers don’t really believe that their problems can be solved by this class, or possibly even solved at all. Therefore, they should be treated initially as Visitors, with empathy. If they display any hope that something can be done about their problems, that’s the time to get them engaged in the class. Often, this display of hope comes in the form of a tentative question that doesn’t refer directly to the Complainer, such as,

“Could this technique be applied to dealing with a boss who doesn’t appreciate your work?”

“But this technique couldn’t be used on a project under heavy schedule pressure, could it?”

Understanding and recognizing the four types of participant is obviously helpful to you when your job is to instruct a class, but what good does it do if you’re a fellow student? And what if you’re not in a class, but just a plain vanilla contract professional working on the job?

As a consultant,I’m seriously interested in my education. When I attend a workshop, I want to get my money’s worth – because I’m paying my own tuition and I’m usually not getting paid for my time. (Sometimes I can get my client’s to pay me for attending a workshop, but that’s a subject for another column.)

Therefore, whenever I’m in a workshop, I watch my fellow students just as I would if I were the instructor. If they’re Customers, I watch to see that they’re shopping for the same learnings I am, because if they’re not, they may steer the workshop into areas that are not related to what I’m shopping for. If they do, I may suggest something to the instructor, such as, “I see that you and Val have a deep interest in this subject, but it’s not my main focus right now. Would you be willing to continue off line with those who are really interested?”

If some of my fellow students are Learners, I cautiously enjoy their excursions into the unknown, because I’m always partly a Learner myself. I do my best to protect them from overfocused Customers (including me), while at the same time keeping my own goals in sight. If necessary, I try to steer things gently, as by offering, “Thank you for that wonderful exploration. I was fascinated, and could probably spend all day exploring it. But I wonder if we couldn’t come back to the subject of …”

If the instructor has a Visitor or Complainer to cope with, I consider myself a junior partner of the instructor and try to help out, generally off line during breaks. This role comes naturally to me, since we usually lead our own workshops in pairs – one instructor “on stage” and one ready to handle Visitors or Complainers one-on-one outside of the classroom.

For example, in a recent workshop, one of the Visitors was using one of our breaks to try to recruit other students to his cause by convincing them that the workshop was a waste of time – which, of course, would make his boss look like a fool for making him attend. Once I recognized that he was a Visitor, it wasn’t very hard to turn the subject toward his problems with his boss, and away from deprecating the very professional job my co-instructor was doing. Eventually, he realized that he had a choice between spiting his boss by learning nothing, or spiting her by actually learning some things that made him a better professional.

And speaking of professionals, I don’t spend most of my time being a student or instructor, so what does all this have to do with my day-to-day work? If you’re a regular reader of this column, perhaps you know by now that I always have my own learning in mind when I negotiate an assignment. I firmly believe that when I stop learning, I’ll stop being a professional – so, I’m always a student.

Yes, I’m on the job to earn money by helping my client, but I’m also there to learn, so I’m always on the lookout for Customers, Learners, Visitors, and Complainers among my co-workers. I believe that any worthwhile high-tech assignment is too difficult to be accomplished without constant learning by all participants, so I’m always working to enhance the learning environment, for me and for the others.And, one more thing.

Like anybody else, I, too, am susceptible to these stereotyped behaviors:

• becoming too focused on just the immediate job at hand (Customer);
• drifting off the subjectinto interesting side tasks (Learner);
• detaching myself from the importance of the assignment (Visitor);
• feeling powerless and whining about everything and everybody (Complainer).

None of these roles enhancemy performance on the job, so I always try to watch myself, too – and bring myself back to a more professional and effective role.

---

¹ At the suggestion of David Schmaltz, one of our PSL instructors, I adapted these categories from my teacher and colleague, Bill O’Hanlon. See, A Brief Guide to Brief Therapy byBrian Cade and William Hudson O’Hanlon ©1993 by Norton in NYC.

convert this post to pdf.

©2003 Gerald M. Weinberg, www.geraldmweinberg.com

The introduction of the new $20 bill has me thinking about the Bureau of Printing and Engraving today. They’re one client I ever had who couldn?t use the slow-payment excuse that they’re short of cash, since they print the stuff. One of the most irksome parts of being an independent contractor is the client who doesn’t pay, or at least seems like they won’t pay in time for you to pay your own bills.

First of all, this is not a new problem, so it’s important not to take it personally. Taking it personally only gets you annoyed and out of your best thinking mode. True, some clients believe that contractors don’t need to think creatively: “Just keep your ideas to yourself and get back to coding,” they say, but they’re wrong. Creative thinking is your best ally when it comes to getting your fair share of the cash.

There are, of course, traditional ways of enticing your clients to pay you on time. My father was in the auto painting business, and I recall how careful he was to pay his paint bills on time in order to earn his “2% discount for payment in less than 30 days.” Knowing that this discount strategy worked well to motivate my father, I once tried it on a slow-paying client.

This multi-billion-dollar company had typically taken 4-5 months to pay my tiny bills. I started adding that “2% discount” clause to my bills, and sure enough, it motivated them to change their behavior. They still paid in 4-5 months, but they now deducted 2% from every bill.

I learned several lessons from this experience. The first lesson is that large clients have payment patterns that no rinky-dink contractor is going to change. I call this Gilb’s Law, because I once asked Tom Gilb about a recruiting firm in Europe that wanted me to do some work with them. I’d had some trouble getting payments overseas, so I asked him about their payment practices. “Oh,” he said, “they always pay. Eventually.”

In short, their consistent pattern was reliable, but slow. The second thing I learned was that I can use the client’s consistency to my advantage. Knowing that they typically paid 6 months late, I inflated my normal billing rate by an amount equal to 6 months of interest on that rate. If they wanted to compete with my bank for my CDs, that was fine with me (but I did add a tiny bit more because they didn’t offer Federal Deposit Insurance).

This strategy has worked well for me ever since. The most important part is that I no longer get annoyed with my clients for playing financial games with my money. It’s never a good idea to get annoyed with your clients, so it’s never a good idea for someone like me to feel that I’m a victim of my client’s lack of adaptability. After all, if I’d wanted to be a helpless victim of a large corporation, I could have been their employee?and gotten health insurance to pay for my psychiatric bills.

A few clients actually understand their own slow-pay patterns and have worked out solutions that I have adopted as my own. (As Tom Lehrer says, “if you steal from one person, it’s plagiarism; if you steal from many, it’s research.”) I gave a short course once at a large government agency, and I was picked up at Washington National airport by Chuck, my contact at the agency. As we drove to the agency, Chuck asked if I was in a hurry to get paid. “How much of a hurry?” I asked. (That’s another good consulting technique?answer difficult questions with other questions.)

“Well,” he answered, “we seem to have a difficult time processing this kind of payment in less than eight months.”

“In that case,” I said, “I’m in a hurry.”

“I thought you might be,” said Chuck. “But don’t worry, we can pay you in cash.”

This wasn’t the Bureau of Printing and Engraving, so I was rather surprised that they could actually do cash business. I told Chuck of my doubts, but he reassured me. “In fact,” he said, “we’ll get you paid in advance, just in case there’s any hangup.”

And, sure enough, when we arrived at the agency, he took me directly to a barred window marked “Cashier.” The little guy behind the window lacked a green eyeshade, but otherwise looked just like the teller in a bank about to be robbed in a Clint Eastwood Western. He didn’t even blink when Chuck slipped him a hand-written voucher for $2,500. He asked me for some identification, then a signature, after which he counted 25 hundred-dollar bills into my hand. I was then led to the classroom where I gave a stunning class, never once being distracted by worries that I might not be paid.

I’ve now added “cash in advance” to my repertoire of payment possibilities. It’s especially useful in cases of doubt or complication, such as working overseas. There can be drawbacks?every solution creates new problems, as every consultant knows. Once, after an extended tour of Japan, my sponsor had me in for a tea ceremony, during which he handed me an envelope wrapped with a red ribbon and containing, I presumed, my fee for the visit?in cash, as our contract had stipulated. I thought it would be discourteous to count it in front of him, but as I was about to slip it into my inside pocket, my translator suggested it would be rude not to count it.

Knowing that cultures differ, I opened the envelope and counted over $10,000 in crisp new American money. The amount was correct, but counting it raised my anxiety about carrying so much cash. I wanted to take it to a bank and convert it to some sort of non-negotiable instrument, but I was told, regretfully, that it was “Honor Old People Day,” so the banks were closed. That night, I slept with the money under my pillow (and not too well).

The next morning I had to leave for the airport before the banks opened, so I had to carry the cash with me all the way home. I learned, also, that when you carry more than $10,000 cash into the USA, you have to have a friendly discussion with the customs agents?a discussion in which you must convince them that you’re neither a counterfeiter nor a drug dealer. I also discovered that it wasn’t even that easy to deposit that much cash in my own bank?once again, lots of rather personal questions.

In other words, cash has some disadvantages of its own, in addition to the disadvantages of money in general. Disadvantages of money? Yes, life is never as simple as we contractors think it should be. Indeed, the worst accounts receivable situation I have had to solve?the one that took all my creativity and more?was when, Lily Gilding Limited (LGL), one of my best clients paid the same bill twice .

The bill was $4,240. (It would have been $4,000, but I had added the interest for their 4-month pay cycle.) The first check arrived right on schedule?that is, four months late. Unfortunately, even before I had time to spend all of it, a second check arrived?same invoice number, same amount, same date.

LGL was a good client, so it wouldn’t have been good business to try to pretend that we didn’t get the second check. We called their Accounts Payable Department right away to tell them of their double payment, but they said, “No, you must have made a mistake. We couldn’t possibly have paid you twice. We have controls . You’d better have the manager of your Accounts Receivable Department check your records.”

I smiled, thinking of how Lois would feel being called the “manager of the Accounts Receivable Department,” but I kept my mouth shut. A/P departments can only talk to A/R departments, not to the do-everything-person-named-Lois in a small consulting firm. Lois checked everything again, and I double-checked Lois’s records. Same result. LGL had definitely paid twice.

After about twenty calls back and forth, I became convinced that LGL could never admit to such a mistake. I then brought the matter to the attention of my contact person, Nel, and she made a few phone calls on my behalf. Next time I was consulting at LGL, Nel told me, “I’ve tried everything I can think of. My advice to you is just to keep the money.”

“But I can’t do that,” I protested. Mostly I was thinking that LGL might someday discover their error and think I was dishonest. It’s always harder take being thought of as dishonest when you really are dishonest.

“No, really,” Nel said. “Even if you could finally get us to take it back, it would cost us more than $4,240 to get it cleared up. Believe me, this is the best solution for both of us.”

Well, she was right, of course, but Lois is one of those honest Nebraska farm women who simply couldn’t keep money that didn’t belong to her. She simply wouldn’t accept any solution that involved us keeping their money, so I turned the problem over to her?having exhausted my own creativity. And, as usually happens when I have the courage to admit I can’t solve a problem, Lois found a way.

Her solution may not always work for you, but since LGL was a good client, Lois simply deducted $4,240 from the next bill she sent them and called it a rebate. Apparently they were happy to receive a “rebate,” and we never heard another word from them. Another accounts receivable problem solved, and another happy client!

What?s the moral of all this? It reminds me that when you?re in business for yourself, your problems never end, and even that wonderful event – getting paid – can be one of your worst problems.

convert this post to pdf.

©1999 Gerald M. Weinberg

My friend Brad, a Los Angeles cop, mentioned that he regularly sold traffic tickets.

“But it’s not what you think,” Brad smiled. “I work at night and go to school
during the day. If I have to appear in court, I miss classes. ‘Selling the ticket’ is
convincing drivers that they really were speeding, so they won’t take the matter to
court.”

“That’s a side of police work I never considered,” I said. “You have to be a good
salesman.”

“It’s not that hard,” Brad explained. “You see, I give dozens of tickets every week,
but most of the speeders only get one in a year. I get lots more practice than they
do.”

Negotiations between speeders and police can never be equal, because speeders are
amateur negotiators while cops are professionals. By the time you had enough
experience at speeding to become a professional, you’d be in jail.

Negotiations between contractors and agencies can never be equal, because
contractors are amateur negotiators while agencies are professionals. By the time
you had enough experience at contracting to become a professional, you’d be dead.

Unfortunately, you need to negotiate every new contract:

“There will always be issues and disputes between contractors and agencies. The
key, and perhaps the best that can be hoped for, is to understand the other side a
little better

convert this post to pdf.