Archive for March 2007
One of the things I like about the computer is that when I acquire software for it that I decide later I don’t really need, the clutter the unneeded stuff creates is totally hidden away once I turn off the box. This is not the case for dresses or household appliances which seemed like a good idea at the time. Those things sit in my house, silently testifying to my lack of judgment until I overcome my guilt and lingering belief that really, they’ll come in handy someday, and finally truck them off to the Salvation Army.
With Web 2.0, though, my failed experiments no longer just live on my hard disk. They are scattered all over the Internet. I realized this as I considered giving Explode a whirl after reading about it in Tony Karrer’s blog. Explode is an attempt to bring people who are interested in the same thing together across the various networks to which they may belong. The idea is that if you have a page on Xanga or LiveJournal or Blogger or MySpace you can put your explode widget there, and somehow keep connected with your friends who are elsewhere. I thought there was a tag cloud thing involved here somewhere too, but maybe that’s MyBlogLog. I was playing with it today, too.
I sort of got derailed when Explode asked me to put their widget on my page. My page? Which one? The one on Facebook? Or Linked-in? This blog? The ones I played with over on Blogger and TypePad? Or one of the multiple places I have photo accounts? My personal web site, the one I built lovingly by hand back in the days before Web 2.0? The blog I put there a few years ago?
The plethora of choices really is a bounty. But I can’t remember which sites do what well. Where should I put the project I’m doing with pictures and heavy text? I know I was somewhere (was it Google’s Picasa-now-merged-with-Blogger?) last summer which seemed up to this, but heck, odds are the feature sets everywhere have changed.
I hate to admit it, but it’s so tempting just to retreat back to my email box. I know how to find things there! The key people in my network are all nicely alphabetically arranged in my address book, just a click away! I sometimes feel exasperated when customers try to manage their discussions from their email boxes, because our discussion rooms on the web offer so much more power and flexibility. But today, I’m feeling a lot more empathetic.
To hear some Web 2.0 enthusiasts tell it, “training” is becoming an outmoded concept. These days, anybody who needs to know anything can find it on the web. It is a new dawn for the autonomous learner.
It is true that the read-write web has brought us an unprecedented avalanche of instantly available information. If I want a new way to prepare the chicken and broccoli I’ve got in the fridge for tonight’s dinner, a quick Google search on “chicken brocolli recipe” will produce a number of options.
Of course, it helps that I’ve got some domain knowledge. I know something about what my family likes to eat. And about how much time I’ve got available for preparation, and whether I’m up for a frying extravaganza or looking for something a little less fat-intensive. I have enough experience in the field that I can reliably size up a recipe for whether it looks like something that will work for me, in my kitchen, with my equipment and my skill-set to please my audience.
The Middlebury College students writing papers for their Japanese history course didn’t have that advantage. They are still developing their basic domain knowledge, and their knowledge of their professor as audience. Hence, they could not recognize that Wikipedia was steering them wrong.
How much can an organization afford to trust “information in the wild” for apprising members of what they need to know? I’d argue that the reasonable level of trust rises with the domain expertise of the seeker. It is a huge boon to our organization that our deeply experienced Unix system administrators and our java developers can go out on the web to look for and find ways their colleagues have approached the problems they face. We are a small organization, and don’t have the resources in-house to train these guys, in the first place. We depend on them to identify what they need to know, and to seek out books, training opportunities, and web sites for their professional development, because they are the subject matter experts in these domains in our organization.
But for the folks who come in green? They need more than a browser and an internet connection and a mandate to go forth and learn. We want them learning from our SME’s, about how we do things here. We want them learning the cultural history in which the why’s for how we do things is embedded. We’ve invested thousands of person-hours in making mistakes and learning from them, and we’d really like to leverage that investment by teaching our new hires how to avoid those pitfalls. We know about some trusted resources, and we want to acquaint them with these resources. We try to hire creative, self-motivated individuals who will be interested in seeking out new ways of doing things. Until they’ve had a chance to learn for themselves what works well and what doesn’t in “our kitchen,” though, we’d sort of like for them to run any shiny new ideas they find in the wild by us for a reality check before attempting to implement them for our customers.
In short, we want to train them.
Raph Koster has a fascinating slide show he presented to the 2007 Games Development Conference. I like to keep a weather eye on the games industry, because they know a *lot* about how to engage people in the art of learning.
In his presentation, he offered a slide with these points:
- The fail fast, fail often method: “users must be treated as co-developers”
- Google discards 80% of new features
- They often prototype and deploy within two weeks.
- Release early, release often: Flickr issues releases as quickly as every half hour
This is the MO of Web 2.0. It’s dizzying, and fascinating.
And it’s cognitively costly. It’s one thing for those of us whose jobs revolve around keeping up with what new functionality is being explored on the web and how it can interact valuably with other functionality to be downloading stuff, figuring out how it works and finding out that it doesn’t work quite right and sending feedback to the vendor about it.
Similarly, leading edge gamers are often willing, and enthusiastic about spending their leisure time helping to shape the future of their favorite playgrounds.
But it’s crazy to expect that people whose jobs do not revolve around this stuff, but who are on company time trying to get a rather different task list attended to, should be willing, let alone able, participants in the “co-developer” experience. It’s even crazier to expect that their employers are interested in paying them to spend time in this role.
Organizations need stable platforms on which to support training and online collaboration, so that their employees can concentrate on the content of the training and the work on which they are collaborating, instead of spending endless cycles spinning their wheels, figuring out how to use the @#$% tools.
We need to apply the stuff we know about adult learners to our technology roll-out process. It makes sense to invest in a full-featured platform, but it may best to roll out the features over time, incrementally, so that users have a chance to learn the interface and master it at a comfortable pace.
At Q2, we depend on feedback from our customers to guide our efforts as we continue to develop our software. But we work hard to keep the participant interface intuitive and stable, and we sort of think that we should be responsible for the testing and bug finding, so our customers can just get down to work. When bugs slip through, it’s embarrassing to us. That may be a little old-fashioned, but for the moment, I think we’ll take a pass on the “user as co-developer” trend.
I had a wonderful afternoon yesterday talking with Richard Flanagan, recent of Fort Hill Company, and co-author of The Six Disciplines of Breakthrough Learning. We were talking about the (organizational) training industry, and in particular, how so much training does not seem to be focused on business results. It reminded me of a story told by Wayne Hodgins. He relates how prior to home refrigerators becoming commonplace, people used to store their food in ice chests, and ice was delivered to their door by ice trucks. Within a few years after home refrigerators became commonplace, all these ice delivery companies had gone bankrupt. This was all the more odd since they used refrigerators in the delivery trucks, so they understood the mechanics of the new technology. His conclusion? These businesses failed because they were short-sighted about what business they were in. They thought of themselves as in the ice business, where if they had thought of themselves as in the food preservation business they might have been the early adopters of refrigerator manufacturing. What I came away with from my talk with Richard was the same question. What business are we in?
When we proclaim the wonders of rapid eLearning, it’s pretty apparent to me that we’re not in the behavior change or performance improvement business. In fact, it’s not at all clear whether we’re in the learning business at all, or simply in the content publishing business. And if learning were the same as content publishing, universities could all close their doors in favor of libraries.
So what business are we in? What business do we need to be in in order to stay in business during the next down cycle? I would suggest we need to be in the results business, the performance improvement business, the cost containment business, and the revenue generation business.
And the related question comes down to this: Will the VPSales and the CFO be strong allies for you in maintaining and increasing the training budget next year? If not, are you in the right business – and what would it take to get there?
For us at Q2Learning, the answer is results oriented training; training that reduces time to proficiency; training focused on situations where there’s a clear line of sight between increased skills and increased top or bottom line. This is where we believe the mind share of the training organization needs to be.
Where is your organization’s mind share?
Any one who knows very much about the folks at Q2Learning know that we speak long and loud against the “build it and they will come” myth in regards to communities of practice, so to say that creating a successful community requires forethought and oversight is likely not a new flash to folks who read this blog.
But simply telling people they have to carefully plan their communities of practice is a little like the old Steve Martin gag, “how to be a millionaire” (first, get a million dollars!)
So here is a list of questions to ask when starting a community.
- What are you planning on doing in a community of practice?
Not only should this be the first question you ask, but you should ask it of a bunch of people – yourself, the executive sponsor, the community manager, your target user group, and your target user groups management. If the answers aren’t generally the same, some calibration is in order.
- What’s in it for people to contribute to a community of practice?
A lot of times participants are very gung-ho about a community of practice because they see it as a place they can go to get information and expertise (which it is). But if all of your participants are interested in only getting something out of a CoP, it’s going to be a short-lived community.
- Do communities of practice currently exist in your organization?
If the answer is yes, then what’s the impetus for moving them online? Some compelling reasons for doing so include the ability to expand participation, add capabilities such as document authoring and blogging, cateloging and categorizing information.
If communities of practice don’t currently exist in your organization, ask yourself why not. Technology is a great enabler, but if your organization doesn’t actively support CoPs in person, the likelihood of it happening online isn’t really any better.
- What are the critical aspects of current collaboration tools that community members can’t do without?
If you introduce a tool that’s lacking in these critical aspects, no matter how sophisticated tool is otherwise, you are setting your community up for less-than-spectacular success.
- What portion of my people’s tasks can community participation take the place of?
The simple fact of the matter is that if community participation is something that is added on to peoples’ tasks it will almost always take a back seat to other tasks, regardless of the inherent value of the community.
Of course, this is not an exhaustive list, but getting the answers to these five questions will help you determine the next set to ask – which is, of course, how your voyage of discovering the value of online communities begins!
One of the ongoing struggles in the computer world is the quest for the “intuitive” interface.
There are consultants who make big money helping software developers create interfaces to their software which might conceivably be understood by the mere mortals who seek to operate it. Personally, I’m a big fan of Alan Cooper, who pointed out that the need not to look stupid really belongs at a foundational spot in Maslow’s hierarchy. For this reason, Cooper maintains, attention to user interface should be at the heart of software development, rather than an afterthought once the feature set has been built.
Great strides have been made in user-friendliness since the days when the user interface was a punch card or paper tape. I’d argue that much of that progress rests on the concurrent training of the computer-using public to recognize interface elements which were at first utterly foreign.
Consider, for example, the toolbar above. Every school kid knows what that does. But it was utterly new not so very long ago, and required people not only to learn the meaning of the symbols on the buttons, but also to master new skills of “highlighting” text with a mouse cursor.
Brevity, we know, is the soul of wit. A clean, intuitive interface makes a user’s heart sing (or at least prevents it from suffering palpitations!) The increased computer literacy of the public means that there is a much greater array of metaphors for which there is shared understanding than has ever been the case before.
But if software does something new, odds are the folks behind it had to develop new vocabulary and new metaphors to describe its use. Your users will have to learn what these new terms mean, and how the functions they refer to work. And the people who configure the software to customize it for different user groups will have to learn how to twiddle the knobs which control their function.
Just as it takes more time to write a brief piece than it does to write a rambling one, the development of a comprehensive feature set and the flexibility to configure the software “tightly” (to display the only features needed for each set of end-users) requires a lot of time. Even when the actual creation process has been highly automated, just learning how to operate the buttons and levers “behind the curtain” to configure that interface likewise requires a significant investment of time and effort.
Which is to say, that as we marvel at the intuitive interfaces with which we are increasingly presented in the banquet of Web 2.0 applications made available to us as end-users, we need to remain cognizant of the hidden work behind them. Not only is somebody writing the software, but somebody is configuring it and somebody is maintaining the infrastructure: The physical server, the operating system, the web server, the application itself all require the tender ministrations of either one extremely technical adept individual, or, increasingly, a team of them.
Adding new functionality to an organization always comes at a cost. Choosing to go ASP, and paying the vendor of the software to cover the hosting and maintenance can be a good bet. It may also be possible to contract with the vendor to do much of the configuration work. But odds are, you’ll also need to designate at least one individual in your own organization to be the “savant” who knows what the software does, what configurations are possible, and how to get the necessary configurations taken care of. And it’s quite possible that the simpler the end-user interface is, the more technically adept your configuration person will need to be in order to be able to create that “utterly intuitive” experience for your end-users.
Props to Jenna Sweeney at the Corporate Training and eLearning blog for highlighting “instructional interactivity” as a way in which to help learners gain knowledge in a way that will support their performance, not just meet the requirements of having taught them something.
About a million years ago (in technology time), I worked for a custom WBT house that mandated that every three or so screens in a WBT there was an opportunity for some kind of interaction – the learner had to make a choice, answer a reflection question, take a quiz. When I look back on those WBTs, I really just want to hang my head, because clearly in retrospect these were not the type of interactions that would facilitate learning – they might keep the learner from falling asleep in his chair, but that was the extent of it, I’m afraid.
Of course, there are a lot of highly interactive WBTs out there that take advantage of simulations and gaming technology to create a situation in which the learner is able to immerse herself in an experience that meets at least some of Sweeney’s requirements for instructional interactivity: causing learners to think, helping learners rehearse skills and prepare for performance, testing learners’ knowledge when they need a progress check, etc.
But one serious downside to the kind of technology that’s required to provide such a rich learning environment is cost – especially in cases where you are trying to customize the learning to the learner’s particular organization. So how do you create an atmosphere in which learners can avoid the pitfalls that come with traditional eLearning interactivity, while not blowing the budget on a single training program?
Personally, I like the old standby from my ILT days of asking a learner what she thinks, or even better, suggesting that she talk over a concept with her peers, form an opinion, and THEN asking her what she thinks.
I’m not advocating a wholesale return to ILT days, (by any means!), but I think a lot of rigor could be inserted back in to eLearning by incorporating the best practices of face-to-face training: peer-to-peer interaction, group activities, and plain old asking learners to actively participate in the learning process by publishing their thinking.
At Q2, we have a platform that we obviously think is well suited for these types of activities, and the convenience of having everything in one platform is one more argument for blended learning using the eCampus. But even if you’re not using a centralized platform, taking advantage of the tools that are available today like blogs, wikis and discussion forums will add a layer of instructional interactivity that I could not have added years ago, even with an unlimited development budget.
Seems like we may have boxed ourselves in a little bit in thinking about restraints to the enterprise adoption of Web 2.0. As an example, Mark Oehlert quotes Bill St. Arnaud saying “its actually really hard to see how you can have enterprise grade Web 2.0 without changing the way you deliver your existing IT. I think that such thinking fundamentally confuses the technologies and the philosophies associated with Web 2.0.
If by Web 2.0 we mean the philosophies of open source, wikinomics, driving decisions and power to the users, and “information wants to be free,” then yes, there are some fundametal shifts that many enterprises will need to make to adopt and manifest these aspirations. In fact, I would suggest that the freedom for each knowledge worker to choose which open source technology they want to use not only requires a shift in IT, it may effectively hobble or collapse the enterprise. The costs of administration and training are rather staggering to consider, and I haven’t seen any discussion of what happens when workers leave their positions and their knowledge is stored in a toolset that their replacement doesn’t want to use. The notion that all the information will magically be available to just the right people via RSS and all tools will require no installation, administration, or training is not terribly realistic in the short- to mid-term. No wonder IT departments throw up their hands.
On the other hand, if by Web 2.0 we mean technologies that create a read-write web, the answer is much different. Our eCampus, as a for-instance, is not open source. It is built in J2EE with enterprise java beans on a struts framework offering role-based management and enterprise-level security. It can be integrated with an organization’s HR data warehouse. But it also provides discussion forums, blogs, and wikis. It offers native tagging of posts and even integration with del.icio.us social bookmark tags. It supports mash-ups with google maps and calendars. It has deep integrations with commercial instant messaging and web meeting applications.
Applications such as these provide all the participatory advantages promised by Web 2.0, but within an enterprise context where organizations do not want everyone to see every file, do not want every individual to be able to change a wiki page, believe that there should be spaces for limited numbers of people – and want the advantages of Web 2.0 without having to entirely change their philosophy, approach to management, and way of doing business. And without adding untold new responsibilities to their IT department.
And that’s a good thing.