b5media.com

Advertise with us

Enjoying this blog? Check out the rest of the Business Channel Subscribe to this Feed

Slacker Manager

I’m not a programmer, but I play one on TV

by Bren on December 16th, 2004

Ok, not really on TV, but sometimes at work…  For years now, I’ve been convinced that a deeper understanding of relational databases is a key skill that too many managers lack.  Back in the day, when I worked in retirement benefits, I started to realize that being able to ask questions of the database, and get reliable answers, was a rare talent among non-IT folks.  Beyond that, it equated directly into a kind of magical job assurance shield that moves with you from position to position. 

Every modern organization keeps important business information in databases.  Knowing how to access that information efficiently is a key skill that so far has been generally limted to IT folks.  Sometimes, all you need to know is how to work with Microsoft Access, but more often, and especially in larger organizations, there are specialized databases that managers must interact with.  There are lots of software interfaces available that try to make it a little easier for non-IT folks to query the databses, but these vary across organizations.  You may master JD Edwards at one organization and be facing Crystal Reports at the next place.  There is one common denominator for nearly all modern databases, which, if you take the time to learn it’s mysteries, will pay you back over and over again.  That’s Structured Query Language, or SQL for short.  Learn this, and you will rule.  It’s true that there are several flavors of SQL, suitable for different types of databases, but on the whole, the basic concepts are universal.

It literally took me years before I finally committed myself to learning SQL.  Once I finally bought a book about it, and started playing around, I became proficient very quickly.  There are a couple of tools that I think can be used by just about anybody, in any organization to take advantage of SQL.  The first thing you want to do is get your hands on a little book called Sams Teach Yourself SQL in 10 Minutes.  To be sure, there are a bunch of books that will tell you more about SQL, but for the rank novice, this one gets you from zero to sixty in short order.  Once you’ve got the book, read it from cover to cover without touching a computer.  Just absorb what it has to say.  Once you’ve done that you ought to be able to immediately apply your new knowledge to your particular database.

Danger, Experts Only
If you’re still feeling frisky, then go download yourself the ‘Query Tool
from George Poulose’s website (the website is referenced in the Sams
book).  There are a couple of flavors so be sure to grab the one that
works with your database.  The Query Tool is a clean and simple
interface to just about any database.  Your query results can be copied
and pasted right into Excel for further analysis.  You’ll have to
stumble your own way through connecting the tool to your database, but
it can be done.  You might need to call upon your favorite benevolent
geek to help you out.  Once you’ve made the connection, you’ll be able
to browse the tables in your database, build queries and save them, and
more neat stuff.  The one thing you need to understand about the Query
Tool is that it bypasses most of the security of other interfaces.
That means that you can wreak serious havoc upon your
organization’s database in short order if you aren’t careful.  Lots of
people will be mad at you and you could lose your job if you screw up
with this tool.  This tool is serious business and if that freaks you
out (and it probably shoud), stay away from it and just stick with the
tools your organization provides.  When I use this tool, I make sure
that I check a little box that limits my queries to read only.
That means I can’t overwrite data through the Query Tool.  The other
precaution I’ve taken is that I’ve purposely avoided learning how to
write SQL queries that write data.  I’ve only learned how to read
it–that is, I can only run reports, but I can’t make system-wide
changes via SQL.

So, if you invest yourself in learning any new management skills,
seriously consider adding SQL to your toolbox.  It’s a transferable
skill that will make you more valuable as a manager and it’ll make the
challenge of finding and organizing large amounts of data a little bit
easier.

POSTED IN: management, web/tech

3 opinions for I’m not a programmer, but I play one on TV

  • XTremeBlog
    Dec 20, 2004 at 1:54 am

    Carnival of the Capitalists

    Welcome to this week’s Carnival of the Capitalists, here at XTremeBlog. I hope you’ll be back to visit this place from time to time when there is no carnival to draw your attention. We post about everything from hardcore talk of programming, to bas…

  • Kevin
    Dec 20, 2004 at 7:39 am

    I agree that managers can and should learn to query their databases. One comment got me thinking, however - your comment “I started to realize that being able to ask questions of the database, and get reliable answers, was a rare talent among non-IT folks.” reminded me that the reason I (a non-IT person) learned how to query databases was because the responses I got from our IT folks quite often missed the mark.

    Managers know the business issues. Typically, IT folks don’t. Managers who run their own queries can quickly spot results that don’t pass the “sniff” test and adjust and re-run their queries accordingly.

    Also, querying is often an iterative process - a query begets a rusult which results in another, more focused query, and eventually you get exactly the data you need. Not having to go round and roung with IT can dramaticaly optimize this process.

    Great article, thanks

    K2

  • David Foster
    Dec 20, 2004 at 9:27 am

    Of course, managers should know how to query appropriate databases, and the points about interaction and “sniff tests” are good ones. On the other hand, it’s important that it be documented exactly what the fields really mean, and any assumptions embedded in the data, or people may be getting answers meaning something different than they think it does.

    Also, IT people should have the initiative to write programs or scripts that simplify queries in particuloar problem domains, and making these availablel to the appropriate line personnel.