Reflections on a negotiation workshop: we’re better at it than we know

The Sunday before OSCON, I gathered a group of women who work with open “stuff” to participate in a workshop on negotiation with David Eaves. He talked a little bit about his recent work in open source communities in an interview with Ed Dumbill. I’ve mentioned David a few times in previous posts here, and was excited to finally get to meet him in person.

My goal in bringing people together was to launch an effort among open source communities to recognize negotiation as a core, required skill. I decided to target women in open source as the initial audience.

The day-long training was structured around two simulations, one based on personal experiences, and the other using an entertaining business situation – where two sides come together after about 45 minutes of research to negotiate an agreement.

Much of the “lecture” time was spent identifying key steps in a negotiation, and sharing a framework that helps individuals prepare for difficult conversations. A key feedback loop was:

It’s a very simple loop, but crystalizes much of the core of what negotiation is about. Preparation, execution, targeting a goal and reflection.

Like much of what I covered in the “Mistakes were made” talk, the diagram documents and reveals common sense as a system. Negotiation is a feedback loop, and there’s always opportunity for even better, more collaborative and satisfying deals.

Another revealing point in the workshop was that the goal of a negotiation is not necessarily to come to an agreement, but to find an acceptable resolution. That includes a BATNA (Best Alternative To a Negotiated Agreement). Which is to say – enter into a negotiation with a clear idea of what your alternative is, and what your bottom line is so that you can feel comfortable walking away knowing what your next step is (even if it is not your preferred step).

Finally, during the workshop and simulations, I realized how many of the research and bits of process that were suggested I was already doing! It was very nice to leave with a framework for future negotiation, and a set of questions to ask myself and others.

My reaction to the preparation was to consider how I could share whatever I prepared with my negotiating partner in the future. And then I realized that probably wouldn’t always work, but it was a lovely thought. What if we could develop the strength in more of our relationships to be that open and direct?

I highly recommend attending any workshop that David gives in the future, and will be blogging about some suggested reading as I get through the books.

Leslie Hawthorn has blogged about her experience.

We were able to hold the workshop, thanks to the sponsorships of Mozilla, Wikimedia Foundation, Google, Technocation, Inc and O’Reilly.

The importance of doing things badly

Update: added “code review” to the things that we’re doing well below.

There were a couple themes for me from OSCON last week. One is transitions and change. I’ve got a whole slew of thoughts on this, particularly from my experience leaving the management team of Open Source Bridge.

But the other is the importance of doing things badly. In particular, the importance of doing things badly in open source.

Tim Anglade, at about 41:10, says that he thinks the reason why open source companies make money is because open source is kind of shitty (from an interview he did with Cliff Moon last fall). So, on one hand there’s a Money Making Opportunity. Probably not the one that we’d all prefer, but it is what it is.

When he said that, I immediately thought about the other things that we do badly (other than documentation) and the discussions I’d been having with people last week.

Basically, we had a problem in the Postgres community of experienced developers solving every small bug at nearly the moment it was reported. It’s sort of like a cat sitting at the entrance of the only mousehole.

The effect on the code is amazing – we have clearly documented, concise and consistent code. But the effect on the community is that we don’t have mid-level developers, and it is very difficult for inexperienced developers to build up a portfolio of small projects, based on bugs.

I don’t have a ready solution for this problem. And I do not mean this as a criticism of the thousands of hours our core teams have devoted to fixing bugs. We all benefit from the dedication. I am just pointing out that our system had a clear tradeoff – fewer contributors.

What we could do a bit worse (to address the point of this blog post) is lengthen our response time to solving bugs, and let some less experienced developers respond to the bugs queue. This probably involves creating a bug tracker and holding the tension a bit longer on fixes.

Our committers have made efforts toward spreading the load around more – with commitfest – meaning a greater support of code review, with Tom’s recent presentations about the planner, with our wiki-fied Todo list. And there are many more examples of our committers putting real effort into mentoring, tutoring and finding ways of bringing more people in.

The thing that’s missing from all of those efforts, however, is urgency. That’s what bug-fixing is great for. That’s why we have people who remain in operations work even if they hate being woken up at 3am. Urgent work is worthwhile work (mostly).

I’m sure there are other particular areas where we could do things worse, and thus invite more people to contribute. I’ll be thinking about this more in regard to our project event planning, as I think there’s a bit of a disconnect there, and a huge opportunity to involve more people.

I’m reminded again of David Eaves’ talks about how community management is the core competency of open source, not technology. I struggle with that thought every day, but it rings truer the more I try to work on the significant problems facing any particular open source project.

OSCON: We’re at the end…

I’m finally getting to blog, and here are a few highlights:

* “Mistakes were made” was a great time. Thank you everyone who shared stories. And those of you who attended, please connect with me – email or whatever, and let’s continue our discussions about failure.
* I have a little bit of editing to do left on the harder, better, faster, stronger slides. Talk ratings have been very high (thank you audience! :) Should have that up tomorrow!
* Not having a booth at OSCON was a real bummer for Postgres. We need to figure out a way to make this happen for us every year.
* Great having the time to connect with old friends in the hallways this week.
* Thanks O’Reilly for supporting our open source community.
* Thanks Google Open Source Programs office for bringing together open source leaders yet again this year for some important conversations.

Thank you everyone from the Postgres community who contributed to the Postgres day just before OSCON. All the speakers and their talks are listed here.

We need to keep having adjunct events like this! I think LCA has it right scheduling Mini-BoFs to provide networking opportunities for the distinct groups. I think OSCON should formalize this next year, and figure out a way of facilitating those groups in a more structured way.

I have another blog post brewing about difficult conversations.. but that’s going to have to wait until after I enjoy the brewers fest!

OSCON: Postgres represent! And my links for Harder, Better, Faster, Stronger talk

I’m giving a couple talks at OSCON this year. The first is on Tuesday, 10:40am room C123: Harder, Better, Faster, Stronger: Postgres 9.1. The other is Mistakes were Made, Wednesday at 1:40pm in room D136.

My colleague Robert Treat is giving a Pro PostgreSQL workshop Wednesday at 1:40pm too, room 204. He’s also giving a Scalability Patterns talk at 4:20pm Tuesday. I’m sure his talks will be awesome. :)

And here are the rest of the talks tagged with PostgreSQL.

Also remember — there’s a PgDay tomorrow at the Oregon Convention Center!

I’m pushing my examples for my 9.1 talk into a github repo. It should be populated with whatever I decide to use for the talk by Monday evening.

Building 9.1 for me on Mac OS X (leopard!) involved the following:


git tag -l | grep REL9_1
git checkout REL9_1_BETA2
./configure --with-perl --with-python --prefix=/opt/pg91beta2 --with-readline
make
make install

Normal caveats apply – you need X Code of a reasonably recent version, and a bunch of support libraries to make this happen. I haven’t rebuilt from scratch on OS X in a long time, but now I realize that maybe I aught to go through the pain and document this again.

But I digress!

I have a long list of resources for this talk and wanted to share. Probably in the slides for the talk, I’ll provide shortlinks so that people can pull them up and read instead of listening to me :D

Here’s my links:

And if you’re wondering about the title, I took it from an great Daft Punk song that fans have created some epic videos of:

http://www.youtube.com/watch?v=K2cYWfq–Nw

Getting ready for OSCON, code of conduct and cultural change

UPDATE: See bottom of post.

I totally should be working on my talks right now, but instead I’ve been talking with people about the lack of a code of conduct for OSCON.

I’ve written before about cultural resistance, and how I think it fits in with changes that must happen in technical communities when we invite more women in.

One of those changes is making it clear that women (and other minorities) are not just tolerated in public spaces, but that they are explicitly wanted there.

I think OSCON has made great strides in that direction by changing their marketing materials to include the faces of women. Sarah Novotny, co-chair of OSCON, travelled extensively to invite women face-to-face to submit talks. There are many women speaking at OSCON this year.

OSCON put the time and energy into creating a sense that women were already attending (which they are), and that they wanted more.

So, why all the fuss about having a code of conduct? Well, this community is changing.

What people think of as “summer camp for geeks” is this year a gathering that by definition includes people who haven’t previously been part of the OSCON community. When a community (which OSCON definitely is) sets out to change the gender percentages, it needs to be clear that the women are being invited to join and shape the culture, not just show up to be tourists of the existing culture.

The leadership of the conference needs to establish with existing attendees that the cultural change is wanted. The fact is, OSCON is a for-profit enterprise, with a business driving the event. Grassroots activism is helpful in encouraging change, but ultimately, the owners of the brand need to make a statement in addition to the marketing.

I applaud Jono Bacon for his creation of an anti-harassment policy for the Community Leadership Summit. I also am heartened at O’Reilly’s recent tweet that they are following this conversation.

I don’t think that codes of conduct are the perfect solution. But how else do we communicate to everyone participating that the change is happening, and that they need to accommodate new members *who are very different from them* during a period of cultural adjustment? That’s not a rhetorical question — I am genuinely interested in answers to this question.

I’ve updated my profile to state that I am pro-code-of-conduct, and included a link to anti-harassment resources, which I think should be part of an overall code of conduct. Donna put up a wikipage with easy to cut-n-paste additions for OSCON speaker profiles. If you agree that a code of conduct is a positive direction, please join us!

UPDATE: Tim O’Reilly has blogged about his expectations in a post titled “Sexual Harassment at Technical Conferences: A Big No-No” regarding a code of conduct for conferences under the O’Reilly umbrella going forward.

Looking for worthy “mistakes were made” stories

I’m giving a couple talks at OSCON this year! One of them is titled “Mistakes were made“, and I need a few good stories.

I’m focused on web operations, but really, any stories where there was a plan, and it went horribly wrong, would be great. And, I’d love to know whether whatever went wrong ultimately got fixed, hacked around or was just left as-is.

Thanks!

Running a Successful User Group

running a successful user group

After the People For Geeks talk, I presented “Running a Successful User Group” with Gabrielle Roth on Wednesday. You can find our slides and our presentation handout over on Bacon and Tech. The handout is pretty cool, take a minute and print it out!

PDXPUG Day on July 20 – Register now!

pgday 2007

photo courtesy of Dan Browning

Registration for PDXPUG Day on July 20, 2008 is open! Please sign up and let us know what size t-shirt you’d like. We’re requesting a $20 donation (by cash or check) at the door. All proceeds to to Software in the Public Interest, a 501(c)3 organization that is used to fund PostgreSQL advocacy.

Registration for OSCON is not required to attend.

Registering also gets you in the door at the Gotham Tavern, our after-party location close to the convention center!

Our line-up of talks includes:

PostgreSQL Unit Testing with pgTAP – David Wheeler
Inside the PostgreSQL Shared Buffer Cache – Greg Smith
Muldis D – Portable Databases At Full Power – Darren Duncan
A Streaming Database Talk – Rafael J. Fernández-Moctezuma
Using GLORP to connect Squeak Smalltalk to PostgreSQL – RandalSchwartz
Fighting Disease with PostgreSQL Full Text Search and JRuby on Rails – Mike Herrick
All Your GIS Are Belong to You – Abe Gillespie
What’s PgUS – Joshua Drake

Sign up today!