Transitioning into Management; lessons learned…
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.
November 20, 2012
· 
stuart · 
5 Comments
Posted in: Professional Development, SQLServerPedia Syndication
post #summit12 write-up
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â¦.
November 12, 2012
· stuart · No Comments
Posted in: PASS, SQLServerPedia Syndication, The Social Web
The 9-month countdown has begun…
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.
November 5, 2012
· stuart · 6 Comments
Posted in: Blogging is FUN!, Health, The Social Web
Finally putting together my #SQLPASS Summit schedule
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).
November 1, 2012
· stuart · No Comments
Posted in: Conferences, PASS, SQL Server, SQLServerPedia Syndication
My reading list…
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 
.
October 30, 2012
· stuart · One Comment
Posted in: Blogging is FUN!, Book Reviews
Dear #SQLPass Board…
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.
September 20, 2012
· stuart · One Comment
Posted in: Election2012, SQLServerPedia Syndication
Back in the saddle….
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.
August 30, 2012
· stuart · No Comments
Posted in: Blogging is FUN!, Conferences, User Groups
What’s your mantra?
Iâve been busy lately making the shift from âhands-on engineerâ to âhands-off managerâ; itâs been tough, because Iâm not accustomed to stepping away from a problem and letting someone else figure it out. Even though Iâve got an education background, and have been (inconsistently) involved in technical communities helping other people solve problems, Iâve never had to balance the responsibility of making sure that a job gets done with the responsibility of allowing someone to âlearn from their mistakesâ. Itâs harder than I thought.
As part of my management training, however, Iâve been focusing on laying out principles and guidelines rather than specifics; for example, instead of saying something like:
We need to make sure that John Smith has limited access to that database; can you do that for me?
I’m trying to say something like:
Our databases need to be secure, and that includes differentiation in access based on job roles. Can you verify that all accounts are set up using that model? If there are exceptions, can you document why?
The idea is that a) I need to trust that the people that work for me know how to do their jobs, and b) I need them to start aligning their practices with the principles that I think should drive our work. I realize that last statement sounds a bit tyrannical, but in reality, I trust my team to help me develop those principles. However, itâs my job to provide the direction, and their job to keep the boat afloat.
As part of this exercise, Iâve begun to realize that Iâve had a worldview for several years that Iâve always fallen back on when it comes to solving problems. Iâve never thought of it as a mantra before, but the truth is that the following statement sums up my approach to most problems.
Simple is best.
When I encounter a challenge, and am forced to figure out a solution, I always fall back on the thought that a simple solution is usually the best one. When Iâm face with deciding between option A and option B, Iâm usually going to lean toward the one with the fewest moving parts, even if it doesnât address every possible outcome. Iâm a big fan of things like the 80/20 rule, and Occamâs Razor; itâs far easier for me to tackle problems in bite-sized chunks. Itâs the first principle by which I evaluate any solution that my team presents; if itâs not simple, itâs not manageable in my opinion.
Not everyone I work with is oriented toward simplicity; one of my best friends (Iâve worked with him for 9 years) often chooses beautiful and thoroughly complex solutions to problems. I donât know if could express what his mantra is, but Iâd bet it would involve something about slicing and dicing problems into small pieces. I also work with another guy who loses me in jargon in every discussion; heâs very passionate about writing code that covers every scenario, even if it takes 6 months to a year to do so. I have a tough time thinking like that.
Mantraâs can be positive or negative. For example, two of my former managers had different mantras that they relied on; one manager used to say:
Never make a person do what a computer can do for them.
That helped guide us when making a decision on work priorities; if youâve got someone cutting-and-pasting information from your application so that they can send an email, and they have to do that on a consistent basis, then you probably need to write some sort of hook into your application to let them use their email program from your app. If youâre hiring staff because of the uptick in workload, then you should probably figure out ways to reduce the amount of work using computing power.
The other manager (different company; different time in my career) used to chant:
Whoa, whoa, whoa; thatâll delay the project.
which made us all think that that the project was more important than actual details. It was a joke; the slightest interruption or shift in perspective would tip the entire apple cart. His inflexibility was legendary, and ultimately led to the loss of his entire staff (before he was eventually sent packing).
Whatâs your mantra? Do your teammates or employees know it? Does it contribute to the work effort, or has it become a tired joke among your colleagues?
June 25, 2012
· stuart · One Comment
Posted in: Good Habits, Professional Development, SQLServerPedia Syndication
#TSQL2sDay.. For Whom Do You Log?
This month’s T-SQL Tuesday is being hosted by Aaron Nelson [blog | twitter]; since Iâm posting this late in the day, I got a chance to sneak a peek at some of the other entries, and most of them were great technical discussions on how to log, what to log, and why you should log. Iâm not feeling technical today; todayâs a conceptual day. So, rather than write about the pros and cons of logging, I thought I would ask you to step back and consider who is your audience?
At my company, we monitor logs for our customers; Iâve had to reverse engineer a bunch of different log formats in my day, and there are some basic principles behind good logging practices; hereâs my stab at them:
1. Logging without analysis is useless storage of information.
I realize that our jobs as data professionals have gotten more exciting because of policy requirements that insist upon the storage of all kinds of information for exceedingly long periods of time. I recently read a requirement that said a company must maintain source code for 20 years; thatâs a heckuva long time to keep a log of changes around. Unfortunately, if no one ever looks at the log, then why store it? If youâre going to be storing information, you need to have some process that consumes that information in order to get the most value out of it. Good logging processes assume that someone will be reviewing the log at some point, and using that information to act.
2. Logging structures should be flexible.
If you are logging information with the mindset that someone will be reviewing the log in the future, then you need to balance precision (i.e, gathering adequate information to describe the logged event) with saturation (donât over-log; not every event is always important). For example, if youâre building an audit log to track changes to a customer account, you want to be able to isolate âriskyâ behavior from normal account maintenance. If your logs become lengthy result-sets filled with change statements, itâs easy to overlook important events such as a bad command.
Most logging structures attempt to overcome this by having some sort of categorical typing appended to the log; in other words, if we think in tabular terms, the columns of a log dataset might look like:
- DateOfEvent â datetime
- Category â Classification of the event (Error, Information, etc)
- Severity â Some warning of how important the event is
- ErrorCode â Some short (usually numeric) code that has meaning extrensic to the system
- Message â The payload; a string description of what happened.
It becomes relatively easy to isolate the error messages from informational messages; however, how do you search non-categorical information with the message itself? For example, if you want to determine that there was a specific error code associated with a specific logon, and that logon information is embedded in the message of your log file, how do you search it? The easy answer is to use wildcards, but is there a better way? In my experience, good logs use some form of intra-message tagging to isolate key elements within the message; the log file remains simple for quick searches, but can easily be adapted for more in-depth searches. I like XML attributes for payload logging; itâs easy to implement, and can be parsed quickly. For example:
acct=âStuart Ainsworthâ msg=âAccess Deniedâ object=âSuperSecretPage.aspxâ
is an easy message to shred and look for all denied attempts on SuperSecretPage.aspx. If I wanted to look for all activity by Stuart Ainsworth, I could do that as well.
3. Logging should have a maintenance plan.
If you log a lot, you know that logs fill up quickly. How long do you retain your logs (and the answer shouldnât be âuntil the drive fills upâ)? Too much information that is easily accessible is both a security risk and a distraction; if youâre trying to find out about a recent transaction by a user, do you really need to know that theyâve been active for the last 10 years? Also, if your log file does fill up, is your only option to ânuke itâ in order to keep it running and collecting new information?
A good logging strategy will have some sort of retention plan, and a method of maintaining older log records separately from new ones. Look at SQL Server error logs, for example; every time the service starts, a new log file is created. Is that the best strategy? I donât think so, but it does isolate older logs from newer ones. If youâre designing a logging method, be sure to figure out a way to keep old records separate from new ones; periodically archive your logs, and find a way to focus your resources on the most recent and relevant information.
June 12, 2012
· stuart · No Comments
Posted in: SQLServerPedia Syndication, TSQL2sDay
#SQLSat111 is a wrap…
Iâve tried to do these wrap-up posts over the years to give advice to the upcoming SQLSaturdays based on our experience, but I wanted to do this one a little differently. Before I go too much further, let me do two things:
- State the obvious: SQLSATURDAY 111 ROCKED!!!!
- Thank a whole bunch of people: Audrey Hammonds, Aaron Nelson, Tim Radney, Julie Smith, Rob Volk, Kristina Mishra, Erin Hicks, Lorra Newton, the AtlantaMDF leadership team, and a whole bunch of speakers and volunteers who helped make this show work (far too many to thank here; it was inspiring to see the people who gave their time to make this work).
This was the second year that I served as a member of the team, rather than trying to pull it off. Audrey did an amazing job of pulling everything together. We may have had a few bumpy spots along the way, but from all of the feedback we got, the event ran extremely smoothly for the attendees (all 460 out of the 650 registered). However, as I was reviewing the twitter feed, one tweet in particular stood out for me:
This is what itâs all about; an attendee at our event left wanting more. It made me think about the nature of this post; I usually write up some practical advice on HOW to do something (and lessons learned). This time I wanted to focus on WHY you should do something. I guess this is my attempt at inspirational writing, so breathe deep, assume the lotus position, and read on.
First, itâs the people.
SQLSaturdayâs are a big party, and thereâs enough of them going on around the country world now that weâre starting to become a traveling band of gypsies. Many of the people who speak at these events speak at a whole bunch of events, and this becomes a little family reunion at every event. I love that, but what I loved even more was the fact that I got to see a bunch of my local database people âget their learn onâ. Itâs really easy to get caught up in the moment of working at the event, but at the end of the day, the point of this event was that you should inspire somebody to learn something new, to change the way they approach a problem.
Second, you are people.
If youâre hosting a SQLSaturday, donât neglect yourself. I went into this event tired, grumpy, and a little worried because I knew there were some last minute issues that I had neglected. Guess what; nobody cared. The party rolled on. I spent a great deal of time running around trying to make sure that I touched base with people, and I didnât attend a single session (other than my own). That was a mistake. I should have totally taken advantage of the great training opportunities that were there, and learned something myself.
Iâm pointing the finger square at myself on this: I need to invest more in me. Not that I should neglect others, but Iâve neglected studying and learning because Iâve let other things take away my time. When I was a kid, I used to always hear the mantra of âFaith, Family, and Workâ; I still believe that, and for the most part, Iâve done that. What Iâve forgotten is that Learning=Work! If Iâm not investing in my own education, and not investing in putting my own ideas to digital paper, Iâm starving the creative process, and thus starving my own career.
To that end, I guess the person that left this event the most inspired was me. If youâre thinking about hosting one of these events, donât forget to learn something yourself.
April 16, 2012
· stuart · 2 Comments
Posted in: Conferences, SQLServerPedia Syndication
