Employees don’t have time to waste narrating their work


Summary : it’s impossible to think about emergent collaboration and self-organized structures without visibility on others’ work. That’s the reason why employees are more and more expected to share statuses related to the progress of their work. An approach that carries many promises and tangible benefits but that’s also time-consuming and complex when business and collaboration applications are separated. Solutions exist but are not still seen as essential by organizations when they make their choice : integrating both in a digital workplace. That’s a key challenge because by favoring community logics to the detriment of the flow of work, organizations misses lots of tangible and easily measurable benefits and leave employees who are more focused on their day to day work aside.

One can’t get help from other if he does not share his problem. There is no answer without question. One only asks help from those who seem being help to help him.

To make it short : collaboration, cooperation, problem solving and even innovation requires something to be shared so trigger the dynamic. Moreover, people often don’t realize they can be helped : sometimes we believe we’re doing right while we’re doing wrong, we’re doing right while we could do better, differently.

Hence a new standard in information sharing and communication between employees advocated in many enterprise 2.0 and social business approach : employees need to narrate their work on the flow to trigger collaboration.

At the very beginning, blogs were the perfect tool to do so. After all, nothing better than a media dedicated to personal narration to narrate one’s work. But it did not work for everybody. Perfect tool for those who love longs stories and elaboration in some very specific situations, blogging was not the right thing for many users who don’t like writing or have not enough thing to say to fill the space and was not relevant in many situations (when the length of the information to be shared was not longer than the title of the entry). In other words, blogging was good for reports, explain things or expose ideas but not to say “looking for a case about…” or “formalizing the action plan for…”.

Like on internet where twitter either completed blogs or replaced it for those whose message were as long as a post title, microblogging entered the enterprise application portfolio. A very relevant tool in fact because, in the end, sending signals is even more important than starting conversations. And even if still not massively adopted, for maturity reasons, internal microblogging, that supports a kind of situational intelligence, made usages that blogs limited to a small category of people take off.

You’ll often find this trend mentioned in the specialized weblitteracy under the name of “visible work”,”narrate one’s work”, “observable work” or “working out loud”.

This approach brings actual benefuts

– as said before, it allows to trigger collaboration, problem solving dynamics etc. that could not start without.

– it allows a light form of reporting : managers can have a look at what people are working on without bothering them with the usual and time consuming “what are you doing ? ” and a large part of the reporting activities that have few value regarding to the time they consume.

– it supports a kind of light coordination within a team, allowing members to auto-adjust and react without formal, synchronous and time-consuming meetings.

But even if microblogging made things much easier, there are still many lacks.


As a matter of fact it supposes individuals to take actions, even light ones, to send the signals in question. Actually, an action that’s not that light if we have a closer took :

– switch tool

– take time to write

– get back to the tool where work is done

– refocus

So it’s more time consuming and tedious over time when than expected because if the operation does not take a long time it takes time often. That’s the reason why if many events are worth being shared, few are, not by everybody and with more or less rigour.

Truth is we can’t complain on the one hand about the time dedicated to reporting and useless meetings and ask, on the other hand, people to narrate their work. We can’t complain about the interruptions caused by emails, phone calls etc. and ask people to share any small event. More, and that’s a recurring problem in the history if IT, it’s absurd to ask employees to key the same information in many tools in order to report the same thing.

The solution : if people’s work’s worth being narrated, people should not always be the narrator. Their time is too precious to ask them to play the role of transponders. Fortunately we can see the emergence of many answers to this problem even if organizations, which are still over-focused on community management and conversations do not spend enough energy and attention on this essential matter.

As a matter of fact, many enterprise social networks solution that, in fact, look more and more like digital workplaces, allow third-part business applications to publish information in their activity stream. For example a weekly report, an alert caused by the reach (or not) of a new step in a project or a workflow etc. Some even allow, in addition to the event itself, to bring context related information (GANTT, customer profile etc.) in the social tool to avoid having to switch tools to read the information upon which action is needed. If needed, people will be able to take time to add, elaborate…but even it brings an added value. For basic and factual information, we should not appeal to employees but save their time and attention.

Among those who are embracing this way, I’ll mention (in alphabetical ordrer) IBM, JIve, Salesforce, Tibbr…each in his own way. Before making any decision on which tool you should use in your organization, check that the link between business apps and social platforms is not restricted to applications from the same vendor but that there’s a framework allowing to build synergies with any third-part solution. Also check that, more than events, contextual information are also shared. More, check if actions can be triggered in a tool and performed in the other without switching tool. Last, make sure that, in addition to these capabilities, the tool has the usual collaboration and community features because it would be prejudicial to separate what is about the flow of work and what is about knowledge sharing in two competing platforms while both complete each other…users won’t accept this.

Anyway, organizations must take this point into account right now when they design their project, workplace and choose their future platform if they don’t want to end with a major barrier to massive adoption and the need of investing in other more vertical solutions a couple of month later.

And don’t forger that separating the tools where problems are from those where solutions can be found is not the best way to improve the performance of your organization.