Chapter 14

Engaging External Collaborators

In This Chapter

Recognizing how external collaboration is different

Setting ground rules for external sharing

Providing for proper security

Engaging partners and customers

Start to demonstrate success with internal social collaboration, and very soon there will come a day when some piece of collaborative work needs to extend outside the organization. Maybe your employees need to collaborate with their counterparts at a distribution partner, manufacturing partner, or ad agency on the launch of a new product. Maybe you want to run an online focus group discussion with a dozen of your most loyal customers, connecting them with your engineering and product development groups to brainstorm about new products within a secure workspace.

This is different from operating a public social community, which is more the territory covered in Community Management For Dummies and Social CRM For Dummies. To create a public community, you may take essentially the same platform Jive provides for internal use and set it up on a public website and allow anyone to sign up by filling out a short registration form. Or you can set it up as an invitation-only/registration-approval-required community for business partners, which only the employees of certain companies are allowed to join.

But even organizations that use Jive internally typically run public communities on completely separate instances of the software. Ditto for IBM Connections and other social platforms that support both internal and external communities.

This chapter is about inviting selected external users into your internal social network, providing them with just enough access to engage in a specific collaboration activity.

Recognizing How External Collaboration Is Different

You may have external users whom you treat essentially the same as employees — say, freelancers, contractors, and consultants whom you trust enough to give full access to your internal social network. Sure, you may have them sign their lives away on a nondisclosure agreement (NDA) form before you give them passwords, but you consider them no more likely to breach your trust than your regular employees.

Don’t give out accounts like candy, however. If you let too many external users roam the digital hallways of your business, eventually, you will regret it.

There are more cases where you want to invite external users in for a specific purpose, without giving them access to the CEO’s blog and the latest sales projections. Even if you deem a few freelancers or contractors trustworthy enough to treat like employees, there will probably be dozens of others you would prefer to keep on a short leash. You have a need to collaborate with them, but you pulled them in to work on a specific project and have no particular way of knowing how trustworthy they are. Instead of giving each participant the equivalent of an employee account on the social network, you provide each external user with a login that allows that participant access to a specific collaboration group or workspace. When they sign in, they see only the content in the groups they have access to.

For the external user, this is more like being invited into a meeting in a corporate office where a security escort takes you directly to a specific conference room and escorts you wherever you go for the duration of your stay.

In business today, it’s common for companies to be partners in one context and competitors in another. So you may want to collaborate intensively on the development of one product, while keeping your partner in the dark on another.

In a customer focus group scenario, you might invite consumers to give feedback to your products group on proposed products or your marketing group on concepts for advertising campaigns. This information is confidential, and you make them sign an NDA that provides you with some legal cover, but you have no deep reason to trust them. You definitely don’t want them to have access to any information beyond what you specifically decided to share with them.

When you create a group with mixed internal and external users, make sure employees know what they can and can’t share in that group. Generally, social collaboration platforms try to make the external context very obvious. Jive features a big orange Externally Accessible label at the top of every page for an external group (as shown in Figure 14-1), and documents associated with the group are similarly flagged. On Yammer, the whole color scheme changes when you move from an internal network to an external network. This, in essence, is the Here, there be dragons warning on the map of a collaboration network to make employees think twice about what they share there.

Figure 14-1: External groups should be labeled so it is clear that content will be accessible to outsiders.

And you may want to think twice about which employees have the judgment necessary to make those calls. Perhaps for that reason, Jive dictates that externally accessible groups must also be configured as private or secret, meaning that employees can join them only if explicitly invited by the group administrator. That also means content within those groups is invisible to nonmembers, including employees.

Yammer supports a similar model but also a more informal one in which all employees can join without an invite: a check box option. Yammer external networks can also be configured, optionally, so any member can invite other members to join, just by providing an e-mail address. Figure 14-2 shows external network creation in Yammer. As of this writing, Yammer was also working on a way of allowing external sharing of individual conversations or documents without the overhead of creating an external network. This reflects Yammer’s traditional emphasis on flexibility and agility over tight administrative control.

Figure 14-2: Creating an external network in Yammer.

Setting Ground Rules for External Sharing

The group owner should make plain to all participants who the external users are and whether the composition of the group is fixed or changeable. For instance, a private group created for the collaboration between the finance department and its auditors may exist specifically for sharing all sorts of documents and details related to the company’s finances, whereas sharing that data with any other group of external users would be completely inappropriate.

External networks require clear ground rules to prevent misunderstandings about what should and should not be shared with external participants.

The same acceptable use policy for corporate systems that covers what sort of information employees should not e-mail to an external collaborator or post on an external website can be a starting point. Given the many types of participants who may be engaged through an external collaboration group, each group should also spell out its own rules. For consistency, consider defining a few model policies for different classes of external users, which can be tweaked as necessary for different business scenarios.

Suppose you create an external group for collaboration with a business partner on joint development of a new product. Of necessity, group members would be free to discuss all sorts of confidential matters related to the development of that specific product, but not outside of that scope. For example, if you also have a business relationship with that partner’s competitors, it would be inappropriate to share confidential information about that other company.

Other examples of information that would be out of bounds for discussion in an external group would include:

Financials for a public company that have not been publicly released or other information that can materially affect the stock price

References to internal strategy discussions or content quoted from a CEO blog post intended for internal consumption only

Jokes or cynical discussion about real or perceived dysfunction in company business practices

Providing for Proper Security

You want your collaboration network to be secure to begin with, but engaging external collaborators is bound to prompt a re-examination of the security characteristics of the platform.

When you invite members into the network but try to keep them inside a box, the next logical question is whether they can escape that box. If you were physically inviting them into your corporate office, the parallel question would be how easy it would be for them to sneak out of the conference room and give themselves an unscheduled tour of the research and development department. These people are inside your collaboration network, with only the logical security model of the software preventing them from accessing things you don’t want them to access. What are the odds they could hack their way past those restrictions?

Information security specialists call this an escalation of privileges attack, in which users who start with limited privileges give themselves a promotion — in this case, from outsider to insider, or even to system administrator.

The relevant questions are

How likely is it that they would try?

If they were to try, how likely is it that they would succeed?

If they were to succeed, how likely is it that they would be caught?

You can minimize the first risk by screening external users more carefully or inviting only people you already trust. The other two boil down to requiring an assessment of your confidence in the security competency of your software vendor or cloud operator. Even in the absence of a hack, a software bug or data center operations error can expose confidential information more widely than expected. Such problems have cropped up periodically with cloud collaboration applications like Google Drive and Dropbox. You wouldn’t have chosen your collaboration network vendor in the first place if you didn’t believe it took security seriously, so maybe you will be convinced that the probability is very low — but it’s not zero.

As with most information security decisions in the web era, if the risk is worth taking, estimate the risk and do whatever you can to minimize it.

Engaging Customers

Inviting customers into an external group attached to your internal social network can be a way of forming intimate connections by providing them with exclusive access. This is not the way to provide mass market, self-service customer communities. However, if your business works with a relatively small number of large customers, creating an external network for your work with each of them can make perfect sense and be the only social customer service solution you need. Or, you may provide a publicly accessible community for your broad customer base but invite a select few into a deeper working relationship.

Make sure all employees involved understand to treat customers as honored guests, displaying their absolute best manners, while also understanding the limits on what information can be shared with them.

When you invite customers into an external group on your collaboration network, you are inviting them into a private space where none of your discussions are going to wind up in a Google search.

Uses of an external group for customers include

The group dedicated to your work with a single large customer: Consulting firms and engineering organizations may use this structure to share project plans and respond to day-to-day issues.

The elite customer group: These representatives from your biggest customers want to be able to ask questions in private and work directly with some of your top people. Support staff may still play a role, as may peer-to-peer interaction between customers, but at a more exclusive level.

The focus group: These members are not necessarily elite, but you do want to make them feel special for helping you formulate product and marketing plans.

Bringing customers into an external group also changes the experience for the employees participating in those groups, who will be connecting and collaborating with customers in the same environment they use for internal collaboration. If the company operates a public social community, some employees may have been in the habit of putting in cameos there: for example, software engineers dropping by to answer questions that the technical support staff may not be able to address. Now, instead of signing into a separate social community for customers, they have customers coming to them.

Engaging Partners

Like customer communities, partner communities are often supported on a separate social collaboration platform from the one used internally, where both are in play. Partner communities are typically more private, with their membership restricted to firms that have an existing business relationship with your organization. An example would be a reseller network sponsored by an electronics manufacturer.

If you have thousands of partner relationships to manage, using a dedicated social platform for that purpose is probably the better choice.

Reasons for extending access to your internal collaboration network to partners include

You don’t have (and don’t think you need) a separate platform for partner collaboration, but you do have certain partners you want to be able to work with more closely.

You have a major project (or series of major projects) requiring intense collaboration between your engineering and marketing people and those of your partner.

Some collaborative work requires more privacy than is afforded by your existing partner collaboration platform.

You require access to collaboration tools that are present on your internal collaboration network but not your existing partner platform.