THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

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

 

Published Thursday, April 24, 2008 12:01 AM by andyleonard
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

No Comments

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement