Erin Knight and I have been working on a set of communications assets aimed at explaining the value of Mozilla and P2PU’s Open Badges project for a broad audience.
We’ve just completed an updated set of drafts for:
A one page overview. Explaining the project in simple terms.
A simple napkin sketch, explaining the experience from the user’s point of view.
Five one-page learner stories. With examples of how badges can help people in the real world.
A one-page technology overview, including a tech diagram.
A PDF version of Erin’s badge paper. The original source for all of this material.
These assets will need to be vetted and further improved, but combined we’re hoping they provide a pretty good overview of the project. All of them are available for download in PDF format here. Or check out the Open Badges project wiki.
Here’s some flat image versions to give a sense of what’s contained in the package:
That’s the title of an extremely thoughtful postEugene Eric Kim was kind enough to share with me today. It’s part of a dialogue that began after my own “How to Work Open” post a couple weeks back.
Writing about the Packard Foundation‘s experiment in sharing knowledge through an open, public wiki for the past year (they call it a “see through filing cabinet”), Kim writes:
So what has the impact been? I know that they’re constantly asking themselves that question… because they’re doing that openly as well.
I also know that, generally, one of the big hopes / expectations around doing something like this is that others will join in as well. I think this is reasonable, but I also think it’s overstated in terms of value.
Of greater value, in my opinion, is the ability to do what [the Packard Foundation] did. You want to know what we learned? You want to know what we’re thinking? Easy. Go here. Doing your knowledge work openly allows you to reuse this knowledge in useful ways — repackage it, redistribute it, refactor it, with the ongoing possibility of others joining in as well. Beautiful.
I think that nails it. It’s a breakthrough moment I’m struggling to share with other organizations curious about working open and its real, no-b.s. value.
It’s true we work open to enable participation from others. But it’s also true that even if our goals were far more modest, even if we were simply seeking to decrease the collaboration cost, stress, overflowing inboxes, and general noise and cognitive static involved in daily work, we’d still work open. To collaborate more effectively and creatively with our co-workers across the room or down the hall. Let alone with those beyond the walls of the organization.
Or as Mark Surman put it recently: “the best internal communication is public communication.”
Eugene also writes about some work he’s currently doing with the leadership team at a Fortune 500 company around more effective global collaboration:
Most consultancies do this sort of thing in a very closed way: Talk to a bunch of people, gather some data, then go off in a corner and think really hard by yourselves until you come up with something smart to say.
We don’t work this way. For us, participation isn’t constrained to “input” and “feedback.” It’s about learning collectively, which leads to activation. That means opening up our process, sharing our artifacts, and allowing the client to see our thought process with all of its inevitable warts and missteps.
He hastens to add that its not automatic or magic, or as simple as flipping a switch from closed to open. Like everything, it depends on how well you do it:
It’s a tricky balance. Our client is busy. We can’t expect them to sit in on all of our meetings or to look at everything we’re looking at. So we’re strategic about designing our process to maximize the time we have with them. But, we also create opportunities for emergence by making our artifacts available and by inviting (but not requiring) participation whenever possible.
I sometimes question whether trying to work open — and encouraging others to take the leap as well — is really worth it. Whether it’s all just a nice idea that doesn’t actually work very well in reality. Or simply too difficult for traditional organizations to embrace. Do the benefits actually outweigh the effort and cost at the end of the day?
Experiences like Eugene’s give me confidence that there really is significant “there there.” And that smart people around the world are conducting similar experiments with similar results. It’s heartening, and proof positive that Mozilla’s way of working is something worth learning, evolving and sharing with others.