Work – Page 8

Avoidable Drama

3 February, 2019

The Moorings, looking west from the north side of A dock. B dock was destroyed in the hurricane and is being replaced, hence the barge and crane. If you look carefully to the left of the barge you will see the mast of a sunken boat sticking out of the water — a Hazard to Navigation.

I was chatting with a friend in the BVI last week who had seen an interview with someone — I don’t recall who, unfortunately — who made the point that there are two kinds of drama to be dealt with in life: Avoidable Drama and Unavoidable Drama. Hurricanes, and interacting with your family, are examples of Unavoidable Drama. There is nothing you can do to mitigate or prevent it, you just have to deal with it as best you can.

Avoidable Drama, on the other hand, can and should be avoided, unless you are a Dramatic Person and thrive on that sort of thing. (Probably worth mentioning that most Dramatic People don’t realize they are inducing Avoidable Drama, rather they believe they are victims of Unavoidable Drama. But that is another blog post.)

Anyway — Avoidable Drama was in full force during our return to The Moorings dock A on Friday afternoon. Total disorganization on the dock was made worse by a few as yet un-dealt-with shipwrecks in the harbor (Unavoidable Drama). This was further aggravated by a whole bunch of catamaran crews with no idea what they were doing (Unavoidable Drama). The combination turned what should have been a straightforward procedure into a stressful interaction with lots of yelling back and forth between us and The Moorings boat handlers that left a bad taste in everyone’s mouth at the end of a really nice trip.

Why was this avoidable, when there are so many unavoidable elements present? Well, all that had to be done to remove the drama and lower everyone’s temperature would have been to tell all the boats coming in to hold in Road Harbor (where there is plenty of sea room) until cleared to enter the marina. This would only have required a single organized person with a radio, a pencil, and a pad of paper. Instead, the standard procedure was to tell every boat that radioed for permission to enter to come to the end of dock A and wait for further instructions. Unfortunately, because of the above-mentioned Unavoidable Drama (shipwrecks), there is only really room for one boat at the end of dock A. Try to put us and 8 clueless catamaran captains there at the same time, and hilarity ensues.

(What did we do when faced with this situation? The only safe thing to do: We entered a random open slip and tied up the boat. We were lambasted by the dock maser for this, but the alternative was crashing into something and endangering people and property, so…)

If there is a moral to this story, it is that the way to avoid Avoidable Drama is by putting a bit of process in place. Of course, if you put too much process, then you create more Drama than you avoid. So be careful…

Good Customer Service

16 January, 2019

I just had a very nice experience with Concept2, the company that makes the rowing machine I spend a lot of time sitting on. The electronic monitor on my machine has been throwing errors for a while, which doesn’t really hurt much but it’s annoying in the middle of a row. So I finally got around to emailing them about it. Turns out they use Zendesk to manage their support inquiries, which I have seen before only because Kim just started using it at Harp Column.

Anyway, it turns out that the monitor on my rowing machine, which is about 5 years old, was from a batch they have had consistent problems with and they are sending me a replacement for free. Good customer service, that. The only way to do better would have been not have the problem in the first place.

Consider, though, the amount of effort it took to make that customer service good:

They had to be tracking complaints about this particular performance monitor
They had to have a tracking system in place
They had to have a team of people trained to use the tracking system
They had to have a way to replace defective bits for customers — spare parts, etc.
They had to build into the product a way for customers to check what version it was to tell the support team
Finally, they had to have the actual will to be good at customer service

I used to think that just having a policy of caring about customers and being nice to them was sufficient. Turns out it requires much more effort than that.

Demos, Videos, and Lies

15 January, 2019

I’m involved with a research project here at Red Hat that is really very interesting. It’s an open-source platform for executing medical image processing codes and managing the results. Imagine you’re a radiologist and you want to quickly run some kind of algorithm — say, a brain volume scan — on the 100 brain MRI slices you just got. You can either go to the command line, assemble all the files, remember how to execute the image processing program, and hope it works, or you can use this nifty app — called ChRIS — we’re helping to build and do it all by pointing and clicking.

For the big Red Hat Summit event coming up in May, we want to add a new capability to this app which is even more interesting — the ability to compare the result of running one of these plugins with existing results held by hospitals doing the same kind of work. The catch is that these results will be protected by patient confidentiality (as they should be), so the hospitals can’t legally share them with other hospitals even for research. For this project, though, we are leveraging a thing called Secure Multi-Party Computing to allow us to share knowledge about the collection of results across hospitals, without actually sharing any of the private data. So a radiologist should be able to ask things like “What percentile does this particular amygdala fall in relative to others in the same age range” and get an answer that is informative but doesn’t compromise anyone’s privacy. This is really cool and potentially game changing for radiology, and medicine in general.

HOWEVER there is a little problem. The UI for the ChRIS app is in the middle of being reworked, and because this is a volunteer project, it is unlikely we will be able to finish it in time for the planned demo. So the chances are we’re going to fake the video to show what the app will look like when it’s actually finished, even though it isn’t.

Now, if anyone asks us, we’ll cheerfully tell them that there is work left to do and that the UI doesn’t really work yet. This isn’t a commercial product, after all. But even then, is it really wise — or ethical, even — for us to do this? We’re trying to generate enthusiasm around the project and gain more contributors; would we be better off to be completely honest about exactly what state the app is in right now?

I think the answer is actually “no.” In describing what a piece of software does, it is almost always better to give the sales description (“It will shine your shoes, too!”) than the engineering description (“It’s a pile of garbage that no one should ever touch.”) People expect the optimistic spin, so if you don’t spin, they think your app must in fact be really terrible, which probably isn’t fair.

What a strange industry…