Technology, The Mirage of Shareholder Value, and Why Icahn Should Just Retire

“We may see the small Value God has for Riches, by the People he gives them to.”

—Alexander Pope (1688-1744)

There are some days that I feel as if I am a late night talk show host blessed with a particularly inept politician. This past week was particularly fortuitous for me, as Carl Icahn has proven himself to be a gift that keeps on giving. I have been fairly blunt in my assessments of his spectacular effort to morph the Dell LBO into a goat rodeo (See here and here.) Hence, it makes me crazy that he managed to show up in the headlines once again this week, engaging in the same fatuous behavior that makes him a caricature of what my friends in finance would call "dumb money". This time, despite the ostensibly impossible odds of success, he decided to take on Apple. For a quick primer, the NY Times Dealbook blog does a great job:

Icahn Amps Up Pressure on Apple, but His Stake Limits His Leverage

It is hard to overstate the the pointlessness of this move. As I type this, Apple's market capitalization is an immense $484 billion. For Icahn to get the 5% stake in Apple needed to incite his usual proxy cat fight, he would need to come up with well north of $20 billion in cash. Which would be fine, except that he just doesn't have that kind of money. How do we know?  Because he was such an abject failure at topping the $24.4 billion offer that Michael Dell and Silver Lake were making for Dell. With bluffing skills like these, he needs to be kept away from the poker table at all costs. I haven't had this much fun watching M&A since a fish oil company called Zapata tried to buy an Internet company 6 times its size with stock in during the .COM boom. Here's some advice for Carl: Stick to raiding businesses where you might have some rudimentary understanding of their operations, like, say, lumber, fish oil, or buggy whips. If you you can't find any, it is far better to quit at the top of your game rather than have us remember you as a laughing stock.

With that said, Icahn is but a pathological symptom of a much bigger problem in the industry: Management's over reliance on optimizing for a high stock price rather than for building a sustainable business. This is especially true for the information technology industry, where the reductionist private equity strategy of cutting research and development in order to run the business for cash flows makes no sense. The fact is that no business can really be run as an accounting identity. In technology however, the product sets and platforms have a half life measured in low single-digit years. Killing a single dollar of R&D will set up for certain failure two years into the future. Tragically, stock prices get managed in 90 day intervals, so, if you are a CEO, firing your entire engineering organization will make you look like a hero in 12 months. In 30 months, you will likely yourself be fired; and your company, your customers, and your employees will be irremediably damaged.

The correct way to run a technology business - any business, for that matter - is to focus on the needs of the customer first. Build a world class product and solution set. Provide a lavish support infrastructure and build lasting relationships. The only way to do this is to assemble a talented and productive team, and show them that their contributions are valued. Build their loyalty. Enable them to to delight customers, and support them and their needs. The wants of the typical shareholder are so far removed from business success because the typical institutional shareholder is far removed from the customer. Does Carl Ichan care about the product needs of Apple's or Dell's customers? Absolutely not. He is clearly eyeing the cash in the bank and would hire new management to implement his redistributive strategy.

Managing for shareholder value rather than for happy customers is a problem that has reached almost crisis proportions. Thankfully, at least in technology, there are always cadres of small nimble companies out there who focus on their customers. They are the ones that are privately held and VC-backed, however. In most successful companies backed by venture capital, not only are the employees focused on the customer, but so are the investors. Maybe it's not a coincidence then, but these investors seem to score some of the most amazing returns for their money over the long term. Hopefully that will not go unnoticed. In business, customers - and not shareholders - always come first.

The Box-ification of Software Continues

Well, Tuesday came and went and we finally go the big announcement from Apple's Tim Cook. As usual, the world was focusing on all the fun toys - the "boxes" - and, to a large extent, Apple delivered the usual array of sustaining innovations that will make their competitors seethe for the next 6 months. Despite the inevitable critiques, and the occasional gaffe (Maps, anyone?), the products will sell and achieve wide adoption. All this will happen in the face of withering competition from the commoditization experts in Asia. What got my attention yesterday, though, was one of the more modest announcements that is likely to get forgotten until it really matters, i.e. when someone's business is disrupted: Apple is giving away productivity software with it's new machines.

As I type this article into my MacBook Pro, while controlling my stereo from my iPad sitting across my desk, I feel like I should repeat what I have said before: The slave-like attention to integration, user experience, and polish will always win out over gimmickry and slipshod commoditization. For this reason, I think it is quite significant to consider what Apple is doing here, and what it portends for product development trends going forward. There's always an underlying strategy to these types of moves.

First, for the Apple fanatics amongst you, it surely has not gone unnoticed that MS Office on the Mac has become somewhat of a second class citizen. While the Windows suite was recently refreshed, it appears that the Mac version has not had a major refresh since 2011. More importantly, MS has chosen not to support any of the iOS platforms with its flagship productivity suite. There are two consequences of this decision, and both are bad for my friends in Redmond. First, it makes the lives of Mac users more disjoint and unpleasant if their data is locked up inside Office documents that they cannot edit from iPads, Minis, and iPhones. This gap creates opportunities for other people to fill the missing bits, by offering apps to provide the missing functionality. In Apple's case, it also allows them to provide customers a chance to experience what an integrated suite might look like. If you haven't tried the iWork suite, you really might want to now, especially the touch enabled versions for the tablets. Unsurprisingly, you might even start to prefer iWork over the collection of things you have now.

The flip side of this is that Microsoft is not moving the user interface idiom forward on the Apple platform any more. The future is touch and mobile, and we already know Microsoft is not there today even on their own Windows OS. They will proceed to lose ground as the masses continue to buy iPads in lieu of Windows laptops. You would think that learning to get tablets and touch right should be a strategic imperative. Apparently this is not so for them, unless it manifests itself in Windows first. They seem to have forgotten that they themselves learned how to build a GUI by building Word and Excel for the Mac long before Windows was around. In the old days, Microsoft used to be too paranoid to let these kinds of things happen. I don't think it's too far-fetched to infer that with hundreds of millions of iPads out there, it would only take a few good features in iWork to seriously damage Office. Not supporting these devices is very dangerous for MS.

The most profound part of this move, however, is the continuing theme of vertical product integration that is sweeping the low end of the technology industry. I have been talking about it for quite some time in the context of some of the things we did at EqualLogic with iSCSI storage: The lower end of any market abhors complexity. You cannot sell them a bucket of parts and expect them to build a solution from it. They will reward the manufacturers that pull together an end-to-end experience that is flawless and integrated. This is something that is unique to technology - people are afraid of it, and are always looking for an easy way to use it. EqualLogic ran the same playbook as Apple has been running: They are building all the software into a single package and polishing the experience to delight their end user. That package is a single system, either a laptop, or a tablet. In our case it was a storage array.

The big idea to draw from all this is that technology mass markets will continue expect these vertically integrated solutions. We see Apple gradually extending theirs this week. We have been seeing Microsoft doing the same thing with their Slate line and, more recently, their acquisition of Nokia's tablet and handset business. We even see it happening in various parts of the IT infrastructure markets, where more integrated, easy to use products are favored over those that require specialization. This is a mega trend that will affect people's expectations of how to consume technology. More importantly, it will substantially raise the bar for those who want to build that technology.

Um, Can I Work From Home? Please?

It really is amazing how organizations can take a relatively simple idea and supersize it to the point where it is unrecognizable from its original conception. Last week, in a bizarre reversal, we learned that HP has decided that their people should not work from home any more if at all possible. As usual, Arik Hesseldahl from AllThingsD summarizes it the best:

Computing and technology services giant Hewlett-Packard, which appears to be taking a page from Yahoo CEO Marissa Mayer, has quietly begun enacting a policy requiring employees to work from the office and not from home.

While it hasn’t yet reached the level of a company-wide directive with the same jarring effect as a new policy put in place by Yahoo earlier this year, HP employees are being told by bosses that if they can work at the office, they should work at the office.

I thought that I'd discuss this a little because the subject comes up frequently for me and, unsurprisingly, there is no correct answer - just a lot of nuance. So, why are these large organizations recalling their remote workers? What exactly is the "state of the art" when it comes to workplace design? How did we get here in the first place, where CEOs need to issue these kinds of decrees? Well, its quite interesting.

First, let me just make the incendiary pronouncement: Except in a small subset of job roles, working from home for extended periods is probably not a best practice. Sorry. If you read between the lines of the HP announcement, you get a pretty good reason for getting people to the office every day: immediacy of contact. This is not, as it turns out, the only reason to bring people together every day. There are all sorts of others, ranging from morale, to the rotation of the earth and the speed of light.

If you want to get into some very interesting academic research on the subject, the faculty at MIT's Sloan School have plenty of reading material for you. For example, Alex Pentland of the Media Lab has done a great deal of research that shows the value of people who work social circles within office environments. Long before him, Thomas Allen, a distinguished professor at the same institution, published a book that discussed a lot of the same kinds of issues. The overwhelming conclusion you arrive at from the reading is that the effectiveness of an organizations largely depends on how well, and how quickly, information gets disseminated and processed through the ranks. People working in intellectual or physical isolation create problems. Having whole teams of people that never see each other is unambiguously bad for productivity and creativity. There's a reason that "open" (i.e. cubicle-free) office environments are popping up everywhere: It forces people to talk to each other and collaborate.

The problem is that, for many years, it has been all the rage to geographically disperse organizations and try to make that work. Usually, the justification for this is money - the desire to cost reduce some aspect of the process by leveraging cheap labor in low wage locales. At some point it became a real estate cost reduction: Office space can be smaller if everyone worked from home, and so a company can pay less rent. Just like everything else related to pathological management behavior, if a little of something is good, a lot must be better.

Of course, these schemes have a cost, and that cost is usually management overhead. The managers have the unenviable task of getting all these people to work together. It usually means having to say the same stuff multiple times to different people in different time zones, waiting days for consensus to form, backtracking and starting over when misunderstandings inevitably arise, and a lot of wasted time. It also means that communication many times becomes mostly hierarchical. Information sharing becomes stunted unless the manager is an amazing person. Worse yet, it adversely affects corporate culture in ways too numerous to mention here. It's clear that this is what Meg Whitman is ruminating on at HP. It is also an interesting thought experiment for us to consider what this trend portends for the future of knowledge work.

As for the original question about working from home, I do allow it for a small subset of people. If you are one of them, it means that I have worked very close to you before, and I understand your work habits and your thought processes intimately. It means that I have decided I will allocate the time to interact with you daily, and maybe hourly.  It means that you have committed to being in the office one week a month at a minimum, and I will make sure that your travel is paid for. In fact, if this is you, you can consider it the supreme compliment from me: You are incredibly valuable to the organization, because I do not have the time to do this for more than a couple of people and still do my job well. If this is not you, I'll talk to you at the espresso machine...

Sunday Night Scotch: Disruption Is So... Well... Disruptive

The reason that God was able to create the world in seven days is He didn't have to worry about the installed base.  - Enzo Torresi

Maybe it's a sad testament to the human condition, but the technology industry does not seem to lend itself to attracting individuals with humility or self awareness. Since my very early days as a junior software engineer, I have noted that it is only a matter of time before many archetypical tech nerds, having achieved a modicum of monetary success, start to behave erratically. Before long, you see them standing on top of the roof at corporate headquarters, laughing maniacally. In a thunderstorm. Waiving a five-iron in the air. I'll grant that this happens in other professions as well, but there's something about the rags-to-riches nature of tech that makes it all the more poignant.

If you are an executive in a leadership position at any firm, it therefore follows that you need to go through the history of other people's mistakes obsessively so you learn from them. (I recommend doing so very clinically - like the NTSB examining the wreckage of an airplane crash.) What you inevitably find, tragically, is that history really does rhyme even if it doesn't repeat. With that thought in mind, I present to you the scariest part of my reading list from last week: The Globe and Mail's investigative piece on the failure of Blackberry:

Inside the fall of BlackBerry: How the smartphone inventor failed to adapt

In it, you'll find a freakish retelling of pretty much every cliché of every tech downfall you can imagine. If you are a technology leader, and you'd like to engage in some negative reinforcement therapy, I recommend it highly. Likewise, if you need an excuse to have a strong drink, you'll find all you need there. Here are some of my thoughts:

Disruption Is Never Evident Until After The Fact

In her book entitled Being Wrong: Adventures In The Margin Of Error, Katherine Schulz states that being wrong feels exactly like being right. What we remember most painfully is the moment when we realize we are wrong. What will make you cringe, therefore, is the fact that much of the investigative narrative does not occur in the months after the iPhone's market success in 2007 and 2008. It is a story set in events of 2012 and maybe late 2011. It wasn't until then that the mobile phone market had been disrupted to the point where Blackberry sales were beginning a secular, irreversible decline. That is a long time. Friends, that is what disruption looks like.

The point here is that you can't advertise a sea change. Smart people do not screw up this badly unless they are completely unprepared. By definition, a technology market can't be disrupted if all the players were anticipating the change. So, all you Storage Geeks take note: Things like flash technology are really more evolutionary. Everyone knows about them and they are all making bets. It is unlikely that anyone will go out of business. In fact, recent failed IPO's are testament to that. True disruption sneaks up on you.

Listening To Your Customers Can Kill You Too

Conventional business wisdom would have executives in a bear-hug with customers, listening and catering intently to their every whim. In a disruptive situation, the customers you are listening to aren't the ones that are going to rock your world. It is the early adopters and the rebels that are driving the change. A large, established technology company cannot pay attention to these people because they do not represent a viably large market. When it would have mattered to do otherwise, Blackberry was clearly making decisions based on the needs of their huge revenue base: the one that was paying them for physical keyboards on their phones. They were doing precisely the correct thing. They were wrong to do so.

Just hiring a CTO to go watch these people wont work either. I know exactly what it feels like to point out that a fringe minority has a better idea about how to do things. In a publicly held company, the business worships at the "church of what's happening now". There is no accounting gimmick or spreadsheet that you can conjure, which makes an ROI case for investing in a disruptive technology. You will lose your case every time. When the return is 4 years into the future, no one will care. This is why there are venture capitalists.

Finally, we can see what can go wrong when you send off  a bunch of rebels to "do the right thing" as Blackberry did with the touch screen products. They can easily lose touch with your customer base, and build something that your existing customers wont transition to. At the same time, they may not get any new customers either, unless they are truly brilliant in their execution.

No One Can Explain the Ten Year Run Apple Has Had

When the history books are written for business over the last decade, I am not sure how they will be able to distill the moves Apple made into a real repeatable formula. It is not lost on me the hypocrisy of criticizing the seemingly stupid, calcified, large incumbent technology organizations, when the player bringing the disruption is actually a big company, too. The ability to attack huge, seemingly unrelated markets from a position of financial strength helped. Not having to drag an existing user base along also seemed to go a long way. So did the organizational structure that protected the development of these new products from the vicissitudes brought forth by the markets. ...But getting it right every time on these giant bets? That is pure genius or pure luck.

Cheers!

Software Defined Storage - Zombie Box Huggers are Winning

In all honesty, I first submitted the abstract for a talk on Software Defined Storage to SNIA very early this year. It seemed like a different world then, and I really had no idea what I was getting into. For the purposes of full disclosure, I was the sponsor for an SDS project before I left Dell, and so I had spent a lot of time sifting through all the data and the nonsense that surrounds it. It felt apropos to put together a talk on what we had learned about the topic: the use cases, the technologies, the market, and the business. In the intervening months, something happened out there to cause the topic to become an epic technological hot potato. I've now given two talks at two separate conferences, and served on two panels, all in the vain attempt to place a clinical definition on SDS. I don't think that such a definition will be possible. Additionally, I want to make it clear:  I am a skeptic when it comes to the products on the market today. Let's talk about my somewhat slanted viewpoint:


SDS is Like Tobacco...

While this may sound like a cruel metaphor, it is apt. You can substitute alcohol, or any other recreational drug here, but the relationship would be the same. There is a short term buzz you get from the products, but there are long term problems and dangers that need to be managed. The sellers are fundamentally hoping that you are adult enough to not go on a bender and crash your car, or destroy yourself in some way, so you can keep coming back. There are use cases where the products work, but one should be very wary of assuming that, in a super-competitive industry, storage arrays are so massively mis-priced that it is economically advantageous to construct one from parts. Integration and testing is a huge task that effectively "de-commoditizes" all of the storage products available today. A bug that has a .1% chance of occurring may seem like an acceptable risk with 4 disks. With 100 disks, you have a different calculus to consider.

One of the comments that I heard at SDC is that we have effectively unlearned all the things that we learned 20-30 years ago about creating resilient systems from cheap disks. This isn't entirely true. What we have learned is that there may be better ways to get storage resiliency at very large scale. It's a sexy concept, and those who think they have the physical scale necessary owe it to themselves to try it. Those without cloud-sized data centers need to consider the possibility that the best bet is to rent disk space from companies that have the mass, i.e. Amazon, Google, etc. Trying to convince someone that they can be Google or Amazon if they only just bought your software, is much like selling steroids to people who don't work out. Nice story, but missing key facts.


The Box Huggers Are Not Who You Think

It has been a long-speculated axiom of storage that the people want boxes. If you want to sell storage, you need to put it in a metal box and sell it. Upon much contemplation and discussion on the topic, I have come to the conclusion that his has more to do with economics than anything else: customers are used to buying capacity and sellers are used to selling in the same manner. In fact, there are very few people who have gotten past the notion of paying for something other than capacity. Generally, this is how storage works: you have some data of a particular size, and you want to put it in storage commensurate with that size.  The more hazy your needs are, the more likely you will overbuy and hence overpay for your need.

It should not be a surprise then, that the people who are most religious about clinging to boxes tend to be those who are selling them. In full disclosure, I have to confess that I may be one of this cohort. It really represents the easiest way to comprehend what you are selling and what the customer is buying. You would like to be able to offer X Terabytes of highly available storage, with quantified performance, up to N LUNs, up to M snapshots, etc. This is really an indication of tested limits more than anything else, and it should be construed as a support statement from the vendor to the customer. Without that metal box to test, guaranteeing any level of performance or functionality can quickly spiral into an unbounded problem. Hence, we love boxes more than anyone. Perhaps this is why many perceive that the market is troubled by the encroachment from the cloud scale services such as Amazon's and Google's. Nonetheless, the box hugger's view of the world is that any product without clearly defined and testable performance objectives is fundamentally a toy.


Most Customers Are Actually Data Huggers

In my wanderings over the last decade, I have met many, many customers who buy and manage infrastructure. The one most important commonality among all of them is how tightly the security of their employers' data is tied to their success. The word "security" in this case is not to be understood as only protection from intrusion, but also its availability, performance, and the general control of its destiny. That last item - control - is perhaps the most important of all. Putting their data in the cloud gives them the same detachment that they get from sending their kids off to college. Risking data loss is so unacceptable, that making copies and scattering them in as many places as possible seems to be de rigueur. That is pretty paranoid.

This should be a hint to everyone. There is a mentality evident among many software vendors that their role in providing the aforementioned security can be conveniently redlined above the disks or the hardware platform or the network. I don't think that there is a bias against software only solutions. Rather, it's evident that the data-hugging masses aren't getting the feelings of security that they need to widely adopt the approach. As I said in the panel discussion last week, this is less of a technical problem and more of a business model problem. If a model exists that allows the technology to be delivered to customers with the warm, fuzzy feeling of control, I'm sure this market will find it. I don't see one right now.

So what will happen? Without some major redirection, it's clear that there is going to be a shakeup of sorts in this space. The minority of shops that have the expertise, the mandate, and the spare time, will make their choices. The bulk of those choices will be for free software because that is the easiest way to rationalize the internal support costs of the do-it-yourself approach. In the end, the paying market for many of these solutions will not be large enough to support all the players. The winners will be either open source (i.e. profit-free), or solutions incorporated into existing platforms at no extra cost (watch VMware and Microsoft here). Finally, without addressing the needs of the data hugging mid-market, its hard to see any of these products seeing more than limited acceptance.

I'm pretty flexible with my opinion. I change my mind when the facts before me change. Right now, this is what I believe.

Dispatch From SNIA SDC: Hardware Defined Software

Much to my surprise, the most contentious portion of my June SPDECon discussion on software-defined storage was the seemingly innocuous slide I added at the end: In it, I simply decreed that hardware widgets couldn’t be a part of a software-as-storage solution.  This seemed to be a self-evident assertion and, accordingly, I put it at the end of my slides thinking that no one would notice it.  We never got to the Q&A part of my talk because this discussion usurped all of the extra session time.

After a good amount of thinking on the subject, I think I have changed my mind somewhat. Software defined storage is tragically a hardware-constrained technology. We run out of compute cycles, and the speed of light may be too slow. These sorts of vexing architecture problems are more directly and easily solved with specialized hardware.  Clearly, the people in the room last June who made a living from solving problems with hardware had a legitimate concern. After that smack-down, I have done fair amount of evolution on my thinking on hardware in a software-defined world.

It is looking like I will be doing the same talk again tomorrow at SDC. This time, I am using a different deck. It might turn out to be a bit more depressing if you are expecting a cookbook on how to build SDS. While I am not going to spoil my own discussion topic, I will say that it is instructive to look at places where platform properties have successfully been abstracted, so that the software doesn’t cease to work when specific hardware is missing. One example of this is the advanced SCSI functionality that has gone through standards over the last few years. VAAI, ODX, and the like are all hardware specific functions that make life substantially better for people without de-virtualizing their virtualization platform.

All that said, I’m sure I’m going to learn something new again… 

Sunday Night Scotch: Gelsinger Wrong About Intel/ARM, and May Need Help With Math

There's math, and then everything else is debatable...

- Chris Rock

One of the most spectacular wastes of my time over the last 5 years has been the incessant, relentless, and sometimes vacuous discussion about whether the world is going to be dominated by the juggernaut that is the Intel chip machine. You see, I used to work for a company that was so beholden to the idea that Intel would dominate, it didn't really matter what the argument was that was put up against it. Even if you won the battle today, the true believers would come back and reignite the the discussion a few months later, claiming that everything had changed. I'm a software guy. I really do not have a horse in this race. My stuff more or less compiles and runs on any architecture you want to go with. I do, however, want to make money. This is why the line of discourse that Pat Gelsinger took in a panel discussion last week seemed, well, a little off.  Specifically, those of you who were there may recall the tirade he made on ARM processors, saying Intel would win "even if you reduced the power consumption of ARM CPUs down to zero."

Perhaps I am suffering from Post Traumatic Stress Disorder resulting form my experiences of the last 11 years, but hearing that nearly caused me to hurl my coffee at the stage. Back in 2002, I used to think somewhat like him, but I got educated. It's about time that everyone else just ran the math. Intel is great if you are looking for a bunch of pizza boxes to sit in a rack and run VM's, but one only needed to take a walk on the show floor to realize that this is hardly the only use case out there. There is a reason why there is so much custom hardware on the floor. There is a reason why the EqualLogic storage arrays (and others) still run Broadcom. There is a reason why smaller form factor devices run almost anything but Intel.

The causes for which ARM-based and MIPS-based SOC designs will continue to succeed are numerous. Generally, they do indeed consume a lot less power, and, despite the fearless predictions of Mr Gelsinger (and others) this has a lot of consequences. Lower power consumption is not just a "tree-hugger's" value proposition. First, it means that a device does not need to have a power supply that sounds like the back side of a Boeing. It also means that the device need not have a heat footprint that NASA can track from space. In other words, I can put one of these devices on my desk, or on top of my TV, or in my audio cabinet. That alone opens up new markets.

More importantly, there's the simple matter of cost. Once you consider the compute power you get, the costs of additional network connectivity, and the other gizmos that are generally being included on the die with many of these devices, along with the power consumption and heat dissipation advantages, it really is no comparison. That doesn't mean that Intel will never be competitive in this area. For now, and for the last 10 years, that just hasn't been the case. The math always fails to support the rhetoric, as much as many would like it to. Despite this, we all are continuously subjected to relentless propaganda from the guys who have bet the farm on one architecture.

My suggestion: Even if you don't fully buy into an opposing view, it's always useful to have a hedge. Large software codebases inexorably tied to a single vendor's hardware can become strategically vulnerable to disruption. Perhaps this is one reason why Microsoft has brought back the ARM port of Windows. That, and the fact that they want to make money from the increasingly large installed base of ARM devices. Which brings me to my last suggestion: never, ever, let religion get in the way of making money.

Sunday Night Scotch: Every Day, A New Reason to Start a Company

All bad precedents begin as justifiable measures.
- Julius Caesar

One of the non-tech items that caught my eye over the last week was the interesting news from UPS that was covered by all manner of news outlets, perhaps most colorfully by MarketWatch's Jim Jelter in the video spot called.... drumroll please... "Why Your Boss Is Dumping Your Wife". The video is after the break below in case you missed the news. To summarize, UPS decided that they were going to deny coverage to working spouses of employees if they were at a company that also offered health insurance. Regardless of the political excuses, this idea was inevitable: My former employer was imposing a non-trivial surcharge to employees of working spouses who were similarly eligible - and this was back in 2008. Oh, well. I guess both Dell and UPS are OK with not being on the Fortune "Best Companies To Work For" list.

I think this is a great opportunity to try and understand how something like this could seem like a good idea to anyone. First, a look at the math: According to the Health Connector website here in Massachusetts, the difference between insuring me, my spouse, and my two kids, and dropping my spouse, works out to be between $320 and $550 per month depending on the plan. That works out to $4-6K per year in cost, of which $3-4K might be paid by the company.  UPS claims that this will affect 15,000 employees, so that tops out at a nice round $60 million, or roughly 7% of net income in the last 12 months. (By coincidence, that is the exact figure the company mentions.)

Admittedly, there are two ways of looking at this: On the one hand, some might say that health benefits have become too extravagant to be shouldered by the shareholders of the business. It's the shareholder's money after all. I am way out on the other extreme, however: Why does the business and its leadership suck so bad, that this is the only scheme they can conjure to increase shareholder value? Professing your lack of love for your employees, prima facie like this, is surely not a way to make your customers happier. Moreover, that earnings bump next year will likely do nothing for the stock price. Analysts know well that it does not represent real growth in the business. So then, why bother?

Like human beings, large organizations are very complex. Also like humans, to get an idea of what really propels organizations, you need to observe them at the moments where they are least inhibited: In this case, a time of despair. The economy is rather flat. The numbers are likely to disappoint. Somebody is going to lose a bonus. This is where discipline counts. Real leadership would dictate that you go talk to customers and find out what can be done to grow their businesses and yours. Mediocre leadership would dispatch a team of "efficiency experts" to see if they can find coins under the sofa cushions in the employee lounge. Doing the former is hard. It's much easier to do the latter. Each time you opt for the latter, you only make things worse down the road.

The point here, is that it is very easy for big businesses to lose their compass a little bit at a time. The proven way to make money is by focusing on addressing the needs of customers. Whenever there are substantial resources devoted away from that one singular focus, it almost always leads to a bad outcome. The reason startups can do so well is because they have no choice but to focus on their customers or perish. The reason the Googles and the Microsofts of the world got so successful is because they enabled their employees to do the same in scale. Indeed, that $4K per annum is noise compared to the profits that they bring per employee.

As for my part, if you happen to end up working for the company that I want to build, I can assure you that your spouses will be covered. Your espresso will be provided. Your scotch will be free. We'll throw in a few meals as well. In return, I'm going to expect that you will devote all your energy toward delighting customers. Seems like a good deal, but I assure you that it's the much harder path. It's much more rewarding, though. This is something I know from experience.

Shocking news! Renting More Expensive Than Buying!

I came across a blog post on Wired Enterprise this evening that made me smile. More precisely, I got that warm feeling that only vindication brings after a long argument. That post, written by Cade Metz, was entitled "Why Some Startups Say the Cloud Is a Waste of Money". In it, he frames an argument that I was having just a few weeks ago with certain folks that should know better. I was being called a blasphemer for suggesting it, and clearly, Metz is aware that he is off the beaten path. I need to buy him a beer. Without further ado, here's the money quote:

...in May, about two years after MemSQL was founded, [Eric] Frenkiel and company came down from the Amazon cloud, moving most of their operation onto a fleet of good old fashioned computers they could actually put their hands on. They had reached the point where physical machines were cheaper — much, much cheaper — than the virtual machines available from Amazon. “I’m not a big believer in the public cloud,” Frenkiel says. “It’s just not effective in the long run.”

The post goes on to describe a number of other companies that have reached the same conclusion: At scale, it simply is not economically viable to layer your SaaS or PaaS on top of someone else's rented infrastructure. Oddly, the disproportionate cost of cloud infrastructure is well known to all the startups that I know who are using it. Everyone is moving off of Amazon as far as I can tell. If you run the numbers, it is also pretty clear that AWS is likely reaping quite a fat profit from their operations.

In my case, I was forced to run the numbers because no one believed me. Not a problem. I love math. Here's what they looked like based on pricing available mid June of this year: I could get managed physical server hardware, colocated in several large data centers that would run 20 AWS Linux instances of my specification, at a third the cost. That included the VMware license. Even better, if you wanted to buy the hardware yourself and just rent the rack space, power, and connectivity, it got even cheaper. Based on my math, AWS only makes sense for a small number of compute instances, or when running for a short period of time. One more thing: The two approaches are headcount-neutral. There is no meaningful difference in the number of people and internal operating expenses that go with one way versus the other. 

When you step back from this, you realize the big obvious truth: Nowhere in nature does renting cost less than buying: Not with leasing cars. Not with apartments and real estate. Certainly not with compute resources. Renting has always been a way to avoid major capital expenditures - either because the capital does not exist, or the need is short term. The longer and larger your commitment, the more advantageous it is to use capex if you have it available to you. In the case of the SaaS providers, the name of the game is to reduce service costs. Why let your service providers expropriate your profits if you don't need to? 

What to rent? Buying a giant data center in a large metro is insanely expensive. It makes sense to rent space in someone else's. Renting someone else's PowerEdge R720 maybe does not.

Anyway, I feel better now that I don't feel alone...

It's the Use Case, Stupid

I'm trying not to sound angry, but when I find myself engaging in the same discussion repeatedly, I think I am entitled to lose my patience. Very recently, I got into the "order of magnitude" argument once again, in reference to the still-super-secret product I am working on. For those of you who have forgotten, in the tech world, this discussion always starts like:

"If your technology cannot provide me 10 times the performance and/or at 1/10th the cost, I am not looking at it."

If you are inspired to start a tech company and build a new product, you come across this sort of thinking repeatedly. To be fair, it comes from the old school, venture capital reasoning of the pre-bubble era, when the next generation of successful technologies always seemed to share this "order of magnitude" characteristic. Alas, correlation and causation are frequently transposed at the casino. So let's be careful about this:

1. Unless you can use it, 10 times more of something is not interesting. The reason 100Mbit Ethernet was compelling was because networks were choking on 10Mbit. Similarly, 100Gbit is useless if you have no way to fully utilize it.
2. Even when successful, the "order of magnitude" products are focused around the use cases that justify their expense.
3. The world has become so complex, that it is awash with successful new products which clearly are no faster or cheaper than their predecessors. They succeed because they solve significant management problems rather than doing stuff faster. The product I am most recently associated with was exactly like this.
4. If my widget was 15 times faster, and speed didn't solve your problems, you'd still buy the incumbent vendor's stuff because the risk/reward dictates that you do so.

The real formula for success is use cases. Things that customers can do with a new product that the old  would not enable in a meaningful way. Sometimes the use case is the business model. Sometimes it's a new way of managing around an old problem. Finally, there's always the problem you didn't know you could solve, because you never considered the possibility that your IT infrastructure could be made faster. With all of these, the real product question to ask is "Why is this idea so disruptive that the incumbent players would not want (or be able) to copy it for the next 4 years?"

File this one under lessons learned....