David Wilcox and I had a great conversation yesterday (my first opportunity to use Skype--thanks, David!) and among many topics, we discussed the concept of the technology steward in a community of practice.(David has been doing some thinking about it lately here.)

In case you haven't seen this term, technology stewards have been defined by Nancy White, Etienne Wenger and John Smith as:

“. . .  people with enough experience of the workings of a community to understand its technology needs, and enough experience with technology to take leadership in addressing those needs. Stewardship typically includes selecting and configuring technology, as well as supporting its use in the practice of the community.”

Now Nancy has posted a presentation on technology stewardship that she'll be delivering at Ignite Seattle! (Thanks to Beth for the link) I highly recommend checking it out on Slideshare so that you can benefit from Nancy's notes on each slide in the comments section.

As David and I talked yesterday, one of the issues we discussed was the fact that technology stewardship really requires meeting clients where they're at and helping them to take baby steps towards using technology to support their knowledge development. I try to do this as I work with them on other projects that are initially unrelated to technology. Basically always looking for a chance to try out some tech as I do other work. 

Unfortunately the clients I work with are sadly behind in their uses of technology. The other day I did a training for a client that has blocked work access to all online e-mail (gmail, Yahoo, etc.), despite the fact that this client is supposed to be helping people find work and today's workplace requires that you be able to access e-mail. The staff of this same client could not even tell me their work e-mail addresses because they said they didn't use them. It's hard to talk blogging or wikis with people who haven't accepted e-mail as an indispensable work tool.

Nonetheless, I'm trying baby steps with them, using a wiki to support the training I provided. Not calling it a wiki, because that's information they don't need to have and that would only confuse things, but at least using it so that they can get acquainted with what it can do.

With another client, I'm using Typepad to develop a "Hot Jobs" website that their job developers can use to showcase employment in the area. At first, I won't be including any commenting features, just using Typepad as a way to create a quick website that they can easily update themselves. But eventually I'm hoping that we can move into some of the community aspects of the software as they become more comfortable with using this kind of publishing tool.

One thing I'm learning is to stay away from the social media jargon with these organizations. As soon as I say "wiki" or "blog" or "podcast," they get a bit of the "deer in the headlights" look on their faces and they tend to shut down. Instead, I'm just talking about blogging and wiki software as tools that allow staff to create their own websites, just as Word or Publisher allows them to create a newsletter. I'm not even mentioning the terms, just what the software can do.

I'm also learning to not overwhelm them with the features of what they COULD be doing. That is too scary for most of my clients. They're often looking for reasons to say "no" to anything new, anyway. So I'm trying very hard (and against my own nature) to focus only on the specific features that will address a specific problem they've identified for me. "You need a way to be able to highlight jobs on a daily basis without having to go to a webmaster? There's a tool that will do that for you. Why don't I do a quick prototype for you so you can see how it would look?" Increasingly they say yes and now I have my foot in the door.

Once that door has opened for me, I'm able to sneak in a few more features. The Hot Jobs site I'm  developing--I added in a Wayfaring Map mashup and some video to show them what was possible. These were things that were hard to explain on their own, but within the context of addressing a problem they'd already identified, the features started to make more sense to them. 

I'm finding that this kind of stewardship is really working best with my longer-term clients, although I also try to incorporate what I can in everything I do. I've come to believe that part of my technology stewardship responsibility lies in waking people up to the even the existence of these tools. Although I may not be able to facilitate their implementation in the long run with some clients, at least I've moved things along by making them aware that the tools exist.