Employees don’t have time to waste narrating their work

4
2766

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.

 

 

  • driessen

    Good post about an important topic, Bertrand! I think we still have a long ways to go hear, from a technology perspective. The gaps between the different tools k-workers use are often too large. And we all know most k-workers live in their email. However deep integration between email and social tools is often lacking. An step forward could the approach Spreadd is taking. Spreadd says they want to narrate your work for you, because you have so little time. So basically Spreadd is connected to the tools you use and based on the things you do, it (automatically) posts them to a stream so others can see what you’re doing.
    There’s also another side to this problem: do we give employees time to narrate their work. McAfee wrote about this in his book ‘Enterprise 2.0’. He called it ‘slack’. In my experience this is important. If you don’t have time to sit back, it’s hard to narrate your work.
    Interesting topic for the next E2.0 Summit, I think! ūüôā

  • I think this is spot on, Bertrand (but hey, I would do —¬†http://www.jroller.com/MasterMark/entry/social_processes_if_you_add). ¬†But… ¬†Four years (!) after writing about social processes for the first time, I’ve learned some valuable lessons. ¬†Watching social tools being used, in anger, in the real world, has led me to notice two things that should have been blindingly obvious to me, but weren’t:

    1) some people strongly object to Big Brother watching over their every move, and they interpret pretty much every conceivable way of implementing the “transponder” or the “narrator” as being just that. ¬†Indeed, in the culture I’ve spent most of my adult life in (Germany’s), the aversion to any kind of a “narrator” function is more than a¬†behavioral¬†quirk of some subset of the population — it’s a¬†fundamental¬†building block of the majority. ¬†So that beggars the question — if you agree that people should not have to step out of the flow to narrate their work (and I certainly do agree with that, myself), but a significant group of people¬†vigorously¬†rejects any notion of automating that narration, what alternatives are left? ¬†The implications for system design raised by this question are both profound and subtle, and I have seen absolutely no attempt, from anyone, to take a serious run at them.

    2) some people are disturbed by the notion of an automagic narrator not so much because of privacy concerns as they are because they’re frightened of their boss. ¬†They have what can only be described as really lousy management supervising them, and they’re concerned that if data about their daily work is exposed at the level of granularity that such a narrator implies, it will make their lives much worse, not better —¬†because¬†what their lousy manager will do with that data is very bad indeed. ¬†This concern is often hidden behind the first one — ostensible privacy concerns are often just a smokescreen for this deeper issue, in my experience. ¬†And at it’s heart, this one is about something that you and others have been shouting about for years — if you simply add social tools to Industrial Age business processes, you’re as likely to make them worse as you are to improve them. ¬†If a work environment is¬†characterized¬†by a factory metaphor — with assembly line thinking, where people are measured by the time spent on tasks more than on outputs, then narrating that work is about the scariest thing a worker could imagine.

    I know you know all this, Bertand — we’ve talked about some of it. ¬†But I think it’s worth calling out, because I think *these* are the problems that need solving, that are important — far more so than how fast Vendor X is moving to enable proper social processes.

    • ¬†Hi Mark,

      You’re raising a couple of valuable points :

      – what to make visible : some things could be mandatory (things one usually shares daily or weekly with his team for reporting needs etc…it may also remove a pain since less time will be used for project updates etc) or not (true narration, sentiments etc..)

      – on which scope : sometimes the problem is not visibility but the scope. Not everybody should be able to see some things for confidentiality reasons or just because having everybody seeing work in progress is far from being the best way to move forward efficiently.

      – culture : once dealt with the scope issue, then comes culture. Depending on local, biz or personal factors openness is not that easy and may even be harmful. That relates to the big brother syndrome, insane peer pressure, History etc…

      Then, and only then, software matters to make visibility as less time consuming as possible. But useless until there’s not a strict and clear governance and guidelines about the previous points.

      The point is, as always, social or not, business is not a field of dreams. Openness, sharing etc…are nice values but not necessary realistic or good in some contexts. In fact it can be a solution to some issues but not a one-size-fits-all magic wand.

  • johnt

    Really good post…as usual your pragmatic view is essential in these areas of human behaviour and constraints.

    There is a blur between “narrating your work” and observable work”…the former is more an explicit update, whereas the latter is actually within the process of doing the work (ie. there is nothing to update yet as you are still doing the work)

    When you talk about activities in 3rd party applications appearing in your activity stream, and perhaps even the ability to comment and take actions within embedded objects in the stream; this is the realm of “observable work”, it’s not an update at all, it’s simply doing work.

    Now if your boss or colleague “follow” you, they may know exactly what you are up to right now, without you having to microblog or blog an update (sometimes you don’t have to narrate your work, if your work is already observable)

    I’m not saying “narrating your work” is not necessary, I’m just saying sometimes if others observe your work, they will know the latest without you having to narrate your work…but even on these occassions you still may want to narrate your work for reporting, reflection purposes.

    Your example of 3rd party app activity within the activity stream is not the only example of observable work. It can happen in simply microblogging conversations.
    If I’m on a group task…my responsibility may be to speak to some people in the business to help me with some information. Example – Just say I microblog a post to a guy in IT about some technical stuff…after the conversation I may¬†ATmention¬†the people in the group task updating them about my conversation with the IT guy. BUT, if they follow me, they would have already seen my conversation with the IT guy, due to my work being observable.

    I still think a narrating your work type update is needed as not all work is observable (ie. me an IT guy may have add phone conversations, etc..)

    I posted on this a while back
    http://libraryclips.blogsome.com/2010/07/19/enterprise-microblogging-you-no-longer-have-to-report-back-to-base/