When Shane Atchison took the job of CEO at Possible Worldwide in April, he needed a way to get in sync with 1,100 people across 32 offices. Possible, a division of the advertising giant WPP, then acquired three small companies in four months, making the issue even more pressing. How do you build a sense of community when you’ve got people from Poland and Budapest and Moscow connecting with people in Cincinnati or Seattle? “You can’t fly everyone around and say, let’s be friends,” says Atchison.
The corporate intranet was okay for sharing templates and forms but terrible for sharing knowledge. Atchison figured he could kill both problems with a social network. Not Facebook, not LinkedIn, not Tumblr or National Field, but a brand new one, built specifically for them. “We’re in the business of creating social communities and connecting the relationship between brand and customer, so I thought it would be fairly hypocritical of us to go license Yammer,” Atchison says.
“If I can get a creative director to post a challenge to any employee in the world, and any of them can say ‘I have an idea,’ and in 24 hours we can all vote on which ones to develop–that’s what we want,” says Atchison. “That builds culture and connectivity. Not going through eight people to get it done.”
Possible manages social strategy and community for big brands like Procter & Gamble, Nokia, Microsoft, Michael Kors, and the BBC, so Atchison figured this was his shot to prove Possible could eat its own dog food. “For me, it was a leapfrog opportunity. All the agencies have been playing ‘me too’ around social and mobile. But the real question is, what are you doing inside the agency?” he says.
They formed a skunkworks in the C-suite to get an internal social network up and running as quickly as possible. Atchison gave ownership of the operation to Jonathan McVey, the company’s chief creative officer, and holed him up in a “safe harbor” office in Seattle where he wouldn’t have access to client work. The core team included Atchison, McVey, two developers, and two designers who were all locked in a room for eight weeks.
“The safe harbor was crucial,” says Atchison. “We had to get this thing out there fast, instead of spending six months and maybe getting it right, maybe not. We figured, the network itself is what people will use to ask for changes to whatever we build.”
￼They started with the basics. “When we initially started talking about it, the network was a library to share all documents internally,” says McVey, the chief creative officer. The early meetings were spitballing sessions: What else should the network achieve? Can they actually build this it right way? “It felt like a product startup company.”
They didn’t base the design on any other network. “I wasn’t even aware of Yammer at the time. We were trying to build something that would be engaging to people, and something that would make us look as good as possible,” says McVey.
But how? He knew employees would be curious about each other. “The Seattle office, the London office–what are those people like? We realized there’s a social process to it. That’s when we knew that what we were creating was a social network–it was an aha moment. We thought, the intranet is a real chore. How can we make this more playful?”
The team met every day in a small room to refine their plans. Builds of the initial web app product would get released by the developers in the middle of the night, and for two months the team iterated, not knowing if employees would love their new network or treat it as just another corporate kluge.
Normally, you’d widely validate an idea like this with employees before you began designing anything, let alone building the product. But as a digital agency, the top-secret approach was necessary.
“For us, secrecy at the onset gave us the autonomy to do something without distraction,” says Jamie Liese, the lead developer in the skunkworks. “Getting the product out the door was more important than making it perfect or having it solve every problem off the bat. We limited our final decision makers to Shane and Jon, with input from our CIO, and that allowed us to stay laser-focused on our initial vision, and to move quickly.”
The problem with transparency at the beginning, Liese says, would be the flood of ideas. “All of our employees are incredibly smart. They think about digital all day, every day. But if we had involved all of them and taken every suggestion into account, we’d still be in the middle of building the most badass social network of all time. But we didn’t need the most badass social network. We just needed one that worked.”
The team named it CoLab. Once the basic web app had congealed, they announced it to the company. Employees immediately suggested features and made requests, and the skunkworks team began listening.
The timing of the internal launch would be crucial to enfranchising employees. “When employees feel a sense of ownership, they’re more likely to contribute and participate,” says Liese. Being a social network, contribution was the point. “We wanted CoLab to feel like an opportunity and a community, not a mandate.” That meant revealing the product early enough that some of their ideas could actually be built in–but not so early that the product would appear formless.
Interface and the user experience would be incredibly valuable to how CoLab was received. “The intranet was designed with an IT mindset, so it was clunky,” says McVey. “We wanted to make it clear CoLab was designed for people, we made it as usable as we could.”
Leise says the UX was one reason they opted to build their own network. “When we looked at other tools in the market, we saw a lot of options that were technically sound but visually lackluster: They had no personality or they felt overly complicated to use,” he explains. “Our goal in designing CoLab was to keep it simple, visual, and playful.”
Liese saw a few common things that the employees were trying to do over email and file servers, which he knew could be automated within the network:
- Learn about each other and the offices
- Share ideas, dialogue, and stories
- Find (and share) brand materials or case studies
From these needs came three core features:
- People: find anyone, and connect with them.
- Library: a database of assets which would replace the old intranet, so people could easily find materials.
- Social: a kind of expertise network that could enable “collective intelligence.”
Since different offices and roles rely on different devices, CoLab would be multi-platform from the start. Instead of trying to achieve one common experience across platforms the way, say, Twitter’s apps attempt to do, Liese and the other developers and designers let the devices themselves dictate the UI paradigms. “We wanted to consider the purpose and the most important features for each device,” he says.
For example, the iPad version was designed to be more of a showpiece than the other apps; something they could hand to a client during a meeting as evidence of their own internal innovation. “So it fits that the iPad version has a few extra bells and whistles, like the bubbles that emanate up in the People section,” Liese says. “They move with the gravity of the iPad and expand at your touch.”
The iPhone version lacks that feature, only needing to accommodate the basics. “We considered how a person would use CoLab on their phone: mostly to look up contact information, update a status, or consume content.” The web platform is also cleaner and quicker to digest than the iPad version.
When the team finally launched the first version this summer, it was to a limited audience of a few hundred employees. After two weeks of QA, they opened the network up to the rest of the company. Adoption soared. Within three days, 75% of the employees had signed up.
But it’s what happened immediately after launch that surprised the skunkworks team. (Below, an early wireframe.)
“The first API is documented, the service level calls are there,” says Liese. Engineers from within the company began reaching out to the developers who built the service layers, asking them to put features or other items into the development backlog.
Rather than continue to be top-down, the development process became ad hoc. A team in Costa Rica surprised everyone by building their own app on the platform–without asking permission or notifying anyone. “We have this hotshit team there that runs Android development, and they decided they wanted an Android version. They talked to one of the developers on the CoLab project and on their own time–not billable, not requested by managers–they built it,” says Atchison. “Then I see a CoLab post last week that there was an Android version ready.”
In fact, internal development exploded. “We built the three main parts,” says McVey, “and it took on a life of its own. Now we have apps for web, iOS, Windows Phone, Windows 8, Android, and Xbox Kinect.”
The three main parts–library, people directory, and social–wound up becoming four, with the “social” component comprising two separate features. Now, the four main features of CoLab look like this:
- Pulse (a curated home page featuring internal posts and status updates)
- Perspectives (a full social feed of posts and status updates)
- People (a company directory complete with social profiles)
- Library (a knowledge sharing network)
What they had before was “built in the late ’90s and looks like it,” says Liese. “There’s a company directory, but it’s not interactive. There’s a best practices wiki, but it’s not up to date because no one uses it. The design is barebones; everything that was added to this over the years was just tacked on. You can download forms and templates. There are also ‘resource request forms,’ but ugh, they’re horrible.” Here’s a breakdown of each feature.
The Pulse page is a curated landing page that highlights the best employee posts and status updates. It shows the top 25 items, which users can scroll through five at a time.
There are categories for posts here: industry, creative, tech, and culture, and you can sort posts chronologically by date of last action.
There’s also a map that tracks the location of employees, a feature which is opt-in. (It’s not a manual check-in, just an automatic location pin from wherever you launched the application last.)
“Yes, our employees can be tracked!” says Atchison. “We thought, this will be a real mess. What employee wants to be tracked? But there’s the opportunity to say, Hey! You’re in Berlin, you should go meet our good friend, or this client. And the fact is, people opt into it!”
Why have a curated homepage? One reason is the 32 global offices. “Because we had people posting from several different time zones, posts were getting buried very quickly,” says Liese. “If something was generating a lot of conversation, five or six people could come in, post, and push that popular item off the front page,” says Liese.
A mix of human and automated curation makes up the Pulse page. A human team maintains a calendar for the top “featured” spot, and employees can request to have their posts highlighted there. An algorithm that looks at the number of views, likes, and comments and weighs them over a three-to four-day period to determine “top” content. Human curators can also promote posts to the News section of Pulse, and every week they compile an email with popular news and staff updates, plus an employee poll, and a list of new items added to the library.
Perspectives is the entire feed on infinite scroll. There are filter options: You can sort by posts, status updates, and category of content. CoLab also imports Twitter feeds here, but there’s currently no real way to have a conversation here, says Liese, so the team is adding commenting to items in the feed.
So what’s the difference between a status update and a post? “The status update is a perfect place to advertise for help on a project in 140 characters,” says Liese. “You can eliminate that the email problem where you’re contacting a dozen different managers asking who they have available. Here, you can blast it out to huge audiences.”
A “post” is more in the style of blogging, with a drafts editor, title field, article source link, post text, category, optional video URL, and embedded images. The system adds an image to every post if the user opts not to.
“We had a big debate internally about status,” says Atchison. “Does someone have a ‘status’ within the company? We figured, if people do it frequently, and they comment on each other’s status, it’ll be a sign of culture. You can take a friendly jab at someone–giving each other a little shit. I think the fact that people are willing to manage yet another status besides Facebook is proof they like it.”
The People feature is a full directory, sortable by department or office location. Employees can also organize into groups, find existing groups and add themselves as members. On their profiles, Possible employees have space for a biographical summary, recent updates, contact info, and social media links. There’s also an archive of that user’s posts.
Liese says they’re changing the algorithms that sort People to list super-users at the top of the page to incentivize engagement. They also have an item in the development backlog to investigate adding an email-like direct messaging feature to CoLab. “It’s a highly requested feature,” says Liese.
Liese says he’s also adding a field for a CV on employee profile pages, listing projects an employee has worked on, areas of expertise, and background. Also on the way is a more powerful search feature for finding people across the network by these characteristics. “We’re considering putting up a roadblock to login so that people add all this information, since it’s so crucial to resource-sharing,” he says. “It’s one of the highest requested features from the executive levels.”
Here, the company stores assets, brand materials, biz dev resources, ideas, performance marketing materials, policies, project work, training materials, and information about CoLab itself. “What’s a tablet,” says Atchison, “if not a beautiful flash drive? We can push all this information directly to people instead of storing this on a file server.” With one fell swoop, this feature deprecated the intranet.
So who benefits most from turning all this information loose a social network? The resourcing team, more than anyone, says Liese. “They actually have an Excel pivot table with everyone’s skills and billable hours, which they use it to match resources manually. But now that we have this big global network, managers can try to do it themselves first, and if they have trouble they can call the resource team to handle it over the phone. We use the network to make the whole process quicker.”
Sign up for the Fast Company daily Newsletter.