sdclan


Uh oh, I’m a Technology Steward — Part 1: Four Technology Stewardship Design Principles

November 22, 2011 | LND | Methods & Tools |

Share

Rating: none

By Nancy White

nancy_whiteHow many times have you been faced with coordinating work, knowledge sharing or learning with a colleague who is not close by?  Of course, we have the magic of the internet, right? Which knits us across countries and contexts, right? Well, it could, but most of us lack the magic wand to make this happen flawlessly. There is a useful practice to picking and using technology in service of groups called technology stewardship. Let’s take a peek into tech stewardship together. We will focus here on definition and some design principles, and look at implementation practices in a second blog post.

Definition of tech stewardship

“Technology stewards are 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.” (Wenger, White, Smith, 2009, Digital Habitats: stewarding technology for communities.)
So, you have enough technology know how to try things, but some might say only enough to be dangerous. You know your people well, but do you want the responsibility for picking tools? Sometimes you are all they have. So here are a few tips for being a useful technology steward working in a global development context… even if you are an accidental steward! These tips are focused for people working in a global development context — in other words those facing bandwidth, electricity and other access issues!

Four Technology Stewardship Design Principles

Technology stewards often don’t have a lot of time to work on this. So let’s boil down a few principles to help us focus on what’s practical.
First, a bit of context. You are not the IT department. You may have some IT help or are on your own. If you have IT support, your main job will be to represent the perspectives and needs of your group. Face it, sometimes we speak a different “language” than IT, so bring real stories about activities the technology needs to support, not a list of features. This helps the IT folks translate it to their language because FEATURES don’t make a great experience. Using features in a way that provides value to the group is what matters.
If you’re on your own use these principles to take little steps. Learning from small, fast failures is better than failing big and slow and really end up badly! Dave Snowden calls this “Safe-Fail Experimentation.” Read more about it here and here.

Identify the activities needing support

“We need to collaborate” or “we need to learn together” is not specific enough for good technology stewardship. More useful is to identify particular activities you need to support. For example, a distributed community of practice may need an ongoing conversation space to ask and answer questions. A research team may need a place to share citations. A work team may need a way to track task progress. For more on how to identify and prioritize activities check out the Activities Spidergram tools we’ve developed over the past few years. You can see a presentation about this here. The bottom line: prioritize 2-3 key activities, then ask what tool(s) can support these activities. The tool landscape is always changing, so I like to ask my networks and communities what they are using and use THEM to help me sort through options and get their feedback based on tool use, not some vendor description. There is no way I can keep up with tool evolution by myself.

Start where people already are and build bridges

Research in the use of social media in organizations (See the work of Gartner and Marcia Connor) shows that if the tool you choose is not in people’s existing workflow, the chances of voluntary adoption are low. This is why email is still so dominant — it is in our workflow, whether we like it or not! However, we can define workflow both in terms of people’s jobs and the rest of their lives. Are they on Facebook, Twitter, or one of Google’s applications? Are they on their mobile phones more than their computers? Use this information to guide your selection of initial tools. Groups that have real, tangible needs to interact will then be happier to add or shift to other tools if you start in a comfort zone. Think about it. This is building both useful practice and trust!

Start simple and iterate

It is easy to get caught up in “finding the best tool or platform” (a collection of tools bundled together with a single sign on for users). Experience teaches us that people rarely use all the tools and often stray outside the platform to find more suitable ones. So start with one of your identified activities and build on existing tools that people use, or experiment with deploying a new one. Set a time frame and a small, specific goal for people to try the tool. It is best if that goal is relevant to the work people have to do together. Debrief it half way and adjust as needed. Review and evaluate at the end and use your results to make your next design and practice decision.

Design for the group (not just yourself!)

I said “start where people are.” I did not say “start where YOU are!” One of the traps tech stewards fall into is designing for the group based on their own preferences and patterns, rather than taking some time to understand the preferences of others. Have some conversations with key members. Better yet, if you can watch them at work and SEE what they use, you will gain some really useful insights to guide you: we often don’t accurately represent how we work — it is mostly unconscious. When someone else observes, we become more aware ourselves. People usually find this a very engaging process and it already impacts their own collaboration and work practices. A double bonus!

An example

So how do these principles work in practice? Here is a list of tools the Nile Basin Development Challenge used (http://nilebdc.org/comms-tools/). Note how there is clarity on what the tool was used for (activities).
For project members and collaborators:

Learn More

Here are some additional resources. Please share your thoughts, questions or other resources!

No Comments

Leave a Reply