In a previous article, I wrote about the usefulness of treaties between technical teams, but I didn’t give much detail about the actual negotiation process that goes into making a successful treaty. To learn about such negotiations, let’s look at two scenarios of negotiations that went wrong.
Here’s Scenario Number One:
Bob (the Boss): Fay, what’s your estimate of when that component will be ready to ship to testing?
Fay: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.
Fay: Isn’t that okay?
Fay: I suppose I can really push and get it in 12 weeks.
Fay: Darn. Well, if everything goes exactly right, I can make it in 10 weeks.
Fay: Okay, I guess I can push for eight.
Here’s Scenario Number Two:
Darlene (the boss): Ira, what’s your estimate of when that component will be ready to ship to testing?
Ira: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.
Q: What’s the important difference between these two scenarios?
A: Nothing. Nothing important, that is. Bob used a soft approach; Darlene used a hard approach, but nothing was really different. Successful negotiations usually involve trade-offs among schedule, resources, and technical specifications, but these two contain no trading off at all – just different kinds of manipulations to make one person submit to another person’s desires.
Here’s Scenario Number Three, which should produce a better result:
Annabelle (the Boss): Myron, what’s your estimate of when that component will be ready to ship to testing?
Myron: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.
Myron: Isn’t that okay?
Annabelle: Well, not really.
Myron: If the schedule is that important, we can look at alternatives.
Annabelle: I can’t give you any more people. We’re shorthanded already.
Myron: Darn. Well, actually, new people right now might be more disruptive than helpful. Well, something has to give – we can’t reduce schedule and hold resources and specs constant.
Annabelle: That’s certainly true. But I do need something to show to my marketing team in eight weeks. There’s that business expo where we have to do a demo, and I can’t change that date.
Myron: Okay, I guess we’ll have to see what features we leave out of the demo, or perhaps fake a bit.
And so Annabelle and Myron get down to the business of examining which features will contribute most to a good demo (her problem) while at the same time being within Myron’s team’s capabilities (his problem). Nobody was forced; nobody was manipulated. The negotiation stayed open and based on facts, not speculation or screaming or placating.
Of course, this kind of negotiation takes trust – trust in the other person, but even more, trust in yourself.
You must feel that you can be honest without being taken advantage of.
You must be confident that you understand the trade-offs on your own side of the business.
You must have enough self-esteem to be able to say what you don’t know.
It also helps to know that agreements forged through manipulation will be weak and unreliable agreements.
In my experience, at least half of the problems developers have with customers are the result of poor negotiation – usually the result lack of skill and will to deal with various forms of conscious or unconscious manipulation by their negotiating partner.
Do you understand what I’m telling you? Well, you’d better understand, unless you’re too incompetent to do your job! From now on, I’m assuming your commitment to learn to do better at dealing with manipulation, so don’t disappoint me!
(Of course, the way you’ll disappoint me is by yielding to my attempted manipulations.)