Today I taught a man to fish!

By Nighty on 27 November 2009

Sometimes, a little communication can go a long way. Today's story involves:

  • The customer: bright young lad, fun to work with, has a clue - what a relief!
  • The connaisseur de configuration: yours truly!

Having arrived late at work, see previous adventure, I'm slurping my first coffee of the day and reading up on my mails. Mails, apparently being Tinkerbel on crack, as I discovered recently. I reach the customer's mail. It seems he needs to know which database of application B in a specific environment is connected to ours on the same environment.

Almost automatic, I fire up my database client. I log into the correct database, look up the info and provide the customer with the result of my search. I open the next mail and move on attention-wise.

Minutes after clicking that send button, it hits me, as if the coffee was starting to kick in and wanted to make damn sure I knew about it... This is like the umpteenth time a similar request has come in from the customer's team. Perhaps instead of feeding them fishes all the time, I should teach them how to fish?

I open up another email and give him the SQL command involved, explaining this way he won't have to wait for me every time he needs to have that information. The reply is a simple thank you note: the customer agrees that indeed this is better, and is probably wondering at this point why he never thought of asking if it were possible for him to look it up himself.

Now what happened here? We communicated, that's what happened. Sure, we were talking before. But communication goes beyond the superficial, the literal meaning of the exact sentences uttered. When somebody repeatably asks you the same thing, something which he can't figure out on his own, he doesn't just express a need for that particular information as it exists right now. The repeating pattern suggests that his need, whether he realises it or not, goes beyond the here and now and it might be beneficial being shortcutted straight to the information itself instead of having to go through a liaison.

Thinking about it, I realised I was applying that same principle already in another area: whenever I feel my role is mainly to act as a messenger between two parties (which given my function happens a lot more than I would like), I get them to talk to each other. You'd be amazed at how slow things can get resolved if you have to coordinate over email, the phone or middlemen instead of getting the implementers or stakeholders together into one room. And how much of your time, that you could be spending more productively, is being sucked up in the process. You'd also be amazed at the resistance you encounter from some people when you try to optimise by plugging the stakeholders directly into each other...

So in the end, I had a pretty good day. I made a customer less dependent on me, removed a bottleneck in his workflow and most of all: I wrote that blog post I promised him in jest. Tomorrow, I'm mailing him the link. ;)

Oh, and the SQL command involved? Either SELECT * FROM DBA_DB_LINKS or SELECT * FROM ALL_DB_LINKS, depending on your particular set of rights in Oracle.