I know; I suck at blogging.
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.
Just a quick note; SQLSaturday is coming back to Atlanta on May 18, 2013. This free (lunch is optional) event usually sells out way in advance, so you may want to go ahead and sign up. Also, the speaker lineup tends to fill up pretty quickly (call for speakers closes 2/24), so if youâ€™re a SQL Rock Star or just want to share your knowledge, go ahead and submit your session as well!
So, January came and went, and no post from me. I continue to suffer from writerâ€™s block, but Iâ€™ve finally cobbled together enough ideas that I feel like I can put a couple of quick posts out there. Iâ€™m still struggling with learning how to manage a technical team (MaTT) as opposed to being a technical person, but hereâ€™s another concept Iâ€™m beginning to grasp.
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:
- It shows measurable progress (in my experience, bosses love metrics), and
- 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.
This has been a busy year for me; apart from all of the personal news, Iâ€™ve spent the last year feeling out my new position as a manager. While is not my first job as a manager (I spent about 3 months as a manager working for a department in a death spiral in 2002), itâ€™s been a bit of a bumpy ride. Iâ€™m learning as I go, which is a great skill to have as a technical person, but tricky in a management position. Hereâ€™s a short list of things Iâ€™ve learned over the last year, and I hope itâ€™ll be useful to those of you that are making that transition yourself:
1. These ainâ€™t the problems youâ€™re used to solving.
As a database person (DBA, Developer, Architect), I was very accustomed to tackling technical challenges on a daily basis. Disk running out of space? Check for unexpected log growth. Bug in a procedure? Rewrite it and test. I just assumed that as a technical manager (managing a group of DBAâ€™s) that I would continue in that vein, just with more help and more paperwork. I was wrong (so wrong).
You see, most of the problems I face today arenâ€™t technical; theyâ€™re people and processes. Iâ€™ll talk more about the people in a bit, but the process issues stem from things like "we canâ€™t get this bug fixed because the devs are busy writing new featuresâ€ť or â€śI have 35 things to do on my top priority list; which one do I do nextâ€ť. As a manager, my primary obligation is not to make sure that technical problems are addressed, but rather to make sure that there are no impediments for my team to implement technical solutions.
2. The people in your department arenâ€™t you.
And they donâ€™t solve problems like you do; they have their own systems, answers, and methods to get to those answers. While it may sound conceited, I think I was a damn good database person as an employee, and I think it was those skills which ultimately led to this opportunity. However, I have quickly learned that not everyone approaches problems the way I do, and I canâ€™t simply jump in and solve the technical problem for somebody. Itâ€™s tough, especially when I see that one of my employees took a few hours to google something I knew how to do blindfolded, but I have to let them learn at their pace (and encourage them to learn faster).
One thing I have learned is that I have to make time to pass on my skillset, and thatâ€™s not a one-time thing. I need to spend some recurring time collaborating with my team so that I can step away from solving the technical problem and focus on the impediments (see rule 1 above).
3. Donâ€™t let the drama get to you.
As an employee, it was fun to be snarky. When something (or someone) ticked you off, you could go ahead and rant about how stupid the decision was or how bad the system sucked, all the while knowing that you would be doing your best to fix the problem the next day. Your words didnâ€™t really mean much; it was just a way of blowing off steam. As a manager, other people are watching you, and you canâ€™t blow off steam (in front of them). Compounding the problem is the fact that as a manager, people come to YOU to rant. All you can do is listen and try to get to the core of the problem; again, if thereâ€™s a real issue where it looks like the train is going off the tracks or your team canâ€™t accomplish itâ€™s objectives, then you need to be able to delve into that issue and resolve it. But you canâ€™t participate in their rant session; listen, decipher the issue, and then take action.
4. Find time to stay technical.
As an employee, I can tell you that itâ€™s tough to work for a manager that doesnâ€™t understand what you do; donâ€™t become that manager. I canâ€™t stay abreast of every specialized aspect of SQL Server, but I can keep up with the gist of things. I may not be up to speed on the latest and greatest design patterns, but I need to be able to have a conversation with a developer and understand what theyâ€™re trying to do. Iâ€™ve recently started studying for the MCSA on SQL Server 2012; I havenâ€™t been certified on a platform since SQL Server 7. I feel itâ€™s important to show my guys that Iâ€™m trying to stay a technical resource for them, and also encourage them to pursue more knowledge. The expectation in our department is that research is part of our jobs.
I used to dream about being an Microsoft Certified Solutions Master; I put that dream on hold so I could take care of my personal life, and now it looks like Iâ€™m walking another path. It doesnâ€™t mean that I canâ€™t be a technical person; I just will have a broader repertoire.
5. Change is hard; get over it.
I just got back from the first week of Model-Netics training which is offered by my employer in a four week series (over four months); one of the first models we talked about was the change curve, which looks something like this:
The idea is that everybody is plodding through life at a certain level of productivity and morale, and then a change occurs (a promotion, a formation of a new department, a new process gets implemented, etc…); suddenly everything is askew, and productivity and morale go sliding down the mountain toward the valley of despair. At some point, acceptance will set it, and if the change is a positive one, productivity and morale should settle in at a new high.
Scholars will note that the change curve is widely used in terms of the 5 stages of grief, but the point of it is that normal acceptance to a change takes time, and a realization that things are different and youâ€™ve got to adjust to the new normal. I went into this management position thinking that I could quickly bounce into doing the things I wanted to do, without realizing that it was going to take some time for me to adjust to my new responsibilities. I also had to balance the productivity and morale issues in my new department (as well as my old one). That realization is the basis for transitioning from a slide into a climb.
Itâ€™s been an interesting first year, and Iâ€™m looking forward to the new challenges ahead. Iâ€™ve never worked so hard in my life, but yet I feel like my job is important to me, and at the end of the day I can put it down and focus on other things. Life is about more than a career.
Everyone does one, so I figured I should Unfortunately, I barely recovered from my trip to Seattle, and am now rushing out the door to Dallas for company training, so Iâ€™m afraid this will be brief. I do intend to blog more in the future (promises, promises), but for now, hereâ€™s the highlights:
- Day 1 Keynote rocked; it looks like SQL Server vNext will be an awesome release for DBAâ€™s. 2008 and 2012 brought a lot of cool things to the table development/BI â€“ wise, but less love for administrators (IMHO). Hekaton will change that.
- I was really burning out on the whole chapter leader/SQL Saturday/community activist thing; three days in Seattle changed that. Weâ€™re now planning Atlanta SQLSaturday 2013 (woo-hoo!!)
- The Chapter Leader meeting format was very effective, and a big difference from previous years.
- Session planning seemed a little â€śoffâ€ť this year; too many people trying to cram into too small a space. I missed some good sessions because the rooms were too full.
- I got bit by the cert bug, and passed exam 70-461 Querying Microsoft SQL Server 2012 on the second try. I flunked it on Wednesday, got pissed off about it, crammed that night, and passed it on Thursday. More on that later.
All in all, it was awesome. I had a great time reconnecting with people, and Iâ€™m looking forward to the year to come. Gotta run; the Atlanta airport is an hour away. I have no clue how you road warriors do thisâ€¦.
So, there it is. Two little lines, and BANG! Iâ€™m going to be a dad again. Itâ€™s been 14 years since Iâ€™ve last seen a positive pregnancy test, and Iâ€™ve got to tell you, the mixture of excitement and downright panic doesnâ€™t really change. True, Iâ€™ve got a lot more experience under my belt, but then again, Iâ€™ve got a LOT more experience (Iâ€™ll be 42 in July). Wow.
We heard the heartbeat today, so my wife is officially 7 weeks along, and except for a few close friends and family members, weâ€™ve been trying to stay quiet and think happy thoughts. Weâ€™re finally out of the woods far enough that Iâ€™m comfortable telling people.
Comfortable may not be the right word; Iâ€™m still slightly in shock, but Iâ€™m significantly more optimistic about the outcomes. Iâ€™m going to be a dad, again. Itâ€™s an amazing feeling.
My head is still swimming with the news, but I hope this explains why I havenâ€™t blogged much over the last year, and why I probably will be sporadic for the next few years . IVF is a time-consuming process, but as I recall (sheesh, I sound like a geezer already), so is raising a baby. At least this time around Iâ€™ll have a couple of high-school students to help out. My two daughters are thrilled about the possibility of a little sibling; both are hoping for a brother, but as my mom put it, my â€śtrack recordâ€™s not so great in that areaâ€ť.
Other words of wisdom from my mom: â€śyou better get your ass to a gym.â€ť Iâ€™ve got less than 9 months to get into the best shape of my life; Iâ€™ll have a rugrat to wrestle. Life is good, and I need to be around for a long time to enjoy it.
Itâ€™s hard to believe that the Summit is next week; Iâ€™m just now pulling together my schedule, and Iâ€™ve got some tough choices to make. I have noticed a pattern, however; this year, Iâ€™m going to sessions for new features and possible solutions as opposed to â€śOMG, I have to solve this problem NOWâ€ť kinds of sessions. Iâ€™m also going to sessions where I think my team should get more knowledge, not just the things that interest me. I guess Iâ€™m finally growing into this management role.
Below is my tentative schedule; see all the red? Thatâ€™s double-bookings, or even triple booking. Sigh. Iâ€™m also planning on getting enough liquid courage this year to SQLKaraoke (although many of you may wish I donâ€™t).
OK, so I havenâ€™t blogged in like, foreverâ€¦ (and apparently, Iâ€™ve adopted the speech pattern of a teenager from the 80â€™s while I was away). Suffice it to say that Iâ€™ve been working on a few major projects, and Iâ€™ll fill you in on them later. I did want to pick up the torch again, and thought I would write a quick email about the three books that are currently on my reading list:
On my iPad (and no, I didnâ€™t get a Surface RT, and it sounds like it was a good thing I waited), I recently picked up Managing Humans by Michael Lopp. Itâ€™s a fun read, but his principles and axioms are a bit like the Book of Proverbs; itâ€™s a loose collection of ideas on how to manage software engineers. Iâ€™m a bit more simplistic than he is, and itâ€™s tough for me to put all of the puzzle pieces together. Iâ€™m still digging my way through it; itâ€™s fun at times.
My technical book of choice as of late is Practical PowerPivot & DAX Formulas for Excel 2010 by Art Tennick. Weâ€™ve got a new self-service BI initiative at work, and my department is responsible for evangelizing the capabilities of SQL Server. What Iâ€™ve seen so far of PowerPivot, I like, but there are a few challenges; Iâ€™m not an Excel guy, and so the interface is not intuitive for a DBA. This particular book has been helpful on more than one occasion when I’ve been frustrated by my lack of ability to get the software to do what I want.
And now for pure geekiness (and Iâ€™m sure my wife is shaking her head at this one), I recently found the entire Apprentice Adept series from Piers Anthony in a used bookstore. This was one of my favorites in my early high school career (yep, I was a nerd), and I just started reading Split Infinity. My excuse is that I bought it for my teenage daughter, but in reality, its for me .
Like most PASS members, I got the email yesterday announcing the PASS board elections, and it looks like a great slate of candidates. To all of them, I want to say thanks for volunteering your time and energy to run. Three of you will be elected to help shepherd an influential and active community, and you will probably not often hear a sincere â€śthank youâ€ť. To the current Board of Directors and the Nomination committee that helped put this slate together, I also want to give thanks; your service is much appreciated. I do have a slight favor to ask, though, and like most Southerners, Iâ€™ll illustrate the need with a personal story.
I have a teenage daughter who has recently acquired her driverâ€™s learning permit, which means that like most parents, I have prematurely aged. Iâ€™ve sat in the passenger seat, gripping the â€śOh $h!tâ€ť handle while screaming â€śSTOP!â€ť at the top of my lungs while simultaneously punching the imaginary brake pedal in front of me. Iâ€™ve reached over and adjusted the steering wheel to help her avoid drifting into the other lane of traffic. Iâ€™ve done the apologetic wave to other drivers when they pull up beside her at a stop light (after riding her bumper at EXACTLY the speed limit for the last five miles); Iâ€™ve been less apologetic to the idiots who screamed at her. Iâ€™ve both protected and corrected her, and after a few short months, sheâ€™s become a pretty good driver. Weâ€™ve still got some work to do, but now I donâ€™t hesitate to slide her the keys and head for the passenger seat. Most days I donâ€™t even grab the handle.
As my daughter has matured behind the wheel, our conversations have changed from specific instructions (like â€śyou have to check your mirrors, adjust your seat, and fasten your safety beltâ€ť) to more general principles (â€śdo your checksâ€ť). Sheâ€™s learned that she can ask me questions, and that she can trust me to pay attention. We communicate about expectations, and if a situation does come up that we havenâ€™t specifically discussed, she can generally predict what my expectations are. For example, she knows the 3-second rule for following a car, and she knows that she should be more cautious at night, so she can extrapolate that she should use 4 seconds for following a car at night.
In my mind, PASS is growing out of its awkward adolescence, and the last few election cycles have demonstrated some serious growing pains. I donâ€™t want to rehash the controversies, but as a community member I do want to remind you that this election cycle is the time for the organization to shine. I recognize that with every misstep that the Board of Directors has taken action to learn from the experience, and has taken steps to avoid similar situations. However, an election without controversy has been elusive for the last three years, and Iâ€™m asking you to drive this one home.
How? Communicate with the community about what the expectations are for the election. I think youâ€™ve done an OK job with efforts like the elections.sqlpass.org site, but I think you need to go above and beyond this time. Promote the heck out of it; let the community know that you want to get this election right, and that itâ€™s a priority for PASS. Make sure that the conversations happen BEFORE the unexpected situations arise. If something does go awry, then make sure that you can explain what happened and continue to demonstrate that same desire to learn from the experience.
I realize that this note may seem a bit harsh coming from me, since I was intimately involved in at least one of those controversial elections. As I tell my daughter all the time, Iâ€™m partially responsible for her driving mistakes because Iâ€™m the one helping her learn. Weâ€™re learning together; Iâ€™ve never taught someone to drive before. That means that we have to be able to discuss what weâ€™re learning, and that we focus on improving the outcomes every time we get in the car. I expect the same from this election.
It’s been a while since I’ve last posted anything; I blame it on a strange blend of workaholism and laziness. However, before I drifted off to sleep tonight, I did want to mention that I would be presenting a topic at SQL Saturday 167 in Columbus, GA on September 9. On September 11, in Columbia, SC, I’ll be presenting the same topic at the Midlands PASS Chapter. If youâ€™re around either one of those meetings, please feel free to stop by and say hello!
The Agile DBA: Managing your To-Do List
Agile development is all the rage, but how do the principles apply to database administrators? This presentation will introduce the basics of the Agile Manifesto, and explain how they can be applied to non-development IT work, such as database administration, maintenance, and support. Weâ€™ll cover scrum (one of the most popular development methodologies) and kanban, and identify some of the common struggles with implementing them in an organization. This is an interactive discussion; please bring your tales of success and your horror stories.