AndyLeonard.blog()

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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.

Angry Pets

Peeves make lousy pets but I have a few nonetheless. One of them is hearing people referred to as “resources” or “assets.” Time is a resource. Office furniture is an asset. People are people. We deserve our own category in the enterprise infrastructure. We’ve done nothing to deserve being lumped in with office furniture and time (not that there’s anything wrong with office furniture or time).

User Groups can fall into this trap of corporate-think. It’s easy to move from appreciating volunteerism to depending on people to making demands of their time, talent, and energy. It’s a slippery slope if ever there was one.

Developer community volunteers are the types of people who are drawn to help others. Most of the time they initiate their work in the community by either approaching an existing group or starting a group themselves. But then life intrudes. Things change and stuff happens. A large project begins at work or across the country. A family member becomes ill. The volunteer gets married or has a child.

Before you know it, the website hasn’t been updated in a couple months and no one has received a newsletter for a quarter. A negative spiral sets in as the volunteer starts getting complaints on top of their growing guilt. It’s ugly. This is how User Groups implode.

The solution? Backup plans. The ultimate backup plan? A succession plan.

Anti-hypothesis: If your user group doesn’t have a backup person for each activity and a succession plan, you are participating in a dysfunctional community.

Backup planning means that every dotted line – real or virtual – the volunteer signs is accompanied by another signature on an adjoining dotted line. No man is an island. No one stands alone. When something goes awry or comes up or a volunteer begins to feel the drain, the other person steps up. It should be a no-questions-asked kind of thing. You call. They go.

There should be no visible difference to the attendees of the meeting, Code Camp, or function. Now I know that was a silly statement – of course there’s going to be a difference. A different person is volunteering. A better way to say it is: There should be a minimal (or no) drop-off in Team Building, The Show, or the Quality. (Where have I heard those topics mentioned?).

Succession planning is the ultimate backup plan. It is imperative that leaders begin succession planning as soon as they assume a leadership role. “Everything was great while _____ was here, but then she got a new job and everything fell apart” is not a good legacy. Worse, it’s a disservice to the community you serve as a leader.

The Richmond Saga, Part Four

Early during one change of leadership in the Richmond Developer community, our website went dark. We scrambled (and by “we” I mean Frank La Vigne, who personally paid the bill) and got it back online. A couple months later the site went dark again… just before our first Richmond Code Camp. Perfect timing. This time the issue wasn’t with hosting but with the domain.

Have you ever tried to change the domain ownership away from the person who owns it to yourself?

Don’t. Especially if you cannot reach the owner of the domain.

The previous leadership, as gifted and talented as they were, had not considered succession planning. As a result we were locked out of our most powerful means for communicating to our group. To say it hurt our feelings is an understatement. The new leadership looked like helpless dolts.

“Never again,” we vowed. This will not happen to us, nor any that follow us, again.

Richmond User Groups Corporation owns the websites for the Richmond .Net Users Group and Richmond SQL Server Users Group. We own the domains and we pay the hosting costs. The sites will not go dark – never again.

Conclusion

Remember, user groups are championed by volunteers. Most of the time these people give of themselves in time, talent, and money – even when there is sponsorship money available.

If you see room for improvement, that is a clue. You should get involved. Pitch in and help out. You will learn and grow and your developer community will be stronger because of your activity!

:{> Andy

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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.

Angry Pets

Peeves make lousy pets but I have a few nonetheless. One of them is hearing people referred to as “resources” or “assets.” Time is a resource. Office furniture is an asset. People are people. We deserve our own category in the enterprise infrastructure. We’ve done nothing to deserve being lumped in with office furniture and time (not that there’s anything wrong with office furniture or time).

User Groups can fall into this trap of corporate-think. It’s easy to move from appreciating volunteerism to depending on people to making demands of their time, talent, and energy. It’s a slippery slope if ever there was one.

Developer community volunteers are the types of people who are drawn to help others. Most of the time they initiate their work in the community by either approaching an existing group or starting a group themselves. But then life intrudes. Things change and stuff happens. A large project begins at work or across the country. A family member becomes ill. The volunteer gets married or has a child.

Before you know it, the website hasn’t been updated in a couple months and no one has received a newsletter for a quarter. A negative spiral sets in as the volunteer starts getting complaints on top of their growing guilt. It’s ugly. This is how User Groups implode.

The solution? Backup plans. The ultimate backup plan? A succession plan.

Anti-hypothesis: If your user group doesn’t have a backup person for each activity and a succession plan, you are participating in a dysfunctional community.

Backup planning means that every dotted line – real or virtual – the volunteer signs is accompanied by another signature on an adjoining dotted line. No man is an island. No one stands alone. When something goes awry or comes up or a volunteer begins to feel the drain, the other person steps up. It should be a no-questions-asked kind of thing. You call. They go.

There should be no visible difference to the attendees of the meeting, Code Camp, or function. Now I know that was a silly statement – of course there’s going to be a difference. A different person is volunteering. A better way to say it is: There should be a minimal (or no) drop-off in Team Building, The Show, or the Quality. (Where have I heard those topics mentioned?).

Succession planning is the ultimate backup plan. It is imperative that leaders begin succession planning as soon as they assume a leadership role. “Everything was great while _____ was here, but then she got a new job and everything fell apart” is not a good legacy. Worse, it’s a disservice to the community you serve as a leader.

The Richmond Saga, Part Four

Early during one change of leadership in the Richmond Developer community, our website went dark. We scrambled (and by “we” I mean Frank La Vigne, who personally paid the bill) and got it back online. A couple months later the site went dark again… just before our first Richmond Code Camp. Perfect timing. This time the issue wasn’t with hosting but with the domain.

Have you ever tried to change the domain ownership away from the person who owns it to yourself?

Don’t. Especially if you cannot reach the owner of the domain.

The previous leadership, as gifted and talented as they were, had not considered succession planning. As a result we were locked out of our most powerful means for communicating to our group. To say it hurt our feelings is an understatement. The new leadership looked like helpless dolts.

“Never again,” we vowed. This will not happen to us, nor any that follow us, again.

Richmond User Groups Corporation owns the websites for the Richmond .Net Users Group and Richmond SQL Server Users Group. We own the domains and we pay the hosting costs. The sites will not go dark – never again.

Conclusion

Remember, user groups are championed by volunteers. Most of the time these people give of themselves in time, talent, and money – even when there is sponsorship money available.

If you see room for improvement, that is a clue. You should get involved. Pitch in and help out. You will learn and grow and your developer community will be stronger because of your activity!

:{> Andy

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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. 

Every Square Is A Rectangle…

… but not all rectangles are squares. You can run a company like a user group, but the inverse is not always true. You can tune a piano but you can’t tuna fish. What do I mean by all this?

User Groups are big extended communities – almost a family to some members. Meetings are anticipated. Folks even get excited about the newsletter emails! Communication is required, and it must be clear, concise, and consistent.

Just like in corporations.

But there are distinctions to be made. User Groups are nearly always volunteer efforts – even when there is sponsorship money involved. As such, leadership has to exercise patience and maturity when asking things of membership or other leaders. Demands are verboten. Ultimatums are useless. Authority is an honor.

Anti-hypothesis: If leadership wields authority by making demands and delivering ultimatums, you are participating in a dysfunctional community.

Leadership is a privilege.

When there is money involved, the collection and dispersing of finances must be transparent to leadership at a minimum, and should be reported to membership yearly.

More Of Our Story

When we organized the first Richmond Code Camp, companies in the area began asking us about sponsoring User Group meetings. Through sheer serendipity, one company in town pretty much had a lock user group sponsorships. As president of both groups, I now began fielding embarrassing questions about the situation.

At the same time, I wanted to give away cool swag at Code Camps. When I say “cool swag” I mean an X-Box. Although a mediocre salesperson, I could not convince Code Camp contributors to contribute an X-Box. So I began searching for an alternative… “maybe we could buy an X-Box if only we had some money” I thought… (which again reminded me of the Steve Martin shtick mentioned in the first post).

Darrell Norton is an MVP with an MBA from Richmond. If you have a local MVP who has an MBA you already know this: those guys come in handy now and then! Darrell had written a business plan for developer communities years earlier while working in Virginia’s Tidewater region. He circulated it some back then and got at least one taker: a user group from NoVa. It had worked very well for them.

The plan consists of multiple tiers of sponsorship: platinum costs the most but keeps your logo on our website and all communications for a year. Platinum sponsors also get to choose two monthly meetings to sponsor, for which they provide food for the attendees. Gold, Silver, and Bronze levels cost progressively less and offer progressively less to the sponsor.

I approached the company that held the lock on Richmond User Groups and laid out the plan. They had steadfastly supported the developer community for three years. I was going to open up the groups to outside sponsorship using Darrell’s plan, and I would give the company holding the lock three years at the Platinum level for both the Richmond .Net Users Group and the Richmond SQL Server Users Group – free. They agreed.

With our first sponsorship check in late 2006, I formed Richmond User Groups Corporation using LegalZoom. An S-Corporation in the Commonwealth of Virginia, we became a not-for-profit corporation and did not file for charitable status. This preserved the option of selling stuff (sponsorships).

If you plan to follow a similar road, you definitely need to check on the laws in your state, province, and/or nation to see what’s allowed and what isn’t.

The corporation sheilds the officers and crew of the User Groups and Code Camps from some legal situations. It also allows our sponsors to write off the money they send to us for sponsorships as a business expense. Best of all, it makes us look (and feel and behave, believe it or not) like professionals.

In addition, the websites for Richmond User Groups are wholly-owned by the Richmond User Groups Corporation. Remember (from the first post in this series), leaders can flow into and out of leadership. When they leave, the websites are not disrupted – the leaders do not own them, the corporation does.

All that is required when a leader moves away is a change of corporate officer titles. Done and done.

Conclusion

Perhaps incorporating isn’t the way for you to go. Regardless, remember the cool ideas practiced in user groups will work in your corporation. Communities work, people are social (even us geeks!) and want to belong!

:{> Andy

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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. 

Every Square Is A Rectangle…

… but not all rectangles are squares. You can run a company like a user group, but the inverse is not always true. You can tune a piano but you can’t tuna fish. What do I mean by all this?

User Groups are big extended communities – almost a family to some members. Meetings are anticipated. Folks even get excited about the newsletter emails! Communication is required, and it must be clear, concise, and consistent.

Just like in corporations.

But there are distinctions to be made. User Groups are nearly always volunteer efforts – even when there is sponsorship money involved. As such, leadership has to exercise patience and maturity when asking things of membership or other leaders. Demands are verboten. Ultimatums are useless. Authority is an honor.

Anti-hypothesis: If leadership wields authority by making demands and delivering ultimatums, you are participating in a dysfunctional community.

Leadership is a privilege.

When there is money involved, the collection and dispersing of finances must be transparent to leadership at a minimum, and should be reported to membership yearly.

More Of Our Story

When we organized the first Richmond Code Camp, companies in the area began asking us about sponsoring User Group meetings. Through sheer serendipity, one company in town pretty much had a lock user group sponsorships. As president of both groups, I now began fielding embarrassing questions about the situation.

At the same time, I wanted to give away cool swag at Code Camps. When I say “cool swag” I mean an X-Box. Although a mediocre salesperson, I could not convince Code Camp contributors to contribute an X-Box. So I began searching for an alternative… “maybe we could buy an X-Box if only we had some money” I thought… (which again reminded me of the Steve Martin shtick mentioned in the first post).

Darrell Norton is an MVP with an MBA from Richmond. If you have a local MVP who has an MBA you already know this: those guys come in handy now and then! Darrell had written a business plan for developer communities years earlier while working in Virginia’s Tidewater region. He circulated it some back then and got at least one taker: a user group from NoVa. It had worked very well for them.

The plan consists of multiple tiers of sponsorship: platinum costs the most but keeps your logo on our website and all communications for a year. Platinum sponsors also get to choose two monthly meetings to sponsor, for which they provide food for the attendees. Gold, Silver, and Bronze levels cost progressively less and offer progressively less to the sponsor.

I approached the company that held the lock on Richmond User Groups and laid out the plan. They had steadfastly supported the developer community for three years. I was going to open up the groups to outside sponsorship using Darrell’s plan, and I would give the company holding the lock three years at the Platinum level for both the Richmond .Net Users Group and the Richmond SQL Server Users Group – free. They agreed.

With our first sponsorship check in late 2006, I formed Richmond User Groups Corporation using LegalZoom. An S-Corporation in the Commonwealth of Virginia, we became a not-for-profit corporation and did not file for charitable status. This preserved the option of selling stuff (sponsorships).

If you plan to follow a similar road, you definitely need to check on the laws in your state, province, and/or nation to see what’s allowed and what isn’t.

The corporation sheilds the officers and crew of the User Groups and Code Camps from some legal situations. It also allows our sponsors to write off the money they send to us for sponsorships as a business expense. Best of all, it makes us look (and feel and behave, believe it or not) like professionals.

In addition, the websites for Richmond User Groups are wholly-owned by the Richmond User Groups Corporation. Remember (from the first post in this series), leaders can flow into and out of leadership. When they leave, the websites are not disrupted – the leaders do not own them, the corporation does.

All that is required when a leader moves away is a change of corporate officer titles. Done and done.

Conclusion

Perhaps incorporating isn’t the way for you to go. Regardless, remember the cool ideas practiced in user groups will work in your corporation. Communities work, people are social (even us geeks!) and want to belong!

:{> Andy

Introduction 

One take-away from the MVP Summit 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:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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

Introduction 

One take-away from the MVP Summit 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:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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

Introduction 

One take-away from the MVP Summit 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:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. 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

The transcript of the first few minutes of the .Net Rocks Show on Database Testing is in the new issue of CoDe Magazine!

Coincidentally, I was presenting on the topic of Database Testing in Roanoke, VA a couple weeks back when the Roanoke Valley .Net User Group received their copies of CoDe Magazine. Robin Edwards (aka Geekette) asked at the end of the meeting “How come you didn’t tell us you’re in CoDe?” I had no idea.

But it’s really cool!

Speaking of CoDe Magazine, I got to meet Markus Egger at the MVP Summit last week – cool guy!

:{> Andy