I was tagged by SQL Server Expert Brent Ozar in his response to a great, thought provoking blog post called Give Me a Coconut and Six Months by Tim Ford (SQLAgentMan on Twitter).

The short summary of the post is if you had six months free of distraction, what would you turn your attention to.  Tim’s choices included backups, security, and monitoring, which I think is a great “solid foundation” to work from.

Brent posits that if he became more effective at data mining, he would be able to provide a business with critical insight with which to improve sales, product focus, and develop key personnel.

If I had more time (and skills), I could tell executives things like:

• These are the top five customers who are about to leave us.
• These are the top five products that are about to go viral, and we need to stock more ASAP.
• These are the top five salespeople who need coaching to produce more revenue.

Walk into an executive’s office with this kind of information, and you’re a hero.

Here’s the shocker Brent… I agree. 

I agree that delivering that kind of data to management is the Holy Grail of IT projects.  Before coming into the IT realm, I ran a small business and I would have killed for information along those lines. 

One thing I think is missing from Brent’s discussion is that there are three parts to this type of data mining:

• The first part is the technical aspect on how to retrieve the data from databases and other sources of information, which Brent probably has handily covered. 
• The second part is not a technical question at all.  The second part of the data mining is actually coming up with questions you have for your data.  The quote above from Brent’s post highlights those, and point to an area of expertise outside the technical.  Brent is demonstrating (and probably should have said explicitly) that a domain/business knowledge is very important in determining these requests.  This is often difficult for the stereotypical IT person, but is essential if you are interested in moving your career past a technical implementer. 
• So, it appears Brent’s real goal is the the third part of this process, which is translating these questions (taking the business knowledge) and retrieving and correlating the data (using his technical skills) that he will need to make these determinations.

Brent continues on to cover a common area of disagreement between us.

I kick the PowerShell horse a lot, and here it comes again. If you’re in IT, listen up: you’re either cutting costs, or making money.  Guess which one has more upside.  If you truly bust your hump, become an amazing scripting deity, and save 99% of your time, you just saved 99% of your salary.  If you’re really good, you might save 10 people 99% of their time.

I work as the sole admin/accidental DBA/desktop support/multimedia support/”if it has a blinking LED light” support for an agency that collects lots and lots of data.  As a scripting practitioner, if I save myself 25%, 40%, or even 60% of my time not having to solve the same problems over and over, I’m free to plume the mysteries of my database and convert the bits stored their into meaningful data and even information that is usable and actionable. 

Not every environment has the luxury of being able to afford someone of Brent’s caliber to come in and learn their business and help them develop methods of turning their data into knowledge.  In my situation and that of many small to medium businesses, scripting is the tool that enables the IT generalist to explore and branch out into these other areas.

Brent may feel ” you can go into data mining and make 100 salespeople twice as effective” and that IT people who keep things running are replaceable and he may be right, but I believe, especially in tighter economic times, specialists become a luxury that only a few can afford where efficient generalists that know the business become more in demand.

Don’t be mad Brent… it’s okay to be wrong every once in a while!

So if I had six months of no interruptions and could focus on certain specific projects, I would:

• Finish automating (via PowerShell, SQL, or other means) common tasks
• Develop the questions my administrators (not technical admins, but departmental administrators) would like to ask our data sources
• Build tools to answer those questions via reports, graphs, network maps, or other data visualization techniques (like the cool stuff Doug Finke and Chad Miller have been doing)

I personally think that EVERY technical person should have a grasp on the basic business environment, be aware of what is happening in their company’s industry (or at least their department’s industry for larger organizations), and begin to develop more in depth domain knowledge as to the business processes.

Due to the odd path I took to becoming an IT person, I’ve actually accumulated quite a bit of domain knowledge about the law enforcement, the various jobs, information requirements, and the ins and outs of our workflows and data.  This background gives me a great starting place when going to look at my data, since scripting has given me the time to do so. 

Judging from the pattern in Tim’s and Brent’s posts, I’m supposed to tag a few people..

How about:

• Doug Finke (developer, data visualization explorer,  and PowerShell MVP),
• Hal Rottenberg (administrator, VMWare vExpert, podcaster, and PowerShell MVP),
• and Wes Stahler (administrator, blogger, and PowerShell enthusiast)