After 4 years with my current company as a ASP.NET/VB.NET Developer, a SharePoint Admin and a MS SQL DBA (I was a “jack of all trades”), I have decided it is time to move on and concentrate on a specific career path. Tomorrow is my last day and I begin work with an IT Consultant firm as a full-time SQL DBA. Truly I have to tell you I have not been as excited about a career change in a long while.
But how does one leave a DBA job in a position where it will not “break” after you are gone? After reading Alan Cranfield’s article, Leaving a SQL Server DBA Job Gracefully, I started to wonder if I had done everything I could to ensure the systems would still run after my domain account would be disabled. (I never want to burn any bridges). Being responsible for so many different type of systems (not just SQL), I decided to expound on Alan’s article.
So these are the steps, that I took to ensure (crossing my fingers), that all the systems that I am currently responsible for would continue to work after my account is disabled.
Development Projects – always tried to use Domain security groups to control web access, not personal accounts. Odds are, security groups will not be removed from AD, but I bet you my first paycheck that my AD account will be disabled before the door closes behind me. But to be sure, I did a search of all my code to ensure my account was not in the code controlling security anywhere.
SharePoint Projects – as the SharePoint admin for my company, of course I was the Site Collection Administrator for all our SharePoint sites. Once my replacement was identified, using the Central Administration site, I changed each individual site using the “Site Collection Administrators” page found under the SharePoint Site Management heading. I know this is the tedious way and STSADM.EXE probably would be faster, but I am such a visual guy, that it always seems easier for me to use Central Administration site, to ensure accuracy. It also ensures that John Doe’s request for access email will be sent to the correct person.
SQL Projects – using Alan’s suggestion and example scripts, I went through all production databases, to ensure I was not the “owner” of any objects. Surprisingly, I found a few and changed them to the SA account to prevent system from failing.
And of course the key to this for me was doing all this before I actually left, so if I actually missed something, I was still around to show my replacement how to fix it, or I just fixed it myself!
Here’s the fun stuff….Starting a new job can always be nerve racking; however I have learned over the years (and through many jobs) that odds are the people who hired you already like you; otherwise they wouldn’t have hired you. In a past life (as a Food Service Manager), I didn’t hire anyone that I got a “bad vibe” from when I interviewed them.
A new job means new learning opportunities. I am by no means an “expert” at anything, so I always look to learn from my supervisors, colleagues and even subordinates (if I had them). I am never to old to learn something new, and either should you. Embrace the opportunity to learn as much as you can from the people around you (and always Blog what you learn). Be nice and good things always comes to those who are patient.
I am excited about my new career choice. I not only get to focus my career path on a specific skill set (MS SQL) and give my self an opportunity to obtain MS certifications, I also get a little extra money in the process. How bad is that?