Wednesday, May 27, 2009

Building Community

I recently read a blog post where community is described in the following way:
It is a requirement that if you’re a member of the community, and one day you stop showing up, people will come looking for you to see where you went.
I think there's a lot of truth to that. A community is more than simply a gathering of people in the same place. It is more than a lecture hall, more than a tutoring center. For you to belong to a community, your leaving must affect it.

So if you want a community in your user group, you need to think beyond putting people in a room and having them learn. You need to pull them in, and connect them to others.

To be a good community facilitator, then, you need to know enough about your members to know who would gain a lot from knowing each other - that's the networking component - but then also who would just get along really well. Of course at the same time you're introducing some members, the rest will hopefully be socializing on their own. All this is core to your group even if no one discusses a word about technology.

Finally, don't forget about your new members! A meeting of old friends is great but it can lead to newbies feeling left out or unwelcome. Best is to ask some of your longer-term members to help you make sure no one leaves without a personal welcome. That way your community will grow and you'll also build other leaders.

(P.S. The quote is from an old blog entry by Adam Fields complaining about the lack of connection between users on many websites. But of course real-world groups can suffer from the same problem, if we aren't careful - and I think it's even more deadly.)

Thursday, May 21, 2009

We are a part of history

I recognize I'm exceedingly late to any discussion on women in computers that started after the GoGaRuCo kerfluffle - that's fine by me. I'm not going to express an opinion about that particular event. But I would like to remind people of a few details:

* 3.5 generations ago - women received the vote in the US - my great grandmother gained the right to vote as an adult.
* 2 generations ago - The Feminist Mystique was published, NOW founded. My mother was in elementary school.
* less than 1 generation ago - in 94 - women made up just 8% of the faculty at MIT's School of Science (It rose to 18% in '02, not sure of the current numbers. It's clear that in 2005 the problem hadn't been solved at Harvard though.)

The point is that we are here, now, part of a larger story on women's issues. I think it's easy to forget that. When we ask the question "why are there not more women at tech conferences," the question is important and relevant - but we shouldn't be shocked that we don't have the answer yet.

Secondly, the recent focus and concern on the number of women in particular fields is not limited to the software industry. Across many disciplines, from science and law to golfing and race car driving, people who consider themselves living in an enlightened society are looking around and wondering why there aren't more women there or why women are being treated differently.

As a society, we continue to break new ground. Let's not get disheartened along the way by the way things are. Instead, when I am reminded of the history that comes before us, I can only consider the current state as a call to action -- things can change, things will change. and they'll change faster if we continue to care about the problems, and talk about them and investigate them in public forums.

Case Studies vs. Practice Talks

Case study talks are almost always boring. The premise behind them I guess is that we, the talk attendees, are looking for validation that the tools we use are great and that they can be effective in places where other tools might not be. But I don't look for validation from my talks - I look for information I can use, or if nothing else, a good story I can take home.

Case study talks are often light on both.

Compare this to a Practice talk. By that I mean a talk about a practice - a particular, detailed set of tools or methods that someone uses every day at their job and helps them be effective. In my experience, these presentations tend to be very well received with a good set of questions. It's likely that the talk is going to include some unfamiliar piece of technology but you can be sure that any questions about details will be answered with "In my experience..."

Of course many talks are practice talks in disguise. But "in my experience" the presenter will do well to let as much of the practical information they have about the topic at hand to bleed through as makes sense given time and the talk level. That will help their introductory talk or case study transition into something more powerful.

Thursday, May 7, 2009

Asking for help

If your user group becomes moderately successful, you may find yourself overwhelmed by the number of tasks that it takes to keep all the balls you're juggling going. As your life becomes busier, it may be difficult to pay attention to the small things that your user group needs - updating web pages, reaching out, etc.

If this has happened to you, the answer is obvious: ask for help.

What may not be obvious is how to do ask effectively. From my experience, it doesn't work to simple send a broadside, especially in a user group setting - "I need help, if anyone wants to get involved, please let me know." This is a good first step, in that it results in you admitting that you need help, but it's unlikely to be effective. From that pitch, your members see none of the benefits of volunteering and all of the costs.

So how do you get the help you need? There are several options. The first is simply to ask people personally for specific favors. When you ask someone personally for some specific thing, taking into account their skills and connection to the group, it is much easier for the person to say yes. So I've found that by splitting up the upcoming meeting into small tasks that I could request from people who have attended multiple meetings and shown their interest, we are able to manage the meeting even as my personal life has gotten much busier.

But if you need long-term help, you may need to turn to other methods. One possibility is to formalize your organization, with a mission statement, treasurer, etc. In that case, you can hope that people will volunteer for the positions, and accept the obligations that those positions create. Transitioning to this sort of formalized system isn't one where I have little experience (although I've been involved with them), and I'd love to hear stories about making that transition work.

Whether you create such a formal structure or not you'll have to sell the volunteers on volunteering. So don't forget that helping to organize a tech community _does_ come with real advantages! You'll have to figure out what advantages your group has, but whatever they are, you should remember to mention them - people have to be choosy about how to spend their time so you need to sell people that they're going to gain something from the process, or if you can't promise that, then at least promise fun.

And really, I think organizing a user group should be both. That's why I do it.

P.S. One other way to avoid being overworked is to only grow your user group based on your member suggestions. Pare down your group to what you can manage, and then encourage anyone who wants to do more to take their ideas and run with them with some support from you. If any members of your group have energy this can be one way to grow your group in a way your members are by definition going to like. Your job becomes then becomes that of a facilitator to a self-organizing group. Sounds nice if you can get your group to do it - and it works for NextNY.

Sunday, May 3, 2009

User Group Leadership Summit

I recently returned from the North East User Group Leadership Summit. This was a day-long even hosted by Microsoft and O'Reilly aimed at gathering the organizers of user groups in the northeast to discuss the common issues that affect user groups. The event was run in an "unconference" style that allows the attendees to propose the topics that are interesting to them and then discuss them with other interested people. Afterwards, there was a reception.

So much for the facts. Was it worth the time?

In short: absolutely. The range of user groups attending was large - from those with 8 regular monthly attendees to those with hundreds. Those who had successful groups and innovative ideas were happy to share with those who were starting out. Also, the unconference style is perfect for a group of natural self-organizers like user group leaders. I'll be posting some of the lessons I've taken out of the unconference in separate posts. (You can see the summaries that came out of the sessions on their wiki).

However, a large part of the benefit of the conference was the networking that was taking place - and it seemed to me this was especially true for those groups located in the Boston area. As the reception in the evening wore on, one could see clusters of related groups forming. I overheard these groups talking about how to share resources, speakers, and more. Connections in the Boston tech community that didn't exist before have sprung up due to this event - people who are passionate about the Boston tech community now have formed a community.

I'd like to see these same connections form around the country. This type of event benefits particularly from having many local meetings as opposed to one national one, due to the benefits of simply getting tech leaders in the area to meet and exchange information in ways they might not do if when siloed into their particular communities. I think it fills a need that other attempts to get community members to cross technologies boundaries don't.

So I suggest you go and make this happen in your area - I think you'll find that all you need is a space and a small amount of sponsorship. If you're in New York City or the surrounding area, let me know - we are already starting to plan for one here. If you'd like to talk about the details of planning one in your area I'd be happy to talk about that as well.

Thursday, April 30, 2009

Building a Community

I'm not an expert on building community. Certainly not like Jono Bacon, Ubuntu community manager and author of the upcoming book The Art of Community.

Instead, I'm still in the process of building a tech community. I'm trying to group my local group from something small to something great. To me that means, among other things:

* Great presentations from our members
* Ongoing collaborations between members on projects
* A path to grow from a new community member into a guru
* Members contributing to national conferences
* A feedback loop from local corporations using our tech to our group.
* Coding sprints, local conferences, national presenters

Working towards getting all of that set up is a challenge! Mostly, however, I want there to be a level of energy that is self-sustaining. Right now I'm contributing a lot of energy in order to get that level going, but I'm trying to figure out how to transition that to something where my position is tangential to the longevity of the group. So that's one challenge.

Of course there are many, many other issues. Many of them are to generic to _all_ communities, but plenty of them are specific to technical user groups - coding sprints, code reviews, lightning talks, tutorials, and more. This blog is devoted to information and ideas covering these issues, as well my experiences putting those thoughts to work.

Thanks for checking in, and I hope you find my blog useful, and please join in! I'm looking forward to talking with you.