Introduction
One take-away from the last week is: We're doing some pretty cool stuff in the Richmond (Virginia) Developer Community. I attended a breakout session on Developer Communities and found the room divided into roughly two groups:
- Those who were active in a thriving local developer community
- Those wanted to be active in a thriving local developer community
After participating in the lively session, a couple fellow MVPs gave me their business cards and asked for more information about what we were doing in Richmond. "I need to blog about this" was my first thought. I'm ashamed to admit I don't know why I haven't thought of it before. But here goes:
On Developer Communities...
I hold the following hypotheses about successful, growing, and thriving developer communities:
- First, you need a team builder.
- You can run a company like a user group, but the inverse is not always true.
- Quality always works.
- People are not resources or assets.
- Don't go away.
Each hypothesis is accompanied by one or more "anti-hypotheses" - clues that you are not participating in a sustainable developer community.
First, You Need a Team Builder
This reminds me of an old Steve Martin routine (some of you are old enough to recall Steve Martin used to do stand-up comedy...) - "How To Become A Millionaire And Not Pay Taxes" (paraphrased):
First, you need a million dollars. Then when the tax man calls you say "I forgot."
That first part sounds deceptively simple, doesn't it? But it's actually hard work earning a million dollars - or building a team.
In Theory...
A Team Builder is someone with a knack or gift or talent or whatever-you-want-to-call-it for identifying people willing to help along with an area where they can do some good. It isn't a dictatorship or even remotely authoritarian. Far from it, the Team Builder is usually the quiet one in the back of the room or along the wall in the meeting that makes the one or two suggestions that cut through the Gordian Knot and suggest the solution to everything without raising their voice. It's up to the group or meeting to realize and acknowledge this is a great idea - and then act upon it.
Anti-hypothesis: If you are currently involved with a developer community where great ideas are ignored for any reason, you are participating in a dysfunctional community.
Team Builders are typically follow-me style leaders, as opposed to go-and-do-that-over-there style leaders. They are actively engaged and mentoring along the way. They get things done initially by doing most of the work, then encourage others to participate and share the workload.
This proves a fantastic model for any type of social instrument. It is not just limited to developer communities. It's organic. It's natural. And it just works.
In local Developer Communities, the Team Builder may initiate things by starting a new group. They may participate in the existing organization, they may attempt to participate and be shut out. They may simply wait until the non-organic, unnatural, dictatorship implodes; and then either start helping or rebuild over the debris. Team Builders have a knack for knowing where they're needed most, and most are extremely patient.
In Practice...
In Richmond, I found myself president of the Richmond .Net Users Group and the Richmond SQL Server Users Group in the summer of 2006. Frank La Vigne and I had restarted the Richmond SQL Server Users Group in May 2006. Although it was a very difficult decision for him, Frank moved to Northern Virginia (we call that area NoVa around here) for better opportunities - personally and professionally.
Frank is a Team Builder. He had started building a team before he left town, and I was part of that team.
Together, Frank and the team were slowly slaying the dragons that held back the Richmond Developer Community. Our Developer Evangelist, G. Andrew Duthie (aka .Net DEvHammer), was a great help getting things going - especially when we decided to put together our first Code Camp in April 2006.
The Key
The key to all this was finding people willing to step into leadership, assume the responsibility, and remain enthusiastically engaged for as long as possible. Simple right? (First you need a million dollars.)
We accomplished this in Richmond by waiting for folks to walk up and ask "How can I help?" My response is always "What do you want to do?" It usually grows from there - organically, naturally.
We've learned we need a minimum of three people in leadership of each group. That allows one person to be sick, on vacation, or out of town and still have a lead and one backup. Each group now has four to six people in leadership. This gives us immense flexibility when it comes to doing additional events - things like last winter's InstallFest.
More importantly, it allows leaders to flow into and out of leadership. Job responsibilities and life in general can leave someone less amenable to participating in User Group leadership. It's imperative to not punish leaders for burning out, in my opinion. They burned out doing stuff for the community - let's not shoot our wounded, let's allow them ample (personal) time and (personal) space to heal. In fact, let's build that into the process. Cool?
Conculsion
The Richmond Developer Community is still a work in progress. We're enjoying more attendance and more active participation - it's so cool to be part of this community!
:{> Andy