An Interview with Phil Gibbs, Manager of Statistical Procedures in Technical Support
Phil Gibbs has worked in Tech Support for over 15 years, where he has most recently handled customer
questions concerning the mixed models software and optimization in the statistical procedures.
He's recently become manager of the statistical consulting group, and I spent an hour talking with him recently.
Gibbs has degrees in Mathematics from Vanderbilt and Clemson, with a specialization in statistics. He
worked as a statistician for organizations such as Pratt Whitney, Michelin, and the EPA before coming
to SAS Technical Support. He now manages a group of ten statisticians, most having worked in tech support for
over ten years. Phil's group covers products such as SAS/STAT, SAS/ETS, SAS/OR, SAS/QC, and SAS/IML.
You must like working in Tech Support.
I do. I like solving customer problems. In fact, I solved a problem during my original job interview.
Eddie Routten had me sit on in a call, and he couldn't answer this particular question off the top of his head.
But I knew the answer, so I waved my hand and told Eddie, who relayed it to the customer.
Did you get paid for that?
No. But I did get a job offer soon afterwards!
What happens when a user calls in with a statistical software question?
It gets routed to the statistician on phone duty right away. Almost forty percent of the time,
the question gets answered during that call. If that statistician can't resolve it, the question gets
routed to the statistician who covers that specific area. We get a response to the customer within 24 hours.
Most of the time, this response includes a resolution. Sometimes the problem needs additional research and
consultation with a developer.
How does that work?
Everyone on the team has their own area of expertise, survival analysis or categorical analysis, for
example, and we work closely with the developers for those areas. When we contact development with a
problem we can't solve, developers usually drop what they are doing to help us resolve the issue. If
it's a new issue, we can document the problem with a SAS Note.
How else do you work with development?
We review new documentation, and we often provide suggestions for existing documentation.
We also make suggestions for new features, based on what our users are telling us, and also
based on our own observations.
I know that technical support is a career in itself at SAS, rather than a starting point like
at many other software companies, but you have people who have been in the same job for over
twenty years! What explains that?
Every single day is different. You never know how your day will go each morning.
You are constantly learning in this job. In fact, I'd say I learned something new
every day for the first ten years I worked here. It can take that long to reach a point where
you might go a single day without learning something new.
I would imagine that includes learning new areas as new software gets written.
That's right. We often need to divert responsibilities so one of our team can dig into a new
area---for example, Bayesian analysis. Rob Agnelli needed time to take courses, go to conferences,
and study that subject area as well as learn our new software thoroughly.
Nobody knows the statistical procedures like you guys do. I know I get asked questions
I can't answer at conferences and I often look to see who's there from tech support to help me out!
And there's a lot to know! Sometimes we get calls for procedures like REG or CAPABILITY,
and the user has combed the documentation for an option he or she knows is there, but
can't find. The user can be embarrassed when we recite the option name without skipping a beat,
but we understand! Comprehensive software means lots of features!
What can users do to best facilitate getting answers from Tech Support?
First, we should let your audience know that any SAS user with a valid site license can call
Tech Support. Years ago, all questions had to go through a SAS site representative, but that's
not true today. Then, having your SAS release number at hand, along with relevant error messages,
is important. We'll also need access to your SAS code, log, and data sets if we need to recreate
a problem. Also, I should probably point out that we work on software issues; we can't provide
advice on how to solve statistical problems.
Any final thoughts?
I've never worked with a better group of people than the statistical group in SAS Technical Support.
I wish everyone could have this experience at work.
