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.