Ross Mayfield's Weblog

Meeting Hell

Meetings are a big productivity killer that you can control by working together better.  Studies have shown the cost of meetings, you probably spend a week per month in meetings, and you can calculate your own cost of meetings. The issue isn't just where you spend your team's time, but how you spend it. Vinnie Mirchandani, following my post in Forbes on Email Hell, points out the productivity problem isn't just email.

The other big productivity killer in corporations is meetings. I am constantly surprised to see too many of my client employees just go from meeting to meeting - then, of course come back to their desks to handle the deluge of email!

Like email, improving meeting productivity requires more than personal tactics.  Through leadership, the behavior of the group must change.  This distinction is critical in our current climate.  Companies need to make do with less -- and doing so cannot be done through personal productivity gains -- but with efficient and effective coordination and collaboration of teams, the organization as a whole, and how partners and customers intersect.

Changing meetings is difficult because nowhere does company culture manifest itself, if not define itself, than through meetings.  The meeting culture of some companies puts a premium on presentation, or cooperation to consensus, or conflict as creativity.  Research has even shown that most meetings are status contests.  Beyond this theater as a disclaimer, here is some practical advice to make meetings more effective and efficient:

Do I need to be there?

Without a criteria for who should attend meetings, the attendee list tends to grow.  Not only does having more people in the meeting effect the productivity of the meeting, but it keeps people from working on other things.  Put responsibility for this criteria upon the person calling the meeting, as they have the greatest odds of abusing it.

Share notes

At the beginning of every meeting, ensure that someone is taking notes and how they will be shared.  Better yet, have an established practice for how this is done in every meeting.  Sharing notes can help decrease the attendee list for efficiency sake.  How notes are taken can make the group more effective:

• Consider having the note taker project while taking notes.  This clarifies and gains support for what was said and what is agreed to. 
• Take notes in a wiki to make it easy to link to supporting materials, pass editing control to others, share while taking and makes the notes searchable and discoverable alongside other knowledge.
• Don't aim for meeting minutes, encourage summarization, but try to capture as much as possible.  The great thing about meeting notes is that they carry with them the context of an event.  Small things said may mean a lot in the future. For example, someone might contribute an alternative point of view that wasn't part of what might be the summary, but when someone finds it outside the meeting they can contact the person to further explore it.
• Focus on next steps.  Conclude meetings with agreement on what was learned and the action items.

One tendency I have seen is to constrict note sharing for sake of politics.  Sometimes this necessary, but the instinct for control tends to hamper productivity.  For example, if division heads need to meet on an HR issue and craft a message for broader consumption, sometimes the meeting owner controls the notes.  Always share notes with meeting attendees and have a protocol for how they will be shared further.

What's the goal?

A meeting without a clear goal shouldn't exist.  Goals help focus conversation, but also ensure time is being spent towards the right outcome.

The most unproductive outcome of a meeting is having another meeting.  Usually because of unclear goal setting.  Unfortunately, meetings are autopoietic, meaning they self-propagate.  The only time a meeting should lead to another meeting is if that is the up front goal (let's plan the annual sales kickoff, or let's divide the strategic planning we need to accomplish into these three meetings).

What's the agenda?

The structure of an agenda should support accomplish the goal of the meeting.  One challenge is trying to limit agenda items while everyone has their own agendas and need to be heared.  One of the quickest produtivity gains available is to perform agenda setting in a wiki beforehand.  Be sure you bring people's attention to the agenda as it changes.  Link to supporting materials so everyone arrives at the meeting not only understanding the goal, but understands the subject matter behind each agenda item.

Will this ever end?

Always have a firm start time and end time for meetings.  Notice that when meetings have a firm end time, and you get close to it, suddenly the meeting becomes more productive?  Consider how time as a constraint can provide focus for conversation.  Consider trying that hour long meeting in 30 minutes.

Identify Subgroups

Before a meeting, consider if a subgroup of attendees can better discuss and decide or recommend a course of action.  During a meeting recognize when the conversation really is for a subset of attendees, and if time allows, table the conversation until the subgroup can work it out.

Standup Meetings

One of the best practices businessfolk can adapt from agile software development methodologies is the standup meeting.  Have the team meet daily for 5-15 minutes to synch on status.  Sometimes this is done litterally standing up, which gives even the most diligent of soldiers a stake in ending the meeting before they pass out.  Each team member takes a turn updating everyone, perhaps taking clarifying questions, but not using the forum for protracted discussion.

Prep Time

The beauty of the standup meeting is that everyone comes prepared to update others.  However, this preparation doesn't come for free.  You need to allow the team members time to prepare for the meeting. 

One evolution I've witnessed at Socialtext is how they increasingly shared their status updates in the wiki before the standup meeting, and then it became convention for everyone to read the updates before the meeting.  In any meeting format, status updates are better replaced with coordinating conversations, unblocking issues and gaining a shared understanding of priorities.

BAHM: Big Hairy Audacious Meetings

So far, I've provided general considerations for making meetings more productive for groups. But what are some bold things you can try with your team? For the more adventurous teams, here are some Big Hair Audacious Meeting methods to consider:

• Barcamp Your Retreat -- At Socialtext, half of our employees are remote, so our face to face meetings really matter when we have them.  Initially we did like all companies do, lots of time preparing the perfect agenda, with lots to cover.  Once we tried a Barcamp-style open space methodology for the first afternoon.  People liked it so much, we threw away the structured agenda for the week and let it self-organize.  At the end of the week, everyone revelled in the experience, but we also reviewed the original agenda and found we covered every single item.
• Turn it Off or Turn it On -- Companies have gone to the extreme in adapting to having connectivity available during meetings.  Some have banned laptops and blackberries during meetings, which I think completely misses the point.  Doing email in meetings is bad, but the cause is usually a culture of unproductive email and meetings.  Having laptops augment meetings, with wikis, backchannels and the ability to search, is good with the right focus.  But you need to make people conscious of the issue.  Try three things:
  • During specific portions of a meeting, or certain kinds of meetings, the organizer needs to demand all laptops shut for 100% focus on the people in the room.
  • Try meetings for a week where you specifically ask people to bring their laptops and look to augment the meeting with social software and search. Afterwards, ask people how this made your team more productive, or not.
  • Try meetings for a week where you specifically ban everything but pen, paper and people.  Afterwards, ask people how it helped or hurt productivity -- but more importantly talk about if time and effectiveness is being lost because people are not valuing attention.
• Standups -- I used standup meetings as an illustration of how time is best use for status reporting, but do try this format with your team.
• Make Every Meeting a Party -- I always quote Pete Kaminski's insight that "time spent face to face is too valuable for work" to make the point that teams need to socialize.  If you don't afford the time to help your team be unproductive, they will make meetings unproductive.
• Turn Recurring Meetings into Processes -- survey the meeting topics of your organization and you may find recurring meetings that are the result of broken business processes.  Fix the process or lackthereof.
• Get Back to One-on-Ones -- short one-to-one meetings can be incredibly productive.  They even help decrease email volume.  Consider the patterns with your team, and if you can carve out the time for one-on-one meetings by having less group meetings.
• No Meeting Monday -- this is the obvious audacious one.  Consider banning meetings on Monday, not just because it is a good day for people to collect themselves and orient how meetings should be conducted for the rest of the week.  But it will raise the conciousness of meeting cost.  As with email, knowing it is an issue we are all responsible for is half the battle.

In summary, I don't take the extreme position that meetings are wholly unproductive, and the issue isn't the cost of meetings, but how to increase their return by working together better.  In future posts I hope to address how to make meetings more effective and efficient with partners and customers.

Related readings:

• Best Buy's Results Only Work Environment (ROWE)
• Tim Ferriss' Do-Not-Do-List
• 37signals' Meetings are Toxic
• Short case study on meeting augmentation
• Outsourcing memory
• 43 folders on Topless meetings
• Productivity of Far Flung Teams
• The hidden cost of meetings

Diplopedia

The New York Times has an article about the U.S. State Department's Diplopedia.  Eric M. Johnson of the State Department’s Office of eDiplomacy shared his learnings during the Wikimania conference in Egypt (video accessible if you use Internet Explorer, sigh). 

The art of diplomacy excels with shared context that wikis can support.  And while fundamentally State may gain productivity, particularly if they allow it to work across agencies, evolving from manufacturing era cable systems could evolve culture itself:

There was a larger point to bringing his message to Wikimania 2008, as the annual conference is called: if wikis can work at the State Department, with its fabled bureaucracy and attention to protocol and word choice, they can work anywhere.

There certainly is a culture of collaborative writing at the State Department, Mr. Johnson acknowledged: memos are drafted, massaged, passed up the chain for comments and then approved. But this form of collaboration is based on the notion that the more people who read something, the less chance it will be candid. Wikis, by contrast, are collaborative only in retrospect ― someone has to be prepared to be the first to write something, and deal with having those words changed by a complete stranger.

Mr. Johnson said his office occasionally gets calls from new contributors: “People will say, ‘I have something I want to post; I want to check before I do it.’ And we say, no, no, put it up.”

The decision to embrace wikis is part of a changing ethic at the department, from a “need to know culture” to a “need to share culture,” said Daniel Sheerin, deputy director of eDiplomacy, which was created in 2003. “This is a technological manifestation of a policy difference,” he said, a change he dated to when Colin L. Powell was secretary of state.

Emphasis mine.  I'm not sure I would say that wikis are not collaborative in retrospect.  They are in prospect, when words first written find collaborators and it turns into collaboration when their is a shared bounded goal.

Back when I worked in this sphere in Estonia, they didn't have legacy infrastructure and culture.  I set up a Lexis Nexis account, ran persistent searches on diplomatic topics and sent out a newsletter daily by email.  In retrospect, it was a form of blogging.  If only I had the tools I have today.

Wiki Universal Edit Button

Yesterday at Supernova's Liquid Conversations panel I asked what people were doing to make a better and more usable user experience across tools.  There wasn't much of an answer.  Today, UniversalEditButton.org was launched.  Pete Kaminksi, my co-founder and CTO blogged about it:

...The UEB creates a common notification icon and a common way to "click to edit" across many more wikis across the whole web. We hope to increase the size of the read/write web, so more and more people can easily work together via wikis.

Here's how it looks in my Firefox browser:

It works by having the wiki engine include a little bit of HTML markup in each editable wiki page. Your web browser then auto-detects the markup, and displays the Universal Edit Button to let you know you can edit the page.

Marshall Kirkpatrick notes:

Installing this extension is a no-brainer though and could help any of us remember to edit the pages we knew we could but perhaps didn't think about. Seeing all these wiki providers come together to build a common standard is particularly inspiring.

Exactly.

You Judge Wikileaks

Wikileaks, a site for whistleblowing otherwise confidential documents, had its domain name desisted by a federal judge in California and now has free speech legal support.

...One reason why U.S. District Judge Jeffrey White ordered the domain name offline was that Wikileaks had not sent a lawyer to a hearing or responded in any form. After that, a judgment for the plaintffs wasn't exactly a surprise.

Wikileaks, by the way, was sued by a group of Swiss bankers--Bank Julius Baer--who claim in the lawsuit that confidential information is on the site. Wikileaks is still online at the Internet address http://88.80.13.160/wiki/Wikileaks and a host of mirrors including wikileaks.cx.

A strength and a weakness is that a wiki is a central resource with decentralized control.  That openness and the open access to provision a wiki, makes models like Wikileaks possible, if not inevitable and ubiquitous.  Plus volunteered mirroring when a community starts to carry value that people don't want to shut down.

Regardless of if you think Wikileaks is a good thing for our society and the rule of law, if how information wants to be free trumps the Freedom of Information Act, its more than inevitable forces at play.  Wikileaks grew to the point where its community developed norms and standards, if not a good bullshit detector, which is encouraging for its half-life.  And perhaps inevitable if it is to be credible, by a different judge.

I have to draw the distiction between these wiki moments in nascent communities on the public net and what happens behind the firewall.  Such re-education from successes like Wikipedia or failures like Wikitorials are a big part of what we do.  In an enterprise you have both transparency and accountability.  If someone break the rules you know, and you can, um, fire them.  I haven't seen that happen, and perhaps there is a different kind of self-regulation.

"Wiki Moment"

I have a lot to blog about when it comes to my trip to Italy.  But I have to share the phenomenon of the "wiki moment" that emerged out of the State of the Net conference. Here's actress and blogger Marina Remi's moment of improvisation in the joy of sharing:

Such moments are exploding out of nowhere across the net.  While a "wiki moment" lacks definition until you contribute to it Gigi helps add some context.

What's your "wiki moment?"

Zack and Wiki

Jens Alfke has a hilarious review of Zack and Wiki:

I’ll say it up front: ZackAndWiki: QuestForBarbarosTreasure is a disappointment when measured against the expected checklist of wiki features. Most seriously, it has no text editing at all, either WYSIWYG or markup. Instead the “pages” take the unusual form of 2 1/2-D environments, like jungles or ice palaces, that you “edit” by pointing to and manipulating “items”. This is a lot more limited, but in compensation the overall interface is extremely polished, with lots of colors and animation. Editing is accomplished by moving the Wii remote in a variety of intuitive ways, and offers nearly the expressive power of a keyboard while looking a lot cooler to do.

There is more.  Go read it.  Side-splitting for wiki geeks.

Gartner Magic Quadrant for Enterprise Social Software

Gartner Research released the first Magic Quadrant report on the Enterprise Social Software market this week.

This is a pretty big milestone in the development of the Enterprise 2.0 category at-large.  Just a few years ago, the only analysts covering the space were blogalysts.  Now, perhaps the most rigorous and influential vendor analyst reports in enterprise software says it really is enterprise software. The analysis rightly says we all have work to do.

It also says that Socialtext is the most visionary provider and behind only Microsoft, BEA and IBM in execution.  This tells me that if we want to be the leader we need to demonstrate better execution (mind you, I'm not taking out IBM next year, but it is good feedback).  SuiteTwo, of which we are a core component, also scored well in vision but has a way to go in execution.

Wikinomics: The Wikinomics Workplace

If you haven't picked up a copy of Don Tapscott's latest best seller, Wikinomics, Chapter 9: The Wiki Workplace is available for download exclusively through Socialtext.  Go read it and become a contributor to the forthcoming Wikinomics Playbook in the Wikinomics wiki.

IDC Survey: 1/4 of Enterprises Use Wikis

Jeff Brainard posted a the results of an IDC survey along with a Q&A with collaboration analyst Mark Levitt on the Socialtext blog.

"IDC’s 1Q07 AppStats survey, nearly a quarter of the 258 U.S. respondents reported that wikis are already in use at their organizations."

This is the only research to date we have found on the current penetration of wikis into the enterprise.  Gartner predicts that 50% of companies will use wikis by 2009.  Perhaps we are halfway there.

Enterprise Mashup Summit

I'm at the IBM Mashup Summit in San Francisco today.  As we are within the bowels of a large enterprise, there is a process to follow to get wifi access, so I'm offline.  We're here to talk about mashups within the enterprise.  With all the innovation on the web with mashups and widgets, real work needs to be done on standards, identity, process and security to bring them into the enterprise.  We aren't just talking about technical work to make things work, but how to market it before insecurity FUD curbs innovation.

Dion Hinchliffe phoned in an introductory talk about what he is seeing in the space (I'll try to find notes to link to, and update this post later).

Then Pete Kaminski (Socialtext CTO & co-founder) and I gave a little talk about the things we have seen, done and questions we have.  Unfortunately, Open Data is being seen as enough in this space.  Be like Flickr, just put up an API, let people innovate, and that's good enough.  But it isn't good enough for enterprises, which is an opportunity for us to work on standards that may conversely enhance the consumer web.  For an enterprise, to develop upon a service, they need to know if their effort is at risk, as the API may change.  Especially when services are built upon services upon services.  Enterprises also pay particular mind to switching cost and lock-in risk, and standards and open source provide ways of reducing cost and managing risk.

Mostly we talked about Amo, which means "to carry" in Hawaiian and is a REST API for wikis we hope becomes an ad-hoc standard.  It incorporates the Atom Publishing Protocol thanks to some good work Chris Dent did over a weekend.  Unfortunately, the folks really working on this stuff are up at our hackathon in Vancouver this week.  But it gave us a chance to share what we have heard and not from enterprises over the last four years.  Customers have stronger needs to integrate with directory systems for single sign on, and despite our efforts to make auth pluggable, the lack of standardization in this area is a problem not just for deploying a wiki -- but signals the complexity and perhaps greatest risk in enterprise mashups, that of identity.  When a mashup platform has multiple services and multiple logins, where and how are they stored is an exponential problem that puts security and system cost in conflict with usability.  We didn't get customers coming to us asking for mashups in numbers, but we did get people asking for data to be available and offline editing.  We created RSS and Atom feeds for every page, tag, search query, watchlist, weblog and wiki.  In absence of other clients, we used the Atom API for offline editing using Ecto, a blog editor.  Most recently, we created SocialPoint for Sharepoint portal integration using our SOAP API.  With the REST API, we worked with Jeremy Ruston to create Socialtext Unplugged for offline wiki reading and editing.

Pete made an interesting point about the currency and quality of data that reminded me of a post by Allen Morgan I read yesterday.  Pete pointed out how the rise of the convenient cell phone has changed user expectations for call quality within land-lines themselves. Allen is exploring similar trends in audio and video: fidelity declines with the rise of convenience.  Pete gave the example of how a user of Socialtext Unplugged can board an airplane to Hong Kong with a reasonable expectation they will be working with less current information the further they travel.  What user expectations and education will they have when using mashups across different data from multiple processes.  This is an important question because it also informs how expensive it should be to build and operate these systems.  Rod Smith suggested there should be a "freshness dial."

I emphasized that there are some areas you don't want to automate, such as merging revision conflicts, because people are better than algorithms for many things, and suggested other service providers borrow from some elements of wiki design like revision history.

I shared our experience with open source application licensing.  From the conversation, I think people understood the need for a different license for open source web applications compared to infrastructure.  But it also was clear to me that I've not communicated our current status, as someone in the know asked if we were "Open Source."  Nobody owns the term and can modify it in their own way, but there is a significant role for OSI to accredit project as OSI Certified.  Socialtext is almost six months into the process of getting it's license OSI Certified, we don't claim we are yet, but we do say rightly we are a commercial open source provider.  We are about to submit a third revision of our license, so I write more later, but if the process concludes in the negative, we will choose a different OSI license.  Not because it will suit our needs, in fact it will decidedly not, but because of the role we want to play in the community.  We'll see what the other 15 MPL+Attribution projects do.  But attribution is an important issue for mashups, and people here seemed to be in favor of it.

Stephan from Kapow technologies sees the stack as Mashup builders like QEDwiki, Teqlo and Excel and Mashup enablers like Kapow and RSSBus..  Because we don't have UDDIs and WSDLs of the web services world, we need service discovery through a central service repository and builder specific repository. How do I find the data I need and get it into the format I need? Within the enterprise, users want to be able to get to data without involving IT.  An example of this is IBMs Mashup Hub, and while more service descriptors are needed, people just want to grab two values off of different sites (using Kapow's web-scraping) and put them together in Excel or SocialCalc. Need to communicate through WS* (he assumes SOAP is what legacy speaks.  Someone pointed out that at Mysql conference nobody knew about SOAP, and he countered that people in Europe don't know REST), REST, RSS/Atom feeds, Atom Publishing Protocol, APIs.  And access the data through HTTP and HTTPs.  Suggested solution: Define microformats to describe each type of service.  Define a simple way to inform Builders of the existence of services and define a simple way for Enablers to request service information from central repositories.

At a certain point the notion of having a market of services that people could purchase on a granular billable basis came up.  I suggested to start from the opposite side, encouraging the commons.  Or more specifically this group could go to Creative Commons and try to host a directory of CC licensed APIs.  We also discussed availability, and I pointed out that in other industries we would start with conversations about standardizing SLAs.

Paul Raymond who is in the commercial division of AccuWeather, which provides weather info to 106 million Americans each day.  Their primary asset is their brand, they copyright much of their material and want to syndicate under control.  Web scraping creates new business models for them, even if it is just linking back.  They co-brand over 20k affiliate sites, provide a number of mapping web services and work with other mapping services, have a number of widgets and more.   Other business models: subscription and fixed pricing that is secure and authenticated -- or CPM-based control content, campaign, source and cost.  Their basic approach is let people hack upon it, but largely encourage marketing attribution in return.

I had to leave before the afternoon sessions by SnapLogic, Jeff Nolan, Reuters and Mashery.  We still haven't really talked about security, or the marketing thereof, which is the elephant in the room. It will be interesting to see if a common roadmap emerges.

A guy from the EPA was asked about politicizing of data.  He shared how there is a law where you can dispute the bias or accuracy of data and gain resolution.  He told the story of how a US Satellite over the north pole started picking up anomalies in ozone levels and scientists believed it was impossible so they normalized the data syndicated.  It wasn't until British scientists used balloons to find unreported change that they opened up the logs and corrected the feed. 

Data is political and when you have so much change it is the politics, as much as the technology, that needs to be worked out by the community.

UPDATE: More coverage from Jeff Nolan, SnapLogic, and otherwise I'm disappointed more participants aren't blogging this.