Congratulations New 2015-2016 BRSSUG Officers!

We elected new officers tonight for the Baton Rouge SQL Server User Group Official PASS Chapter, the second year in a row we've made an effort to do so.

We departed from a singleheaded user group mostly on the shoulders of a single volunteer. Prior to 2014, making things happen for the BRSSUG was mostly on William (me), with sporadic help from volunteers. Prior to 2011, it was mostly on Patrick Leblanc (now with Microsoft), who started the group in <2008, with sporadic help from volunteers like myself,

So the rest of this blog post is intended for the audience of user group leadership, no matter what structure (or lack thereof) your user group leadership takes.

We started electing officers in 2014 (after our annual SQL Saturday) in order to serve four goals:

1. Capitalize better on enthusiasm in the user group
2. Foster more ownership-type thinking about the user group, with the hopes of increasing volunteerism
3. Allow others the career/resume/networking benefits that leadership of a user group can provide
4. Share the load, Mr Frodo

To be honest, we had mixed results in the first year. We're still rounding out who some tasks should be owned by, and peeling more and more tasks away from myself, and finding the right sense of volunteerism between meetings.

If you're considering having "elections" for user group officers, it's worth a try. Don't be surprised if the spirit of hesitance and collegiality leads all officers to be elected unopposed, with humble candidates try to out-humble eachother to cede victory to the other, or for some folks to run in absentee, or both. And that's totally okay. 

This isn't supposed to be competitive officership. And if someone doesn't "win" an office and still wants to help? Great! As a leader, never shut down this sort of enthusiasm. Find some way to involve and foster that sense of ownership. Then, trust them to get the job done. Trust, but verify.

Remember, enthusiasm is the primary job qualification for volunteer user group leadership.

I'm very excited about our new officers in 2015-2016:

Adrian Aucoin (@CajunSQL) - President
Matthew Tessier (@MatthewTessier2) - VP of Media
Me (@william_A_dba) - VP of Logistics
Kenny Neal (@KennyNeal) - VP of Education and Court Jester

If you're curious (and these aren't original to us), here's the officers we elected tonight. Our buddies in the Baton Rouge .NET User Group elected their four as well.

President

•  SQLPass Chapter Leader and SQLPass Representative
•  Scheduling, Event Planning and Facility
•  Website announcements (cooperatively with VP of Media)
•  Officer communication and commitment followup
•  Social Media communication

VP of Media

• Website updates, images, photography and announcements
• Mailing Lists spamming
• Lead Social Media (especially Twitter, Facebook, new outlets, brand management)

VP of Logistics

• Host facility communication/logistics/cleanup organization
• Organizing/verifying Monthly Food order
• Swag/prize receiver and collector
• Purchaser/Accounts Payable 

VP of Education

• Books requests from various book publishers or training providers
• Applications for freebees, sponsorships, giveaways
• Work with regional UG's to arrange speaking tours
• Organize study groups, certification prep groups, other learning opportunities

Shared Officer Responsibilities

• Speaker recruitment and centralized scheduling
• UG sponsor recruitment and centralized scheduling
• Act as master of ceremonies for UG meetings, raffle giveaways

Presentation Downloads from SQL Saturday Columbus GA 2015

Thanks for joining us at SQL Saturday Columbus today on a gorgeous day to go inside and learn about SQL Server! And even bigger congrats to those of you who use Google maps and were still able to find the brand new event location at the Troy State University Riverfront campus!

My colleagues Cody Gros and John Walker joined me on a trek from Louisiana earlier this week and I was so happy to see my SQLSaturday friends, including the great and magnificent SQL Saturday empress Karla Landrum, once again.

A special thanks and job well done to Tim Radney for organizing this top notch event throughout a rough week and the loss of his father. Friends are all over the place Tim, glad so many of us could be here today to tell you this in person instead of from afar. Great job, great facility, great event, great people.


Here are the downloads for two presentations. These presentation files are also available on the SQLSaturday event website.

SQL + SharePoint: Friends Forever (William Assaf and Cody Gros)
12:30pm in room 213
http://www.sqlsaturday.com/439/Sessions/Details.aspx?sid=40086

SQL Admin Best Practices with DMVs
3pm in room 310
http://www.sqlsaturday.com/439/Sessions/Details.aspx?sid=40049

Downloads here:
http://1drv.ms/1YWsU2C

Sorry, no, we won't be uploading our Sparkhound Jeopardy game from the lunch session. Can't be giving away all our answers! Er, questions.

Why I Don't Use the Architect Title

I get nervous when I see the title "architect" in IT job roles.

I've had this title before as an employer's standard, but lobbied against it. I instead prefer separating job titles from project roles.

Why?

"Architect" as an IT role descriptor carries an appropriate level of technical expertise and broad experience - but typically, for too long. I don't like "Architect" because it sticks.

The verb "architect" implies a leadership and guidance in big system design decisions.
The noun "architect" can be a bludgeon in a software planning meeting.

Putting egos aside when making platform and architecture decisions can be next to impossible if someone decides to wield the "architect" hammer.

Can you think of a situation when large amounts of dated technical experience did not make for quality technical guidance in the future? I bet you can. I bet you know exactly the type I'm talking about.

Platforms, language versions, feature sets and even product suites change regularly, so a clingy title like "architect" may be appropriate for only one or two projects or generations of a given technology. A few major releases, framework versions or platform changes later, and the "architect" title may be as stale and waning as the technical skillset behind it. Without continuing education, "architect" becomes synonymous with "boat anchor".

When the next project comes, the "architect" resource from the original project may be (not as a rule) more gentrified than skilled. And while the "architect" doesn't need to be the most technically savvy member of a project team, the assumption that "architect" was an applicable title a few years ago - and so shall ever be - is a dangerous trap.

• The "architect" for your SQL 2005 project needs to get up to speed on the latest changes (ex: data types, high availability, and columnstore indexes) before serving in a similar role for your new SQL Server 2014 project.
• The "architect" for your .NET v2.0 project that's now in maintenance would perhaps better serve as a developer for your new .NET 4.5 project. 
• The "architect" for your first-iteration Entity Framework 4 project might not be ready to carry the lead that new EF6 application.
• The "architect" for your SQL Server 2008 R2 SSAS multidimensional business intelligence platform may not be aware of architecture features involved in your new SharePoint-based business intelligence project leveraging SSAS Tabular and PowerBI.

Instead of your top-tier developers assuming the title of "architect", try using the names with transient intent, like Project Lead, Team Lead, Technical Lead, Designer, Analyst or Developer.

In summary, please make sure that you and your coworkers aren't treating "architect" like academia treats tenure. It's not a lifetime appointment, and the ego boost that comes with "architect" needs to give way to honesty, humility and continuing education.