Wednesday March 15, 2006

17 Years

My time at Sun Microsystems is soon to come to an end, and so I've taken this opportunity to take a retrospective look at the last 17 years with Sun, 71% of it's life, 42% of mine. If you're not mentioned it's an oversight only, and if you do recognise yourself, then smile.

Peak Experiences:

Hawaii: Winning the ultimate atta-boy in 1993. I did work very hard on the phones in the UK Support Centre, and won a Services award for my efforts. (Taking and closing 28 NeWSprint/Modem/Printer/Serial Port calls in one day was my personal best). For my efforts I was given the once-in-a-lifetime experience of going to a Services conference on the island of Maui, Hawaii with my wife and we stayed in the four seasons resort for three days. It was a glimpse of another world that I had never even dreamed of, and was truly a peak experience.

Cooking: For a number of years the White family organised the food provision for the Sun Summer BBQ at Camberley Cricket Club. The goal was to provide a BBQ for 700 people and feed them between 5:30 and 7:30pm – 350 people per hour, more than 5 people a minute for 2 hours served with hot food and salad, catering for vegetarians and carnivores. I recruited my colleagues in the Solution Centre, complied with all food hygiene, local council and employment laws, sourced food from local butchers, and together we offered an excellent service to our colleagues in Sun, for about half the cost of an external catering company – oh and it was fun. JN and his competitive BBQing, HH forgetting to take money with her to the shops, all memorable and such things added colour to the work we were doing.

Barn Parties: I had a notion that my colleagues were dangerous when drunk, leaving a trail of hotels that would not have us back – yet the Solution Centre did like to party, so I had the idea of a heady mixture of real ale, BBQ'd food, good music and an environment that they simply could not break – empty arable farm barns. All the barn needed was water and electric, and be away from other people (like in fields, where arable farm barns usually are). We had a number of Barn Parties, all well attended, most people got outrageously drunk, we camped on site, had a hearty full English fried breakfast in the morning and as the venue was typically “rural” there was very little to clear up afterwards. And farmers would have us back.

Hmmm, on reflection a lot of this wasn't actually work related, more about the Fun@Sun activities that used to go on in Sun, and since the dot bomb have all but ceased.

Travel: This career was lived on location in:

Bahrain, (excellent duty free at the airport)
Belgium, (good beer, lovely colleagues)
California, (spending the night sleeping under the stars in Death Valley, and waking up at 4am to go to Dante's Peek to watch the Sun rise was a peak experience)
China, (Beijing – an incredible place to visit, some truly talented people working in the Sun office there)
Colorado, (Visually stunning airport, many lovely colleagues)
Czech Republic, (Only place I've been threatened with physical violence when asking for a taxi receipt)
Finland, (Eat more fish, there's a limited supply, when it's gone it's gone, so help yourself to some more, here's a really big pile of it, go on, you know you want to)
France, (The Paris Peripherique on a Friday at 5pm on a motorbike is an experience to savour and survive)
Greece, (Lovely and crumbly)
Hawaii, (See above)
Iceland, (Beautiful, cold, dark, expensive, sulphurous, exciting off road adventures in a 53 seat coach, expensive, did I mention how expensive it was? Oh yes I did.)
India, (Excellent food and hospitality, lovely silks on MG Road, very clever colleagues, always got sick no matter how careful I was)
Ireland, (Fresh Guinness, a beautiful thing. Eating chinese take-away on the beach at Malahide in good company. Priceless.)
Italy, (Northern industrial towns in winter can be somewhat grim I think.)
Japan, (Winners of the “feed a foreigner something strange and watch the reaction” competition with a fish that was not actually quite dead at the time of eating).
Kasakhstan, (beautiful to look at, personal safety not assured, came closest so far to dying - in a car crash – somehow everyone missed crashing, I'm sure that physics was looking the other way. And too many guns. And beautiful beautiful women).
Massachusetts, (Would you like beef with that beef sir?)
Netherlands, (Flat and efficient. All they need to sort out is the position of the traffic lights at their intersections and all would be perfect.)
Nevada, (Only popped in for a short while, walked in one casino and out the other side – could not see the appeal...)
New York State, (Bagels, turnpikes and obfuscated roadsigns, a heady mix of brusqueness and efficency)
Norway, (Fish. See Finland)
Qatar, (The seafront has got to be one of the most beautiful of the Persian Gulf)
Singapore, (Everything works, great tailors, beautiful people, lovely weather, efficient rapid transport system)
Spain, (Tapas. What an excellent eating strategy.)
Switzerland, (Airport, Bankers, Airport – repeat)
UAE, (Spent a month there over Christmas being the Solution Centre in the '90s. Truly enjoyed the Suk and the sunsets).
UK, (All over, customers and offices)

Cast:

Steve White – himself
Best manager in career – SU
Man with best hospitality in the world - RG
Best impression of a Dutchman - BS
Clever people in office – CG, TU, CK, MH
Men in canteen – MH, SS
Open All Hours – JF, PH
Man who most often saved me from redundancy – IW
Man who gave me the best breaks – JR, DP, IC
Man who showed me the real meaning of company car cleanliness when he suggested I clean my wheeltrims with a toothbrush like he did - WS
Lounge Lizard – LH
Man comatose in hotel room – DG
Driver of funniest road traffic accident – MT (Now before you reach for your “Dear BBC” notepaper there is no such thing as a funny road accident, except this one. I cannot tell the tale publically, those who were in the UK Solution Centre at the time will remember it as just a classic of it's genre. MT will probably sue me over even mentioning it. Or he might drive into a pond, you really cannot tell).
Driver of second funniest road traffic accident – DG (Again only funny because no-one was hurt, and getting an Astra 17ft up a lamppost on flat ground really is most impressive. As I drove into Watchmoor Park that fine dry morning and saw the litany of vehicular carnage only one thing crossed my mind... “That'll be one of ours”. And it was).
Reformed driver: TU
The Doctor – RH
Colleague who should have written a personal image improvement guide – Anita Selfe
Management who sound like Ricky Gervais in “The Office” – all of them.

Outtakes:
A new colleague who has interviewed well and was not very good was telling NT and me about his hobbies in an idle moment office chat of the “getting to know you” kind of way. He said that he and his wife like Jazz Magazines and N pricked his ears up (being a musical Jazz fan) and said “I'm a great fan of jazz. What kind of jazz?”. “Pornographic” was the reply. Oh false floor open up and take me away. Until that moment I had no idea that Jazz Mag meant anything other than music. He did leave soon after.

I am going to have to name his name for this recollection. All was quiet late in the evening and a few of us were heads down when a colleague on the other side of the partition answered the phone. It would be like the 40^th time that day that he'd answered the phone and was not quite as clear as maybe the first occasion. His real name was Jon Peacock, and from that day we knew him as if his first name started with a D and his second name with a K.

There were a host of other outtakes – I just can't recall them now.

Directed by: IC, JE, DG, DP, JR, SU
Produced by – Scott McNealy

This has been a Steve White production for Sun Microsystems.

The sequel will shortly begin with Kepner-Tregoe. swhite at kepner-tregoe dot com.

sdw0: transmission stopped.

Tuesday February 14, 2006

Rational troubleshooting takes too long. It is a well established fact that rational troubleshooting takes too long. It's always been the case that when a Support Engineer in Sun is shown that there is a rational way to approach the data gathering and processing of incoming symptomatic information there's a mantra on first impression "this takes too long", "I'm paid to fix problems, not understand them", "There's not time to handle things this way".

If we treat this observation as a "performance problem", as in "Understanding the symptoms of a problem takes too long" we can begin to use KT-Resolve / SGRT thinking to pick this apart.

Is the Should good, is the Actual factual? How long should it take to initially handle a customer case during the first contact with the customer? Many companies have a tiered approach to customer handling, and plucked out of the air (I think on the tide of "Live Call Transfer" installations) was the figure of 15 minutes per customer case for the initial examination of the concern. If that's an average, all works well, and we also know that where there's an average there is a distribution curve. Many many incoming cases take way less than 15 minutes to process - "I need a patch", "When I do this, this happens - and this is what you need to do" and so on. Obviously on average there are cases that take about 15 minutes to understand, and when acknowledging the existence of a distribution curve there are inevitably cases that take longer to specify.

So if we're in agreement that some cases will fall to the right of the average on the distribution curve, how do you know which ones to concentrate on?.

I believe we have found the answer - it's cases which are a "problem" (using the Kepner-Tregoe definition of a problem, not the ITIL definition, they call it an incident) to the techie who is handling the incoming case.

When handling incoming customer cases, despite the acknowledgement of a distribution curve you have only 15 minutes with the customer to get a clear understanding of the problem. The question is whether you attempt to fix the problem in 15 minutes (without understanding it fully, which often results in "shotgun" fixes) or you spend 15 minutes characterising the problem for someone else to solve.

What can reasonably be achieved in 15 minutes?

Situation Appraisal when done quickly is hugely revealing about the root concern - and action can then be considered to mitigate the effect or the cause. Situation Appraisal is applicable to every incoming case. If the result of the SA is that the customer is facing a problem, then it makes sense to State and Specify the problem.

It is not necessary to collect a full specification of a problem at this stage as the information is likely to be used to route the problem to someone who knows more about the content, and also to guide their thinking and approach. In Sun we have discovered that it's necessary to concentrate on a subset of the whole specification. In this way, for most of the time (again a distribution curve comes into play) the fundamental essence of the problem can be collected in under 15 minutes.

We run a "15 minute spec" exercise while delivering the SGRT class to end users when the audience includes frontline "first customer contact" staff. It's (of course) only an exercise, and we've found that we can extract the essence of the problem from the problem owner (who, for the sake of the exercise has all the answers - not so in real life) in around 8 to 10 minutes.

This first iteration of the specification is good for routing (we'd call it a top level spec, which has general answers) and guiding the thinking of the content expert, and is not detailed enough for continuing with if the problem is not solved quickly by the content expert. It takes a content expert to be able to frame the questions in the technology at hand to produce a "second level" specification on which the remaining processes in Problem Analysis can be operated.

When rational troubleshooting is used to the degree necessary, using targeted and clear questioning, it can reduce the time to close problems by a huge amount. When used well, rational troubleshooting takes no time at all to use, because it's saving time that might be otherwise spent on irrational troubleshooting.

( Feb 14 2006, 02:27:14 PM GMT ) Permalink

Thursday December 29, 2005

Rational Troubleshooting and Betty The Adaptive Model of technical support about which much is written and details can be found elsewhere is a technique for structuring a support organisation in a way that removes the artificial barriers often imposed unthinkingly. For instance, when there is a "frontline" organisation which is local to the customer, and a "backline" organisation that is distributed, one frontline engineer has no access to excellent technical skills that might be in a peer frontline organisation. The tacit belief is that superior technical knowledge is "upwards", and to access that technical knowledge is an "escalation", the very choice of that word bringing to mind an upward movement.

The Adaptive Model is a leveller, and will allow anyone in the support organisation to be involved in any customer issue, irrespective of their geographical or hierarchical location. Suddenly a much greater number of alternatives are presented as potential candidates to answer the question "who is the best person for the job?" as it might be a "frontline" engineer in another country or region who has just the expertise that is needed to solve the issue.

This levelling brings with it two hard problems to solve. One is how to offer the issue to a wider set of people than before, and secondly how to communicate clearly the needs of the customer within a dynamically assembled team quickly and effectively. Clever routing tools answer the first issue. I believe that rational troubleshooting processes satisfy the needs of the second, and we have done research in Sun to identify the time efficiencies possible when people in a support organisation are good at, and genuinely use the same thinking methods.

This is not template completion. Template completion is easy and practically useless in terms of time saving.

The results from this research were derived from an experiment using people who use the "SGRT thinking way" - an internal-to-Sun label which expands to practical and consistent use of the right tool for the situation, used to the degree necessary to get the result needed. It's the mindset of using Situation Appraisal when first speaking to the customer, and if the SA concludes with an inkling that this is a problem, seamlessly and elegantly transitioning into Problem Analysis questioning, using the process so well that only a customer also trained in rational troubleshooting would recognise that they are being guided to answer specification issues, and with product content knowledge that allows a deeper exploration of the issue than "Machine Crashed". It's then offered to other technically capable engineers who also approach the collaboration with the same thinking processes, continue SA, continue PA and test their possible causes against the specification information already gathered, before concluding with Think Beyond The Fix.

Working in a support organisation is a bit like fishing in a river with a bucket. When you have space for more work you dip your bucket in the never-ending stream, and there are two options - you either fix the customer issue yourself, or you gather information to advocate the customer situation to the dynamic team you are going to build around you. Rivers can be flat, and broad, and have deltas, the concept of always going up is gone, to be replaced with flow.

In Sun, when we experimented with some technically experienced volunteers who were SGRT trained and supported in a coaching group, we found that the customers benefited in elapsed time savings hugely when rational troubleshooting was applied.

In the Adaptive model, good use of rational troubleshooting will be key to solving customer problems in a timely manner, and the results speak for themselves.
( Dec 29 2005, 11:51:47 AM GMT ) Permalink