The Black Liszt

The Dimension of Software Automation Breadth Examples

One of the major ways software evolves is by increasing along the dimension of automation breadth. A domain can be dominated by products at a given breadth of automation, and suddenly a existing or new competitor starts winning by increasing its breadth of automation, offering its customers more value for less effort and money. It's a classic move and a good way for new entrants to disrupt a market.

One of the most frequently given pieces of advice, including by me, is to “focus,” i.e. basically solve fewer problems, try to satisfy a narrower range of customers, etc. While this advice is applicable more often than not, the natural and recurring progression of products through the spectrum of “automation breadth” makes it clear that, sometimes, when the conditions are right, the winning strategy is to be among the first to increase the breadth of automation that you incorporate into your product.

Example: Athena Health

A clear example of this is shown by the story of AthenaHealth. At the time the founders started the company, a wide variety of products were already available to run physician offices, from small single-office practices to extended medical groups. These products generally ran on inexpensive machines that the practice would keep in some back room, and would support multiple users via a LAN or terminals. Most of the products were sold by license, so that the office had to pay only a modest price for the license, and then annual maintenance.

Along comes little Athenahealth, with a better way of doing things. Athena had a cool new practice management system (PMS). Unlike all PMS’s at the time, it was built using internet technologies, so that it could be operated as a service, with people at the office accessing the system using machines with browsers and internet connections. Athena took care of the computers, relieving the medical office of a burden it basically didn’t want.     

But they ran into a little problem: the people in charge of medical practices are doctors, and doctors really don’t care about PMS’s – they care about patients and medicine. A PMS is a necessary evil, something you should buy for as little as you can get away with and ignore until things get so bad you are forced to buy a new one. Money spent on the PMS is just money out of the doctors’ pockets, as far as they’re concerned. Oh, you have a “better” one, do you, whatever that means? Stop wasting my time.

The folks at Athena noticed that one little thing the PMS does is produce bills and claims, the purpose of which is to get patients and insurance companies to send them money. No claim, no money. Unfortunately, merely producing the claims rarely proves to be sufficient to get the money flowing. People are required to do special things to the claims, provide additional information, harass the payers, etc. This is so specialized and time-consuming that it either consumes the time of a number of people at the office, or is outsourced to a “billing service.”

The Athena folks went on to notice additional important things: (1) the chances of getting paid are a direct reflection of the quality and appropriateness of the information on the claim; (2) the PMS and how it is used is the main source of this information; (3) by actually performing the billing service, you can learn how to produce a better PMS that produces better claims, increasing the effectiveness of the billing service while reducing the cost of running it at the same time. Finally, they found out that there is something the doctors who run medical practices care about other than medicine – surprise, surprise, that something is money.

So Athena introduced an outsourced billing service, but required practices that use it to also use their practice management system – at no additional cost! And they got so good at collecting the money that doctors could essentially get more money and a really cool, state-of-the-art PMS (like they cared…) for free!

This is a nice story for Athena, but the point of telling it here is that it illustrates the principle of product automation breadth evolution. While products are evolving within a “level” of automation breadth (i.e., how many of an organization’s functions it automates), it is normally a good idea to maintain discipline, avoid distractions, and concentrate on automating that function. But at a certain point in the evolution of each product category, pretty much everyone in a space has automated everything within that function, and everyone is reduced to concentrating on sales strategies and niggling little details. At that point, and PMS’s were at that point when Athena came along, it makes sense to do what you’re normally supposed to avoid – look for another function inside the organization to automate, particularly if there are synergies in implementing the two functions within a single framework, as there certainly were in this case.

Example: Bank and Retail Credit Cards

In 1983 a small company called CCS (Credit Card Software, later called Paysys) released a body of COBOL code that would enable a bank to process credit cards. A number of small and regional banks bought copies of the code and ran it successfully. The code was enhanced over the years.

A major retailer, Michael's Jewelers, approached CCS and asked if they could make a version of the bank software that could handle purchases from their stores, including a variety of payment plans and financing options offered by the store that were not supported by bank card software.

The company's programmers quickly gave up on the idea of modifying the bank code to handle the problem. Many aspects of bank card processing, such as the difference between issuing and acquiring, were irrelevant to retail. In addition, the many financing options supported by retailers went far beyond anything banks did. So they borrowed from the bank code to the extent that it helped and ended up creating a separate body of software called Vision 21. Once it was available, it proved to be a big success in the market, and was quickly enhanced by customer demand to include all the options desired by retailers Before long it supported the needs of retailers in other countries as diverse as Japan and South Aftrica.

Finally, there was very large processor, Household International, that was running multiple copies of both products, separate because they had been customized for a variety of reasons, for example to support methods of credit that were unique to a market (for example “hire-purchase” in South Africa). While CCS, now called Paysys, had failed to create a generic bank/retail product when confronted with an example of the generic problem, unifying multiple bodies of related code into a single, highly parameterized code base proved to be a far more tractable problem, particularly with a single important customer who insisted that these variations were the only ones to worry about.

The industry quickly rallied to this new product, called Vision PLUS, that could be directed at so many different problems with such relative ease. For example, it enabled retailers to issue co-branded cards that worked like regular bank cards, except when used in the issuer's retail store, when it acted like a classic store card with features like "90 days same as cash" options that bank cards don't support. While “parameterized product” may sound like an abstract concept, it translates directly into business advantage compared to more primitive product types, by enabling the product to be customized, installed, upgraded and maintained with less labor, less time and lower risk of error.

The company that built Vision PLUS was bought by First Data, a major card processor. The reason is interesting: in spite of having thousands of programmers (Paysys had only dozens), First Data was unable to modify their US-centric code base to handle processing in Japan. At the time of the sale, Vision PLUS was processing about 150 million cards world-wide. The code lives on and currently runs over 600 million cards.

Conclusion

These are two examples of companies growing by broadening their focus -- in a strategic way, driven by just a couple of representative customers. In neither case did they address a whole new market at the beginning, though that was the eventual goal. They took their existing software along with a cooperative customer and met that customer's needs. Athena started with just one specialty in one state with a single payer. Paysys started with a single existing customer. In each case they grew the broadening of their focus a step at a time, making each customer happy as they went. As they grew, word got around in the industry, and they shifted to saying "no" to the vast majority of inquiries in order to maintain the step-wise customer success they were building.

This is a classic pattern of focus broadening that can bring transformative success to companies when handled well.

 

Software Development: the Relationship between Speed and Release Frequency

There is a deep, fundamental relationship between the velocity of software development and the frequency of releases. I hope this relationship will be studied in detail and everything about it understood, but the basics are clear: with minor qualifications, the more frequently you release your software, the more rapidly it will advance by every relevant measure. It will advance not only in feature/function, but in quality!

Mainstream thinking on Releases and Development Speed

The relationship I propose, "more releases = more features & better quality," is counter to the vast majority of mainstream thinking in software. In fact, in those terms, it's counter-intuitive. Here's why.

Think about software development in the simplest possible terms. You've got define it, plan it, do it, check it and release it. Five basic steps, which apply across a wide variety of process methodologies. Each step takes some time, right? After you do the work, you've got to check it and then release it. And you can't just check what you did -- you also have to make sure you didn't break anything that used to work, the "keep it right" part of quality, which grows ever larger as your software evolves.

This "check and release" process is a kind of necessary evil, the way most people think of it, and as quality failures hit you, it tends to get bigger and longer. A clever project manager (an oxymoron if there ever was one, except when intended ironically, as it is here) will naturally think, gee, let's go from 6 releases a year to 4. By cutting the overhead of the two extra releases, we'll be able to buy some development time back.

Yup, that really is how people think! Fewer releases = more time to do other stuff = we get more done.

Not!

A Real-life Example

A good example of a company that illustrates the proper relationship between release frequency and development speed is RebelMouse. RebelMouse is a next-generation, socially-fueled publishing platform. It can be used to turn boring-appearing blogs like BlackLiszt from this:

to this, a snapshot from my RebelMouse page:

v

Increasingly, they are used by big-media places, for example for Glee:

and the recently released real-time publishing curation features were used for The Following to create a social firestorm:

RebelMouse -- the Facts

The CTO/founder of RebelMouse is Paul Berry. Here he is below explaining something to his fellow nerds at the nerdfest I held a while ago.

RebelMouse has grown like crazy in its short life. Currently there are about 280,000 websites powered by RebelMouse, and that number is growing over 100% month-to-month. Their sites have over 2 million unique visitors a month.

Does RebelMouse have just a handful of releases a year? Duhhh. Try over 10 a day. A day! And there are more than 30 developers, who are not all in the same location.

Digging in

There is a lot to be said on this subject. For now, I'm just going to keep it to a single simple but important observation.

The relationship between development speed and frequency of releases does not hold up at a fine-grained level; so, for example, given two organizations, one of which has a release every 10 weeks and the other every 11 weeks, any difference in speed will be random. Similarly, if the two organizations release 5 times a day and 10 times a day, any difference in speed will also be random. But at a coarse-grained level, I observe large differences. HUGE differences.

Conclusion

RebelMouse is far from the only example, but they show the relationship between development speed and release fequency very nicely. They move much more quickly than most development organizations of their size -- in fact, they manage to push hundreds of releases in the time most organizations would have been able to limp through an "agile" (heh) development cycle or two.

 

Computer Storage and Batteries in the 21st Century

Computer storage is a key weapon in the arsenal of Cloud service providers. It's the difference between a mediocre service and a great one. Batteries play a similar strategic role in electric cars. A bulky, old-style battery consigns an electric car to trailing the pack. Comparing these two domains can help us understand both of them.

Batteries

I hope most people know that cars have batteries like this one:

Batteries are an essential but minor part of normal gasoline-powered cars. But in hybrids and all-electric cars, their characteristics determine the overall success of the car.

When you drive an all-electric car, you can experience the importance of the battery.

• How fast does the car accelerate? In part, this depends on how fast the electricity flows from the battery.
• How long can you drive it? In part, the more charge the battery holds, the longer you can drive. You can also drive farther if you can use all the electricity in the battery.
• How long do you have to wait to drive again while re-charging?
• How many years will the battery last? How often do you need to service it?
• The weight and size of the battery are also key factors. Everything else being equal, a battery that weighs twice as much will make acceleration and drive time worse, and a battery that takes twice as much space will similarly degrade operation.
• Finally, cost. Let's not forget about how much you have to pay.

When you walk into a dealership and ask about electric cars, you may think purchase cost is the main thing that matters. But as you get educated, you learn about these other factors that are just as important.

Boston Power Batteries

Oak invests in the maker of the best battery for electric cars, Boston Power. Boston Power didn't invent the underlying chemistry being exploited, Lithium Ion. But they have scores of patents for making the underlying chemistry safe at car-sized applications, dense, light, and fast and effective at taking and giving electricity.

Each one of these factors is important. You can experience them personally in a car. The safety issue isn't a minor factor, since lithium ion batteries, when not built with Boston Power safety technology, can catch fire and explode; there have been massive recalls as a result of this. Here's an illustration:

 

If a little notebook computer battery can do that, imagine what could happen with a car-sized battery!

The key thing is that Boston Power's batteries are best-in-class at all the things that matter: energy density, long life, fast charge, safety and environment.

Computer Storage

I hope most people know that computers have storage like this one:

Storage is an essential part of computers. But just as things change when batteries power whole cars, what is the best storage changes when computing moves into the Cloud.

It's not as easy to personally experience the impact of storage as it is to experience the impact of a battery while test-driving an all-electric car. But the change in scale is every bit as dramatic. While your department's computers might fit in a closet or small room, Cloud data centers go on for acre after acre.

It doesn't make much difference if your department's system takes one rack or two -- but if a given storage system requires two acres to do its job when a Cloud-sensitive one can be better while taking just one acre, that makes a big difference.

When you operate on a Cloud scale, factors that don't matter much at a smaller scale become hugely important. The important factors are remarkably similar to those of a battery:

• How quickly can you store and retrieve data? If it's too slow, you'll have to buy more to get the speed you need.
• Can you fill it completely with data and still have it perform?
  
• How many years can you use it? How often is service required, and how costly is the service?
• Size and power consumption are key factors. Space and power may not seem like large factors, but on a per-acre scale, they are huge.
  

When you first learn about storage, the only question you ask is how much it costs to buy a given amount. As you get educated, you find these other factors are just as important.

X-IO Storage

Oak invests in the maker of the best storage for large-scale data centers, X-IO Storage. Just as Boston Power didn't invent the chemistry, X-IO doesn't make the basic storage devices. Just as Boston Power has made the chemistry practical for car-scale application, X-IO has scores of patents for making large numbers of storage devices (spinning disks and SSD's) safe and practical for acre-scale applications: dense, low-power, long-lived, low-maintenance, fast and effective at taking and giving data.

For example, most storage systems treat their disks as throw-away items: devices that often fail and must be replaced frequently. Typical rates are amazingly high, resulting in substantial labor, replacement and error costs. The Google video below illustrates the consequences of this well; start at 2:42.

 

The Managed Reliability aspect of the X-IO technology reduces storage device failure rates by over 100 times. This is such a huge advance that disks can be sealed in their enclosures, which leads to other benefits.

The key thing is that X-IO storage devices are best-in-class at all the things that matter in storage: storage density, long life, reliably high performance, low power and environment.

Conclusion

Whether it's batteries that make electric cars practical or storage that makes acre-scale data centers affordable, Oak invests in companies that develop fundamental, industry-changing technologies over many years, and sees those companies through to success.

Oak Investment Partners in the 2012 WSJ top 50 VC Companies

Oak Investment Partners backs 4 of the 50 companies in the 2012 WSJ list of top VC-backed companies. This isn't the first time Oak has been well-represented in that list, or in other important lists. But it feels great every time.

Venture Capital and VC-backed Companies

There are a very large number of companies backed by VC's, and a similarly large number that aspire to that backing. For this list, 5,900 companies were considered, so the list is what the WSJ considers the top 1% of all such companies. An elite list!

As to VC firms, there are also quite a few. The NVCA gives a couple definitions; depending on the one you prefer, there are between 460 and 791 venture firms in the US. This means that most venture firms probably have no companies they back on the WSJ list.

And our companies aren't just any old companies. Last year, our company Castlight Health occupied the number one spot. We've got the number one spot again by backing Genband.

The Companies

As I've done in the past, here's a quick summary of the companies:

#1 Genband. This is a rapidly growing, complex company that provides products and services deep in the innards of networks. The simplest way to understand them is experts in implementing the long evolution of fixed networking and communications systems to ones that are IP-based, for example VOIP.

#25 SmartDrive. SmartDrive has been on the list before. They're pretty much the same thing as they were, except they've clawed their way higher in the list this year, as they richly deserve. They still help drivers of commercial vehicles drive more safely and use less fuel. The market has rewarded them by installing their service on more than 10,000 commercial vehicles.

That's 10,000 vehicles that are safer, more fuel efficient and more cost effective than there were before, something which benefits everyone.

#27 Movik. Movik is deep inside the mobile networks. Most people don't think about what happens when they talk on their mobile phones while walking or driving, and they don't need to, because of the astounding web of complex systems that make it all happen. But we all know the mobile networks aren't flawless, in spite of the billions of dollars spent to upgrade and maintain them. This is where Movik steps in. With their deep insiders' knowledge, they have constructed a kind of real-time "big data" application with analytics and automated responses. They get a flow of information from the various internal systems and decide, for example, that a person walking and talking is connected to a local cell tower that is becoming overloaded, and there's a nearby one that he's walking towards that has excess capacity -- and gets him switched. It's cool stuff, and creates a win for customers and the carriers.

#46 Keep Holdings.I'm having a lot of fun working with Scott Kurnitt and his ace team, based here in NYC, as they rapidly evolve their way from good ideas and implementations to great ones. Starting with AdKeeper, they've now added a service

to enable consumers to get back control over their in-boxes from commercial messages, seeing offers when and how they want to. They're also rolling out a "social commerce service"

that plays in the intersection of e-commerce, social networking and consumer curation of products.

 

Does your Software Work Well? Look Good?

It doesn't matter how good your software looks if it crashes. If it's broken, please take it home and don't come back. But if it does work, then the next thing you should care intensely about is how good it looks. Software winners tend to combine great design with code that, you know, works.

I'm a fanatic about software QA. It is one of the most unappreciated aspects of software development. But it's not the only thing that matters. Just as in math, beauty is something that pervades all aspects of great software, internally and externally. The impact of great design should never be minimized.

One of my favorite Oak companies is OneMedical. They are re-inventing the doctor's office. They use great software behind the scenes, much better and more effective by far than most doctors use. They use modern methods for patient/doctor communications; you can e-mail with your doctor -- what a concept!

On top of all that goodness, they have great design. The pictures on their website give you the basic idea.

I just went in for an annual checkup. My doctor, Malcolm Thaler, was great. Here's a picture I took while in the "waiting room" (given how it looks, I kind of hate to call it that).

Here's a picture I took through the window of Dr. Thaler's office.

Even if you don't have access to the software behind the scenes like I do (I mean in general -- no, I can't and wouldn't want access to patient records), the great design of their offices gives you the visceral impression that good things are happening at OneMedical. As indeed they are.

The lesson is a general one. Once you've gotten good, be sure you look good, so that people will think the right thing at first glance.

Communicating Technology: the SMiT example

I love my job.

I was in Beijing, China a couple weeks ago talking with an incredibly fast-growing internet ad network, YoYi Media. These guys are doing great things; they'll succeed whether we end up partnering with them or not. While on-site, I got a chance to talk with Liya Wang, who was helping us "on loan" for a couple days from her main responsibilities at an Oak company I've had nothing to do with until now: Shenzhen State Micro Technology Co, SMiT.

Liya is a finance person working on primarily financial issues with SMiT, and as such, she needs to explain to bankers and investors what SMIT does; understandably, people kind of want to know what you do prior to signing the check. As a start, she tried to get me to understand what they did. Fortunately, given my background, it wasn't too hard. But I could appreciate her trouble. The company essentially makes complicated chips that do complicated things that help make digital TV better. It is difficult to even start talking about what SMIT does without plunging into acronyms that are no more understandable when spelled out.

This is exactly the point at which ... the CTO should jump in and solve the problem!

... Wait, wait, don't you mean the fluffy, slick marketing people? Don't you mean the branding people? How can you possibly mean the CTO, who is the leader of the nerds who create the communication problem in the first place?! I mean, the CTO is the head of the incomprehensibility crowd, the lead creator of obscure acronyms, the guy who says things like "if I tried to explain it, it would just scramble your brain."

The CTO you should have, the CTO you should aspire to be, is exactly the right person to explain the problem, because he is the one who is most likely to actually understand the technology that needs to be explained! It's that simple.

Liya and I took a first pass at coming up with a way of explaining what SMIT does that does not involve scrambling of brains or twisting of tongues. She personally used Powerpoint to take a first cut at putting it into slides. I thought she did a great job, so I'm going to embarass her by taking some of images from the builds of just one of her slides that explains the core idea quite nicely. (I'm sure it can be improved, but this is a quick turn-around first cut!)

Starting, of course, with the problem: here's the confused user who would like to watch cable or satellite TV, but instead of just a TV and a remote, has an extra box, wires, things to hook up and several remotes.

So what SMiT do about this messy problem? The cable/satellite box disappears and there is a little card.

Then you see the card moving so that it's inserted in the TV -- in fact, it can be pre-inserted.

Once the card is in the TV, all the wires are gone, and you see the multiple remote controls turn into just one control that enables you to do everything:

The user of course is happy about this, and so gets a nice green check mark. But for the verbal learners in the crowd, it's worth spelling out the benefits:

This simple sequence of animations shows anyone what SMiT does and why it's good. Thanks, Liya!

Sequences like this are usually painfully obvious once they've been created -- it seems like they've always existed. But having been around many times when there is no such simple way of conveying the essence of a complex technology, I know how hard it is to do, and how important it is to get it right: to be simple without being simplistic.

While this is not in the typical CTO job description, it is actually one of the most important things a CTO can do, and no one does it better than the best CTO's.

If you're a CTO or on the path to be one, I suggest that this is an incredibly important exercise to undertake. It actually helps you to get perspective about what you're doing (and why you're doing it!) to be "forced" to explain it to non-technical people. It gets you "outside" of yourself in a way that is often useful.

ERP, HRP at Collabera and Sutherland

Modern ERP systems have brought the automation and efficiency of turning raw materials into finished products to a high art. When will the equivalent systems for finding, selecting and deploying human resources become widespread? When will we have "HRP" (Human Resource Planning) systems that are up to the level of modern ERP? The Oak company Collabera has such a system which is more advanced, automated and efficient than anything I have seen or even heard about. When I learned about it, I was glad, but also wondered why they had to create their own, why everyone doesn't demand such a system?

Is There an HRP Problem?

Yes. All you have to do is think about people as though they were raw materials to be sourced for a factory, and ask basic questions like: what are our basic systems for sourcing the raw material (people) we need? How do we distinguish good sources from poor ones? When we encounter a batch of new material (a candidate), what are our systems to assure the material meets our standards and will perform? What steps do we take to turn the raw material we acquire into finished goods (an effective, trained, reliable employee)?

Putting metaphors aside, I have personally been involved in the chaotic process of identifying, selecting  and hiring people with programming and software management skills for years, and the process has remained catch-as-catch-can for decades!

In most places, the HR people somehow identify candidates essentially using keyword match methods that focus on the most incidental aspects of programming, like what language you've used most recently. If you were burned even more than usual with your most recent hire, you may bump up the experience and/or degree requirements, but that's about it. Then you may do phone interviews and in-person interviews, but those often amount to little more than verbal resume recitations and get-to-know-you chats. Some big companies like Google think they're being smart by giving people trick puzzles to solve, but those tend to be jokes.

I remember on my very first job out of college, I quickly ended up interviewing all programming candidates because somehow my boss had decided I was a good interviewer. I have no idea why -- I was just winging it -- but then so was he, and at least I wrote up notes!

So I would say, yes, there is a major HRP "opportunity."

Why Isn't HRP Ubiquitous?

I've often wondered about this. I think the answer is related to other long-standing mysteries like why does the software in certain industries (like health care) severely lag behind software in other industries? I think (pure speculation here) that the answer has to do with the degree of technical focus (i.e. nerdiness) of the management, and how "hard" (quantitative) the success measures are. For example, medicine is all about people and there are loads of tough-to-quantify aspects of their health, while manufacturing is all about making things, and nearly everything about it is easily measured. So software and automation has a hard time making headway in medicine, while it's table stakes in manufacturing.

Who is ultimately in charge of hiring people? Mostly, it's highly people-oriented HR types, and their business is even harder to quantify than medicine. You might think that when hiring programmers, getting interviewed by other programmers would be a great selection method, but particularly in large companies, it tends to be terrible! What else would you expect when non-people-oriented programmers are asked to perform this highly inter-personal task for which they have little talent and no training??

Everyone knows that interviewing programmers is tough, that only programmers are qualified to do it, and they're simply terrible at it.

What can be done about HRP?

I first realized that there were ways to make the hiring process better when I saw it actually done at a couple of Indian outsourcing companies. I noticed something was different when I attended a meeting and they would trot out the most important, prestigious person on their executive team: the head of HR! It didn't take long for the reality to sink in. As an outsourcing company, your main job is hiring and managing people better than the company you're outsourcing for. The whole reason outsourcing exists is that the client company does a terrible job finding, selecting, training and managing their people, particularly in IT and customer service. The outsourcing company has to do a better job, or the client company might as well in-source! Being real good at HR is life or death at an outsourcing company, so they tend to focus on it and apply systematic methods and automation.

Another Oak company, Sutherland Global Services, provides a great example of how an outsourcer can be better than its client at performing essential business functions (in their case customer service and various forms of BPO) through superior methods, HRP and automation. Among other things, these methods enable them to be truly "global" as their name says, for example shifting the mix of work among various locations including the US, Canada, the Philippines and India without wrenching dislocations.

Conclusion

In field after field, everyone is convinced that a certain job can only be done by a highly skilled human, a craftsman, an artist, a professional. There is outrage when automation is introduced. There are riots, and machines are destroyed. Eventually, however, the automation is so successful that is replaces or greatly aids the human.

Why shouldn't the process of selecting, training, placing and managing humans in those positions that (at least for now) require humans be subject to the same transformation? Not only can it be done -- it is being done. The startling growth and success of Sutherland illustrates the practical impact of applying system and automation to human resources, and demonstrates that it can be done all over the globe.  Collabera uses its innovative and effective HRP methods to hire people who often work alongside and intermingle with "regular" employees of Fortune 500 companies; their methods make such a difference that their clients keep coming back for more, as shown by their admirable growth rate.

Everyone involved in hiring knows it can be done better. It's only a matter of time before human resource automation becomes a widespread practice.

The Xiotech ISE and Technology Fashion

We all know what fashion is. Think of Vogue Magazine, or impossibly tall, thin women walking in that special way down the elevated runway, wearing something no normal person would be able to wear, or would want to wear if they could.

But fashion extends way beyond women's clothing. Let's start with men's clothing: how many guys wear suits and ties to the office today? Then cars -- how many modern cars have those giant fins that were popular in the '60's?  The kind of popular music you like dates you at least as much as wrinkles on your skin. The more you think about it, the more you realize how pervasive fashion is.

"Technology is a counter-example," perhaps you say. "It's bits and bytes and silicon, no fashion there!" Well, that's true, except that it's people who buy the technology, and people are fashion-driven creatures. Let's face it: the cool kids who once drove sporty cars now pull out their iPhones at the slightest excuse. Waiting on line to see the Beatles; waiting on line to get the latest iPhone -- what's the difference? They're both fashion-driven fads.

"I concede that consumer technology is fashion-driven," perhaps you admit. "But hard-core computing technology, where nerds are building things for nerds; how can that possibly be driven by fashion?" I fully concur that no nerd techie would ever admit that his choices, selections and designs are driven by fashion, not even to himself. But all too often, that's exactly what's happening. The techie nerd who comes up with a design approach for solving a problem almost always prides himself on originality and foresight, without any awareness of how fashion-determined his most important decisions are. These decisions are often not made consciously; they are assumptions. "It's not worth discussing, of course we'll take approach X," the techie would respond in the unlikely event that the assumption is questioned -- by some "ignorant" (which is tech-talk for "unfashionable") person. Just to be clear: we're not talking about how nerds dress; we're talking about how nerds think.

There are examples in every field of computing technology. The Java/J2EE fad during and after the internet bubble is an obvious example, and before it client/server computing was a huge fad.

There is a clear example in storage technology today. The fashion is as clear and obvious as short skirts, and moreover is explicitly stated by its adherents: the fashion is that storage functionality should be provided as a body of software, independent of any hardware embodiment, and without regard to any particular storage hardware. Companies that previously sold storage hardware no longer have real hardware design functions -- all they do is bundle their software with hardware provided by others and sell the combination. The most popular form of this approach is to buy drive bays from an OEM and connect them to controllers consisting of off-the-shelf specially configured processors; 3Par and many others do this, for example. IBM's xiv implements a variation on this theme, using all IBM commodity server hardware. While there are still loads of dollars being spent on old-style, hardware-centric storage systems (think EMC), engineers building new storage systems are uniformly following the software-centric fashion.

In this sense, the Xiotech ISE is decided unfashionable. The ISE was invented at Seagate, in response to the CEO, Steve Luczo, wanting to create a storage product that was higher value than spinning magnetic disk drives. The idea was simple: build a fixed-format super-disk, with many Seagate drives, intelligence, etc. It would be bigger than a disk, but smaller than a SAN. It would emphasize basic storage functions (write, protect, read) and leave the "high level" storage functions to the SAN vendors.

What is interesting is that Steve Sicola and a group of other storage industry veterans ended up working side-by-side with Seagate engineers, something they never would have done at a SAN vendor. Sicola and his team knew the evolving fashions in storage quite well: ignore the details of the drives, that's "just storage." Build fancy high-level functions.

But since they were stuck with the drive engineers, they did something unusual: they actually listened to them! They learned about the amazing functions the engineers embedded in the drives that all the SAN vendors ignore. They learned how annoyed the Seagate engineers were at all the drives marked "bad" by SAN's, the vast majority of which are actually good; they learned about error codes and performance details that all the other storage engineers in the industry were studiously ignoring.

Before long, they got absorbed in what you could really do once you really knew the hardware. And, being good nerds, they invented a bunch of stuff, like how to virtualize over a fixed number of heads so that top performance was maintained even when the disks are filled up. They also invented a bunch of stuff that provides major, persisting advantages as new drives with higher capacities come out.

Since I know a fair amount about Xiotech's ISE, I want to go on and on about it. But I won't, because the point of this post is technology fashion. The purpose of bringing up the ISE is that it's a great illustration of the power of fads and fashion in technology. Any normal group of self-respecting storage nerds would have built a completely hardware-independent storage system. As such, it may have had nice features, but it would be pretty much like all the others in terms of its basic functions of reading and writing disks. But because these storage engineers were sequestered with hardware types and had a unique mission imposed from above, they did something very rare: they built a leading-edge storage system that is decidedly unfashionable. Because the engineers actually paid attention to the hardware, the ISE does things (performance, reliability, density, scalability, energy use, etc.) that no other storage system on the market today does, even though it uses the same disks available to others.

Fashion is, of course, a relative term. Fashion is one thing at diplomatic receptions, and quite another hiking in the wilderness or in a war zone. What is appropriate for one doesn't work for the other. Shoes that are appropriate for a salon can cripple you in the woods.

Well, it turns out that the modern storage fashion of ignoring the storage hardware may be acceptable in salon-type environments (where appearance and style is important but there's no heavy lifting to be done), but is as crippling as high heels in the I/O-intensive environments that are increasingly found in virtualized, cloud data centers. The ISE is like storage fashion for war zones of data, for data-intensive applications like virtualized servers, where the applications are concentrated in a small number of servers, all fighting to get their data. Most storage systems know how to hold their tea cups and conduct refined discussions and other things that matter when getting your data sometime today would be nice, thanks.

But when you've got a crowd of rowdy, tense applications all of whom are demanding their data NOW, perhaps more of a war-time style is appropriate; that's what the "unfashionable" nerds at Xiotech created in the ISE.

E-Commerce and E-Media

When are e-media companies going to start honoring the "e" in "e-media?" When are they going to start acting like e-commerce companies?

E-commerce and e-media

Everyone knows what e-commerce is. You can look it up on Wikipedia, where there's a major series of articles on the subject. Simply put, it's the electronic version of retailing, a.k.a. e-tail (which redirects to e-commerce on Wikipedia).

You might think that the same thing would happen to media. But we know it's not so! They are so different that "e-media" doesn't mean much -- e-media doesn't even have an entry in Wikipedia! How pathetic is that?!

So what is E-media?

If "e-media" means anything at all, it's got to mean the electronic, on-line version of media. So if plain old media includes, for example, the New York Times, then e-media has got to be the electronic, on-line version of a newspaper. Right?

Yes, of course that's right. There are lots of on-line news sites, and they're mostly the on-line editions of print or broadcast media. If you know what to expect from the paper or the broadcast, you can get something similar at a website, with a few enhancements such as frequent updating. And that's exactly what's wrong with e-media!

Putting the "E" in E-commerce

You would have thought (as many did at the beginning) that being a big, resourceful, successful retail company would give you a huge advantage on the web compared to a bunch of nerdy computer types who, when you glance at them, don't make you think "good at customer service." You would have thought that e-commerce would be dominated by names like K-Mart, Sears and Walmart. Of course, it didn't happen. All the fancy executives at the brick-and-mortar giants were certain they would crush the nerdy wanna-be's. All the fancy executives at the brick-and-mortar giants were wrong. Dead wrong.

Let's look at some of the most obvious things that distinguish e-commerce from its bricks-and-mortar forebears:

• Web-centric leadership. This might be the most important factor. Jeff Bezos of Amazon is the poster child for this point.
• Web-centric approach. This is a tough one. When you look at the web from the perspective of long experience in retail, you can't help but seeing the commonalities; after all, in both cases you've got real people coming to a "place," viewing goods and deciding whether to buy them. In their essentials, they're mostly the same, aren't they? This is exactly backwards. Succeeding on the web depends on seeing what's unique about the web and how to exploit it to advantage. Think for example about how Amazon knows it's you and presents you with things you might like, and tells you in real time how other people decided among the alternatives you're considering, lets you read what other people think, etc. Going "native" works.
• Technology embracing. Sure, retail companies use technology. Walmart is famous for their data warehouse, for example. But Walmart didn't invent anything -- they amazed the world and flustered their competitors simply by using state-of-the-art data warehouse technology. By contrast, the leading e-commerce companies not only use the latest technology, they advance it and invent new technology. Sometimes they do such a good job, they even sell their technology to other companies (again, Amazon is a case in point here). Retail companies may use technology, but e-commerce companies are immersed in it and create their own.
• Driven by Data. Again, Walmart is well-known for collecting and using data to retail advantage. They do it by product and by aisle. But the consumer has already made their most important decision simply by driving to the store. On the web, "driving" to another store is a matter of a couple clicks. The level of competition this results in is unheard-of in the world of bricks-and-mortar. In the e-commerce world, you can track everything, second by second and click by click, and the successful people do exactly that. They test, track, measure, modify and repeat.

Putting the "E" in E-media

It's pretty clear that today, we're just at the beginning of creating a true e-media. The way these things usually work, they will follow much (not all) of the path taken by the e-commerce folks. Here are a couple of the key points:

• Web-centric leadership. This is a tough point for most successful old-media executives to accept. But the burden of proof is on them: why is it exactly that they will succeed when all their brick-and-mortar fellows failed miserably?
• Web-centric approach. When you look at the web from the perspective of long experience in print (for example), you can't help but seeing the commonalities, and focusing on characteristics shared by print and web. After all, aren't you in both cases presenting a visual lay-out of words, graphics and pictures? Aren't headlines important? In both cases, it's real people consuming the product, and their reactions are the same, aren't they? This is exactly backwards. Succeeding on the web depends on seeing what's unique about the web and how to exploit it to advantage. I'm not going to spell out exactly how this can be done, because it's at the heart of e-media winning on the web. But the principle is clear: Going "native" works.
• Technology embracing. In the print world, printing presses are somewhere "else," and no one important invents anything technological. When editing and typesetting went digital, the media industry certainly went along. But they didn't invent it -- they just bought and used it. By contrast, the leading e-media companies not only use the latest technology, they advance it and invent new technology. The programmers aren't just functionaries beneath the notice of the "important" people in the company -- they are essential engines of innovation, and a good part of the success of the enterprise depends on their work. Media companies may use technology, but e-media companies are immersed in it and create their own.
• Driven by Data. You've got some data in the print world, but it's kind of pathetic in web terms. You put out a paper that has international, national and local news; sports; arts and entertainment; ads of all kinds, including classifieds; and other things -- and you have no idea who is spending how much time reading which part of the paper or how they're responding! It's like running a department store and being able to see how many people come and go, but not which sections of the store they visit or what they buy! Talk about flying blind... In the e-media world, you can track everything, and the successful organizations will do exactly that. They will test, track, measure, modify and repeat. 

No one knows how e-media will evolve. But the best companies (some of them Oak investments such as Demand Media, Federated Media and Huffington Post) are already marching down the road I've just described. While it's clear there's a ways to go, the leading companies following these principles are increasing their leads from the pack.

 

Healthcare: Higher Quality, Lower Costs: Candescent Health

There has been a lot of talk about how to pay for health care. At the same time, everyone wants the best quality care they can get. We all know that in practically every area of life, in order to get higher quality, you have to pay more. A better house? More money. A better car? More money. Better food? More money. How will we ever get out of the spiral of ever-increasing, ever-more-unaffordable health care costs? Everyone knows (empty promises from politicians notwithstanding) that we are marching down the road towards higher costs for lower quality health care.

Several companies in which Oak Investment Partners has invested in are pulling off the impossible, that is, lowering costs and raising quality. None of them involve magic. All of them make common sense. But they're new! The overall common theme is simple: understand the process, give consumers real, informed choice, and above all: use technology to automate the process. Here's one of them.

Candescent Health

Candescent Health is taking a well-understood, necessary, highly-valued medical service (medical imaging), and applying methods that have been used with great success for years in call centers and back office automation. The methods are proven and widely deployed. They lower costs while improving quality, often dramatically. The only surprising thing is that it has taken so long to apply the methods in medical imaging; but that's a potential subject for another time!

The core method is usually called workflow. It is widely applied in factories, document processing, and nearly any setting in which there are repetitive units of work. The key elements include:

• Digital unit of work. The foundation of modern workflow is a digital unit of work. This means the unit of work is like an e-mail, only with structure and controls. It contains the image, everything about it and everything that's been done to it.
• Central work distribution. There is a central location that "sees" (like an e-mail server) every piece of work coming in, every doctor who is working or ready for work, and the deadlines.
• Intelligent routing. It's important that the central work distribution makes intelligent decisions about which piece of work to give to whom. In a call center, this means you talk to someone who is qualified to handle your issue. For medical imaging, it means that the right specialist (for example, someone who only does shoulders!) handles your case.
• Specialized processors. A Swiss Army Knife is great, but for any given task, a real screwdriver, etc. is better. In the same way, someone who specializes in a kind of work produces superior results more quickly than a generalist. This is the key to better quality.
• Process automation. Once the right person gets the right piece of work, making that person as efficient as possible makes the person happier and more efficient. Every keystroke and mouse click that can possibly be eliminated is eliminated.
• Standardized output. Of course there are standard reports. But there should also be standard lexicons, and the same information should always be provided, regardless of who does the work. It's called "interchangeable parts." When this concept was introduced to manufacturing in the early 1800's, it led to an explosion of economic benefits. Now, in the early 2000's, we're applying it to medical imaging!
• Continuous improvement. Anyone who has worked seriously with workflow knows that the system can always be improved. Building in a process of continuous improvement helps maintain quality and make things better.

These are the elements of success for Candescent Health. I've just described their innermost secrets! But the key is that Candescent Health is actually delivering what I've described, and everyone involved (patient, referring doctor, specialist and hospital) is better off as a result. Everyone wins. Makes me smile.

Demand Media and the Media

Members of the mainstream media seem to have trouble looking at Demand Media, understanding its success and the fact that it is pioneering a new and valuable form of content creation. This trouble is illustrated perfectly by an article by David Carr, the media specialist for the New York Times. The article is surprisingly fair, but the author's feelings are easy to read.

At least from the article, it appears that the author (along with nearly all mainstream-media writers on this subject) either isn't familiar with the Innovator's Dilemma, or is unable or unwilling to apply the concepts to his or her own industry.

It's really not that different from the transitions between disk drive form factors, an example used by Clayton Christensen in his classic book (The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail) on the subject.

In each case, the people who are invested in the older technology look at the newer one as inadequate, cheap, failing to meet crucial requirements, and so on. They fail to appreciate how the new technology opens up new markets, fills unmet needs, and satisfies new classes of customers.

In this case, the old-media establishment is stuck on the notion that any form of media production must meet the following criteria:

• a small number of
• high-priced,
• full-time workers in
• central offices, producing
• small amounts of content that are released in a
• small number of
• elite outlets that
• charge readers for access

By contrast, Demand Media is pioneering media that meets the following criteria:

• a large number of
• moderately paid,
• part-time workers in
• distributed locations, each producing
• as much content as they choose, which is
• released on the internet and is
• free to readers,
• supported by advertising

Since Demand Media knows it's pioneering, it is experimenting and iterating its way to success, largely driven by direct feedback from its new class of customers. They are learning new things every day.

Again, the Times article was a relatively fair one; but critical feelings about Demand Media are completely understandable -- simply put, the people who make them often feel threatened by DM's success. But the day is long past when a small number of highly influential media figures can sway the thinking of the public. In the end, the internet is enabling consumers to vote with their "feet" (actually, their fingers and clicks), and from all the evidence, the number of votes in favor of Demand Media is growing at a rate that the management of old media can only dream about.

Kayak and Customer Intimacy

Kayak is a case study in how to get engineers to interact with customers to move your product or service ahead rapidly.

Paul English, their excellent CTO, put up a recent blog post on the subject that humorously features a red phone.

I continue to be amazed at how frequently organizations try to protect those "precious, critical path resources," their engineers.

The engineers are often complicit in this. They do all this project planning and get signed up for an ambitious string of deliverables. Then things happen -- new requirements come along, some things are harder and take longer, they are late and feeling the pressure. How do think they react when some well-intentioned, idealist jerk comes along and talks about what a great idea it is to have engineers handling customer requests and complaints directly? R-rated, to say the least.

It's the whole way organizations are set up that leads to everyone thinking that the "red phone" is a terrible idea. And that's a good test for your organization -- if the "red phone" seems like a terrible idea, then maybe your organization needs to change.