by Paula Thornton
July 9, 2009 at 8:03 pm
· Filed under 2.0 Design Thinking, Adoption, Emergent, Enterprise 2.0
The wagons are circling…around the wrong campfire.
Clearly, adoption is an important part of Enterprise 2.0 efforts. The FASTforward Blog team believes it’s significant enough that we’re shifing our focus to the topic. But the language of adoption for 2.0 is broken:
“…coming up with innovative ways to address those three issues to drive end user adoption” Still Looking for End User Adoption
“Reach out to existing communities of interest to drive adoption…” Think Adoption, Not Deployment
“…how a user centric (rather than technology centric) approach to deploying Enterprise 2.0 technologies will drive adoption” Expanding Enterprise 2.0 Beyond the Early Adopters
While some of these authors have introduced critical elements to address — seamlessness via platforms, work specific, governance & roles — they all use the phrase “drive adoption”. This is the antithesis of 2.0 fundamentals.
If you have to “drive adoption” you’ve failed at 2.0 design and implementation. The fundamentals of 2.0 are based on design that is organic — meets the individual where they are and adapts based on feedback — it emerges. The ‘adoption’ comes from rigorous ‘adaptation’ — it continuously morphs based on involvement from the ‘masses’. If done right, you can’t keep them away…because you’ve brought the scratch for their itch.
Good design work includes research to identify the relevant itches and discovering the possibilities to deliver capabilities right from where individuals already ARE. If that hasn’t been done, even if you’re successful — it’s relative success, you could have done a LOT better. That’s the problem with success — it’s rarely evaluated for potential capitalization (there was X potential and only N% achieved).
From a physics perspective, “driving” is the same as “push” or “pull”. None of these are relevant language in 2.0, as they waste energy (e.g. resources). Tapping natural energies — existing activities — ARE fundamental to 2.0 designs.
Rather than worry about adoption, make sure there has been adequate investment in design with a focus on the ability to adapt.
Adoption follows adaptation (the solution to the individual, not the other way around).
Footnote: The language of living systems is critical to E2.0 efforts. If you’re not conversant in such language (esp. complexity, emergence, self-organizing), have a sit-down with Mother Nature — she’ll set you straight.
Permalink
Well said, Paula. I freely admit to having committed the crime of using the phrase “driving adoption” myself, but now that I’ve seen the light, I’ll focus on encouraging adoption.
Driving adoption smacks of the old joke: “The beatings will continue until morale improves”!
I’m in agreement that force is not the right method ever for improving ‘user adoption’. However I do disagree that adoption can’t be driven. I understand linguistically where you are making your point but this raises the wrong impression.
People resist change, whether that change be pleasant, effective, or good for them. Since we are complex people, and organizations have many different sub cultures it’s important to ‘help’ or ‘drive’ user adoption. Without it your productivity and benefits (return on investment) is not going to be as large as it otherwise could be.
Again, not forcing (pushing, or forcefully pulling) but rather helping to drive it along. Dangling a carrot is fine as long as they get to eat it. But never use the stick.
Anyways this is my thoughts on it. Would love to hear back in case I misinterpreted.
Richard Harbridge
You have nailed it perfectly. Users should not be driven to adopt a solution. Either the solution adds value to all members involved or it will not be used. Check out my post on CRM usability :
http://johnfmoore.wordpress.com/2009/07/02/crm-usability-issues/
One commentor stated that users are lazy and must be driven, they don’t get it either. Keep up the good writing.
John Moore
Paula,
Right on! Great observation. When I hear the word “drive” I think of a “cattle drive” which unfortunately only moves under pressure and stops dead unless you are pushing! Push technology failed back in the dot com (remember the old pointcast, backweb, marimba etc…) and push attitude fails even more so. If you have to ‘drive” anything today you are doomed. Whether you look at E2.0 or Sales 2.0 – friction needs to be minimal. Driving a nail into wood – creates friction and heat – which is really what we see today as enterprises grapple with social media/social networking.
We need to “enable” adoption. Make new things simple, frictionless and easy for everyone.
Good post!
Tom
Richard: A similar point was raised via Twitter. Here’s my fundamental belief (but recognize that there is huge room for variability in who/how it’s done): “The cognitive resistance to change is due to change that is cognitively disruptive.”
There is a lot of detail in all of my references to design above that many may not fully appreciate. Design done well will have researched and attempted to accommodate the issues contributing to resistance. The whole purpose of the adaptive components are to address the specifics of such issues as they are uncovered — because it is not cost effective (nor even possible) to do so initially. It’s a continously adapting solution. Indeed, I have problems with the word solution because of the historical baggage of something being ‘done’, moving to ‘maintenance’. These are NOT like products in that regard.
I see what you are saying and where you are coming from. I think I also forgot before to say I really liked the article, and think overall it does provide some really good points and a good message.
From a design perspective I completely agree that the design should be constantly improved overtime which (if successful) will ‘drive’ (pull) more users along and into it because it is more useful, beneficial or more easily understood. Realistically though this point alone disrupts the initial statement I was against which is that adoption cannot be driven. What you really seem to be saying here is that good effective and continual design will drive adoption of a system.
Certainly you need shared understanding of value from those who implement something and those who use something. (I also agree that ‘solution’ is a word with particular connotations I also would like to avoid in this circumstance (maybe always) as a result – Really neat thought btw).
Where I find it difficult to agree is actually with the perceived concept I feel the “Adoption can’t be driven” instills. That specific phrase is basically saying it shouldn’t be driven (which the article also tries to support). However there is no way for a new/different ‘solution’ to be implemented successfully without ‘driving’, or ‘helping’ adoption. (IMO)
Here is a couple thoughts that might be interesting:
If the design, interface, or perception infers in any way that it is different certain personalities will cognitively perceive change as a bad thing. This is reaction. The reason is because “All change is cognitively disruptive.”
For some people (most in many circumstances) when we see something shinier, prettier, or newer we may automatically react with a desire to have, use, or explore it (typically more true for the new generations (in North America) where this has been instilled). However not everyone reacts this way. Since we are probably talking about technology (inferred by reference to E 2.0) this is even more predominate because often we are automating, or adding technology to a process that was previously manual or executed in the physical (not digital) realm.
Now to be fair you could say this might be such a low factor it should be ignored or can be ignored. I agree with this response since the way we often measure ‘success’ with adoption is rarely as a value of 100% without resistance. However when you cross cultures (international/global) that level may increase substantially. This might be especially true within places where technology has not been instilled/ingrained/integrated fully into people’s lives.
Just a couple more thoughts. I really appreciate the response back and look forward to future articles/your tweets.
Richard Harbridge
Richard: Thanks for keeping at obtaining clarity. Your points are all valid and are ‘typical’ perspectives (if it weren’t for people like you who can talk to the others who talk your language, the rest of us would be in trouble).
1. There’s a difference between ‘reactions’ and true issues that need to be solved. I’ve seen far too many development teams respond to the wrong issues — they can’t differentiate between what’s relevant and what’s just ‘noise’. But then that shouldn’t be their job. The REAL problem is that the teams lack true designers who DO know how to differentiate these things an apply them effectively.
2. Design has to accept ALL responsibility for the success of the solution (again, do not think ‘visual’ when considering the breadth of design — it’s a total experience, of which “response time” is part of that). Any relevant rejection of a solution HAS to be considered a design failure. That means that no one design fits all situations or people. You can’t just plug in a solution, it has to be ‘fitted’ to the context of its use. Any ‘rejection’ of that is simply a sign that the design is flawed and more work needs to be done. Typically, implementers just stand up solutions and haven’t the vaguest idea how to assess for or accommodate cultures and work habits.
3. ALL solutions must be customized, period.
Ah! I think I see what you are saying here. That definition of design is definitely not the context I was using/thinking.
The little puzzle pieces are now set in place in my mind, appreciate the clarification as to what ‘design’ represents to you.
Also I will toss this in here since I put it on twitter and maybe everyone else isn’t following/seeing those:
rharbridge: I like ‘pull’. It’s hard for me to think outside/in a situation where you don’t pull. A.K.A – Does good design pull? Or rather: adoption is perceived as movement or change to me. Without drive (push/pull) how can things move? (Based on physics example.)
Thanks again,
Richard Harbridge
I figured there was a ‘design’ disconnect. It’s the biggest one we face, which is why I keep repeating it (”the floggings will continue…” : )
Per my tweetstream to you:
Rather than drive, push, pull — movement occurs by mutual attraction: draw (this is a fundamental principle of complexity sciences ala. self organization — per Stuart Kauffman, it’s “energy for free”). But that’s the ‘lesser’ goal. The FIRST goal is to simply GO to where they are. Meet them. While that can be taken literally, it’s more figurative. It’s about figuring out what activity they’re doing and embed function.
Applications require that people ‘go’ to them. Applications are dead. Living functions simply present themselves in context. The only place anyone should ever have to ‘go’ is the browser…browser as platform. It’s about architecture. The most relevant example of the concept of ‘here’ (wherever “I” am) is Google Wave. The functions are ubiquitous.
Hi Paula, I agree completely that we can’t “drive” adoption!
I also agree that up-front design is the key, and would argue that we can “design for adoption”. Too many tools are either:
a) thrown out to the wider staff population, with little more than the rose-tinted hope that they’ll be used
b) really poorly designed for staff to use the tools (see most corporate software)
Every enterprise project should take the time to understand the staff environment and working practices in depth. This involves going out into the field, watching and listening, asking questions.
Only then can enterprise & enterprise 2.0 solutions really be designed for success. (Enterprise 2.0 solutions are not automatically easier or more natural for staff.)
Cheers, James
James: Thanks for jumping into the conversation from Australia (I’m currently watching an old presentation of Richard Feynman he gave at a conference in New Zealand — so I’m feeling a close connection right now : ).
The only challenge I’d offer back is that while something might be ‘labeled’ E2.0 doesn’t make it so. To embrace the true intents of E2.0, an effort/solution ‘would’ be easier (more direct/specific) and more natural for staff. In the end it’s all semantics, because people will call things whatever they want, without regard for the real intent.
I will still stand by the fact that if efforts don’t accomplish such things they not really E2.0 initiatives — they don’t qualify for the definition — they’re just a badly implemented ‘project’. But we know if a project is submitted for funding under an E2.0 label (thus showing up for months on reports labeled “Enterprise 2.0″) and fails, then it’s E2.0 that takes the ‘hit’ not the badly implemented project.
Paula,
I think one of the issues you are raising is that of symantic corporate-speak . The terms “solution” and “driving” are part of the mainstream in the corporate world. My sense is that they are often used in a broader vein than intended. They may also be used to meet the client where the client is at. I remember a time when these terms represented a step forward in terms of progress. However, now these terms do carry the set of meanings that you talk about. Although they may not equate to a command and control mentality, they do reflect that a solution to a problem can be arrived at and its implementation can be driven from afar regardless of where others are at. There are situations where the approach represented by these terms is a helpful one. I agree that Ent 2.0 expansion is not one of these. I think when we find ourselves using these terms, we need to stop and question whether what they reflect is helpful to our endeavors.
For the purpose of Socratic dialogue, we can also take a look at the word “design.” Though the scope of this term does include members of an organization participating in a design that they then implement, it does seem to diverge from what you were describing in terms of expanding the utilization of Ent 2.0. Though architects and developers had to do some design work, the use of Facebook, Twitter, blogging, wikis among the general population occurs without any kind of design. This is more in line with chaos theory than any Newtonian sense of purposefulness. Even the developers of the technology who likely had some intention of usage of their products must realize that emerging reality can quickly trump such intentions. I think when we use the term “design” we must be clear about what we are intending, what are assumptions are and whether this is the appropriate term for the situation at hand.
I see a progression in terms of the use of the “design” approach over time. For many years, I was a practitioner of Socio-Technical Design. In this approach, a representative design team created an organization or process design which was then implemented by a representative implementation team. In time, what the design team created was seen as only a blueprint which the teams fleshed out and implemented. As time went on, design was seen as an activity of all of the organization assembled together who then went on to participate in implementation planning. This was still a linear approach. This was then followed by Open Space Systems in which the entire organization (as much as was feasible) participated in a more emergent process. The term “design” was at best loosely applied to that. Now, Ent 2.0 expansion seems to have moved beyond this. I believe that there are limitations to all of these approaches as well likely be the case with Ent 2.0. In those situations, maybe what will be necessary is some good old fashioned design. Even here, I agree that driving solutions in this day and age will come up short.
Barry:
There are two distinct phases of ‘use’ of a product that are significantly relevant here. The ‘use’ you spoke of relative to Facebook and the like is an ‘end use’. The most overlooked challenge for E2.0 is that most tools are ‘platforms’ and they must be customized for ‘end use’ — by putting the tool within the context of use with in the business. This critical design is the crux of the win/lose proposition for E2.0 — along with a strategy that includes a governance model — a living one that adapts and adopts agreements as to roles and responsibilities and any agreed ‘rules’ (a term I use lightly) or standard adopted conventions.
Buying E2.0 technologies for which the UI is fixed and final is NOT recommended (except for plug-ins — functional adds to the platform).
The latter examples you gave are quite relevant. Sadly, I’ve been in organizations where even communities for ‘open source’ initiatives are locked down and highly controlled. That’s the antithesis of what’s needed for success.
Thanks for your contributions. I hope I didn’t misunderstand or take too many liberties with your response.
Paula,
It appears that in our respective comments we are scoping out a chronological definition of design from the upstream end of technical platform design through the application to the user and then to the behavioral and organizational configurations that provide the downstream context for the technology’s use. Your comments and expertise are helpful to me in fleshing out the upstream aspects of this. Where our respective comments appear to overlap is with regard to what you describe as the “governance model.” It is at this point, I am assuming, that the configuration of the technology and related agreements has the potential for facilitating adoption and a set of behaviors for openness and sharing. My perspective is that the further downstream support of congruent behaviors, norms, skills and organizational processes is important for impacting whether the user organization is in the Need to Know mode or the Need to Share mode (i.e. command and control or collaborative) and whether the use of the technology achieves the potential seen in its use in the general population.
Barry: You are really good at summarizing our exchanges. Thanks!
Cultures of command and control will collectively fail at E2.0. Such tools can provide some hope and sanity to pockets of individuals to ‘escape’ the mind-numbing culture they operate in, but in isolation, the tools will fail to capitalize on their true potential to minimize transaction costs across the company.
Governance Model is a term I hesitate to use only because most examples are bad ones — just more command and control. The goal of such a beast is more of a Collaborative Governance Agreement — what we all agree will help this knowledge economy thrive.
Hmmm, thanks for the opportunity to reference that in this context — knowledge economy. While it’s a term that has been used in many other contexts, I believe it has particular relevance in this context that we need to consider more deeply. If you find any related references please send them along; all the ones I’ve found are not specific to this context.
» Subscribe to the RSS feed for these comments
HTML-Tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Additional comments powered by BackType
