I love building tools. I love making hard or tedious things easy. I could build tools all day.

A big company like IBM is perfect for this. Not only is there a lot of infrastructure I can build on top of, but there’s also a large internal market for tools. For example, the community newsletter tool I built for myself turned out to be great for many people too.

New tools that increase productivity free up more time to invest in increasing productivity. Tools that push the envelope of what can easily be done let people imagine what else can easily be done. It’s a virtuous cycle that I’ve loved working with since my first experience of working on Emacs Planner.

Open source and collaboration play a role here, too. Other people’s contributions – a web design, an idea, a Lotus Notes plugin – add so much value and inspire me to build even better tools. When I build tools, I link to where people can get the source code. This means that people don’t have to start from scratch, and they can learn from source code in the field. It’s good stuff. For example, an IBMer in Massachusetts added my bulk tagging code to his Lotus Connections inviter tool after reading the source.

PHP: Make a symbolic link with a .phps ending. (Ex: ln –s index.php index.phps). PHP will display the .phps file as source code. Add a link to it.

For the Java-based tools I’ve been building lately, I link to the project in our internal open source repository.

Tools, collaboration, lots of people who want or need similar things, and infrastructure for sharing… Awesome.

The hardest part of collaboration is getting started.

In the days and weeks and months before you have a critical mass of people on board, your progress can seem very slow. There’s a lot of resistance. People don’t trust your new initiative. They don’t see the value in changing their behaviour. They don’t see the value in working with you. I see that resistance a lot, whether I’m coaching groups on new collaborative tools or helping organizations learn more about changing business trends.

Building a new collaborative initiative is like making a big snowball. You start with a tiny core. You roll it around and around and around in the snow. Then suddenly it starts picking up new snow easily, and it gets bigger and bigger, and it gets easier and easier to roll. But in the beginning, you have to be very careful about using light snow and smoothening it into the right shape.

Here’s what I’ve learned from coaching individuals, teams, communities, and organizations on collaboration:

Find your champions. Don’t be discouraged if adoption is slow. In any group, you’ll find people who adopt new ideas earlier than others and people who influence other people’s opinions. Find those early adopters and influencers, help them make the most of your new tools, and collect and share their success stories. They will inspire other people to explore, and their examples will help other people learn.

For example, when I help a team learn more about wikis so that they can easily create a web-based knowledge repository, I don’t expect that everyone will contribute to the wiki right away. I look for the one or two people who already organize and share information for the group, and I work with them so that they can use the wiki to organize what they know. If other people find it handy, that’s a bonus. These early adopters and influencers help us convince the rest of the team to read the wiki. Over time, others may be inspired to edit and contribute to the wiki themselves.

Focus on immediate personal benefits. As much as possible, show people why your initiative is worth their time and effort. If you conduct a survey, share the results. If you build a discussion forum, make sure someone is responsible for answering questions. If you want people to read your blog, focus on sharing things of value to them. Help people get value from their participation as quickly as possible.

For example, when people start blogging, they often feel discouraged because they don’t get comments from other readers. That’s the kind of social benefit that comes later, after you’ve developed your network. I help people focus on saving time by using a blog as a professional notebook for remembering solutions and ideas, and I help them see that the practice of writing helps them improve their communication skills. Without that immediate personal benefit, many collective initiatives fizzle out.

Make sure you build compelling personal benefits into your initiative. Personal benefits will motivate people to participate, and then they’ll be able to take advantage of the collective value of their participation.

Fully participate in the conversation. Make it easy to give feedback, and show people that you’re listening. Keep people up to date as you act on their suggestions. Ask questions and reach out.

For example, IBM regularly runs large-scale Jams, which are brainstorming discussions across all of IBM. Seeing decision-makers participate in, respond to, and act on the suggestions raised not only energizes the discussion, but lays the groundwork for even more discussion and action in the future. On the other hand, traditional suggestion boxes that stay locked and unacknowledged can sap morale. As you collaborate with others, show people your progress and the results of that collaboration.

Find your champions, focus on people’s immediate personal benefits, and fully participate in the discussion. Good luck!

What collaboration challenges do large teams face? Here are the key problems I often hear from people, organized in a rough flow of how teams encounter them within each category. Can you help me improve this list?

Assets and knowledge

• Large attachments: People feel this particularly strongly in IBM because the system imposes “mail jail” if your mail database goes over a certain size, and it can take hours for people to archive and reorganize their mail in order to accept the attachment. The problem is exacerbated by large distribution lists that include people for whom the attachment is not relevant. Costs: Wasted time, increased server storage costs, increased bandwidth costs
• Knowledge maps: Assets are scattered in different repositories and websites. People don’t have an overview of the different information sources the team uses, what to find where, and what to look at first.  Costs: Wasted time figuring things out again or answering FAQs, duplicate work, duplicate storage, time spent answering FAQs
• Getting knowledge out of people’s heads: When teams start building their knowledge maps, they often realize that much of the knowledge their team relies on has not been written down. Costs: Wasted time figuring things out again or answering FAQs, duplicate work, increased risk of project delay or failure if a team member becomes unavailable. This challenge is usually broken down into:
  • Expertise mapping: Without a shared understanding of team roles, the team can suffer lack of coordination and duplicate work. Even with a rudimentary expertise mapping system such as a list of people and their roles, new team members can begin to find people who may have the assets they need. Without an expertise map, team members must rely on a few well-connected managers or team members to find people, and the process of personal referral can take time.
  • Products and assets: The next step after expertise location is asset-sharing. Without an asset repository of deliverables and working documents that people can reuse, team members may need to keep reinventing the wheel.
  • Experiences, ideas, tips, and best practices: If people can invest in examining and improving their processes and tools, they can share these tips with other team members and contribute towards emerging best practices. Without this kind of reflective practice, however, team members may waste time and miss opportunities due to ineffective or obsolete processes.
• Managing turnover and risk: As new team members come on board and other team members leave or become unavailable (vacation, retirement, sickness, etc.), the team needs to adapt. Without documented processes and easy-to-find assets, new team members can’t work as effectively. Onboarding effectiveness also affects  morale for both new members and existing team members. If team members become unexpectedly unavailable, the project could fail or be significantly delayed. Costs: wasted time, missed opportunities, less flexibility

Interaction

• Meetings: With an increasingly globally-distributed workforce, teams need to learn how to use virtual collaboration tools more effectively. Telephone-only meetings can lead to limited interaction or disengagement. Face-to-face working sessions can incur significant time and financial investments. Costs: Wasted time, travel costs
• Teambuilding: Without traditional team-building events, team members may not feel as vested in their team’s success, or as comfortable collaborating with people they rarely or have never met. Costs: More friction in communication and teamwork, less effective work, less trust, limited growth opportunities
• Communication: Multiple one-way broadcasts can be overwhelming for team members, who may end up ignoring newsletters and other e-mail. Without broad feedback channels, team leaders risk having limited insights and lack of buy-in. Costs: Lack of communication and shared vision, duplicate work
• Peer-to-peer communication: Without a way to communicate with the larger team without being overwhelmed, members may end up collaborating with only a handful of people. They don’t benefit from other people’s experiences or shared resources, and other people can’t build on their work. Costs: Wasted time, duplicate work, more limited growth opportunities

External

• Working with people outside the team: Team members often need to work with people who may not have access to the team’s resources. This collaboration typically involves lots of e-mail. New collaborators may not be aware of the project history or assets. Distribution lists go out of date or are not consistently used. No one has the complete picture of the project. Costs: Wasted time, frequent miscommunications
• Working with people on multiple projects: The problem of coordination is exacerbated when team members juggle multiple projects. Making sure that new collaborators receive all relevant, up-to-date information can take a lot of time if the assets and project decisions are scattered among lots of messages in people’s inboxes. Costs: Wasted time, frequent miscommunication
• Publishing externally-facing information: A team often needs to provide overviews and other information for other groups. Without a single up-to-date collection of information, team members need to find and send the most relevant information each time it’s requested. Costs: Wasted time, inaccurate information
• Regularly coordinating with other teams: A team may need to regularly keep up to date with the work of relevant teams, without being overloaded by updates. Cadence meetings take time and can be difficult to schedule. Without a record of the discussions and other ways to share updates, team members may struggle to identify relevant news in a time-effective manner. Costs: Duplicate or incompatible work, leading to wasted time

Does that resemble what you see? How can we make this list better?

—-

Goal: Map the challenges, look for teams that address these challenges well, make preliminary recommendations based on their practices, and  then help teams identify their priorities and next steps

Real World Strategy wrote of me:

Here is somebody in their mid twenties who has already spent a decade immersed in a world of collaboration and web based networking. As William Gibson said, “The future is already here – it is just unevenly distributed”.

This is interesting, because I’m both leading and following, learning from what’s new and what’s old.

The new: I represent a whole bunch of new ideas we’re still trying to figure out. Many of the things I do helps people imagine the future. Researchers who explore how power users work using our new collaborative tools often interview me (which is great, because I get to find out what they’re working on!). People figuring out virtual leadership look at how I and other people can influence without authority.  My value is not only in the ideas and effort I contribute, but in the questions I ask and the assumptions I help explore.

The old: All that is so small, though, compared to the awesomeness of being in a company where people have been thinking about and working on collaboration for decades. The infrastructure we can build on, the critical mass of talent we have, the way we challenge ourselves to figure out how we can work better and the world can work better—I love that. 

What I identify with the most is this ad:

… except I smile more. ;)

People are teaching me so much. I work on sharing as much of it as possible, and on figuring out how IBM and the world can make the most of the person they are helping me become. I don’t know enough of the organization to make that overall choice yet, but there must be something amazing we can do with the gifts people have given me.

It’ll be a great adventure!

I attended a virtual watercooler session for the IBM CommunityBuilders community yesterday afternoon. It was great hearing from other people who are also figuring out how to help others use social networking tools to build community. We’re dealing with many of the same issues: encouraging adoption, facilitating participation, keeping up to date. One of the incredible things about working in a huge company like IBM is being able to tap a breadth of perspectives and learn from so many people around the world.

There’s been such a big shift over the past few years. The questions we get from clients and coworkers alike used to focus on what and why and how, like “What’s Twitter? Why would anyone use it? How do I get started?” We still get questions like that, but more interesting questions have emerged. Now that enough of the tools and enough of the culture has taken root, we can start looking for interaction patterns. We can look at how communities and teams use combinations of tools, how that influences their processes and results, and how the discussions flow.

There’s so much that still needs to be explored. I want to help figure out how we can more effectively connect and collaborate, and that work is just beginning.

When Jennifer Okimoto pinged me about possibly putting together a presentation for Web 2.0 Expo 2009 in San Francisco, I perked up at the possibilities. I had been intimidated by the list of previous sessions (who am I to tell all these experienced techies and businesspeople about Web 2.0), but Jen and I could definitely share lots of lessons learned about Web 2.0 in a large enterprise, bridging generations and geographies.

So I started a Google Doc for the abstract. After several invitations, she finally got access to it, and we brainstormed and refined our abstract through the shared document. It was a lot of fun, particularly coming up with a good title. I think my fondness for alliterative, catchy titles showed: “Linking the Leviathan?” “Moving the Mountain?”

This should be easier, though. I should be able to right-click on a person in our instant messaging client and say “Collaborate”, pick a document, work on it in realtime, be able to invite other people in, and have that persist.

Someday…

Today, I want to talk about grassroots adoption, when you’re trying to influence people around you to try out something new–a new tool, a new idea, a new way of working–without dictating to people. I hope that I can help you get a better sense of where other people are, what might be stopping them from moving forward, where you are, and how you can get better at helping other people learn.

I’m interested in this because as a technology evangelist, I’ve talked to a lot of people about social tools like blogging and wikis. Over the next few blog entries, I want to share some of the objections that I’ve come across. I also want to share some of the methods I’ve tried and observed.

But first, let’s talk about what technology evangelism is. You might be wondering why I use the term “evangelism”, considering its religious roots and sometimes negative connotations.

For me, evangelism has that hint of being more than just a dry list of facts. You want to inspire people to action, and you want to do this in a way that sticks even when you’re not around.

The technology you want to promote is not going to be a perfect fit for everyone or every time. Technology evangelism is not about convincing people that your way is the right way. It’s about showing people what their options are, helping them find something that fits them, and helping them learn how to make it part of their work or their lives. (I forget this sometimes, too.)

So if a technology isn’t going to be a perfect fit for everyone immediately, how can you encourage grassroots adoption?

One way is to scatter the seeds as widely as possible. If you reach out, you might find a lot of people who can benefit from the technology you want to promote. Help them, and their success stories and influence will help you reach out to even more people.

You might not have that option. You might have been asked to help a team get up to speed on a tool. You might want to explore a collaborative tool, but before you can take advantage of that tool, you’ll need to get other people on board too. (After all, you can’t collaborate on your own.)

This is where it can get frustrating.

Next post on Monday (or earlier =) ): Sowing seeds: Five common objections