t-sql-tuesday_FI

T-SQL Tuesday is a monthly blog party that is the brainchild of Adam Machanic (b/t). This month the blog party is being hosted by Koen Verbeeck (b/t) and is inspired by Kendra Little’s (b/t) recent blog post regarding the role of the DBA and The Cloud.


#tsql2sdayChange

Working in IT doesn’t have any guarantees except one, that things will change. Change is driven by the business, where they have to continue to innovate or die. In part, change in IT is also driven by better technology because who still wants to be using Windows 98 Second Edition with a SQL 7.0 on NT 4.0? Oh, and floppies because they were so awesome. As technology changes, so will the service offerings.

Does anyone remember ASPs (Application Service Providers)? For those who don’t, think “The Cloud”: the beta version, circa the early 2000s. After the fear and expense of the Y2K bug (I can’t believe I need to link this), ASPs showed up promising the businesses protection from crazy bugs like Y2K by hosting their apps. Great idea, except back then, bandwidth wasn’t as cheap, and the hosting platforming was nowhere near cheap enough for most businesses to use. Well, both problems have been resolved thanks to cheap bandwidth and virtual servers, making “The Cloud” possible.

Are DBAs endangered?

Yes and no. If, as a DBA, you sit idly by and do nothing to adapt to the changes in the industry, then yes, you would be endangered. On the other hand, if you are continually working on expanding your knowledge, forging new skills, and trying new things, then no, you will not be endangered. Oh sure critics, business types, and others who aren’t fond of IT are continually going to say stuff like “The Cloud,” automation, robots, AI (artificial intelligence, not a guy named AL), is going to replace IT. That is until the replacement for IT breaks, and someone needs to fix it. Even Skynet will need to be maintained. Of course, I guess by that time robots will be sentient but I digress.

Sure, a person could dogmatically hold on to the old role of database administration where you run backups, set permissions, etc. but, why would you want to? How many times can you get excited about installing SQL? These types of duties are the necessary parts of our job. The fun stuff is getting to troubleshoot new issues, tweak queries, or learn more about SQL in general. The significant portion of the job is applying that new knowledge to make everyday work life a little easier.

Evolution

My point here is this: If you have been in IT for any length of time, then you have changed. You have evolved. Take charge of your evolution, focus on new areas you know little about, chase a certification, do something that makes you uncomfortable. It doesn’t just have to be about SQL, either. Take the time to learn the business you support so you can figure out how to better support/serve that business. It’s so much easier to solve problems when you understand why.

Kendra said it best at the end of her podcast.

“You get one life. You may as well get to solve problems that you enjoy while you work.” – Kendra Little

Good ProcedureProcedure and Technique

One of the things I do when I workout, or drive alone, is to listen to podcasts. One of the podcasts I subscribe to is the Art of Charm, which they describe themselves as providing social skills training for Top Performers. In short, they talk about all kinds of self-improvement stuff from social skills, entrepreneurship, business, and fitness. This time the podcast was about procedures vs technique.

During one of my drives to work, I was listening to episode number 505, with Karen Baetzel. In that episode, she discusses her career as a Naval female aviator, one of the first. She also discusses communication, leadership, followers, and other constructive ideas she learned in the military. It’s an informative episode, and I would encourage anyone to listen to it.

One of the topics Karen mentioned in the podcast was the difference between technique and procedure. She defined procedure as a standard regulation that can’t be arbitrarily changed. It’s the policy, or rule, governing how an action is carried out. Whereas a technique is a way, an individual carries out a procedure in any manner they choose, so long as they stay within the guidelines of the process.

Why it’s important

Having been in IT for nearly 20 years and a DBA for the last several, this struck a chord with me. We are all very aware of change management, and how change affects our environments. We should all be adept at documenting how we make these changes as well. One of the things I have noticed, though, is there isn’t a standard on how to create documentation. I’ve worked for organizations where the quality of documentation fluctuates wildly from department to department. While I understand the technique portion, I think it gets applied too liberally at times. In this case, how documentation gets created.

Procedures, policies, and in some cases, work items should be thoroughly documented so that anyone can walk right in and take over. However, a document standard/template should be created as an organization, and each department should do their best to meet that standard. The technique can vary with writing styles. If a team, or an organization, needs access to historical information, the last place that information should be is in a mailbox of someone who is off or no longer with the organization. Storing this type of information shouldn’t be left to technique.

Just say no to being a manager

DBA? What?

I assume, like some others, my IT career started when a few of us got together to attempt a LAN gaming party. It then evolved into jobs like supporting dialup internet users for GTE and later on as a desktop tech. From there, I moved up to become a Sys Admin who swore I had no interest in programming and wanted nothing to do with being a DBA. And yet, here I sit, loving my job as a DBA and working towards getting better at development. Somewhere along the line, I decided I wanted to remain technical and stay out of the ranks of management. Irony ensues, it seems, and the harder I work to avoid participating in a management role, the deeper I go as a DBA, the more into management I seem to get.

What do I mean? How often are we asked about impacts on the data? Or about licensing? How often do we spec servers and not think about the costs of these servers in terms of money and resources? DBAs are always making decisions based on costs vs. return, do we not? How often do we sit in meetings, or on calls, identifying risks and trying to protect the database servers? It doesn’t matter if you are the Senior DBA or the Junior DBA, we are all doing the same thing.

Senior DBAs spend more time in these meetings than the rest of us because they know the environment so well. Those DBAs are in there protecting the data and managing risks to the environment to the best of their abilities. Meanwhile, the rest of the DBAs are doing the technical work and occasionally attending the meanings/calls. Outside all of the external meetings, the DBAs are always talking amongst themselves about the data or servers…just a continuous internal meeting. Yeah, Meetings!

DBAs are more than technical

So what’s my point? DBAs spend much of their time on calls or in meetings? To point out the internal discussions are meetings as well? No…that wasn’t my point. My point is this, do you think the only type of training you should be working on is technical? If DBAs have to spend all this time interacting with people, shouldn’t we as DBAs get better at it?

dilbert
Years ago, when I started down the road of becoming a DBA on an AS/400, I worked with a couple of people who lacked interpersonal skills. It was always my way or the highway mentality. One of these people would go as far as to shout and yell in meetings, to bully people into his way of thinking, no matter how right or wrong he was. This person even treated team members with that mentality. It made for an unpleasant work experience. It also gave them horrible reputations, and worse yet, other team members got horrible reputations just for being a part of the department.

Develop other skills

If your goal is to be a better DBA, a more well rounded DBA, or to have a good reputation as a DBA, take the time to invest in interpersonal skills. I’m not saying you have to change into an extrovert with a sales attitude overnight, nor do you have to get all HR touchy-feely either. However, it would be beneficial to make people feel like they can approach you and leave with their heads still attached or not feeling worked up about their interaction with you. Too often, IT people get stuck in the technical end of the business and forget there are other aspects to the job. It might explain why IT departments are located in separate buildings, in basements, or some dingy corner of the office.

snoopyGo out into the sunlight, attend interdepartmental happy hours, jump into a GoT discussion. Take a few minutes to talk about sports, the weather, or ask how someone is doing before and after meetings. Don’t mention one technical thing during these “events,” just work on your small talk. Maybe check out some podcasts like the Art of Charm or read a book on management. Better yet, read a book about the other departments. Why? You might learn something about what other departments or managers have to do and why. Then you might start relating to them a bit and understand the direction of some of their decisions. You will evolve personally, and your career will grow. You can still avoid management responsibilities, but you’ll gain some skills or insight that may be useful somewhere else.