A recurring theme earlier in my career had been work done so well it wasn’t considered appropriate. You read that right. Quality rejected because off the scale, on the top end.
This isn’t an important lesson for most people. First you’d have to get very good at something before this would happen to you. To get there I believe one has to practice skills young, which can come naturally if the environment is conducive.
Below is a shortened version of a retrospective email by a business associate who had become a friend.
I don’t claim to excel like this on every project. I do good work, most of the time. Systems though have become even more complex. People work in teams somewhat differently now. This email tells an earlier story, not about this year’s work. Posted here to help one person or another to make more sense of me or my résumé. This is a factual report, but not a complaint.
Date: Nov. 14th 2014
Subject: Re: a story you had told me
From: Thomas C
I have edited my previous recommendation such that you can use it.
An important thing to remember about that time when MicNotePad was on offer was that the product did several key things that no other product on any other platform could do. In fact no hardware recording systems (Sony etc) could then do things MicNotePad did. An example that springs to mind is, let’s say you wish to go back and re-hear what the speaker just said while the speaker is still speaking but you can’t since he/she is continuing to speak and you will lose the recording of ongoing speech while rewinding and listening to the existing recording. With MicNotePad when taping a lecture you could playback while you recorded!
Your design was a paradigm shift. Prior to your product the average person could not contemplate the solution being available. In fact no one had ever mentioned the possibility of it. An understandable initial reaction was rejection of your product out of hand. Since I had considerable trust in your technical acumen and not being technical myself in general (I do not develop software) I typically referred to our acquaintance K – a senior software engineer and friend of mine for many years. I trusted K’s judgment on all matters technical in the Mac world. If he OKed your work then my own sense that your product was truly a game changer would be confirmed. K had an interesting reaction. “Couple of things, Tom. A little history: Apple’s basic sound technology was god-awful. It is really hard to design a viable Apple sound product. In fact Apple sound developers always begin with an apology about the appalling nature of Apple sound technology. Now with that difficulty at the center of Leo’s product, how believable is it? Secondly, Leo’s human interface design is very tight and very impressive (K was a consulting human interface design engineer). Leo could not do this work without a team and get sound recording stuff done too. Where does Leo work?” I said that I was sure you did this from home with no employees and that I knew you were not working for any particular company. K said it was getting more implausible the longer I spoke about MicNotePad. The notion that one person could cause a paradigm shift in recording and do it on the Mac and do it with possibly the tightest interface design he had seen in a long time and do it by himself. There has to be a catch. Finally, he said “Having used the product I cannot tell you now what the catch is Tom but that’s my opinion.”
I moved on without picking up your product as part of my product lines. And as you know I later called upon you to design some software for me which proved decisively useful. Since you were technical support for a number of years on this software and in that time developed other software products for other customers I realized you had the very ability that K had questioned. Another factor in my change was that one software tool you later developed was a secure document product. Since I was working with sensitive documents this was of great interest to me. Again with the paradigm shift design! I have yet to see (it has been years) a document security management system to match it.
In working with you I learned that much of your technological ability lay in the fact that your psyche has a scientist’s commitment in the search for objective truth. Honing this skill enabled you to ask the right questions (since it was the most efficient way to get to the core design obstacles or to more sharply define the customer’s specification). This was my experience. I knew what I wanted but could not describe it efficiently. You asked questions that drilled down to what I was trying to say. The answer you came back with, expressed in the finished software product, surprised me in that the best answer I could imagine did not match the power, simplicity and elegance of your design. In other words you got my challenge far better than I did. I got years of daily use out of your software and as I deepened my knowledge of that product I could see the profound approach you take.
And now as this story has been retold, can we talk about something else now, please? This seemed so about me. Makes me feel uncomfortable. Let’s solve some of the world’s problems instead.