On Developer Communities: The Sponsorship Plan

A Follow-up To My “On Developer Communities” Series …

I have received requests about how we approach sponsors for User Group sponsorship. I have posted the Sponsorship Document we sent to potential sponsors in 2008 here. Registration is required. It’s my site and I leave you alone… mostly.

This will not work everywhere but it works well in Richmond. If this helps, great. If not, perhaps it will stir up some ideas for something that will help. Either way – enjoy!

I will likely have one more post in this series sometime later. I am coordinating with our very first sponsor to produce a Case Study that describes how sponsoring our user groups has helped their organization. I specifically asked this sponsor to think about ROI. I will likely post the resulting CS on my site and include a link in the follow-up post.

I believe this information will be valuable to anyone attempting to adopt a sponsored User Group model.

:{> Andy

On Developer Communities: The Sponsorship Plan

A Follow-up To My “On Developer Communities” Series …

I have received requests about how we approach sponsors for User Group sponsorship. I have posted the Sponsorship Document we sent to potential sponsors in 2008 here. Registration is required. It’s my site and I leave you alone… mostly.

This will not work everywhere but it works well in Richmond. If this helps, great. If not, perhaps it will stir up some ideas for something that will help. Either way – enjoy!

I will likely have one more post in this series sometime later. I am coordinating with our very first sponsor to produce a Case Study that describes how sponsoring our user groups has helped their organization. I specifically asked this sponsor to think about ROI. I will likely post the resulting CS on my site and include a link in the follow-up post.

I believe this information will be valuable to anyone attempting to adopt a sponsored User Group model.

:{> Andy

On Developer Communities: Hangin’ Around

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.

Keep On Truckin’

The secret key to growing a developer community is (drum roll please): Keep it going.

That sounds a bit anti-climatic, doesn’t it? But this is what I’ve been writing about for five posts now: The details of how to keep it going. This is all well and good when things are going peachy. But it’s in the darkness that the light shines brightest.

There will be darkness. Some days things will not get done. There will be gaps and some people will be disappointed and others will leave the group. A vociferous minority will fire off emails or blog posts describing their disappointment as they go.

They will name names and call down fire. It will not be pretty.

I think it was Winston Churchill who said “If you’re going through hell, keep going.” The gist is simple: When the going gets tough, get tough right back.

Anti-hypothesis: If your user group leadership does not respond to criticism well, you are participating in a dysfunctional community. 

If it was easy, anyone could do it. But it’s not easy, and therefore requires an impassioned developer community advocate to see the job through. You’re going to make mistakes – we all do. You’re going to have to deal with jerks. It’s part of the job my friend.

Conclusion

My Granny used to tell me: “Boy, God gave you a backside so you’d have somewhere to land when you fall.” The moral? You will fall down. Get back up again. Keep going and do not go away, and just watch what happens!

:{> Andy

On Developer Communities: Hangin’ Around

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.

Keep On Truckin’

The secret key to growing a developer community is (drum roll please): Keep it going.

That sounds a bit anti-climatic, doesn’t it? But this is what I’ve been writing about for five posts now: The details of how to keep it going. This is all well and good when things are going peachy. But it’s in the darkness that the light shines brightest.

There will be darkness. Some days things will not get done. There will be gaps and some people will be disappointed and others will leave the group. A vociferous minority will fire off emails or blog posts describing their disappointment as they go.

They will name names and call down fire. It will not be pretty.

I think it was Winston Churchill who said “If you’re going through hell, keep going.” The gist is simple: When the going gets tough, get tough right back.

Anti-hypothesis: If your user group leadership does not respond to criticism well, you are participating in a dysfunctional community. 

If it was easy, anyone could do it. But it’s not easy, and therefore requires an impassioned developer community advocate to see the job through. You’re going to make mistakes – we all do. You’re going to have to deal with jerks. It’s part of the job my friend.

Conclusion

My Granny used to tell me: “Boy, God gave you a backside so you’d have somewhere to land when you fall.” The moral? You will fall down. Get back up again. Keep going and do not go away, and just watch what happens!

:{> Andy

Richmond Code Camp 2008.1 is Saturday!

Richmond Code Camp 2008.1 is Saturday, 26 Apr 2008! This is our fifth Code Camp in two years – we’re so excited! They just keep getting bigger, better, and more fun.

Kevin Israel and the gang have done an outstanding job organizing this event – kudos to the entire team:

I helped some too. 😉 This is going to be a cool event – check out this schedule!. If you’re going to be in the Richmond area Saturday, register and attend! It’s free!

And check out the cool contributors! (Thanks Contributors!)

:{> Andy


 

On Developer Communities: People Are People

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: People Are People

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: Quality is Job Zero

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.

Build Quality, Quantity Will Follow

There’s the temptation to go after big numbers right out of the chute. Like many temptations, the consequences bear consideration. If you establish a pattern of delivering quality, word will get out – fast. Faster than you could spread it yourself. It’s amazing how fast news of your quality will travel through your community.

There’s nothing wrong with big numbers to start with. Just remember that sustainability lies with quality. Folks will not continue to show up if you do not stage a quality show. That’s right, I said “show.” A User Group meeting is a production. It needs to be treated as such.

Communicate an agenda at least one week before the event. Include everyone who is participating in the event – the speaker, group leadership, sponsor, facilities liaison – everybody. Make sure everyone knows what’s going to happen during the meeting, but also include the pre-meeting agenda: when does the food arrive? When do we test the presenter’s laptop? Let’s do that stuff before the meeting begins!

Anti-hypothesis: If your user group does not value quality, you are participating in a dysfunctional community.

Give the speakers and sponsors time slots and ask them to remain within them.

Quality presenters. Quality presentations. Delivered with professional quality. Quality, quality, quality!

For some, quality is Job One. We’re geeks – quality is Job Zero!

Quality in Richmond

Late last year we started our Richmond User Groups 2008 Sponsorship Campaign. We had a lot of response. We turned down a few sponsors, in fact.

Once the promise of money appeared on the horizon, I sent an email to the leadership of the Richmond SQL Server Users Group that read something like this: “Hi Guys! We are going to have money this year. What do you think we should do with it? I think we should use it to buy and give away cool swag!”

The responses were along the lines of: “Andy, Andy, Andy. We need to use the money to bring in better speakers with cooler presentations, not silly old swag!” They were correct. (This, by the way, is an example of Quality Communication… )

In 2008, I started the year off in January with a presentation on using Change Data Capture with SSIS 2008 to do Incremental Loads in CTP5. It was a big hit. We followed that meeting with a Brian Knight presentation on Data Mining in February, Kevin Viers on an overview of SQL Server 2008 in March, and Adam Machanic on Highly Concurrent Application Development in April.

Average attendance soared from about 20 people to over 50 people each meeting! As Foghorn Leghorn says: “Figures don’t lie.”

Conclusion

Remember, build quality and quantity will follow. 

:{> Andy

On Developer Communities: Quality is Job Zero

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.

Build Quality, Quantity Will Follow

There’s the temptation to go after big numbers right out of the chute. Like many temptations, the consequences bear consideration. If you establish a pattern of delivering quality, word will get out – fast. Faster than you could spread it yourself. It’s amazing how fast news of your quality will travel through your community.

There’s nothing wrong with big numbers to start with. Just remember that sustainability lies with quality. Folks will not continue to show up if you do not stage a quality show. That’s right, I said “show.” A User Group meeting is a production. It needs to be treated as such.

Communicate an agenda at least one week before the event. Include everyone who is participating in the event – the speaker, group leadership, sponsor, facilities liaison – everybody. Make sure everyone knows what’s going to happen during the meeting, but also include the pre-meeting agenda: when does the food arrive? When do we test the presenter’s laptop? Let’s do that stuff before the meeting begins!

Anti-hypothesis: If your user group does not value quality, you are participating in a dysfunctional community.

Give the speakers and sponsors time slots and ask them to remain within them.

Quality presenters. Quality presentations. Delivered with professional quality. Quality, quality, quality!

For some, quality is Job One. We’re geeks – quality is Job Zero!

Quality in Richmond

Late last year we started our Richmond User Groups 2008 Sponsorship Campaign. We had a lot of response. We turned down a few sponsors, in fact.

Once the promise of money appeared on the horizon, I sent an email to the leadership of the Richmond SQL Server Users Group that read something like this: “Hi Guys! We are going to have money this year. What do you think we should do with it? I think we should use it to buy and give away cool swag!”

The responses were along the lines of: “Andy, Andy, Andy. We need to use the money to bring in better speakers with cooler presentations, not silly old swag!” They were correct. (This, by the way, is an example of Quality Communication… )

In 2008, I started the year off in January with a presentation on using Change Data Capture with SSIS 2008 to do Incremental Loads in CTP5. It was a big hit. We followed that meeting with a Brian Knight presentation on Data Mining in February, Kevin Viers on an overview of SQL Server 2008 in March, and Adam Machanic on Highly Concurrent Application Development in April.

Average attendance soared from about 20 people to over 50 people each meeting! As Foghorn Leghorn says: “Figures don’t lie.”

Conclusion

Remember, build quality and quantity will follow. 

:{> Andy