Archive for the ‘T-SQLTuesday’ Category

T-SQL Tuesday #028 – Jack of All Trades, Master of None?

March 13, 2012 3 comments


Argenis Fernandez is hosting this month’s T-SQL Tuesday and he asks us the following questions:

Are you specialized? On something? Or anything at all? Has that been a good or a bad thing? Why?

Are you the SQL guy at work? Or the one who does everything?

Do you code? And configure wireless routers at work also?

If you had to pick one thing to specialize on, what would it be?

I’ve mentioned at least once or twice that I fell into, not only DBA work, but IT work in general several years ago.  When I did get that help desk position back in 1999 event though my primary responsibility was to provide first level support, answer the help desk and escalate calls to other, more experienced technicians I found myself quickly picking up the skills needed to resolve an ever increasing number of trouble tickets on my own.  In addition, I found myself taking it upon myself to take on systems themselves.  I worked in a small IT Operations team – there were 6 of us in total and we managed everything from the desktops, network, phone system, server systems, application support, licensing, etc, etc…  I found myself picking up systems that no one else on the team wanted or had time to properly manage.  Things like our old VMS system, Anti-Virus system, and even hardware support.  At one point I could rebuild an Okidata printer in less than 30 minutes – just because I did it so often.

Because I tended to pick up the red headed step systems in our network I have gathered a general knowledge about many areas of IT, and I don’t consider myself an expert in any of them – and honestly I’m okay with that.  It kept me on my toes for the early years of my career.  I never knew if I would be working on a queue problem in VMS or a virus outbreak when I got to work.

Even now – with my official title of DBA I tend to wear a lot of different hats.  I manage licensing for the business, I manage most of our hardware purchases, I am a back up Exchange administrator, I still help out at the Help Desk when needed, and I’m a resource for the newer folks on our Operations Team.  There are times, when my databases are behaving themselves that I don’t even open Management Studio for days at a stretch.

It’s a mixed blessing in my opinion.  Taking this path into IT and being more a generalist than a specialist has given me the confidence that I can tackle any area of IT and become proficient, but the flip side of that coin is that I, at times don’t see a clear path to becoming a specialist, let alone an expert in any single area.

With all that being said, I suspect that I am the most specialized person in my team at this point, and I agree with what many others have said today.  Specialization is best when it follows a well rounded base knowledge.  You have an edge that others might not have with that base knowledge.  You can often see the bigger picture quicker, and you have alternate paths to explore when troubleshooting issues.

So, go be a Jack of all Trades for awhile – and when you’re done doing that think about the one area of IT that really caught your attention and focus on that for a while.  I would guess that it will serve you well just like it has me.

Categories: SQL, T-SQLTuesday

T-SQL Tuesday: Giving the Business what they really want

December 14, 2010 2 comments


This month’s T-SQL Tuesday is a topic that I hold near and dear.  It’s something that happens all the time.  Someone in a leadership or decision making capacity asks the IT group to solve a problem and that business user thinks that they know how to solve it.  Unfortunately, they are asking for the moon, and the solution either doesn’t make fiscal, technological, or just plain logical sense.

So, how does the person with the technology know how get the business a solution that will truly solve their business issue?  After many missteps and wasted capitol expenses we implemented a pretty straight forward process to translate business requests into technology solutions. 

We use a template for a Business Requirements Document that walks business groups through defining the business issue, and what they would like the desired end result to look like.  This template asks questions about physical processes, processes within software, and decision making points within the process and helps define what parts should be solved with technology.  Along with the BRD, we use theory of constraints to ensure that the BRD meets the root cause of the issue. 

Once the business team has completed the BRD, and their TOC work it is usually pretty apparent if the issue they are trying to solve requires a technology solution.  Only then does IT become involved. 

With the BRD, and TOC documents in hand it is left to the IT group to identify the proper technology for the issue.  IT then reports back to the business team with costs, timelines, and if possible alternate solutions.  Once everyone agrees and money and time has been allocated to the project it is scheduled and the real work begins.

I’ll be honest, this doesn’t always lead to the perfect solution that everyone is happy with, but more often than not it does help us solve business problems more correctly the first time and all stakeholders involved are able to feel like their input was taken into account.