Technologies supporting knowledge work are deceptive, especially for knowledge work shared among groups and teams. The ease of getting started obscures the challenge of learning to be effective. We focus on the details of particular features and functions at the expense of ignoring the cognitive challenges of deep thought and collaborative work.
I’ve been participating in a Slack team with a loose group of colleagues scattered across two continents. I was off the grid for about two weeks and found myself lost when I returned to the conversation that had continued in my absence. My first hypothesis was that Slack was the culprit and that some magically better UX would eliminate the problem. Slack, of itself, isn’t the problem but it is emblematic of the deeper issue that should be tackled.
In trades and crafts, the most experienced and effective practitioners would never invest in cheap tools or materials. Learning to use those tools and materials effectively is the work of years of deliberate practice. The strategy shouldn’t be any different if you are manipulating ideas than if you were manipulating clay. But the marketing and deployment of software rejects these hard won lessons. Software fame and fortune is built on promises of simplicity and ease of use, where ease of use has been interpreted as ease of getting started and minimally productive. We’ve all become facile with learning the first 5% of new tools and services. We’ve been led to believe or we pretend that this is enough. Few among us are prepared to invest in pushing further. Fewer still belong to organizations willing to support this investment.
The payoff from even this 5% has long been sufficient in terms of personal and organizational impact. We’re reaching the limits of the return from this minimalist strategy–it’s even more acute when we shift focus from individual knowledge workers to teams and groups.
To go beyond the 5% we need to modify our expectations and approaches about how we blend powerful tools with powerful practices. We need to adopt the attitudes of those who think in terms of craft and expert practice. Organizationally, we need to provide the time, space, and support to design and invent this new craft.
My hypothesis is that there are models to look to and borrow from. In particular, I believe that the world of software development has the longest and richest experience of dealing with the individual and group production of the thought products of the knowledge economy. Further, there are individual expert knowledge work craftspeople in various other fields; their tools and practices are also worth understanding and reverse engineering.
I don’t have this all figured out yet. Nonetheless, I ‘d like to get a new conversation going about how to improve on this train of thought. Where are good places to look?
Thanks, Jim. I’ve had a thought like this swimming around in my head for a while. I’ve grown tired of playing with new tools which promise (again) nirvana for the knowledge worker. They never seem to map to the way I work (or my team works).
None of these things are ever about the tool, as you say. The emphasis on tools/process is so strong everywhere, which is why one of the four values in the Agile Manifesto for Software Development specifically says people and interactions over processes and tools.
How do we want to work? How do we want to work together? What does that work look like? Maybe then we can consider the processes and tools that can support those interactions amongst us.
Maybe the problem is in part the way that tech is “sold”. Your point that getting and initially using tech is a step on the journey. I’m still learning important things in the tech or my 6 month old car.
EMR/EHR was sold to doctors and the public as a magic bullet to replace a paper record. Maybe there should have been a caveat that learning this is as much of a journey as learning any technique.
Gawande once opined in an essay that having a “coach” in the OR after he had been in practice for several years helped him. Maybe IT vendors could come back at intervals and organizations could encourage such coaching in what some others have found helpful in streamlining processes
Hi Jim, I think you pretty much nailed it with the first sentence: ‘Technologies supporting knowledge work are deceptive, especially for knowledge work shared among groups and teams’. The issue here is that most of these technologies have never supported knowledge work. They are only interested in the date we produce and share across and, in the process, try to make that sharing data as addictive as it possibly can, so we never leave, never mind doing ‘knowledge work’. It just won’t happen. It hasn’t in the last 20 years I have been in this space.
And I am afraid we would only have to blame ourselves for it. Ourselves as in ‘knowledge workers’, because we keep falling back into the trap of vast majority of these technology vendors who promise heaven and earth and eventually we end up elsewhere. Yet, we keep repeating the same mistake over and over and over again. As opposed to start challenging those tech vendors into, finally, getting their act together by becoming more conscious and aware of our knowledge work activities vs. just trying to meet their own needs (capture data).
Unless we all start challenging these vendors to adapt more to our needs & wants as knowledge workers than just rather their own, we won’t be going much further than what we’ve done so far in the last two decades. Tech vendors don’t care much about ‘knowledge work’, we do, so unless we get them to understand and adapt to that shift there is not a lot that would happen. We ought to be the ones putting a stop to it, not just those same tech vendors. Once that transition from vendor-centric to people/customer-centric takes place we may have got something that would help us with our knowledge work activities and discourses…
Once the group size gets above a threshold of 6-12 I find Slack to be counterproductive. I am a fan of
Wikis – we use http://www.imeetcentral.com but there are a number of good options.
E-Mail reflectors: I find the longer form writing email enables to be more useful than the snippets in slack. I would rather get a well written email response than a stream of half a dozen slack comments.
Skype text chat — when focused on a particular issue is a good way to complement a conference call. Google Docs are another good option although the higher level organization (of a set of docs) leaves much to be desired.
I agree with your suggestion you don’t want to get a bargain on your tools, you want the best tools for the job. It can be tricky to evaluate, select, and debug collaboration tools but in my experience it’s worth the effort.