On Failure: Getting Up

WP_20150205_004 In my continuing series entitled “On Failure”, I want to talk about skiing.

I’m not a great skier. It would probably be a stretch to say that I’m a good skier. Still, I enjoy doing it, and I want to (and can) get better at it. Since I live in the Dallas area, I don’t get a lot of opportunities to ski – usually 1-2 trips per year – but I try to make the most of it when I do get to go.

When I first started skiing, I fell – a lot. The first time I went skiing, I took a half-day lesson before I got started, after which I assumed I’d be a decent skier. I was wrong. Beginner ski school is more of a lesson in logistics (how to put on and take off your skis, how to board and deboard the ski lift, etc.) than an exercise in actually learning how to ski. So my first trip down the mountain was rife with tumbles, lost skis, snow burn, and “WHY DO MY LEGS HURT SO MUCH??” On those first few runs, I spent more time in the horizontal than the vertical. Because I had to get out of the snow and put my skis back on every few hundred yards, just completing each run was a slow, painful, exhausting process.

Toward the end of that day, I recall that I had a particularly nasty fall after inadvertently crossing my skis (again). I was exhausted, embarrassed, and hurting. All I wanted to do was to lie there, gather my thoughts, and let some of the pain subside. My friend, an experienced skier, was skiing behind me and stopped to help. When I told him I just wanted to lie there for a minute, he told me, “Get up. Lying in the snow just makes it worse.” Grumbling, I got up and continued the slow trek down the mountain.

I’ve thought about my friend’s advice a lot since then. As a skier, I’ve come to find that his words were quite true. Why?

  • Simply lying in the snow after a spill makes you colder, and the cold coupled with inactivity make it physically more difficult to get up.
  • It’s easier to talk yourself out of continuing when you’re lying there feeling sorry for yourself.
  • You’re physically in danger from other skiers crashing into you from behind.

But this statement doesn’t just apply to skiing. We can all use this advice in our careers and business relationships as well. Many of us have had some nasty spills in our careers, being on the wrong end of business failures, professional quarrels, terminations, and other career maladies. Personally, I can completely empathize with the desire to “just lie in the snow” after a career setback. I’ve been guilty of indulging the instinct to just stop moving forward, attempting to soothe those aches using self-doubt and self-pity, after a career setback. But just like the skiing analogy, such behavior only makes the situation worse. Refusing to move forward after going topsy-turvy will almost certainly impact your relationships and career prospects. Sometimes it hurts to get up and keep moving forward, but simply lying in the snow hurts even more.

Every failure, on the ski slope or in the cubicle farm, requires some small amount of time to regroup. But the key objective is to keep moving forward, even if it hurts to do so at first.

On Perspective

Perspective can make or break a career.  Maintaining a proper perspective is very often the differentiating factor between a good technologist and an incredible one.

6281420488_68b88bfc00_zIn my 15-ish years in IT, I’ve said a lot of dumb things.  Many of them I’ve forgotten, but I can’t shake the memory of one particular phrase I uttered more than a few times back in my early days of my career.  Even today, it still embarrasses me that I ever had the mindset to say these words about other people:

“… those stupid end users …”

Yep. I said that.  Why would I say those words?  Sure, there was some emotion and frustration involved, but even more than that, my perspective was all wrong.  Being new to the IT field, my expectation was that it was our job as technical professionals to dictate standards and practices, and that the end users we supported would modify their business processes and their workflow to match those standards.  I looked at most business problems as the fault of the users for not following our standards, or not using their software tools properly.  Looking back on 15 years of experience, it seems silly that I would have ever held that position.  But in my (at the time) limited field of vision, this was my expectation.

Fast-forward a few years.  With a little experience under my belt, my perspective had changed.  Through a few hard lessons, I had evolved to the point that I fully understood that my principal function as a technical professional was to serve the business, not the other way around.  My attitude significantly improved, and I became a more proficient technical professional.  But my perspective still had one significant shortcoming: I simply solved the business problems that were brought to my attention.  Sure, I had my technical resources in order – my backups were always done and tested, my code used common best practices and was checked into source control, and I did my best to get out in front of performance issues before they ballooned into bigger problems.  But I still considered business problems to be outside my purview until my assistance was specifically requested.  My perspective was limited in that I was still trying to be a technical professional, rather than focusing on being a business professional solving technical problems.

I still remember when it finally clicked for me.  I’d been working in the industry for about four years, and after multiple rounds of meetings to solve a particular business problem, it hit me: my perspective is all wrong.  I’ve been looking at this from the perspective of “Tell me your problem and I’ll fix it,” when the dialog should have been “Let me understand what you do and what you need so we can address our problems.”  That’s right – it’s not that those end users have business problems.  It’s that we have business problems and we need to solve them.  There’s nothing more comforting for a nontechnical person to hear, and rarely a statement more empowering for a technical person to make, than a sincere expression of “I feel your pain. Let’s solve this together.”  This is true whether you’re tasked with front-line technical support, you’re working deep in a server room, or you’re a senior consultant in the field.

I believe a person can be a moderately successful technologist by focusing strictly on understanding and solving technical problems.  Where one becomes a rockstar problem solver is the point at which he or she has the experience and maturity to see things through a perspective other than his or her own, while understanding and feeling the pain points of others.

Four things I wish I’d known back then

In the blogging meme of the day, I was tagged by my friend Tim Costello to share four things I wish I’d known back when.  The only hard part was paring the list down to four items.

I think back to 15 years ago, when I was working retail and desperately seeking something else.  Something I could really get into.  Some kind of work I was passionate about.  On a dare, I took the A+ computer certification exam and passed it, and embarked on a career that has led me to where I am today.  Although I miss some of the aspects of that guy I was 15 years ago – bold, fearless, with boundless dreams and ambition – I also wish I could go back and teach my younger self a few things I’ve learned since then.

Failure is a part of growth.

I used to worry a lot more about failure.  I feared that a big failure would end my career, but also worried about day-to-day failures – small mistakes that everyone makes.  I worried that I’d say or do something stupid out of ignorance, and that would be the thing I would forever be remembered for.  It rarely works that way.  In most cases, a person’s career is not measured by their biggest misstep; rather, it is an aggregate of every success and failure – and the attitude they have about those successes and failures.  Failing on the job is a part of the growth process.  As Thomas Edison famously said, “I have not failed. I’ve just found 10,000 ways that won’t work.”  A misstep is only a failure if you don’t learn from it.

jackYou can’t be an expert in everything.

During my first year in IT, I was convinced that I was going to be some kind of technical demigod, and I set out to learn everything about everything – programming, databases, network administration, routing and switching, even Microsoft Access.  You name the technology from the late 1990s, and I probably had a book on it – and intended to master it.  There’s nothing wrong with learning, and to this day I still work regularly to learn about areas outside of my own specialization.  But I wish I’d known back then that maintaining deep expertise in so many different technical topics is exceedingly difficult if not impossible.  I wish I had realized that there’s far more demand for someone who does just a few things, but does them better than 98% of other practitioners of the same craft.

Don’t just have goals. Have a next set of goals.

There was a time fairly recently where I was stuck in the mud.  I was still doing the work I enjoyed, but for a time I was doing it without a real purpose.  Why?  I had met all of the career goals I had set years ago, and I was working largely without a personal charter.  While that’s a great problem to have, I really hadn’t planned for the contingency of completing those objectives.  I wish I could go back and tell myself to be a bit more optimistic about my goals, and to list out another set to be met later, and another after that, and so forth.  Like anything else, goals should be flexible enough to allow you to adapt to changes in the marketplace and your own desires and place in life.  Those goals will be different for everyone, but whatever they are for you, those milestones are critical for measuring progress and challenging yourself to press onward.

Your technical skills don’t matter as much as you think they do.

miltonIn the late 1990s and early 2000s, there was still a great deal of truth behind the antisocial geek stereotype.  One could be a reasonably successful technologist and stay hidden away from the front lines of end user interaction.  And I fell into that trap for a while, spending virtually no time honing my interpersonal or speaking skills and just working to refine my technical abilities.  While the ability to deliver technical solutions is important, being able to talk to people (both one on one as well as in a presentation setting) and understand their business and its pain points is critical for the success of the modern technologist.  I’d love to go back and tell my younger self: Continue to work on your technical skills, but get out of the server room occasionally and talk to people.  Learn about their jobs, and what causes them grief.  Understand how to not just build technical components, but how to solve real business problems.

And to keep things going, I’m going to tag a few people to get their input on this.  I’d like to hear what Marc Beacom, Reeves Smith, and John Sterrett have to say on this topic.

Goodbye, 2013

For me, 2013 was one of the most interesting and busy years of my life.  It was a good year for me, especially on the career front, and it’s certainly been the busiest year in several years.  Among the highlights of 2013:

Going independent

The most significant event for me this year was when I fulfilled a long-time dream of mine to become an independent consultant.  Back in June, I left my full-time (W2) consulting job to launch my independent consulting practice.  At the same time, I joined up with the fine folks at Linchpin People, which allowed me to maintain my status as an independent consultant while aligning myself with other like-minded folks in the same space.  The downside was that this move meant my leaving Artis Consulting.  The folks at Artis – the ownership as well as the employees – are some of the best people I know, and the decision to tell them goodbye was one of the hardest things I’ve had to do in my career.  As difficult as that decision was, I think it was a good move for me.  As an independent consultant, I’ve already gotten to work on some exciting consulting projects, as well as focusing on other related initiatives (including training and tools development).  There are still a lot of unknowns and a great deal of risk along this path, but I’m glad I made the move and am very excited for the future.


I got to see a lot of you people in person in 2013.  Last year, I got the opportunity to speak at numerous events here in the States, including the SQL PASS Summit in Charlotte, the DevConnections conference in Las Vegas, six different SQL Saturday events, and five user group meetings.  In addition, I was invited to speak at SQLBits in Nottingham, England, which was my first international speaking engagement.  All told, I delivered 23 technical presentations this year, five of which were full-day workshops.  This is one of my favorite parts of being involved in the SQL Server community.


For the past 4 years, I’ve been a member of the board of directors for my local user group, the North Texas SQL Server User Group.  My time on the board was an incredibly rewarding experience, one that I would not trade for anything.  However, with the demands of my independent consultancy, I found myself with less and less time to focus on user group responsibilities.  My seat on the board was up for election this fall, and I made the difficult decision to step aside and not seek reelection to the board.  Although I’ll miss being a part of the NTSSUG board, I’ll still be around, attending user group meetings and other functions as my schedule allows.  As an aside, I want to extend congratulations and best wishes to my friend Dave Stein, who was elected to the open board position.


Holy schnikes, this one caught me off guard.  Between travel to client sites and my conference travel, I was gone almost as much as I was home this fall.  I don’t mind some travel, but I got a full year’s worth of travel in about three months.  Particularly with my new role as an independent consultant, there will be at least some travel involved, but I hope to avoid repeating the brutal travel schedule I had during the last 3 months.


I wrote – a little.  Very little.  This blog, which used to be a busy highway of information, has evolved into a rarely-traveled side street.  I love to write, and it is a rewarding endeavor in many ways, and yet I’ve neglected this part of my career this year.  I don’t want to use the term resolution, but it is my expectation of myself that I will write more in 2014.

Personal stuff

Though my professional highlights are almost all positive, there were a few other things that brought sadness this year.  My former sister-in-law, who is the mother of my 10-year-old nephew, died quite unexpectedly early this year.  I lost an aunt and uncle this year as well.  I also marked a sad milestone on what would have been my late son’s 18th birthday.  After nearly three years in business, my wife and I decided to cease operations on our small photography business, a marginally profitable but time consuming endeavor that taught us a great deal about choosing the right business.

There were others around me who struggled this year as well.  I have friends and family who have battled with health issues, job losses, family friction, and other hardships.

Although there were some sad events in my personal life, there were many positives as well.  I got to surprise my kids with a couple of vacations and spend some quality downtime with them.  On one of my visits to a client, I was able to visit Fenway Park for the first time and see the Red Sox beat the Rays.  We added a new family member, of the four-legged, canine variety.

Hello, 2014

I had many successes in 2013, as well as areas I want to work on improving during the new year.  I’m excited for what I see on the horizon, and I hope that 2014 is as good to me as its predecessor.

Dust Off That Resume

Since I started regularly attending SQL Saturday events some five years ago, I’ve sat in on a number of professional development sessions by Andy Warren, Buck Woody, Don Gabor, and others.  Each one offered different bits of advice based on his or her own experience, but there was an overriding theme in all of them: Don’t wait until you need a job to start grooming yourself as a candidate.  Start building your network right now, they would all advise, regardless of your current employment status.  Push yourself to learn, especially where you see a shortage of skilled workers.  Stay visible, stay relevant.

But what about that resume?  After all, the resume is just a very small piece of the big picture… a document that be easily thrown together as soon as you need it – right?  (Note: If you nodded after that last sentence, please, keep reading.)

2585643891_dc3e1b8c4c_n“Tell me about yourself…”

Writing an effective resume isn’t easy.  Most people think writing about themselves is easy until they actually go about doing it.  To describe oneself in a way that is flattering but not overly boastful, colorful enough to be interesting yet still truthful, while keeping the description to one or two pages at most, takes a great deal of time and concentration. Sadly, I see some resumes that appear to be an afterthought – just a means to an end, without much planning or proofreading involved.

Resumes that were thrown together at the last minute have several telltale signs:

  • They enumerate every piece of software or hardware you ever touched, without describing how you used said hardware or software to solve actual problems.
  • They are full of filler phrases like “dynamic”, “uniquely qualified”, “fast learner”, “track record”, and “progressive”.
  • They contain too many errors in grammar or spelling.  (How many is too many? Any number greater than zero.)
  • After I read the whole resume, I still have no idea who you are or what you can do for the company.

My friend Steve Jones delivered a professional development presentation some time back in which he recommended that everyone touch their resume at least once per quarter, regardless of whether they were actually looking for a new job.  I believed in that advice so strongly that I’ve repeated it numerous times since.  However, like an out-of-shape cardiologist, I’ve been quite adept at ignoring my own advice.  When I recently needed a current copy of my resume for a training initiative, I discovered that I had not updated this document in over three years.  I succumbed to the thought that “I’ve got a good job, I’m not looking to make a move, so it can wait” and let the information go stale.

5217079666_076cdc469a_mBut I’m not looking for a job…

Is keeping your resume up to date really necessary, unless you are (or expect to soon be) looking to make a career move?  I submit that it is important, for several reasons:

  • A properly written resume takes time to create.  Don’t allow yourself to be sucked into thinking that you can spent an hour or two to create a superb resume.  At a minimum, you’re going to need several days to get it right.  A resume isn’t ready to be sent to a prospective employer until you’ve gone over it, word by word, to make sure it’s perfect.  Write your resume, put it down for a few days, and come back and reread it to be sure it really tells a story.  You should engage others as well – get as much feedback as possible before you finalize it.  These things take time!
  • You might not be looking for a job today, but you might be tomorrow.  Let’s face it – for those of us in the ranks of full-time employment, we’re just one really bad day away from joblessness.  Anyone who works for someone else could, on any given day, find himself out of work due to a high-profile error, an unforeseen downturn in business, a personality conflict, or for no reason at all (in many states).  If you find yourself suddenly and unexpectedly looking for a job, you shouldn’t let a stale resume slow down your job search.
  • Your career changes faster than you think, and it’s easy to lose track of those changes.  During the three years that I ignored my resume, I had contributed to two books, was elected to the board of my local user group, received the Microsoft MVP award three consecutive years, and learned several new technologies.  What I thought would be an easy task of documenting three years worth of career changes turned out to be much more work than I expected.  Especially in high-tech fields such as ours, careers can evolve quickly, and an up-to-date resume should reflect those changes.
  • You occasionally need an up-to-date resume for reasons other than getting a job.  At a previous job, I was asked on a few occasions to provide a copy of my resume for the benefit of potential clients of my employer – these prospects wanted to know the kind of people they’d be working with in case my employer was selected as their service provider.  Further, some extracurricular activities (community board service, authorship opportunities, etc.) require the candidate to produce a current resume.


Keeping your resume up to date takes time, and it’s even harder to motivate yourself to keep current if you’re not looking for a job.  But in the same way you continue learning and networking while not actively shopping for a new position, it’s beneficial to keep your resume polished and ready to go.

Side note: If you’re a senior BI professional and are looking for a new challenge, why don’t you send me a copy of that freshly-updated resume?  My employer is hiring, and it’s a great place to work!

Being The Best vs. Being Affordable

I read a post on Brent Ozar’s blog last week that discussed employers’ expectations when hiring new team members.  Though the story was specific to database professionals, the same principles apply to almost any hiring situation.  The moral of Brent’s story is that when hiring, just like in real life, you have to compromise what you may really want to stay within the budget you have to spend.  If you had an unlimited budget, you’d hire Paul Randal to be your DBA, Emeril to be your cafeteria manager, that Sham-Wow guy would lead the janitorial team, and every employee would have a corner office and lunchtime massages.  Most situations don’t lend themselves to that kind of financial freedom, so you settle for more affordable talent.

There’s a flip side to this, specifically from the perspective of the candidate.  Everyone who has sat for an interview worries that they’ll be passed over in favor of someone who is better qualified.  Only the most arrogant truly believe that they are the best talent money can buy; the vast majority of people have enough self awareness to know that there are others who are better qualified, smarter, and willing to work for less money.

For the job candidate, the takeaway from this is to simply be yourself.  Understand that the employer wants to find the best person for the job, but they’re operating within a certain budget, and they won’t make their decision on skills alone.  Don’t try to convince your interviewer that you’re Seinfeld if you’re closer to being Carrot Top, or even Ben Stein.  Be honest about your strengths and your weaknesses, and don’t try too hard to impress. Your transparency will be apparent to any interviewer worth his/her salt, and even if you’re not a fit for that position, you’ll make an ally for the next time an opening appears.

Your Local User Group

When I talk to other SQL Server professionals, I’m often surprised at how many do not have any involvement in their local SQL Server user group.  As best I can tell, the problem is not limited to SQL Server types – many technical pros do not even know that there are user groups in their area, much less participate in any of them.

Local user groups are incredible and underutilized resources for technical professionals.  Most active user groups meet monthly, generally in the evenings or on weekends, and most are free.  These groups are not closed social groups as some may perceive, but are quite accepting of newcomers.  In all but the largest user groups, everything is run by volunteers, so there are opportunities to get your hands dirty if you feel led to give back to the community.  These groups offer a venue to share ideas, socialize with fellow techies, and some informal peer technical assistance.  If you are looking to improve your presentation skills, most groups are open to new speakers at group meetings.

If you’re not already involved, I encourage you to check out one or more local user groups.  I’ll take the opportunity to plug my local group, the North Texas SQL Server User Group, which meets at the Microsoft headquarters in Irving on the 3rd Thursday of each month.  The PASS website also has a domestic and international list of recognized chapters of SQL Server users.

SQL Quiz: Two Mistakes

I was tagged by Gail Shaw to post two big mistakes made during my professional career.  The only challenge here was to narrow the list down to two :)

The first one is very easy.  During my early days working with SQL Server, I wore a lot of hats, including that of web developer.  One of my first major web projects was to create a student assessment system, which would allow instructors to create online exams.  Students would then be able to use the web interface to take the exams, and the manual paper grading process would be no longer.  Now I’m not ashamed to confess that I was underqualified at the time to effectively complete this process; as the sole developer/DBA, the entire project from spec to support rested on my inexperienced shoulders.  Nevertheless, I forged on and delivered the application on time, albeit untested.  The magic hour was the following morning, when a dozen educators were to begin entering exams on the new application.  I should also mention that I was still in college at the time, and was in class – over an hour’s drive away – during the critical go-live.

It probably goes without saying that my phone started ringing shortly after the first staff members arrived.  Problems were rampant, and I ended up leaving class to go address the issues.  I dodged the angry mob at the front door and managed to get in and take care of the most pressing issues so the test building could commence.  In the end, the application was made usable and found a niche where it worked pretty well.  However, I can’t help but wonder if this tool wouldn’t have gained more widespread acceptance if I had been more experienced at the time and had done a better job during development and deployment.

Lesson learned:  Admit when you’re in over your head, and insist upon a thorough testing cycle.

The second one caused me a good deal of embarrassment and cost me the better part of a day.  After receiving a report from an end user that a critical report had not been run on one of our main databases, I got with our hardware guys to arrange for a restore of the database backup file from tape.  Since this is a large database, it takes a few hours to copy over, but our backup guru agreed to copy the file directly to the development server to save another copy operation from live to dev.  I got the call a few hours later that the copy was complete, but I found only old files on the target directory (and deleted some of them, as part of a periodic manual cleanup).  I called our backup guy again and told him something had gone wrong and the file hadn’t been copied.  Always a good sport, he kicked off the file restore again.  When the call came that the process was again completed, I checked the backup directory and still found only old files, including one I had deleted earlier.  I made another call to our backup guy to find out what was wrong with the backup software, and simultaneously opened a window to the live database server backup folder.  As I was explaining to our backup engineer that he had made a mistake, I saw the filenames in the backup directory on the live server – which looked curiously like the files I had deleted!  The database backups on the live server had a different naming convention than those on the dev side, and I had recklessly deleted the restored file the first time.  A quick RESTORE HEADERONLY confirmed that I had just wasted a good part of my day, as well as that of one of our best hardware guys.

Lesson learned:  Before you assume someone/something else is at fault, make sure you’re not doing something silly to cause the problem in the first place.

SQL Quiz: Career Challenges

I’ve read a number of responses from Chris Shaw’s first DBA networking quiz.  I missed out on the first one, but I have been tagged by Grant Fritchey for the second round.

The Questions for this quiz…
What are the largest challenges that you have faced in your career and how did you overcome those?

1) The first one of these, I still laugh at when I remember it.  I got involved in the IT industry later in life than most (mid-20s) and found quickly that I had a knack for learning and applying new things quickly.  I was doing tech and sysadmin work and there was an acute shortage of those skills, so I probably received more praise and recognition than I really deserved at the time.  During those early days I started to imagine myself as the alpha ubergeek, and believed that I could be an expert at all things technical.  I started to learn programming, jumping from C++ to Java and Perl to PHP, then onto non-Windows system administration – Linux/UNIX and even a little OS/2, and finally database administration in MySQL, Oracle, and of course SQL Server.  I remember at the time thinking that I would be able to set myself apart as an expert on all these disciplines.  Need an enterprise application built?  I’m your guy.  It’ll be a web app?  That’s still me.  I’m also the database guy (architect, dev, and DBA), and I’ll do the sysadmin as well.  Oh, and I maintain the hardware too.  I actually created a schedule that encompassed about two years, and included time for me to self-train in each of these topics.  I wish I still had that schedule, which would now be good for a hardy laugh, but I can remember that I had allocated a mere three months to teach myself everything about both PHP and MySQL.  This story does have a happy ending, in that I realized the absurdity of my intentions before I got myself in over my head.  My youthful inexperience allowed me to convince myself that I could learn everything about everything, and could maintain this knowledge as the technologies changes.  Another positive result is that my study in these other disciplines gave me a cursory understanding of other technologies to which I might not have otherwise been exposed.

Lesson Learned: Don’t try to be an expert in everything.  Identify a few things that you enjoy and do well, and maximize your time in those areas.

2) This challenge is ongoing, but I’ve gotten much better at this, particularly in the past year.  I’m a big believer in hard work, and I have seen that a person who learns a craft that is in demand and puts his or her nose to the grindstone will do well.  However, when I think about the people that I perceive as successful, these are not people that simply work hard (although most of them do work very hard).  Those who are exceptional are people-persons as well.  They work to know their constituency, including executives, end users, and fellow technical staff, and are comfortable at explaining difficult concepts to all groups.  They are good enough at office politics so that they are rarely blindsided.  In short, these successful people have soft skills to accompany their technical prowess.  One of my favorite lines used to be “I’m not a salesman, and I don’t play office politics”.  However, I’ve learned that everyone has to be a salesman to some extent, even if you don’t sell anything, if for no other reason to do enough self-promotion to ensure that you don’t become an office wallflower.  Office politics is not necessarily an evil thing – at its root, it’s about knowing people and understanding interpersonal dynamics.

Lesson Learned:  Keep working hard, but you’ll do even better if you also spend some time talking to and getting to know the people you work with/for.

To keep this thing moving, I’m now tagging Tim Costello and Devin Knight.

The Next Generation DBA

DBA, database developer, analyst, SQL grunt, or whatever your title may be, there is no question that your role will be evolving in the next few years.

I read a couple of posts from Jason Massie about the Death of the DBA (part 1 and part 2) earlier today, in which he predicts a diminishing market for database administrators, and SQL DBAs in particular.  These posts are not the first references to the “cloud computing” initiative stealing away market share from hard-working DBAs, and to some extent I can agree with this.  Opportunities for the “typical” install-backup-restore-defrag DBA will be reduced in the future, though it could be argued that this has already begun.  The stereotypical introverted techie who works best while locked away in an isolated server room can make a good living right now, but it is this type of position that could be in jeopardy due to cloud computing or similar automation.

Tomorrow’s database professional must know not only the technology but the business that requires it.  DBAs cannot afford to be agnostic about the data stored on their systems; he or she must understand not only the technical objects and methods, but has to grasp the big picture of what the data and metadata collectively represent.  This new generation of database professionals must have an understanding of the organization’s objectives, and must have at least a familiarity with – and just as important, an empathy for – users at every level, from data entry clerks to CXOs.  Top-notch database gurus will have to perform as well in a boardroom as they do in the server room.

I think you’ll find that the role of the DBA is not dying, but will certainly be forced to evolve.  There will not be a shortage of opportunity for those who understand the business as well as the technology and can translate (sometimes ill-defined) business needs into intelligent system objects and functionality.