Tag Archives: negotiation

The Smyth Deal: The Anatomy of a Positional Negotiation Gone Wrong

A classic negotiation challenge is when parties lock into positions. Both sides articulate a demand – usually followed a threat such as “take it or leave it” – and then hopes the other side blinks first.

In the case of Ryan Smyth and the Edmonton Oilers’ I can almost imagine each parties’ statement. Smyth’s agent probably declared “my player is worth $6M dollars not a penny less – take it or leave it.” While the Oiler representative said “we can afford $5M and not a penny more – otherwise, we’ll go to the trading block.” Then, with both sides locked into a price, two things probably happened. First, the negotiation was restricted to a discussion about money to the detriment of the parties numerous other interests. Second, any change in either parties’ position would cause them to lose credibility and/or face. Consequently, any progress in the negotiation would have paradoxically increased the level distrust by confirming each party’s suspicion that the other could and would bend more.

And of course, this is what happened. Smyth was willing to accept less, and the Oiler’s were willing to pay more. A fact made evident as they managed to haggle their way to a difference of $5.4M and $5.5M per year. But getting closer probably had the perverse effect of making the negotiation harder. Each concession made the subsequent ‘demands’ appear less credible and firm. So, to prove that this was indeed ‘their final offer’ each side had to appear more and more inflexible. The result? A negotiation that collapses over a disagreement of $100,000 a year or $500,000 over the life of the contract – about 1.8% of the deals’ monetary value. Oiler’s GM Ken Lowe’s statement this was “a hockey decision and not a financial decision’ is laughable. This was neither a hockey or a financial decision – it was en ego decision.

Indeed, a tearful Smyth was more honest. While getting on a plane at Edmonton International Airport he summed up the process by virtually pulling the definition of positional negotiation out of a textbook: “We were stuck in our concrete, they were stuck in theirs.” (Edmonton Journal) Interestingly, the very fact that Smyth was crying indicates that, while both parties were arguing over money, financial concerns probably only made up a small fraction of each party’s numerous and complex interests.

To contrast against their positions I’ve quickly brainstormed the following list of each party’s core interests:

Ryan Smyth’s Interests

Oiler’s Interests

Maximize (or receive fair?) compensation
Set precedent for future negotiations
Stay close to/not have to relocate, family
Maintain links to community
Play on winning team
Play on Stanley Cup contender
Profitable franchise
Increase franchise’s marketability
Increase personal marketability
Increase interest in hockey
Play in a market where hockey is a major sport

Minimize (or pay fair?) compensation
Set precedent for future negotiations
Profitable franchise
Field a winning team under the salary cap
Field a Stanley Cup contender
Increase franchise’s marketability
Increase Smyth’s personal marketability
Increase interest in hockey
Maintain/improve morale of team and fans
Strong positive presence in the community

As you can see, money makes up only one (albeit important) piece of the puzzle. But in both cases numerous other issues whose value cannot be easily quantified also factor importantly.

For example, one wonders if $100,000 a year (our of $5.4M!) was worth forgoing if it allowed Smyth’s to keep his family in Alberta and stay close to them (especially given the after tax value of the $100K). Smyth probably also had an interest in maintaining/continuing his community work in Edmonton, a place he likely genuinely considers home (unlike Long Island). Smyth probably also had an interest in ensuring that the Oilers have enough money under the cap to acquire other key players that would have given him the chance to hold up a Stanley Cup.

Meanwhile, the Oiler management likely have an interest in players that are marketable and increase the profile of the team in the community (which Smyth is uniquely positioned to do). One wonders how much the lost revenue from merchandising will cost the Oilers. In a small market a local town hero can be worth their weigh in gold (and then some).

The point is that Smyth and the Oiler’s had relatively few conflicting interests compared to those that were either common or simply different (but not conflicting). Had both parties looked at their full range of interests, and not focused almost exclusively on money, it’s hard to imagine that some creative value-increasing options were not possible. For example: the difference of $100,000 could have been donated to a charity of Smyth choice every year – thus helping Smyth’s marketability, improving both his and the Oiler’s standing in the community all while not contributing to the salary cap. Or the $100,000 could have been converted into bonus pay contingent on Smyth’s performance. Ultimately, two negotiators thinking creatively about this negotiation as a collective challenge, and not locked into an ego-driven game of chicken, could have found a deal. But then Smyth’s agent is probably rewarded based on the money he pulls down and the Oiler’s manager on how much money he saves, so in the end money drove the negotiations… right over the cliff.

[tags]NHL, negotitation, negotiating, Ryan Smyth, Oilers, Edmonton, mozilla, sports, hockey [/tags]

Air Canada: A Case Study in how not to Negotiate with your Customers

12 Replies

Fellow travelers looking for a laugh MUST check out my buddy Beltzner’s list of Air Canada inspired haiku’s. Pure genius.

Speaking of Air Canada, WestJet is creating a network of lounges across the country. Great news. Finally some comprehensive competition for Air Canada and some negotiation leverage for the consumer.
Most Canadians don’t even know how badly Air Canada treats them. My favourite example? Air Canada will launch a plane with empty business class seats. In contrast, most US carriers will keep upgrading passengers until all biz class seats are filled (usually prioritizing by status). Why? Because it costs them virtually nothing and helps maintain brand loyalty. In negotiation theory we call that a low-cost/high-value option – something that costs one party very little but benefits the other party significantly.
Alas, Air Canada is essentially telling its customers: Yes, we’d prefer to keep these seats empty rather than reward you for being our customer, even in spite of the fact that it would costs us nothing.

Second example: Never trust what an Aeroplan rep tells you on the phone. I’ve had two friends who, coming within a thousand miles of getting status, proactively called Aeroplan to see if they should book additional flights to ensure they would meet the threshold. Both were told not to worry, there was no need. Yet, in the new year, Aeroplan refused to grant them status. Needless to say, they now ALWAYS book their international flights with another carrier. Nothing breaks trust faster in a negotiation than breaking your word.
Air Canada better pray WestJet doesn’t join a reward program like One World. Between the lure of lounges and reward miles the only thing faster than an Air Canada jet will be the speed at which business travelers jump to WestJet.

I don’t even have a hate on for Air Canada… but this guy does. Plus, the site is a good resource if you feel aggrieved.

(Added on Feb 13th: So I’ve heard through the grape vine that Air Canada does not fill its business class seats because it only packs enough biz class meals to feed the number of people who buy biz class seats. Is this really an insurmountable barrier? One wonders a) if the money saved from not tracking business class travelers might offset the cost of packing enough meals for everyone; or b) if anyone who were upgraded cared if they got a meal, I know I wouldn’t, frankly the extra leg room is far more valuable then airplane food. Was on a AC flight today where several seats in Biz Class remained empty…)

[tags]negotiation, air canada, airlines, air travel, travel[/tags]

Does Jobs really want to set my iPod free?

23 Replies

Will your music be set free? Will you be able to share your songs from iTunes, move them from machine to machine with impunity? Steve Jobs claims “he’d like nothing more.”

Yes, some of you may have read this note from Steve Jobs about the current and possible futures of digital rights management (DRM) in the music industry. For those, like me, who don’t dabble in acronyms like DRM on a regular basis, this basically refers to how online resellers like iTunes encode their music so that a) you are limited to copying it 5 times; and b) you can only play it on their proprietary system (like an iPod – ever tried playing a song from iTunes on something else… it won’t work).

Taken on its own Jobs’ note makes it look like he’s taking on the music industry unprompted, fighting for the little guy – the consumer (that’s me and you!). The truth is a little more complicated. Even this Herald Tribune piece, which has all the pieces to the puzzle, reverses cause and effect and buries the important parts at the back of the piece. The important fact is that Norway’s consumer ombudsman, Bjoern Erik Thon, told Reuters that Apple “must make iTunes music compatible with other players than the iPod by the end of September, or we will take them to court.”

Apparently, several European countries are proposing similar rulings. What makes this interesting (and my understanding of EU law could be flawed here – so please send me clarifications) are the EU’s rules around mutual recognition. Consequently, a ruling that found Apple violating consumers rights in one EU country could be quickly adopted across all the member states. If that happened, the theoretical future scenarios Jobs mentions in his memo would very quickly become the here and now options he would have to implement in a manner of weeks.

I have little doubt that Jobs would prefer to maintain the status quo. He’s got the dominant online music vendor that forces people to use his proprietary hardware. Do you really think he wants to give up this virtual monopoly? No way. Let’s be clear, this memo is the opening salvo in an effort to renegotiate iTunes agreement with the record labels in case the European regulatory environment changes (which is beginning to look very possible). Like any savvy negotiator he’d prefer to negotiate today, when he’s got options, as opposed to 7 months from now, when he’s got a gun to his head and the music labels are threatening to pull the plug unless he shares Apple’s proprietary licensing system – FairPlay – with everyone. Such an agreement would allow anyone to sell music that can play on an iPod effectively destroying his monopoly distribution arrangement.

Jobs isn’t a champion of the little guy – he just likes to look like he is. The change of heart outlined in this memo was not prompted by his concern for consumers but out of concern for the future of iTunes.

Thank you Nicolas T. for the HT link and the prompting email.

[tags]itunes, steve jobs, copyright, copyright law, music, negotiation, apple, ipod, DRM[/tags]

Wiki's and Open Source: Collaborative or Cooperative?

19 Replies

This is a follow up to my previous post Community Management as Open Source’s Core Competency which has become the most viewed post on this site. I’ve been meaning to follow it up for some time, sorry for the delay.

Online communities, and in particular their collaborative nature, have been generating a lot of buzz lately. But are online communities collaborative?

Overview

The more I reflect on it, the more I suspect the answer is a qualified no. While at present there is a tremendous amount of online cooperation, this is not the same as collaboration. This is not to say the cooperative capacity of online communities has not been a boon, but simply an effort to recognize and concern ourselves, with its limits.

I suspect the world’s most interesting and challenging problems cannot be solved in isolation from, or even in cooperation with ,others. Elegant and effective solutions (those most useful to users or consumers) likely benefit from, and probably require, an interplay of ideas and perspectives. Consequently, for those involved in online collaborative projects – such as Wiki’s or open source – understanding the distinction between cooperation and collaboration is critical. If online communities cannot foster collaboration then they will fall short of the hype and ambitions they have set for themselves. Conversely, communities that figure out how to enable their members to collaborate (as opposed to merely cooperate) may end up having a decisive advantage.

Defining the problem

Why distinguish between collaboration and cooperation? Because the subtle difference between these words describes a lot about where we are versus where we need to be vis-à-vis online communities. Admittedly, Websters’ defines the two words very similarly. However, I would argue that collaboration, unlike cooperation, requires the parties involved in a project jointly solve problems.

Truly collaborative processes enable differing and possibly conflicting views to merge and create something new and previously unimagined (think of Hegel’s thesis and anti-thesis coming together in a synthesis). Many online projects – offered up as collaborative – do not meet this standard. For example, some on-line projects, particularly open-source software projects, break problems down into smaller pieces which are tackled by individuals. Sub-dividing a problem and allowing a network of volunteers to opt-in and provide solutions it is a highly efficient. However, those involved in the project many never need to talk, exchange ideas or even interact. Indeed tricky problems may often end up relying on a single clever hacker, operating alone, to solve a problem. While this can be part of a cooperative effort – people with a common goal contributing labour to achieve it – I’m not sure it is collaborative. Equally, many wiki’s simply replace old information with new information, or rely on an arbiter to settle differences. This is at best cooperative, at worst competitive, but again probably not collaborative. (Side note: Please understand, I do not mean to belittle the incredible success of online communities. Indeed the achievements of open source projects and wiki’s are remarkable. However, my concern is that cooperative approaches may only be able to solve a specific, and limited, problem type. Cultivating collaborative communities may be necessary to solve larger, more complex and interesting problems.)

Why Open-Source systems tend to be cooperative and not collaborative

My guess is that unlike cooperation, online collaboration is rare. Why? Probably because online collaboration it is hard. Few people should find this surprising since face to face collaboration can itself be pretty hard. (I make a living off helping people do it better…) People approach problems with, among other things, different assumptions, stated and unstated goals, and data sets. Effective collaboration requires people to share these differences and resolve them. Anyone who has ever been to a business meeting (even among colleagues from the same company) knows that the process for achieving this is often neither self-evident nor easy. Numerous issues can sabotage collaborative efforts – including those that have nothing to do with the substance of the problem. For example, our ideas often end up being linked to our identity. Even just modifying our idea, or worse, adopting someone else wholesale, can feel like admitting someone else is smarter or better – something that may be difficult to do, especially in a voluntary community where your value and credibility is linked to your capacity to solve problems or provide ideas.

From what I can tell online projects only exasperate the challenges of face to face collaboration. Without personal relationships, trust, body language or even intonation, it is easy for communication to break down. Consequently, it is difficult for people to resolve differences, exchange ideas, or brainstorm freely. In short, it is difficult to collaborate.

Successful online projects seem to manage this by being either a) small – relying on a tight-knit community whose strong relationships enable them to collaborate; or b) large – achieving success by doing the opposite of collaboration: separating problems into discrete pieces that individuals can handle alone.

In the large group scenario, interaction may often be limited to peer review processes where criticism – not constructive problem-solving – is the dominant form of dialogue. Consequently, interactions are limited, and usually arbitrated by some central authority. This has the benefit of capping the level of conflict but the discourse among members may remain highly combative.

Such tension can be healthy: collaboration is inherently conflictual. Most ideas spring from parties sharing differing, conflicting perspectives and jointly working to develop a solution that meets both their interests. Eliminate all conflict and you eliminate the opportunity for new ideas. However, too much conflict and the opportunities for collaboration diminish. Large communities – particularly those involved in projects that have some cache – are insulated from the inevitable burnout and frustration that causes members who skin isn’t “thick enough” to drop out. Other community members jump in and fill their spot. It isn’t pretty, but it is sustainable, in a manner of words.

Some recommendations for community managers

Consequently, the goal of online communities should be to determine how to manage, not eliminate, conflict.
So far, to be collaborative – to enable people to work together and jointly solve problems – online communities appear to have two options: (please send others!)

1) Build relationships between their users – stronger relationships can (although not always) enable people to overcome breakdowns in communication. However, building relationships generally takes time and is to scale. To date, the voting system on the Omidyar network – which rewards those perceived as having ‘good’ behaviours and ideas – is the most effective I have seen to date. Although the behaviours are not defined, one can presume that those with higher ratings are likely to be more trustworthy and easier to collaborate with than those with lower ratings. However, this system does not help users develop collaborative behaviours or skills, it simply rewards those who are already perceived as being more collaborative then the mean. Consequently, users with poor collaborative skills, but possessing expertise or substantive knowledge essential to the success of a project, may struggle to contribute. Even more troubling, the vast majority of your users could be inept at collaborating, and this system will do nothing to raise the bar or improve the community. It will only highlight and identify who is least inept.

2) Develop online communities with built in methodologies and processes that encourage or even compel users to jointly solve problems. Here one can imagine an online community that forces users to work through Chris Argyris’ ladder of inference. While likely more difficult to design, such a system could compel users to be collaborative (possibly even regardless of their intentions).

A lot of the theory around collaborative decision-making is explored in greater detail in negotiation theory. This post is part of my continuing effort to flesh out how (and even if) negotiation theory can be applied to online collaborative networks… I promise more thoughts in the future – in the meantime please send or post yours!

One closing note – if there is a compelling link between negotiation theory and collaborative online networks then it would suggest a new interesting area for inter-disciplinary studies. For example, Stanford has the Centre for Internet and Society and the Gould Negotiation and Mediation Program. It would be interesting to know if these two centres believe they share this area of mutual interest. Maybe I’ll work up the courage to email Lawrence Lessig and ask…

Community Management as Open Source's Core Competency

11 Replies

Reaction to this post has been overwhelming – I made it the basis of a presentation at the 2007 Free Software and Open Source Symposium at Seneca college. You can watch it here as a slidecast.

A good friend of mine, Mike B. and I have been exchanging thoughts on open source projects. Mike’s experience is grounded in the ‘traditional’ world of open source – he works on the web browser Firefox (which if you don’t use, you should). I freely admit my own open source credentials are more suspect – I draw my lessons from my experience engaging in a form of open source public policy through Canada25. Beyond, that, what I know is based on what others are kind enough to share with me, and what I am able to learn through articles, books and podcasts.

For those not interested in the whole spiel below the short version is this:

Companies or foundations that run open source project are not software firms, they are community management firms whose communities happen to make software. Consequently to survive and thrive these projects need to invest less in enhancing governance structures or employees who/that will improve their capacity to code. Instead, we should consider skills and structures that emphasize facilitation, mediation, and conflict management – tools, skills and structures that will enable the community to better collaborate.

More detailed thoughts I’m fleshing out an idea flow that goes something like this:

Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package. (I’ll talk more about Canada25 as open source in the future)

The core competencies of a community management organization are different from those of a software firm. Specifically, core competencies reside in their capacity to support and enable the community to collaborate and contribute to the project. Furthermore, the community’s contributions will not likely be limited to a single function (such as coding new features) but will need to include all aspects of the projects evolution including discussions about the direction of the software or marketplace and its impact on strategy. As people volunteer more time and become more invested my hypothesis is that they will want (at least) input (not to be confused with decision-making authority) in more strategic decisions.

Consequently, the structures and skill sets of those working on an open source initiative need evolve over time:

1. In the beginning, because of their size, open source projects can pretend to be software firms – this is because the community is sufficiently small that everyone knows one another so that levels of trust are high and the need for formal community structures are low. In this earlier phase:

i. Respect and influence is based on raw brain power/problem solving capabilities – rather than seek permission those who code solutions to problems earn respect, and others listen and/or follow their lead

ii. Common values and operating assumptions in the community are not, and don’t need to be encoded – it is small enough that those who ‘get it’ opt in, and those who don’t opt out.

1. Success changes everything. As open source projects becomes increasingly successful (and, possibly, more political) the context around the community changes:

i. Success means more people join the community. This is not only true of the number of people, but also of the type of people (e.g. skill set, cultural background, etc…). This increase places stress on the community infrastructure. Specifically, an increase in participants can:

1. reduce levels of trust and the sense of community, raising transactions costs to effective collaboration

2. erode the assumed common community value as new entrants join the project for different reasons

3. decision-making becomes increasingly complex as the consultative nature of open source projects does not obviously scale. This may cause individuals/groups to feel disenfranchised and/or frustrated (and never underestimate the damage to productivity frustrated people can cause – thank you for this Shaver)

ii. As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.

1. Community Management as Cope Competency. My interest in all this is how we can take the ideas, methodologies and tools that come out of the negotiation/conflict management/collaborative decision-making arena and port them over to the open source space.

i. Training up in facilitation skills. Getting the core group of project employees trained up on how to collaboratively solve problems. Some basics might include:

1. using interests and not positions when resolving disagreements

2. using Chris Argyris’ theories about how (particularly smart technical people) fight over conclusions, by failing to share the data and analysis behind their thinking – often referred to as the ladder of inference.

ii. Rethinking decision-making processes – chiefly by setting expectations of how decisions will be made, what criteria will be applied when making them. It is likely essential to give community members a common set of criteria to use to evaluate decisions, that way they we can reframe discussion from what they like more to what adheres to the communities standards the closest. This is true for technical decisions, but also strategic or governance questions. The key around decision-making is not how democratic it is, but how well we set expectations for community members and then adhere to those expectations.

iii. Open source communities may fear accepting that even greater collaboration and openness is their core competency because it raises the underlying question no one wants to ask: Is the open source model scalable , and competitive?

The false answer is no: To believe that becoming more competitive and/or moving quickly means we need to consult less.

The true answer is yes. We can’t be competitive by running away from our core-competency, if we do that the we end up playing by the rules of the established corporate players, rules that we can’t win using. Forget their playbook, we have to get back in the box. We have to become faster, more efficient and easier to use at what we do best: engaging and enabling everyone in the community (customers, volunteers, etc…) to collaborate.

Leaders Matter: The good and bad news is for project leaders – for example, paid employees of the project – is that you are THE role model for the community. Every action you take validates or invalidates certain behaviour types. If a employee behaves in an unconstructive way it will be hard to tell others in the community that this behaviour is out of bounds.

I suspect that most open source projects:

1. Know this
2. It causes nervousness
3. Because participants are smart, we rationalize ourselves out of this problem

But… we can’t. And we shouldn’t. This is our single most important chip. It is what allows us to shape the behaviour and culture of the community. Let’s embrace it and use it.

Sorry for the long post – generated out of some thinking with friends at Canada25, Canada2020 and Firefox. Hope you have lots of thoughts, reactions and comments, definitely want to refine my thinking and there is likely a lot of refining to do.

UPDATE: If you found this piece interesting I’ve written a follow up on to this piece, entitled Wiki’s and Open-Source: Collaborative or Cooperative?

eaves.ca

if writing is a muscle, this is my gym