Welcome to Lake Wobegon, where all the women are strong, all the men are good-looking, and all the children are above average.

~ Garrison Keillor

The New Year is a good time for reflection.  In that spirit, I’m going to try something different here.  One of our regular readers recently made a pointed remark about his clients’ general desires to avoid reaching out to Oracle Support unless
absolutely necessary.  This isn’t the first time I’ve heard this sentiment but it crystallized my thoughts on something I’ve been meaning to discuss here for a while.

“See One, Do One, Teach One”


Cover of Complications-Atul-Gawande.jpg

One of my favorite medical writers is Atul Gawande, an accomplished surgeon and frequent contributor to the New York Times and New Yorker.  In his superb first book, Complications:
A Surgeon’s Notes on an Imperfect Science
, Gawande makes this critical observation:

Every day, surgeons are faced with uncertainties.  Information is inadequate; the science is ambiguous; one’s knowledge and abilities are never perfect.  Even with the simplest operation, it cannot be taken for granted that the patient will come
through better off — or even alive.

… In surgery, as in anything else, skill and confidence are learned through experience — haltingly and humiliatingly… we need to practice to get good at what we do.

… This is the uncomfortable truth about teaching.  By traditional ethics and public insistence (not to mention court rulings), a patient’s right to the best care possible must trump the objective of training novices.  We want perfection
without practice.  Yet everyone is harmed if no one is trained for the future.

The Impossibility of Perfection Without Practice

Technical support isn’t surgery, of course.  But there are many parallels in the complexities of the diagnostic process and procedures for addressing a particular situation. 

Although I’m part of our Development group, I get frequent opportunities to work with our Support team in a number of different capacities.  Like any large organization, I’ve found that Support has staff with varying degrees of technical depth and
experience.  There are seasoned Support staff from whom I learn something with each conversation, and there are novices whom I occasionally coach or correct.

Like the proverbial box of chocolates, you’ll never know who you’re going to get when you log a
Service Request (SR) against Metalink.  You might get a seasoned veteran or you might get someone who’s still learning the ropes for your particular problem.  Support engineers usually search our internal knowledge base and discuss tricky SRs with
the grizzled vets before making recommendations to you.  Regardless, the odds are that some of your SRs will be handled by engineers in the early stages of their careers.  This is inevitable.  If you understand Gawande’s reasoning, it’s also
desirable and necessary.

What Can We Do Better?

Understanding that, I’d like to invite you to suggest ways in which we can improve how we provide support for E-Business Suite technology stack issues.  Remember that I’m in the Applications Technology Integration (Development) team, not Support, and
can’t make any commitments on Support’s behalf.  I can promise you that I’ll make sure that your feedback gets heard by the right people responsible for supporting our EBS technology stack.

Here are some tips for keeping this conversation productive:


  • Keep things focussed on EBS technology stack support, not product support (e.g. for Financials or Human Resources).

  • Please keep it constructive.  We can’t do much with “Support sucks.”

  • Avoid ad hominem attacks and unreasonable flames.  These will be moderated.

  • Be specific, drawing upon your actual experiences.

  • Provide Service Request numbers if you feel they’re illustrative (or email them to me directly if the details are confidential).