Borders, Spaces, and Places
One big problem for collaboration has been too many borders - technical or cultural - creating silos of information for no good reason - and many bad ones. There's also a big problem if you don't have a good way to mark borders that enable collaboration where there's a natural expectation of privacy.
For example - if you work for a law firm there's a reasonable - and legal - expectation that only the client and members of the firm have access to the collaborative space reserved for work with each specific client. But a member of the firm may be working with many different clients at the same time, and need to keep on top of many external engagements - and a host of internal engagements that are shared within the law firm but invisible to all clients.
This "hub and spoke" collaboration pattern is common for business. For example, if your company builds complex, customized products it's valuable to have separate collaboration spaces that connect each customer and your internal product development, sales and marketing team. Everyone on the inside has a bird's eye view across all customer specific work. Each customer sees a dedicated collaboration space for private working communication - and can also read or participate in spaces that you intentionally open to all your customers or the public Web.
Similarly, most businesses work with a network of external suppliers, resellers, technology or business partners and external service providers - including your law firm, accountants, PR firm and others. If you're interested in keeping touch with each of these external stakeholders and enabling your employees to have a birds eye view of what's happening across your entire business the hub and spoke pattern is also appropriate.
Your business may also have good reason to set up spaces for private collaboration that's limited to certain groups (e.g. your Board of Directors) or for specific purposes (e.g. your HR Department privately helping employees resolve medical claim issues).
If your Enterprise 2.0 software doesn't support these patterns of collaboration with a user model that's simple and secure you're limited to internal or public collaboration. This limited form of collaboration is useful but doesn't enable employees in the hub to stay informed or participate in many of most valuable relationships where your business meets the external world. John Hagel and John Seely Brown call this collaboration at the edge:
The point is that by being able to listen deeply and participate on the edge, you can pick up things before anybody else picks them up, and you can use that to accelerate your own capability building. This implies that it is not just corporate training that is important but rather rich participation with partners who are at the edge as well. One of the questions we ask ourselves is, how do you learn as much from a partner as you learn from creating something yourself. This puts a new spin on why distributed collaboration around the world might be critical in creating this sustainable edge. - John Seely Brown Can Your Firm Develop a Sustainable Edge? Knowledge@Wharton
In his Fast Forward 08 Keynote What's Most Important for Success with Enterprise 2.0? Prof Andrew McAfee said that borders are needed in order to use Enterprise 2.0 principals for many valuable business purposes, but it's very important that "Borders seem appropriate to users."
I agree and suggest adding a follow-on principal: "Borders should seem transparent to those with permission to cross them."
For Traction TeamPage this means:
- All content and relevant context are indexed for search, but the search engine delivers the subset of results that the person making the request can read.
- Tag clouds and drill-down navigation present the tags and drill-down paths derived from what that person can read.
- Traction's Dashboard views roll-up content from many spaces based on tag, content or other criteria defined by Section widgets, and automatically shows the subset of content which that person can read.
- RSS feeds, email, IM notifications and cross-reference lists automatically reflect the content and cross references which that person can read.
For example, if you're an employee at the center of a "hub and spoke" collaboration pattern, when you navigate, search or link information, the borders separating different customer spaces and internal spaces you can read become transparent for collaboration.
You can still use the names of spaces created for particular customers to focus your attention on a particular issue or collection of content, but you effectively see one big wiki / weblog. Borders help you visualize the business context and intended audience.
If a customer logs in to your TeamPage server, they see only the rolled-up content, search results, tags, feeds, and space names that they have permission to read. The content - and existence - of private collaboration spaces of other customers or reserved for internal use are hidden.
Traction TeamPage even extends commenting and inline discussion to work transparently across borders.
Let's say a customer posts a page of product suggestions in their own space (Traction calls this a project space). Everyone in your internal team can read and comment on any paragraph in the customer's suggestion page, and by default their comments will also be posted to the customer's project - and immediately become visible to the customer.
Let's say Sue is an engineer working on a related project. She reads the third paragraph of the customer's suggestion page and wants to open an internal discussion comparing confidential feedback on that topic from other customers. She posts a comment on the third paragraph, but instead of posting the comment to the customer's project, Sue posts her comment to an internal engineering project.
The internal engineering discussion is then anchored to the third paragraph of the customer's original suggestion page, but the thread is invisible to all but internal team members who have permission to read the engineering project. After internal discussion, Sue may decide to post a summary comment back to the customer (or add a tag which makes a specific engineering comment visible).
Six months later, Alan in Marketing is asked why particular approach was chosen in designing the new feature. His search finds the internal discussion in the context of the original customer suggestion. He can easily follow the linked trail for background, contact Sue, or add a clarifying note.
This multiple space model is much more than just an administrative convenience that makes it easy to deploy one TeamPage server for different groups within an enterprise. Not that there's anything wrong with administrative convenience!
It starts down a road to creating places which groups use for agreed social purposes - just as the rooms and spaces in a well designed building make it easy to hold conversations in different contexts without a lot of conscious thought. You talk differently in the space near your desk, in a conference room being used for a customer meeting, in a public event held in an auditorium, or in a huddle space for the team you work with every day.
Just as a good architect knows how the to use the affordances and relationships of physical spaces to help cue behavior, architects of social software should aim to use software affordances to make socializing in the neighborhood, workplace, and commons as natural as possible. I think this will require cues to signal and differentiate as well as connect places. The goal should be to help people read context and act comfortably in different places whose norms they can quickly learn, understand and trust. As Harrison and Dourish write:
"A conference hall and a theatre share many similar spatial features (such as lighting and orientation); and yet we rarely sing or dance when presenting conference papers, and to do so would be regarded as at least slightly odd (or would need to be explained). We wouldn't describe this behaviour as 'out of space'; but it would most certainly be 'out of place' and this feeling is so strong that we might try quite hard to interpret a song or a dance as part of a presentation, if faced with it suddenly. It is a sense of place, not space, which makes it appropriate to dance at a Grateful Dead concert, but not at a Cambridge college high table; to be naked in the bedroom, but not in the street; and to sit at our windows, peering out, rather than at other people's windows, peering in. Place, not space, frames appropriate behaviour." - Re-Place-ing Space: The Roles of Place and Space in Collaborative Systems
With the TeamPage model, if you want to hold a conversation with a specific customer, post it to that customers private collaboration space. If you want to address a broader group, use a space a space with broader participation and a less formal purpose, while retaining the the ability to have a more private discussions (or take strictly personal notes) in the context of a more public place.
See Re-Place-ing Space: The Roles of Place and Space in Collaborative Systems by Steve Harrison (Xerox PARC) and Paul Dourish (EuroPARC) for interesting thoughts on where this could lead.
See Michael Sampson's Currents: "TeamPage - the One System to Rule It All" for an independent expert's opinion of TeamPage's capabilities for cross-workspace collaboration.
I18N ERROR: @tsiskin#footer_RSS_Feed