© 2004 Esther Derby

“Our customer doesn’t know what he wants,” complained Sandy. “I try to get him to talk about the product and tell me what he wants, but it’s like pulling teeth.”

Whether you are building a brand new product or working on evolving an existing product, understanding customer business needs is the foundation of a marketable product. But few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about product requirements. 

Building the right product starts with asking the right questions. The right questions are those that help us get beneath the surface and understand the customer’s world, work, and concerns.

First Things First

Before you plunk yourself down in front of the customer and start asking questions, articulate your objective. What do you hope to accomplish by interviewing the customer? Do you want to explore broad options, understand a specific business processes, or learn all you can about how a customer uses a particular feature? Articulating a research objective sets the stage for a successful interview. A wandering, unfocused interaction will yield paltry results and frustrate the customer.

Once you’ve defined your objective, brainstorm a list of all the questions you might ask related to the topic. Then organize the questions into themes and arrange them to flow from general to specific and familiar to unfamiliar. The process of preparing questions helps to identify key topic areas to cover. Following a set list of questions isn’t the point: successful interviewers invest time in designing and testing questions—but then use them as a guide, not a script.

As you prepare for an interview, consider different types of questions. Each type will serve a purpose and elicit a different response.

Context-free Questions

Context-free questions are useful in the early stages of a project, when you are beginning to explore. Context-free questions help you decide which avenues to investigate and provide global information about the problem and potential solutions. Because these questions don’t imply any particular context, they are useful for any design project.

Here are some product-related, context-free questions:

• What problem does this product solve?
• What problems might this product create?
• What environment is the product likely to encounter?[1] 

Context-free questions generate a deeper understanding of the product and project.

Meta questions—questions about the questions—are a special sort of context-free question. Meta questions, such as “Do my questions seem relevant?” or “Is there anything else I should be asking?” are likely to surface areas where the customer assumes that you already know. 

Open-ended Questions

Open-ended questions invite the customer to expand on the topic.

Use What questions to learn about events and considerations.

• What happens next?
• What factors are involved?

How questions ask about the way things happen.

• How do you use the product to__________?
• How do people decide which option to select?

Could questions ask the customer to imagine or express a wish.

• Could you conceive of an example when you’d use the product this way?
• Could you see a way to use the product to solve this problem?

Closed Questions

A closed question is one that naturally leads to a one-word answer, usually Yes or No. Questions that start with Can, Do, Are, or Is are usually closed questions. 

Q: Do you have any problems with the wonder widget?  

A: No.

Closed questions are useful for confirming specific information, but are deadly as an interview staple. You want to delve beneath the surface, and closed questions won’t help you with that. 

If you do happen to slip into a closed question, follow with a probing question to uncover more information:

Q: Can you recreate the problem?

A: No.

Q: What steps have you taken to try to recreate the problem? 

Multiple-choice questions offer a limited set of options and help to establish relative priority:

• Which would you prefer, A, B, or C?
• If you had to choose one, which would you choose, X, Y, or Z?

Like closed questions, multiple-choice questions have their place, but shouldn’t make up the bulk of an interview.

Past, Present, Future

Ask questions about past use to understand problems and weaknesses in the product or feature. Use present-time questions to learn about how the customer currently uses the product or how he currently performs his job. And ask questions about the future to learn about trends and anticipate future needs.

Past: When has the product failed to perform as you expected?

Present: How are you using the product now?

Future: How do you see your workflow changing in the next several years?

Tell Me More

Don’t stop at the first answer. Follow an opened-ended question with a probe to gain further insight. A good interviewer will elicit a second, third, and even a fourth response. When you want to learn more, use questions like these:

• What else?
• Can you show me?
• Can you give me an example?
• How did that happen?
• What happens next?
• What’s behind that?
• Are there any other reasons?

Be sure to probe for more information when you hear emotion or judgment:

“I hate the way the floo feature operates!”

“The product does a poor job.” 

Dig deeper to identify unmet needs or weaknesses in the product. 

Vague statements like “The product must be easy to use” call for probing to learn what “easy to use” really means to the customer.

Questions That Aren’t Really Questions

Some questions don’t elicit the customer’s opinion, but confirm the interviewer’s opinion instead. Biased questions suggest a “right” answer: “My investigation shows that automating the floo process will provide the biggest savings. What advantages do you see in that?” Leading questions make one response more likely than another. Biased and leading questions tend to feel manipulative, and a customer will tune out if he feels the interviewer is leading or putting words in his mouth. Compound questions make it difficult for the customer to respond at all, as in this example:

“Do you think it’s okay to have a question with two topics—unless there are more than that, or if the topic is complex—and is it better to stick to short questions, except in the case where a longer question is better, or is it a judgment call, except in a special case?”

Ask one question at a time, and give the customer time to answer. Rushing in with another question can give the impression that you don’t really care to hear what the customer has to say.

Ask Why Without Asking “Why?”

Curious children ask “Why?” endlessly. They want to know the answers to everything, even things that are unknowable.

We want to know why customers do the things they do so we can understand the tasks they perform and the business needs behind the tasks. But an endless stream of “Why?” questions can wear on anyone’s patience. Worse, “Why?” can sound blaming, or feel like the interviewer is demanding a cogent explanation for something that’s unknowable.  

Avoid putting the customer on the defensive by using How or What questions to dig beneath the surface. 

• How did this come to be?
• What was the thinking behind that decision? 

Or simply ask “Can you help me understand this?”

Putting It All Together

Before you rush off to try out your interviewing skills, practice. Start with a colleague, and then try your interview with an internal customer proxy or subject-matter expert. 

Most people find that maintaining rapport and tracking the interview takes all their attention. To help with this, consider working with a partner who can take verbatim notes during the interview. At the end of every interview, perform a short interview retrospective to identify what worked well and what you might want to do differently in future interviews. 

Most customers appreciate the opportunity to talk about their work and participate in shaping the products they use. Prepare for your customer interview carefully and hone your interview skills through practice. Invest in learning your customers’ wants and needs so you can deliver the right products.

convert this post to pdf.

© 2002 Becky Winant, www.beckywinant.com

This article originally was originally published on www.StickyMinds.com

convert this post to pdf.

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

These days, with all the talk about “internet time,” professional workers are always trying to be the first with new ideas. But is that really the only path to success? Is it, indeed, a very effective path at all? What about being second?

Our culture certainly encourages people to be “first.” In school, the emphasis ranges from who raises a hand first in class to who graduates with the highest grade-point average. The valedictorian – first in the class – gets lots of honors, but the salutatorian – second in the class – has to make the speech (phooey!).

Sports competitions also honor the “winner,” and books on problem solving and business often borrow this metaphor – emphasizing finding the “winning” idea before anybody else. But most problem-solving areas of life are not, in fact, like sports. It?s not having the idea that matters, it?s what you do with the idea that counts.

And, in fact, ideas don?t count that much in sports, either. Anyone can have the idea, “Hit a home run now and win the game,” but there?s a lot more to hitting home runs than simply having the idea. To have a fair chance of hitting a home run, you have to practice, practice, and practice. As in most of life, the key issue is not who is there first with the idea; the key issue is how you develop the idea once you have it. It?s not your ideas alone that win, but ideas plus capability and the will to develop your ideas.

If you think having ideas first is the issue, consider this. Every year, tens of thousands of individuals start businesses based on being the first with a “new” idea. If that was all it took to be wildly successful, many of these firms would quickly displace all of the giant firms and become giants themselves, every year! Yes, we all know stories of small firms that had a better idea and indeed succeeded at becoming giants, but most of the time, the giants persist and the midgets fall humbly by the wayside.

Giant companies survive the onslaught of little start-ups with one of two strategies:
1. Exploring many parallel ideas and developing the few good ones.
2. Letting others do most of the searching for ideas, then developing the few good ones.

What can the individual professional learn from these strategies?

Exploring many parallel ideas depends on having huge amounts of capital, which the individual professional cannot manage. But even giants couldn?t afford to have so many explorations in the pipeline if they didn?t know how to kill the ones that show no promise, and kill them early. So, for the individual, the lesson of this strategy is to learn how to let go.

For me, letting go means not trying to maintain leading-edge competence in every field in which I was once competent. I used to be one of the world?s great IBM 704 assembly language programmers, and I suppose there are still some jobs maintaining such code, but I don?t think I?d want them anyway. I?ve let go of that one, along with dozens of others.

Letting go also means that I don?t try to pursue every new fad I happen to hear mentioned at a conference or on the web – which leads me into the second strategy – letting others do most of the searching for me.
In a field where capital costs are low (like software development), chances are better that some small firm will come up with the good idea first because there are tens of thousands of such small firms out there. In that case, the big successful companies don?t rely on coming up with every good idea first. Instead, they pursue an “always be second” policy, and support it. They maintain some minimal competency in a wide variety of areas, so that they?ll readily recognize one of these good ideas when it comes along – from another company, or often from one of their customers. Then, they?ll either copy the idea, buy the rights, or buy the company.

I?m not able to buy companies, or even their licenses, but I am able to learn from them. And, under some circumstances, I can ally with them. That way, even a single individual can pursue an always-be-second strategy.
To be a great second, I use a process that resembles the way a breeder produces improved plants and animals, with three essential elements: variation, selection, and retention. Variation provides the new ideas; selection weeds out the ones lacking promise; and retention propagates the ones that survive the selection.

Variation (new ideas) for an individual, comes from using a network to supply information from literally hundreds of sources. By communication with people in my network, I can be sure that few new ideas escape my attention. I have created a huge virtual organization, far larger than any real organization I could afford. The AYE Conference is a central element of that network, where I can meeting many of my “nodes” face-to- face once a year and exchange ideas and experiences.

The network provides some of the selection, too. First of all, any idea that nobody passes on to me is unlikely to be a worthwhile idea. Conversely, when I hear of the same idea from three separate sources, I raise its “score.” Of course, in order for this selection process to be meaningful, I have to consider the reliability of my sources. For example, if I hear an idea supported enthusiastically by certain people, I reduce it?s score.
I work hard to keep my network alive and healthy so I can depend on it to do a good job of variation and selection. Ultimately, though, I have to rely on myself to select which ideas are worth retaining and developing, but the whole process is designed to keep me from developing “neat things” that don?t fit the market.

I don?t know how to automate the retention and development of ideas, so it takes a lot of work, and I can?t afford to develop very many new ideas the way a large organization might. Sometime I can share work by co- developing ideas (seminars, books, articles) with colleagues from my network. But ultimately, I have to develop in my own way, to create the unique service I can sell to my clients. This is the place where it pays me to be first – I may be satisfied being second in the race to market, but I always try to be first in quality.

convert this post to pdf.

©2005 Gerald M. Weinberg

We hear a lot these days about “reusable programs,” but we seldom hear about programs that shouldn’t be reused. Most programmers know what it’s like to be forced to reuse code that was supposed to be used only once and then discarded, such as:

1. prototypes, as for simple, quick formatting of output
2. one-time reports
3. test drivers and harnesses
4. research programs to probe some peculiar feature of the programming language, operating system, databse, or other “black box”
5. engineering assist programs, to help diagnose a hardware malfunction

These examples generally fall into two categories:

Frequently retained when they should be discarded:
protoypes and one-time reports, and

Frequently disposed of when they should be kept:
test drivers, research programs, and hardware testers.

That is, though all are thought of as single-use programs, the should-be-discarded software tends to be held somewhere, “just in case.” Only the should-be-kept programs are actually discarded.

If the developer is responsible for the decision, the program is likely to be discarded; but if the customer is responsible, the program is likely to be kept.

Developers discard programs because they understand tha reuse is not free. A program not designed and test for reuse, but brought out of hibernation will cost even if no requirements changes are requested by the customer.

1. The hardware environment may have changed.
2. The system software environment may have changed.
3. The size or format of the data may have changed.
4. The human environment may have chnaged, which might, for example, activate a part of the program that has never been invoked before.
5. Some part of the program or its supporting material may have been lost or damaged.

The longer the period of hibernation, the greater the cost – if for no other reason than somebody must check for one of these five conditions. But you already knew this – we all know this. then why, oh why, do we keep tumbling into the same trap?

I believe the answer lies in our unwillingness or inability to feed back the true costs of program development and program maintenance to our customers. Many software development vendors have reduced the problem to manageable proportions by the following steps:

1. When a program is commissioned, the customer must specify the lifespan and the number of executuions.
2. If there is uncertainty about either of these figures, the vendor bids contingent prices, reflecting the differing costs.
3. The vendor offers a contract stating that the program will be destroyed after a certain time and/or number of executions, whichever comes first.
4. The program remains the property of the vendor, unless the customer takes ownership. In such a case, the vendor places a much higher cost on the job – to pay for preparing the program to be maintained by other than the original developers.
5. The vendor notifies the customer when the program is about to be destroyed, and gives the option (at a substantial and realistic price) of rebuilding the program for further use.
6. If the original contract was for a “one-time” program, no notification is required. Instead, the vendor destroys all copies of the program as soon as the customer has accepted the program’s output.

Inexperienced customers readily accept these terms. So do very experienced customers, who know quite well the realities of “one-time” programs that turn out to be “N-time” programs. Only the in-between customers have difficult accepting these conditions, for they believe – incorrectly – that they understand programming.

In-house IT organizaitons – especially where there is no true chargeback for development or maintenance – have more difficulty teaching these lessons. The users pay nothing for specifying a one-time program and then asking that it be run N times. Without cost, they have little motivation to learn. With chargeback, however, in-house IT organizations can do what good, professional vendors do.

If you work in an in-house IT organization without chargeback, however, you can sometimes achieve relief by manipulating your one available parameter – time. You ask the customer to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use. Initially, users simply will not believe you will enforce this procedure, so get it in writing. After a few lessons – if you don’t submit to screams and threats – they will begin to understand the true costs. Only then will they devote some energy to making their initial decision of one-time versus N-time.

convert this post to pdf.

©2005 Gerald M. Weinberg

The other day, I was trying to help a client (let me call them “StartupCompany”) mired in conflicts, exceptions, errors, anomalies, lapses, modifications and other deviations from the norm. These annoying exceptions were playing tricks with my blood pressure, so I had to be wired to a wearable blood pressure computer for twenty-four hours. As if StartupCompany didn’t have enough interruptions, now my wearable computer was inflating a blood pressure cuff at random intervals throughout the day.

Every time the cuff inflated, I petulantly asked myself: Why can’t they run a project like real people living run-of-the-mill, low-blood-pressure lives?

That night, I was using the Yellow Pages, and in the A categories in the Yellow Pages index, I chanced to notice a curious pattern. Here are the first few items:

Abortion Services and Alternatives. These were the first two entries in the index. I decided to skip them both, so as not to take sides in the pro-choice/pro-life conflict. I had enough conflicts within StartupCompany.

Abuse – Men, Women, Children. I decided to continue my scan of the index, and this was the next entry. The normal process of family living involves people loving and respecting each other, communicating well, and behaving appropriately according to societal norms. But when people start behaving inappropriately, they need Abuse Services. In StartupCompany, people normally respected one another, communicated well, and behaved appropriately according to societal norms. But they sometimes didn’t, and they lacked “abuse services” for coping.

Academies (including private schools and special education). When the formal education system doesn’t provide special knowledge or handle special cases, private academies and special education are called for. People within StartupCompany often needed to know things they hadn’t learned in the public schools, but StartupCompany had no provision for special education.

Accident Prevention. Accidents aren’t “supposed” to happen, StartupCompany had accidents. In order to improve, they needed processes to prevent accidents and to mitigate their consequences.

Accordions. Despite what some people think, accordions are perfectly normal, though not everybody learns to play them or appreciate them. Still, StartupCompany could have used some entertainment to lighten the mood once in a while.

Accountants. Accounting is also normal, but, if everything always went according to plan, we wouldn’t need to account for things so carefully. We have to protect our financial well-being from mistakes and misbehavior, and that’s what accountants do – and also what they should have been doing in StartupCompany.

Acetylene Welding. Some welding is normal, and some is for repairing things that are not supposed to break – but do anyway. StartupCompany lacked a “welding team” to handle lots of stuff that broke.

Acrylic Nails. Most normal people have fingernails, so why is there a nail business? Oh, yes, it’s the human interface, and StartupCompany had to cope with conflicting ideas of what made a system beautiful – but they had no special beauty experts to resolve the conflicts.

Acting Instruction. We all need to “put on an act” now and then when we’re caught by surprise. StartupCompany’s people certainly needed training in how to behave in improvisational situations, but there was no acting instruction.

Acupressure/Acupuncture. If we were all healthy all the time, we wouldn’t need medical services, and if “normal” Western medical services worked all the time, we wouldn’t need acupressure and acupuncture. So, there are not only abnormal services, but meta-abnormal services – the services when the normal abnormal services fail – certainly true in StartupCompany.

Addressing Service. Have you ever tried to maintain a mailing list? Almost all the work is not the mailing itself, but maintaining the addresses. It’s even worse for email, because email services haven’t yet evolved “normal” ways of dealing with changes. Gee, neither had StartupCompany.

Adjusters. Adjusters, of course, are an abnormal service from the get-go. Without accidents, we wouldn’t need insurance, and if things stayed on course, StartupCompany wouldn’t have needed risk analysis. But they did.

Adobe Materials and Contractors. Adobe materials may not be “normal” where you live, but here in New Mexico, adobe is a normal building method. StartupCompany, too, has its idiosyncratic processes that are not normal in other projects – and newcomers have to learn about them or pay the price. But StartupCompany had no special services to bring newcomers up to speed.

Adoption Services. Yes, sometimes people are not wanted by their parents, and StartupCompany certainly had some unwanted people. But, they lacked “adoption” services for moving unwanted people around.

Adult Supervisory Care. “Normal” adults can take care of themselves without supervision, and normal workers wouldn’t need much managing at all. But StartupCompany had two adults who could not take proper care of themselves, and the managers spent an inordinate amount of time on these two out of a hundred.

I stopped there, sobered by my reading. It was now clear to me that StartupCompany, being a startup, had an overly simplistic picture of what it takes to run a company. I needed an adjustor to adjust my blood pressure – I needed to see that my job as their consultant was to teach them that deviations are normal, and that they (and I) could do what real people do:

• stop whining and deal with them
• create systems to deal with them
• create systems to prevent them

convert this post to pdf.

©2007 Jerry Weinberg

Contract
professionals, on the average, change jobs more often than employees, so they
are involved in lots of interviews.? One of our SHAPE forum threads was started
by Pat Ferdinandi, an independent consultant, who complained: “I am
continually amazed at some of the ridiculous or inappropriate questions I get
when interviewed by prospective clients. Keeping a straight face and not losing
my cool is sometimes a challenge.”

The Shapers then contributed many examples from their own experience,
and I’d like to recount some of them and the lessons they might carry for
my readers.

Insensitive and Oblivious
An interviewer made the following statement to Pat: “A psychiatrist has a model
that answers to specific questions fall within. So, by having a base model, he
can identify that the problem with the marriage is the lazy wife.” Pat, being
a wife herself, didn’t care for this analogy. The problem here is, of course,
his gender biases, which might exist throughout the company – but even more,
his total insensitivity to the person he was interviewing.

Well, not total insensitivity.
For that award, I have to turn to a story from a
woman who was interviewing with the manager of the department she would work in
if she took the assignment.? During the interview, he said, “I want you to
feel free to come in and talk to me any time, about anything. Think of it like
a young girl talking privately to her father where she can practice her
techniques for sexual advances knowing that she’s perfectly safe with him,
because he’s her father.”

How did she handle this?
Apparently, the same way everybody present handled it when
she told us. We sat there for about five minutes with our mouths open,
not able to make a sound. She then just walked out.
Maybe he’s a masher, or maybe he’s totally out of touch,
but in either case, you don’t want to work for him.

Gender bias is bad enough, but maybe you’re the right gender.
Sexual innuendo is worse, but maybe the interviewer won’t find
you attractive. Insensitivity, however, eventually snags everyone
working in the environment, so stay away
even if you’re not a “wife” or a daughter.

The Nedlog Rule
There’s
a variation of the Golden Rule that applies to these and a great
many other the bad interview lines:

As they do unto others, they will eventually do unto you.

I call this the Nedlog Rule. Here are some examples:

Candidate: “So what happens to the staff from the other sites?” (The company was a merger of several companies)

CIO: “We offer relocation to the ones we want. That’s the nice thing: we can start over and define our culture”

The candidate has just learned how he will be handled should he become excess
baggage. The interview continued:

Candidate: “Given that, what culture would you want to have?”

CIO: “That’s a good question.
I haven’t really thought about it.”

The candidate figured they wouldn’t start thinking about the culture
they wanted just because they hired him.

Here’s another Nedlog example:

Interviewer: “We would like to have you working for us.
I already heard about you from them
(thumb pointing over shoulder at his employees) … By the way, one of them,
namely George is not very productive, but I can’t fire him”

This candidate figured she didn’t want to be called “them,”
nor did she want her performance deficiencies to be discussed with
actual or potential co-workers. If they badmouth other employees,
you have to wonder what they’ll say about you.

Dumb or Ignorant
Sometimes, the questions you’re asked tell you all you need to
know about the kind of people who will be managing you if you
take an assignment. A software consultant was interviewing for
an assignment in a hardware organization whose managers knew
nothing about software. They asked questions like these:

• You know something about software?
• Do you write computer programs?
• Can you type? How fast?
• How long does it take someone to write a computer program?
• What’s a database?
• What programming language should we use for everything?
• What’s the one thing we should tell people to do to cut
  development costs in half?

My own answer to this last question would be,
“Get rid of the managers who ask questions like this one.”

Where do such questions come from?
In trying to understand this, I tried to imagine
what questions I would ask if I were going to interview,
say, a brain surgeon:

• You know something about brains?
• Do you operate on brains?
• Can you cut with a scalpel? How fast?
• How long does it take someone to do surgery on a brain?
• What’s a nervous system?
• What surgical tool should we use for every operation?
• What’s the one thing we should tell people to do to cut
  surgical costs in half?

Looking at these questions,
I realized that any surgeon would know instantly that I
knew nothing about surgery, let alone brain surgery.
I would think that the surgeon’s next move would be to ask me,
“What is your role with respect to the job I’m interviewing for?”
If there was any role at all, no decent surgeon would take the job.

Should it be any different if you’re a software developer,
or tester, or project manager? It’s not the lack of knowledge that’s
the problem; it’s the lack of knowledge about the lack of knowledge.
I can work for someone who doesn’t know beans about my specialities,
as long as they know they don’t know.

Hidden Agendas
Sometimes, what the interviewer says will reveal to you that they’re
not really trying to fill a position. Sharon Marsh Roberts identified
two common types of hidden agenda interviews. The first are
“professional courtesy interviews” – ones which are scheduled because:

1. the interviewer owes someone a favor;
2. the interviewee has some (hopefully worthwhile) connections; and
3. there is time on everyone’s schedule.

Sharon opposes this to the “comparison shopper interview”:

1. the interviewer has someone in mind;
2. Human Resources hasn’t approved the decision; and
3. the corporation demands some sort of record of “due diligence”.

Many of the worst interviews fall into these categories,
and the best thing you can do (since your’ll never get the job)
is save time by getting out quickly. One
young contract professional was invited for an interview,
believing that she was under consideration for a particular assignment.
The interview started badly enough and went downhill fast enough so that
she asked the defining question:
“Is there something that I should be telling you to explain that
I could perform this job?”

The answer communicated bluntly something on the order of,
“No, because I’m interviewing someone who’s isn’t qualified
for this position.”

She gracefully departed. There wasn’t much she could say,
and besides, why waste more time?

Conclusion
There are dozens more ways in which interviewers reveal this kind of
information, and if my readers clamor for them, perhaps I’ll provide
some more. The important thing to know, though, is no matter how
inept an interviewer may be, you?the interviewee?can almost
always get the information you need to make a decision.
Just don’t lose your cool and thereby lose the information.

convert this post to pdf.

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

On a typical day, I get 100-200 email messages, and some of my clients in large projects receive even more. Though emails improve my ability to communicate clearly and quickly, they may also prove a hindrance to certain kinds of communication. In particular, email does not adequately serve as a medium for recording an important agreement. An important email may be too transitory, too easily lost among volumes of less important communications, too easy to misunderstand, and too easily lead to unnecessary conflicts.

Although email can reduce the need for personal contact, it cannot entirely eliminate contact between teams building components that must work together to form a system. Separation of teams tends to create language differences that lead to misunderstood emails. Teams develop local goals that may diverge from project goals and actually conflict with other teams’ goals. With different language and divergent goals, interfaces stop being stable, clear, stakes in the ground. Instead, they can easily become the disputed border between two warring states or two different cultures. To prevent border wars, I prefer the ancient solution – writing and signing treaties.

A software treaty is more or less identical to a treaty between political units. I like my treaties to be written on a single piece of paper with a fancy border, like a gilt-edged stock certificate. A typical treaty might contain.

1. A reference to the technical terms being agreed to – such as a reference to a specific version of a document in the project’s repository.

2. A statement that all signatories agree to the technical terms in (1).

3. A statement that the treaty will remain in effect unless and until renegotiated among all the signatories.

4. Dated signatures of each team’s official representative – most often the team leader. The treaty implicitly recognizes the independence of the signatory teams and their ability to enter freely into agreements on technical matters.

5. (Possible) Management signatures witnessing the treaty.

Although a manager quite likely acts as facilitator to the negotiations, treaties will not work if parties are coerced into signing something they don’t understand, or don’t agree with. Nor will they work if some affected party fails to participate in the negotiations and sign the treaty, so management must ensure that all affected parties are represented.

After signing, however, good management becomes mandatory to enforce the pact the parties agreed upon. In other words, once each party freely gives its signature, the matter is no longer a purely technical one, but becomes political.

Why political? Because after the agreement, one party could disrupt the project and/or make the other party look very bad by covertly changing the agreement. A written treaty seals off this avenue for expressing any animosity or mistrust that exists between the parties. When people understand that management will rigorously enforce each treaty, they can quit bickering and get down to the business of building. Moreover, teams can work with the assurance that anything not in a treaty is not a commitment – and will not become a commitment without going through the treaty process.

With signed treaties covering all interfaces, no single team can disrupt the project by covertly changing the rules in the middle of the game. Woe to any team that fails to meet the interface specifications agreed upon in their treaties.

What happens if one party to the treaty decides they made a mistake, or got a poor deal? For instance, during the negotiations, I might have agreed to pass error-free data in return for two milliseconds more of execution time, but now I find that I cannot scrub the data that fast. I can then call for a renegotiation, but I may have to trade something else for the relief I seek – even something that will simplify my enemy’s job.

Such a concession may prove a bitter pill for me to swallow, especially as the renegotiation is done in front of management, but I have to understood that unilateral changes to my treaties will damage the project and make my life much less pleasant.

The startup of a treaty system will sometimes seem awkward, unfamiliar, and overly formal. I know from history, however, that this degree of formality is needed if former antagonists are to work together cooperatively. White ties are optional, however, and quite soon the awkwardness dissipates.

We frequently see one party resist actually signing a treaty, but such resistance always indicates that the resisting party is uncertain. Because the whole treaty process is designed to eliminate uncertainties, resistance tells me what I want to know that there is still more definitional work to be done.

Treaties are especially helpful for contractor professionals, who may rush into a poorly understood commitment in their eagerness to improve their cash flow. But no matter how much I hope that the definitional job is finished, the strong commitment implied by a signature prevents me from mistaking hope for reality.

By keeping communications on the level of reality, rather than hope, I may create a few problems today, but I avoid bigger problems tomorrow.

By making agreements between cooperating parties a strategy for peace, I avoid the hardest problems of all, the misunderstandings that lead to interpersonal conflicts.

convert this post to pdf.