My Last Six Months at NetApp
As I said in my last post, I was Mr. Oracle at NetApp for a long, long time. Leaving NetApp and joining EMC was a push/pull. Push out of NetApp and pull towards EMC. In this post, I will cover the NetApp push part, and my next post will cover the EMC pull part.
Part of the issue, honestly, was personal. My family was very unhappy with the level of travel I was incurring at NetApp. My last job at NetApp was Global Architect (later switched to Global SE). The "Global" part is kind of a clue. My territory was a ball, orbiting the sun, with 24 timezones and a Nitrogen/Oxygen atmosphere. I was on a plane all of the time, much of it international. South America, Europe, Asia, Australia/New Zealand. Many, many trips with lots of timezone difference between the location and my home. I was basically given an ultimatum by the wife concerning this issue.
The response from my manager was not encouraging. I could either cease to travel and take a huge pay cut, continue to travel, or leave.
While this was an immediate personal crisis, I have to admit that there were several other issues. Bruce Clarke (who has now left NetApp and probably does not mind my quoting him) once told me "NetApp is the best lead and worst managed company I have ever worked with." A sentiment with which I must admit that I agree. NetApp does the vision thing very well, no question. It's NetApp's implementation that kind of screws the pooch.
An example would be core ONTAP development. While I was there during the last part of my tenure, NetApp shipped ONTAP 7, which contained the functionality of flexvols. I was involved in the alpha testing of this product as it related to Oracle. I went to Engineering and asked about the path for migration from traditional volumes to flexvols, and was assured that there would be a tool to accomplish this built into the product. However, when ONTAP 7 shipped this tool had fallen off the truck, due to scheduling issues. This was never communicated to me (or pretty much anyone else from what I could tell) until after the product was about to ship.
The result was a train wreck. Many, many customers were justifiably upset when a feature which was a critical part of the ONTAP 7 release was denied them as they were marooned onto traditional volumes due to lack of ability to migrate. This problem became embarrassingly common.
Another similar issue was the creation of a version of ONTAP based upon the SpinOS, acquired with Spinnaker. I sat in an meeting where Engineering explained that they had "run out of seats at the game of musical chairs" which they called ONTAP development. In the threads of ONTAP 6.5, ONTAP 7, and the SpinOS based product, they basically had run out of capacity to develop. The result was the necessity to triage the development of a product line. The company made the bet on the SpinOS product, and dropped development of ONTAP 6.5, long before ONTAP 7 was ready for prime time. This resulted in yet more pain.
And the decision was made to ship the SpinOS product as a NAS-only version, and maroon SAN customers onto ONTAP 7 for an extended period of time after the ONTAP 7 product was ready to be replaced.
Based upon these sorts of decisions, I took the position (which I still maintain), that NetApp would have been better off taking the millions they spent on Spinnaker out onto the parking lot in Sunnyvale, chunking them into barrels, soaking them with gasoline and torching them. Spinnaker was a net loss for NetApp in development energy and momentum, regardless of money. Spinnaker made false promises and created false expectations. All they added was confusion.
Many, many other examples could be given of similar instances in which NetApp lost focus and fostered confusion by lack of implementation. The result for me was erosion of confidence in the ability of the company to continue to execute in the business.
In my next post, I will discuss EMC and how they won my loyalty and support away from NetApp.
