Michael Idinopulos

http://michaeli.typepad.com/

Michael Idinopulos is Vice President of Professional Services and Customer Success at Socialtext. He leads the Customer Success Team which is responsible for all aspects of post-sale customer delivery, including technology and customized programs to deliver training, adoption, and organizational change. Before joining Socialtext, Idinopulos was a consultant and global Director of Knowledge Technology with McKinsey & Company where he led the creation of McKipedia, one of the earliest large-scale enterprise wikis. He holds a Ph.D. in philosophy from U.C. Berkeley. His recent publications include "Do You Know Who Your Experts Are?" in Knowledge Management and Organizational Learning (Oxford University Press). Idinopulos lives in Philadelphia and blogs at http://michaeli.typepad.com/

Enterprise 2.0

Enterprise 2.0: It’s not just for knowledge workers anymore

By Michael Idinopulos | December 9, 2011, 4:51 pm | 0 Comments

One of the familiar refrains in the halls of Enterprise 2.0 is that social software’s primary value is for knowledge workers or knowledge-intensive industries. This now gets repeated so often that most people don’t even question its truth.

Like so many orthodoxies, this one’s due for a re-think.

The whole notion of a knowledge worker or a knowledge industry is confused. It suggests that there’s a certain class of workers who problem-solve and innovate for a living, and another class of workers that don’t. But that’s just not the case. An assembly-line worker who thinks about how to reduce the failure rate of brake systems rolling off the assembly line is a knowledge worker, at least in my book. A consultant who reads bullet points from a deck that someone else has written is not exactly doing knowledge work. Knowledge is a characteristic of how the work gets done, not of the work itself.

If you don’t believe me, just compare the cappuccino you get at a world-class cafe like Lovers and Madmen in Philadelphia to what they sling down the street at McDonald’s. Both were made by baristas, but only one was made by a knowledge worker.

There is, however, a fundamental difference between activities that are more routinized and those which are more bespoke. Doing warehouse pick-and-pack for the latest James Patterson thriller is a routinized activity. Sourcing a clean copy of Russell and Whitehead’s 3-volume Principia Mathematica is bespoke. Soliciting $10 donations over the phone is routinized; soliciting $5 million donations is bespoke. Building the prototype of a new car model is bespoke; building the 100,000th instance of that same car is routinized.

Routinized and bespoke activities require different types of supporting tools. Routinized activities require process tools to run the activity at scale as efficiently as possible, with as little variation as possible. Bespoke activities require a toolkit, a basket of techniques, tools, tips, tricks, and experts upon which a practitioner can draw to meet the needs of the moment.

In the early days of Enterprise 2.0 (mid-2000s) enterprise social software was good at toolkit-style functionality. Blogs and wikis gave people useful frameworks and reference materials for doing bespoke tasks. But there wasn’t much functionality for businesses that run a lot of routinized process.

These early tools appealed to high-end consultancies, law firms, PR agencies, and tech startups, which lean towards more bespoke activities. I suspect that’s where people first got the idea that enterprise social software was for “knowledge workers.”

But social software has changed, and changed fast. In the past year, business has started to embrace social software for more routinized processes as well.

The combination of activity streams, robust APIs, and mobile means that social software now integrates with–and improves–industrial-strength process. In London, for example, Southeastern Railway is using social software to automatically alert railway staff when trains are delayed–and to enable those staff to collaborate in real time to get the trains back on track (sorry…couldn’t resist the pun). In Ohio, Industrial Perfection Mold and Machine uses social software on shop floor iPads to regulate and improve the manufacturing process.

Which type of activity should your business try to optimize? My answer: Both.

Every business runs on a combination of routinized and bespoke activities. Running the trains in and out of London may routinized, but when a train breaks down the work becomes very bespoke. Tier 1 customer support is routinized; Tier 2-3 customer support is bespoke.

What businesses really need is an integrated combination of the two: Stream-based tools for routinized activity and wiki-based toolkits for the bespoke stuff.

To borrow a line from the Anita Bryant of my youth: “Social software. It’s not just for knowledge workers anymore.”

Turning Serendipity into Probability

By Michael Idinopulos | December 1, 2011, 4:44 pm | 7 Comments

I’m going to take a swipe at another cherished social software notion: Serendipity. We should ban that word from the social software lexicon. It’s misleading and it makes enterprise social software seem about as relevant to the business as the plastic mistletoe hanging at the office Holiday party: Something amazing could happen, but it probably won’t.

The idea behind serendipity is that social software enables colleagues who have shared or complementary interests and expertise to discover each other and collaborate. It’s serendipitous because, hey, who knew that Theresa in Tucscon was a certified blackbelt in Six Sigma, the very methodology that Victor is trying to implement in Virginia?

It’s true that social software teases out those kinds of hidden connections. But when social software is implemented properly, there’s nothing serendipitous about it.

Imagine Victor in Virginia works for a 10,000-employee defense contractor that has successfully implemented an enterprise socials software tool as its social intranet. If he goes to that intranet and asks who can help him with a Six Sigma implementation, he is almost guaranteed to get five, ten, maybe twenty responses. While Victor may not know who will respond, he can be reasonably confident that someone will. So from Victor’s standpoint, there’s a high probability that asking the question will get the kind of responses he’s looking for.

It’s simple mathematics. Consider the following statistical fact. For any two people, there is a very low probability (roughly 1/365) that they share the same birthday. And when two people discover they have the same birthday, it’s serendipity. But if you fill a room with just 57 people selected at random, there’s a 99% chance that some two people in that room will share the same birthday. That’s probability.

Victor and Theresa may be surprised to discover that they share an interest in six sigma. That’s serendipitous. But we should not be at all surprised that Victor got the response he needed. The odds were quite high. From the moment Victor posted his question, he was almost guaranteed to get a response. That’s probability.

The point is that social software doesn’t enable serendipity; it transforms serendipity into probability. Serendipity is when Victor happens to sit next to Theresa on the red-eye to London and discovers that they’re both interested in Six Sigma. It’s a random event, neither reliable, nor repeatable, nor scalable.

But when Theresa is first to respond to Victor’s company-wide post looking for Six Sigma expertise, that’s probability. It worked, we knew it would work, and the fact that it worked this time makes it even more likely that it will work next time.

What’s that you say? My distinction between serendipity and probability is mere semantics? Maybe, but words matter. Companies and their leaders only take social software seriously when they see it as part of mainstream business process. Mainstream business process is all about repeatability and scalability.

Imagine the response you’ll get if you tell your CEO, “We’re implementing a system to make serendipitous connections among staff members.” I can hear your CEO yawning from here.

Now imagine telling your CEO, “We’re implementing a system to ensure that all staff get the help they need, when they need it, from knowledgable colleagues across the company.” That CEO conversation just got a whole lot more interesting.

So let’s get serious about making business process social, and leave serendipity to the mistletoe.

Social Training for Social Software

By Michael Idinopulos | November 1, 2011, 4:00 pm | 4 Comments

Socialtext active usage is way, way up–over 300% so far this year. There are many reasons for the growth, but in this post I’ll focus on one specific factor: our training approach.

Some time ago, I had one of those forehead-smacking “Ah-Hah” moments about the way we were trying to train customers to use Socialtext: Traditional IT training doesn’t work for social software. Social software requires social training.

When I talk about social training, I’m not talking about charm school, or teaching your collie how to play nice with the local poodles. I’m talking about a unique method of teaching employees to use social software at work.

In traditional training, you interact with technology. In social training, you interact with other people by means of technology. The technology becomes a medium, like a telephone or a videoconference room, rather than the object of your interaction, like an MRI machine or a Boeing 777.

Suppose you were trying to train someone who had never seen a telephone before. You could teach them how to dial, how to put someone on hold, how to work the mute button. But until they actually make a call and speak to another human being, they won’t get the point. And that’s exactly what happens when you use traditional training methods for social tools: they learn how to push the buttons, but they don’t get the point.

Embracing a social approach for Socialtext training caused us to radically rethink the way we introduce new users to the system. In a Socialtext training, you don’t get told all the features of the system. You don’t walk through hypothetical use cases. You don’t get to sit back and watch a trainer walk through a system demo.

Instead, you interact with your colleagues, in real time, using Socialtext. We cram lots of users on a conference call at the same time. Everyone logs in to the system. We walk participants through basic functions like creating a profile, tagging themselves, posting Signals, editing workspace pages. We encourage them to ask questions–then answer questions that others have asked. We encourage them to tag not only themselves, but also their colleagues. We noodge everyone to upload a profile photo. We kibbitz, we cajole, we encourage people to step outside their comfort zones.

The results are amazing. We can jump-start an implementation within a couple weeks, and engage even the most skeptical, change-resistant employees within an organization in a very short time. (Did I mention that active usage is up by more than 300%?)

Why does social training work? Four simple reasons:

It creates a social dynamic from the start. The worst failure a social software tool can make is the sin of “crickets”: a user tries to engage the community and there’s no immediate reply. By getting many users on the system all at the same time, we guarantee that each of those users is experiencing a vibrant, active community at scale.
It answers the “why” question. For most business users, the big question in social software isn’t the “how”. The mechanics of social software are simple. Users don’t need a training course to know that they tag their profiles by clicking the “Add Tag” button, or post a Signal by clicking “Post”. However, many users do need help in understanding *why* they would want to tag a profile or post a signal. For those users, the whole thing suddenly makes sense when they see their colleagues tagging and posting in real time, and in response to each other.
It scales. The ideal size for a training session is anywhere between 25 and 100 simultaneous participants. They don’t have to be in a room together. In fact, it’s almost better when they’re *not* in a room together. That way the software becomes their exclusive mode of interaction.
It’s fun. When these trainings go well, they’re more like cocktail parties than training sessions. People meet new people, discuss interesting topics, and crack jokes all in the course of the hour. Many participants comment that it’s the most fun they’ve ever had at a training.

So whether you’re using Socialtext or some other social software tool…give social training a try. The results will delight you. More important, they’ll delight your users.

social software, training

My Favorite Enterprise 2.0 Session: American Hospital Association

By Michael Idinopulos | June 29, 2011, 7:29 pm | 20 Comments

At last week’s E2.0 conference in Boston, I was surprised and pleased by the way my “in-the-flow” phrase has gained common currency.

I was also surprised, but less pleased, by some of the “best practices” I heard flying around. Whether in keynotes, sessions, or just hallway conversations, I heard a lot of claims of dubious merit, claims like:

Start with a small pilot and let it grow virally
Invest heavily in community management, because a community is only as successful as its managers
Workers won’t use social software without personal incentives
Workers who don’t belong to the Facebook Generation don’t “get” social software.
Social software adoption requires a culture of collaboration
You shouldn’t launch collaborative tools without a collaboration strategy

There’s a common theme behind all this advice: You should be scared of launching enterprise social software, because achieving adoption is really hard, really time-consuming, and really expensive.

Sorry friends, but I’m calling Bullshit.

In the hands-down best session I saw at the show, Karthik Chakkarapani from American Hospital Association described how AHA achieved phenomenal adoption. Here’s the video Karthik’s team put together. It’s a must-watch for anyone interested in this topic. And for those of you with ADHD, here’s the Cliff Notes version:

Made Socialtext their Intranet (so there’s one place to go).
Integrated all mission-critical work tools into that very same Intranet (so there’s one place to go)
Implemented Single Sign-On to remove the barrier of extra logins for the different applications (so it’s easy to get there)

AHA launched with a project team of 2 FTEs working for 3 months. Six months out they’re getting over 95% active adoption.

Karthik’s success makes me think that a lot of E2.0 experts don’t really understand what “in the flow” means. If your company is using social software in the flow of work, that means that the social software is where people work. It’s not a side-room where happy people take time out to brainstorm, swap ideas, or post random tweets. It’s where people go to work. Every day.

And it ain’t that hard.

Enterprise Social Software Adoption: Now Available in Prescription Strength!

By Michael Idinopulos | June 17, 2011, 1:36 pm | 0 Comments

When companies ask me how to deliver enterprise social software adoption, my advice is simple: Go to your local drugstore.

pharmacy

Walk into any drugstore in America and whether it’s Walgreen’s, Wal-Mart, Rite-Aid, CVS, or an independent, I can guarantee you it’s laid out the same way: The pharmacy is in the back of the store.

The marketers who create drugstore planograms figured out a long time ago that the pharmacy customer is a captive customer. If you walk into Walgreen’s for Zoloft, Zyrtec, or Zyprexa, you will fill that prescription. By locating the pharmacy far from the entrance, drugstores force you to walk past a vast array of other items that you may not have come in for: magazines, candy bars, greeting cards, shampoo, toothpaste, and even groceries. While you’re in the store, why not pick up AAA batteries and a few chocolate Easter eggs for the kids

The same principle applies to enterprise social software.

If you want your colleagues to try enterprise social software, you must get them in the door. Every organization has its “prescriptions”, information or transactions which employees need on a regular basis. If you make your social software implementation a place–better yet, the place–to fill those prescriptions, you greatly increase the likelihood of its adoption long after the hype and hoopla of the initial launch has faded.

What prescriptions do your colleagues need to fill on a regular basis? The answer depends on the nature of your business. Here are a few good, generalizable examples:

Product information. Elsevier and Getty Images post product specs, FAQs, pricing, and marketing collateral that their Sales Reps need to sell a rapidly changing product line
Transactional systems. American Hospital Association and NYU Stern School of Business have integrated transactional systems and forms into their Social Intranets
Ongoing operations. Epitaph Records and Meredith Publishing manage marketing and promotional campaigns in collaborative workspaces
Customer solutions. OSISoft and GT Nexus maintain the technical knowledgebases required to support their enterprise customers

These are very different use cases in very different businesses, but they have two things in common. First, they fill prescriptions. They deliver must-have content and functionality that a broad cross-section of staff need on a regular basis. Second, they lead to other “purchases”. Users who initially show up to submit a Help Desk ticket or look up a price quote often find themselves staying to post an idea or upload a slide deck.

When companies struggle with social software adoption, it’s usually because they’re not filling anyone’s prescriptions. They try to lure shoppers into the store by promoting items that are perceived–at least initially–as non-essential. Because those lead promotions are weak, they don’t attract the traffic required to generate follow-on business.

If adoption is an issue for your company, I ask you this: What prescription are you filling?

Warning: Side-effects may include euphoria, engagement, reduced frustration, enhanced productivity, and noticeable spikes in interpersonal connectedness.

Vision for the Social Enterprise

By Michael Idinopulos | May 12, 2011, 2:47 pm | 4 Comments

When I talk with CIOs these days, there’s one question that comes up again and again: How does it all fit together? How does Social play with my Intranet? How does Social play with my document management system? How does Social play with my ERP system? How do Social profiles play with our HR directory? How does Social play with my CRM system?

CIOs are asking these questions at level of both technical integration and user experience. They want to understand implications for the technology stack, and they want to understand how it all forms a coherent experience for their users–especially their non-power business users.

These questions represent a big change in CIO thinking. As recently as 12-18 months ago, CIOs were still peppering me with questions about business value, use cases, and ROI. That has subsided. When it comes to enterprise social software, CIOs are no longer asking Why. They’re asking How.

Maybe it’s my McKinsey training, maybe it’s my Meyers-Briggs type (feel free to guess), but when I see complex, interconnected questions like these, I look for a simple framework or picture that tells the whole story.

So here goes. Tell me what you think.

Application Development

Enterprise Collaboration: One Space or Many?

By Michael Idinopulos | April 29, 2011, 1:46 pm | 2 Comments

A new Socialtext customer, a government organization, is in the process of launching Socialtext for collaboration within and across project teams implementing a major set of environmental initiatives. Today they asked me a fundamental question: “Should we create a separate collaborative space for each project team, or have everyone collaborate in a single, shared space”?

I call this the “one-or-many” question. It comes up all the time. I don’t think I’ve ever blogged my answer, so I will remedy that now.

There’s no right or wrong answer. Both approaches have pros and cons, but there are very clear criteria for when you should take which approach.

Good reasons to have multiple workspaces (e.g., one for each project):

There’s confidential material that’s not shareable within the organization
Employees are intensely risk-averse and won’t participate honestly if their contributions are broadly accessible outside the immediate team
People work in disparate areas, and will view updates from other areas as spam

Good reasons to have one workspace:

You want to support and encourage cross-silo collaboration and coordination
You want colleagues to have greater visibility into what’s happening in other parts of the organization
You have a small implementation and don’t want to dilute the network effects by splitting the cocktail party up into multiple private rooms

In general, I find that very small implementations (<100 participants) almost always benefit from working in one big workspace. The group is small, confidentiality is rarely an issue, and business processes are so fluid that everyone needs to be in everyone else’s business. Once you get over 100 people, however, business processes and accountabilities become more formal, and you want to augment that one big workspace with smaller workspaces that are specific to teams, geographies, projects, etc.

Companies Aren’t Communities

By Michael Idinopulos | February 22, 2011, 3:33 pm | 13 Comments

Companies aren’t communities. They aren’t forums.

Companies are companies.

Of course company life has community aspects, and those community aspects can be quite important in getting the job done. But a lot of social software folks seem to forget that there’s a lot more to a company than community. They treat companies as if they were consumer communities or forums that all just happen to have their paychecks signed by the same person.

Why does the difference matter? Let’s look at the numbers. Online communities and forums typically attract very small audiences relative to the total target population: Less than 1% adoption is typical, and 5% adoption would be a grand-slam. That’s fine for the consumer web, but those numbers inside the enterprise aren’t exactly a ringing endorsement.

Successful enterprise implementations of social software have orders-of-magnitude higher adoption rates. For example, yesterday I was in New York meeting with Getty Images. Getty’s Socialtext implementation is seeing 95% active adoption. Those are the numbers we’re looking for inside the enterprise!

So how do we get there?

Companies, by very definition, have reporting structures, established workflows, shared systems and processes, defined roles and responsibilities, and closely managed performance. Those are assets we don’t have in communities and forums, which are typically ad-hoc groups of individuals–mostly volunteers–in a collective endeavor without clearly defined roles, processes, reporting, deliverables, or metrics.

Getty and others achieve the adoption rates they do by integrating their social software into all those structures, workflows, systems, processes, roles, and responsiblities. As Getty’s Director of Learning and Development, Jennifer Fox, told me today, “We no longer going to teach people how to use Socialtext. We are going to teach them how to do their jobs…which happen to require the use of Socialtext.”

I’ve been saying for a few years now that companies achieve adoption and business value when they place social software in the flow of work. The tools achieve real benefit when people do their jobs–not their evenings-and-weekends jobs, but their actual “day” jobs in social software. That’s when it becomes woven into the fabric of a company’s business processes. Adoption is almost a foregone conclusion, because that’s where you do your work. Business impact is demonstrable because business processes are measurable.

What, specifically, does this mean? It depends on your business, but it’s things like:

Your company Intranet is social (i.e., built and/or integrated with social software tools like wiki workspaces, microblogging, and social networking)
Marketing and Product post sales collateral in your social software tool (not in email!)
Customer Support’s knowledgebase is collaboratively maintained in social software (again, not in email!)
The executive team and other key teams keep meeting agendas and notes in social software
CRM, ERP, and Enterprise Learning systems automatically post major events in social software
Quick links to important resources are available–and maintained–in social software
Technical Help Desks and other internal support functions field requests via social software

Contrast that with an online community, like a gaming group or a technical forum. In communities, there is no flow of work. That’s because most people don’t come to communities to do work. They come to get support help, to swap tips, to praise, to complain, to socialize. Even those people who come for professional reasons are casual, sporadic visitors. The only person who really works there day-in-day-out is the forum/community manager.

There are three groups of people who cling to the “company as community” concept: the “kumbayeros” who wish that companies were as open and democratic as communities, public community managers whose consumer-facing experience has shaped the way they view all online social interaction, and community software vendors who are looking to re-purpose their consumer-oriented products for the internal market.

In the enterprise, we need to take a more pragmatic approach. As the old saying goes, “The business of business is business.” Social software fails when it tries to turn businesses into consumer-style communities. It succeeds when it turns businesses into better businesses.

adoption, business value, Enterprise 2.0, in the flow

If a document falls in Sharepoint, and nobody hears it…

By Michael Idinopulos | January 31, 2011, 4:40 pm | 10 Comments

If a document falls in Sharepoint, and nobody hears it…does it make a sound?

That play on the old tree/forest cliche popped into my head this week while some Socialtext colleagues and I were meeting with senior IT staff of a Fortune 100 manufacturing customer of ours. They’re a big Sharepoint shop, and mid-way through the meeting we had a revealing exchange:

IT Executive: We’re a heavy Sharepoint shop
Us: Cool. How’s adoption?
Executive: Frankly, it’s pretty awful.
Us: Why?
Executive: No one goes to Sharepoint on their own. If you email them a link to a document, they’ll click on it, but they won’t go in by themselves.
Us: Suppose someone adds a document to Sharepoint of potential interest to me. How would I know it was there?
Executive: Someone would have to email you the link.

I’ve had this conversation several times now, with lots of different Sharepoint shops. People don’t go into Sharepoint because they don’t know what’s in Sharepoint. And when they do go into Sharepoint, it’s to retrieve not to collaborate.

There are two problems here: lack of transparency, and lack of agency.

First, transparency. If you can’t see what other people are doing, you can’t very well collaborate with them. Second, agency. Collaboration has many dimensions. It’s not just co-authoring a document (though that’s a good start). It’s a whole range of social activities around sharing, liking, tagging, rebroadcasting, etc.

Sharepoint makes me think of a cocktail party where you can’t overhear guests who aren’t speaking directly to you, and can’t tell other guests about the conversations you’ve just had. That party would quickly face an attendance problem, just as Sharepoint has an adoption problem.

Social software adoption requires collaboration. Collaboration requires transparency. You can do all the change management and attend all the conference break-out sessions you want, but you won’t get adoption until you deliver transparency and agency.

The good news is that there’s an answer to this problem: activity streams. Twitter and Facebook have proven that activity streams are the most effective tool we have for letting folks know who is doing what and where. And they’re the only effective tool we have for making those events social, by enabling others to comment, like, tag, re-tweet, etc.

Of course Twitter and Facebook didn’t have nearly the traction they do today when Sharepoint 2010 was being scoped and coded. So while there are glimmers of transparency and activity streams in Sharepoint 2010, they are incomplete features at the margins of the user experience.

The social software world evolves faster than Sharepoint does, which is why it’s good to have smaller, nimbler players in the ecosystem like Socialtext. We’re smaller, our development cycles are shorter, and we’re more sensitive to firehose of learnings from the exploding world of social software.

Socialtext’s Sharepoint integration pulls Sharepoint events into the Socialtext activities feed. And it “socializes” those events by enabling colleagues to comment, tag, link, etc. Further integrate these evens with feeds from other systems like a CRM or ERP system, and you’ve really got something transformational. And we can send the resulting integrated feed wherever it needs to go: Sharepoint, mobile, Adobe Air, iFrame, you name it.

That document falling in Sharepoint will make a sound–a sound which can be answered, amplified, harmonized, rebroadcast and, yes, very much heard.

adoption, business value, sharepoint

Hospira’s Veterans Day Blog

By Michael Idinopulos | November 12, 2010, 6:28 pm | 1 Comment

Usually I use this space to advocate use of social software “in the flow” of work. I write a lot about business processes, workflows, incentives, and IT integration. Today I want to talk about something completely different.

Yesterday, medical devices and specialty pharmaceuticals leader Hospira created a Veterans Day Blog on their internal Socialtext implementation. It was something of a departure for Hospira, who typically uses Socialtext for “in-the-flow” things like IT collaboration, HR information, and professional development. The Veterans Day Blog wasn’t “in the flow” at all. Whoever set it up was simply creating a space for colleagues to share their thoughts and feelings on Veterans Day. No workflow, metrics, no ROI. The blog was active for one day.

What a simple concept. What a powerful result.

Dozens of Hospira colleagues contributed. Parents sent wishes to children deployed overseas. Ex-soldiers gave shout-outs to comrades still in the service. People remembered parents who had served. Veterans explained when and where they had served. People recognized Hospira colleagues working with the armed forces overseas.

Most posts came from first-time contributors. All were personal. The cumulative impact was deeply moving.

In this age, especially in the technology business, it’s easy to get swept up and carried away by the flow of work. I’m personally grateful to Hospira’s Veterans Day Blog for reminding me once again that work is all about people.

Customer Success, hospira, use case

Michael Idinopulos

http://michaeli.typepad.com/

Enterprise 2.0: It’s not just for knowledge workers anymore

Turning Serendipity into Probability

My Favorite Enterprise 2.0 Session: American Hospital Association

Enterprise Social Software Adoption: Now Available in Prescription Strength!

Vision for the Social Enterprise

Enterprise Collaboration: One Space or Many?

Companies Aren’t Communities

If a document falls in Sharepoint, and nobody hears it…

Hospira’s Veterans Day Blog

About This Blog

Weblog on gaining business results from social software.

What’s Next for Online Piracy

Enterprise 2.0: It’s not just for knowledge workers anymore

Turning Serendipity into Probability

Why Socialtext 360 = Success

Social Training for Social Software

Socialtext 5.0

Socialtext introduces Socialtext 5 – welcome to the power, the ease and the flow of the future!

CIO Insight Interview with Eugene Lee

Learn How the DAU Is Improving Collaboration and Education

Eugene Lee Discusses Socialtext with TMC

Michael Idinopulos

About This Blog

Weblog on gaining business results from social software.

Recording Coming Soon

Free Whitepaper