And it was a good day.  The team (led by Geoff Hiten) pulled off another great event; 555 people attended the event, and there were some AWESOME sessions throughout the day.  I was in the 9 am slot, and my session on Biggish Data went well, even if (as usual) I had WAY too many slides.  Speaking of slides, you should be able to download the deck from the SQLSaturday 220 schedule (as well as many other great presentations).  I did have to slip out early since this weekend was my weekend with the kids.  My current youngest (Grace) had to get service hours for beta club, so she got to hang out with me, but I needed to get back home early to hang out with the oldest one.

So what was cool?  What did I learn?

1. The number one highlight for me was watching Louis Davidson demo Red Gate’s SQL Monitor tool, and he chose one of my custom metrics to use in the show.  I respect Louis a lot, and it made my day.
2. I learned that I need to cut out about 10 slides out of my presentation.
3. I had a great conversation with a few people about table partitioning and performance gains; I think there’s enough material for a future session explaining why you will or won’t see performance benefits from partitioning.  Hmmmm….
4. I had another excellent conversation with Robert Cain regarding the growth of SQLSaturday’s, and bounced around a few ideas about moving to a mid-tier model.  Kind of like what SQLRally was supposed to become, but different. 
5. I also got to hang out with Andy Leonard.   He and my Grace had a good time discussing movies (Where’s my super suit?).

Mostly, I just got jazzed about being back in the #sqlfamily.  Hopefully, I can build off that momentum, and start blogging again.   Granted, the next few months are going to be personally interesting, but I need to make time to share again.

Anyway, I have a couple of upcoming presentations this month, so I figured I needed to get back and gear and at least post a notice about them.  First, I’ll be presenting at A Bunch of Devs (http://www.meetup.com/A-Bunch-of-Devs/) on the Red Gate development suite of tools.  Funny story; I actually work in that building.  The organizers reached out to Red Gate to see if they had a Friend nearby.  I guess I qualified.

Next, I’ll be back at SQL Saturday Atlanta to present on Biggish Data; this is the first Atlanta SQL Saturday that I actually had almost nothing to do with (as a chapter leader, I helped with some basic decision, but very little).  I’m excited that it’s continuing to thrive.  Says a lot about the infrastructure that PASS puts behind these events; they just need a little help from the local chapters, but they don’t rely on the same person getting burned out year after year.

You have to start somewhere.

When I began managing my team, I was tempted to rush in and save the day.  I know where a lot of the problems are, and I know which ones are big, and which ones are not.  I kept thinking that if I could just motivate the team to start attacking the problem, then we’d be sitting pretty in a year.

I was wrong.

Most people are already motivated to do their jobs; if they’re not, then they’re in the wrong position, and it’s hurting them as well as hurting the company.  What a team is usually looking for in a manager is to help them make priority decisions, and to back them up when they need things to change.   Here’s the conundrum: Technical people often (logically) focus on changing the things that hurt them the most.  Your DBA may say “I keep having to babysit this query for the boss because it’s slow, and it’s slow because the developers don’t know how to normalize a database; can we refactor everything?”.  Your developers may say “If we had more time to rebuild everything, we could fix that query; can we hire another person or put these features on hold so we could tune everything?”.  Your boss may say “We need to make a profit; what’s the most cost-effective way to manage our database architecture moving forward?”

If you focus your energy on addressing the technical issues without giving consideration to the profitability of your company, you’re spinning your wheels.  However, you MUST figure out a way to ease the pain of your technical team by addressing their concerns.  It’s no secret that I’m a Lean/Agile kind of guy; I truly believe that these philosophies can help balance the scales between support/development/operations, but you have to start somewhere.

“Somewhere” for me is the small fixes; don’t tackle the big projects head-on.  Focus on being successful at a couple of small things (e.g., reduce the number of support calls in a measurable fashion, or refactor some small but essential bit of code).  Make sure that these changes are measureable, and make sure that you report the changes to your boss AND to your team.  This accomplishes two things:

1. It shows measurable progress (in my experience, bosses love metrics), and
2. It encourages your team by giving them a couple of quick successes.

If your team doesn’t see progress, then in their mind, “nothing is being done”.  Your boss wants to know how you’re improving efficiency and effectiveness in terms of dollar signs; your team wants to know that they’re solving a technical problem.  Make sure you can address both of those needs.

More to come.