You win some, and you lose some

Just found out the day job lost a major storage upgrade to a competitor. Read over the evaluations, and we had some questions, sent them off to the purchasing folks. Its always annoying to lose. But from losing you can gain knowledge of why you lost and hone your offerings or your bidding … well … most of the time you can. Sometimes, the process is engineered for a particular outcome, due to an effective manipulation of rankings. We’ve dealt with these before and its rare that you should ever expect to win such things, unless you are the favorite. These are generally a waste of time to bid on, and it would be great if there was a way to detect these beforehand. I don’t have a good answer as to why we lost, I do have some guesses based on the evaluation returns. One of the evals was simply … well … shocking. Extremely negative, with no information available to us as to why it was so negative. Quite a number missed transcribing some of our results/numbers. We and the other small business fared not as well as the big vendors. When you see this, you usually suspect its being arranged for a certain set of outcomes. I am not convinced of this though, but it could have been. As I said, sometimes you win, and sometimes you lose. Getting good closure on the latter, understanding the issues around the loss is how you can learn, grow, and hopefully not lose/fail in the same way again. Such closure is very hard to come by. People are more concerned about lawsuits than they are willing to divulge useful information. Sad for us, as we want the useful information. And we probably won’t get it. But we did ask, and thats about all we can do. [update] Ruminating on this some more, probably a waste of time on my part, but I don’t like to lose, and I really don’t like not understanding why. We get a great deal of return business. Many of our customers buy 2nds, 3rds, etc. from us. Many of our customers started with one unit or a small unit and moved on to larger ones. In something like 85% of our cases, our customers do not remain one-offs. They usually come back and double, triple, quadruple down on their initial investment. On time scales from 3 months to a few years.

Many of our customers are escapees from other vendors products. We usually have to manage a transition off of their product to ours. Many of our customers love our over-the-top service and support. There are a few who don’t appreciate it though. Some of our customers recoil at paying for support, can’t understand why we don’t give them special discounts just for them, and so forth. When you see these folks, you know, beyond any shadow of a doubt, that they will not be return customers. If they buy, they are focused upon only one aspect. I don’t classify this loss in those terms. Would have been nice to have them return, and use a more updated and easier to support product than their first purchase. But these folks are in the minority of our customer base; those who don’t return after an initial purchase. Again, its sad, and again, I want to understand it better. But I probably won’t get that information as I suggested. This loss aside, we have a whole slew of recent wins, in a new/exciting market for us (post production, visual effects), as well as one of our largest and fastest growing markets (financial services). I won’t let one loss derail us. I’ve got ~500TB in the lab we have to ship out in the next few days/weeks, not to mention some of the fastest storage we will have ever built, in a single box, coming online … very soon. [update] gaak … I know I need to leave this alone and move on, but some things troubled me. We proposed 17 of these units

Run status group 0 (all jobs):
  WRITE: io=65505MB, aggrb=1951.2MB/s, minb=1997.1MB/s, maxb=1997.1MB/s, mint=33573msec, maxt=33573msec

with an new product offering we are going to formally announce soon (been delivering it to the post production industry). Very high IOPs. Ridiculously so. 17x 2GB/s -> 34 GB/s. Even assuming 50% loss in efficiency (massive losses possible with each level of the stack … IB is great for moving data as long as it is well implemented), this is still a 17 GB/s system. I understand the several things that trouble me. I am going to drop this now, as I reached a state where I think I understand what happened. And I think I’d have preferred not to in retrospect.