Abstraction

Related to my earlier post on how selling software to very large entities (e.g. selling software to telecom carriers) introduces unusual business challenges, I thought I’d post some key characteristics of software made for such carriers.

• It works, and continues to work — with five-9 availability — at the enormous scale required by carriers
• It solves a real world problem
• It contains sustainable differentiation
• It has no “single point of failure” (i.e. single external dependency) on which is relies to deliver value
• Avoids “specials” — one off development for a single customer
• Reflects input from customers and customer advisory boards
• (If a platform) provides robust, comprehensive SDKs
• Easy to install, particularly for PoCs
• Easy to configure, customize, and integrate
• Easy to update

So I’m reading something today and learn that the same neurotransmitter (TRPM8) that is excited by low temperatures is also excited by certain chemicals, such as menthol. I always assumed that menthol’s coolness was on account of rapid evaporation, even though it’s just as cool in a closed area (say, in one’s closed fist) as it is on an open one.

In fact, I “knew” that menthol’s coolness was caused by evaporation, even though this doesn’t stand even the slightest bit of active thought. It’s a trivial enough fact that I didn’t bother to expend any bandwidth on it at all, even as it was filed under “things I know.”

The point being that there are likely innumerable other “facts” sitting around in my brain. Hopefully the worst these will do is cause embarrassment as I wax knowledgeable at some dinner party, but I’m reminded how important it is to stay conscious of — respect, even — the breadth and depth of my ignorance.

I *knew* I should have coached my team against telling customers they are stupid and crazy. I’m hanging a copy of this on the wall immediately.

I’m vulnerable to prioritizing crap that, in the end, doesn’t matter at all. Every now and then I come across something that helps return perspective. I’m grateful for that, and I thought I’d pass it along.

Randy Pausch, a 46-year-old professor at Carnegie Mellon university, has incurable pancreatic cancer. He has been given months to live.

Two days ago, he gave his last lecture:

What we’re not going to talk about today is cancer, because I’ve spent a lot of time talking about that … and we’re not going to talk about things that are even more important, like my wife and [three preschool] kids, because I’m good, but I’m not good enough to talk about that without tearing up.

Here’s the full video of the lecture. I think I’ll go play with my son now.

In a previous post I broke a taboo by expressing my feeling that “some meetings are an important, and often neglected, aspect of good management.” (Breaking a taboo, I mean, by doing anything other than denigrating the hated meeting).

And, just as everyone, I still hate meetings. Hate them. Painful. Ugh.

But I see that Tyler Cowen has something positive to say about meetings, too:

But there is good news for the legions of meeting haters: Most meetings aren’t as wasteful as they seem.

Face-to-face gatherings serve valuable if hidden functions. For example, meetings publicize information about status. Who speaks? Who finds it necessary to praise whom? Who displays a confident demeanor? Meetings help managers and employees figure out how to build necessary coalitions. They bestow social intelligence.

A good reminder of the value of consciously maintaining focus and participating within meetings. Meetings are often the primary (sometimes the only) interaction point you will have with many colleagues, particularly those hierarchically above you. Even with colleagues you see and with whom you interact every day, meetings can serve to establish lines of authority and can build (or tear down) respect among teams.

The message: no matter how painful, how redundant, or how meaningless a meeting may seem, you should focus and squeeze as much positive, productive energy as you can out of the situation. The alternative is to risk being seen negatively — no one likes a whiner or a slacker.

Conveniently located down the street from my office is the Computer History Museum, which has a huge exhibit devoted to the evolution of computers. Just as you enter this room, on the wall to the right, is an abacus display. Continue walking and the exhibit provides a mind boggling chronology of computing, including ENIAC machines, 10Meg hard drives as big as my car, Cray supercomputers, and finally the Apple ][, TRS-80s, Atari 800s, and the PC.

By the way, if (like me) you see “TRS-80″ and immediately think “trash 80,” you’re showing your age.

My favorite part of the exhibit, by far, is the display of the more recent (say, ‘85-’95) computing devices, the ones that I used as a kid. It’s fun to look at at an 1200 baud modem and remember dialing up BBSs.

It’s fun, too, to think of how things have changed. In my mind, computing technology evolves in a kind of punctuated equilibrium (with apologies to Stephen Jay Gould). I’m not referring to Moore’s Law as an evolutionary concept, I mean dramatic, changes-everything evolution.

In my lifetime, there have been two of these. The first was the emergence of the PC as a common household tool. The second, of course, was the introduction of the Internet and the browser.

We are at the cusp of a third revolution, one even more significant than the others. It’s not really about the hyped concepts du jour: Web2.0, or IMS, or platforms (although all three of these are made possible by the emerging technologies). This revolution is more fundamental than that: it’s about the distribution of media, all media, via the network. I think the implications for this are truly mind blowing.

Traditional channels for media delivery exist because there was no alternative: CDs, DVDs, shrink-wrapped software, all exist because it was the most effective way to get media from the producer to the consumer. All of these will largely be gone within a decade: CompUSA will no longer sell software, Blockbuster will no longer have brick and mortar stores, music and film distributors will finally give up physically recorded media completely, television will be completely IP based.

The music and movie side to this phenomenon is well known, but truly amazing new businesses are announced daily. Ooma, for example, or Pano Logic, or Zonbu.

To date, all of the attention related to this third wave (if you will) has been focused on the services (the web2.0 and etc.) I mentioned briefly above. And yes, those companies I linked above are cool and amazing. But they aren’t the real winners.

But the real money, by and large, is gonna be made elsewhere: by the folks that make the networks and the network management, billing, and security systems. These are the systems that make it all possible; the technology that’s invisible and expected to perform faultlessly, like the telephone system. Pick up the receiver, and you get a dial tone every time.

Anyone representing a product weaves the conversation along a continuum that includes absolute accuracy, accuracy in terms of planned developed, accuracy in terms of potential development, and just plain inaccuracy.

I think it was in Dreaming in Code that I first came across the term “Shaving the Yak.” The concept has been familiar for a long time, I just didn’t have the words to express it. “Shaving the yak” refers to an focus on tools to accomplish a task instead of actually working on the task itself (e.g. Use this db, or that one? This coding language, or that one, etc.)

Sadly, yak-shaving happens to be one of my all time favorite activities. This is most evident in my book-buying: When I’m interested in a topic, I like to browse and buy books about the topic much more than I do actually learning about the topic.

My house is stuffed to the rafters with books that can serve as a chronology of my various interests over the course of the last decade or so.  You can note the many Dr. Phil books, for example, and, based on their position relative to other books, surmise that I had a fight with my wife sometime in 2001. My penchant for this book-buying has to do with feeling like I’m tackling a subject without actually having to tackle the subject.

For a long time, among my favorite yak-shaving activities had to do with personal productivity. Turns out I’m not alone, either; shaving this yak is so popular it’s got it’s own moniker: productivity prOn. There’s lots and lots and lots of web sites devoted to it, and a book, and many, many gurus. And no geeky blog is complete without a missive devoted to it.

And…I’m over it.  Thing is, my day to day work involves many onerous tasks that I’d really rather not have to do.  I think I subconsciously felt that if I were only to become super-productive, some of these tasks would take care of themselves. It’s akin to buying Quicken to fix an overspending problem.  You install it, feel like you’re making progress, and then realize that the unpleasant not-spending part is still there. (Then, irritated, you go out and buy Microsoft Money instead).

So no more shaving the yak for me.  I’m quitting the habit.  And to prove I’m serious, I’ve found a couple good books on the subject.

High among my (many, many) pet peeves is the bathroom hand-dryer, the wall mounted device that blows a sad little bleat of warm air on your hands, forcing you to either stand around and repeatedly cycle the machine or just give up and smear your hands all over the front of your pants.

Now, reminding me that the potential for a great product is often right in front of you, comes a better hand dryer.

It dries with a slim jet of air moving at 400 miles per hour. The Airblade doesn’t heat the air, so it uses about 80% less electricity than conventional machines. The dryers, which will be launched in the U.S. on June 26, are getting rave reviews from early customers. “Everybody loves them,” says George Denise, general manager for property manager Cushman & Wakefield at Adobe Systems Inc.’s buildings in San Jose, Calif. “They’re high-tech. They’re unique. They work well. And I’d even go so far as to say they’re fun.”

That great products ideas are everywhere, if you only know where to look, reminds me of an aphorism — there is, right now, a tiny company (or just an idea for a company) destined to grow into a billion dollar monster. If you missed your chance as an early employee at Google (or wherever), don’t sweat it; the next Google (or Oracle, or YouTube, or whatever) exists today, right now, somewhere. All you have to do is find it. They’ll hire you, no problem. Also, once you find it, you have to stick with it even when everything is going to hell and you’re sure it’s going to be a miserable failure. Easy, right?

One of the things I love most about living in Silicon Valley is how it celebrates geeks. Everything that is geeky, everything that made high school a miserable experience, is the norm here. It’s embraced. If it happens makes you very rich, it’s even sexy. People that aren’t geeky, or are at least associated with some geeky endeavor, are assumed to be cognitively impaired in some fundamental way. Not in a “you are stupid” way, but in a “you don’t really get it” kind of way.

It’s necessary at this point to admit that every non-geek I know (including my wife) would rush to emphasize that they in no way wish to “get it,” nor do they feel their life is in any way poorer for not “getting it,” and where the hell does a geek get off denigrating another person anyway, for God’s sake, not to mention the many things that geeks “don’t get,” including, all too frequently, personal hygiene and a modicum of conversational ability.

But I digress.

My point, such as it is, is that I just learned about the Tech Shop in Menlo Park. From the Tech Shop home page:

TechShop is a fully-equipped open-access workshop and creative environment that lets you drop in any time and work on your own projects at your own pace. It is like a health club with tools and equipment instead of exercise equipment…or a Kinko’s for geeks.

I think that such a great place could only exist in Silicon Valley. Anyway, kudos to Guy Kawasaki for pointing it out. Very, very cool.

As an ex-comedian (no longer funny), business presentations can be disconcerting. I am always scanning the audience for their reactions, and it’s hard not to feel that I’ve failed somehow if the crowd seems bored. I know, I know. Business isn’t entertaining. More to the point, my current business of networking protocols and the management thereof isn’t entertaining. There’s no way to make it entertaining, either. I suppose I could begin a presentation by saying that “a priest and a Rabbi walk into a bar arguing about MPLS dynamism,” but damned if I know where to go from there. Besides, everyone knows that men of the cloth are more into L7 than they are routing methodologies.

But I digress. Believe it or not, it turns out that many presentations today have some room for improvement. They are, research shows, somewhat boring (in the coma-inducing sense of “somewhat”) and less effective in terms of conveying information.

Initially I thought I’d throw in a sample or two of these poorly-done slides, but I figure it’s not necessary. Everyone has seen them: the slide has a 3-5 word headline, and a series of bullet points. The more technical the presenter, the more bullet points and the smaller the font. For example, a presentation given by a VP of marketing will have about 3 bullets using a 30 point font. A VP of engineering has 30 bullets using various random 10 point fonts pasted from different documents and never normalized.

Research shows that slides that use a sentence instead of a 3-5 word headline are more effective. Further, using images instead of bullets is more effective still. Write a sentence on top, such that reading the headlines of slides tell a little story. Then use pictures down below. Simple as that:

This alternative slide design features a succinct sentence headline that states the main assertion of the slide. That assertion is then supported by evidence presented in a visual manner. Presented in Figure 1 and Figure 2 are excellent examples of this design.

Does this make the presentations more entertaining? No. But it does make ‘em more effective:

Recent experimental tests have shown that the assertion-evidence slide design is superior to the traditional design at communicating technical information to an audience. Studies have shown that using the assertion-evidence design in the teaching slides of a large STEM course led to statistically significant increases (p < 0.001) in the knowledge and comprehension levels of students of course material [Alley et al., 2005].

If you haven’t seen David Pogue’s article about product manager’s it’s worth a read.  Money quote:

Good P.M.s, like good criminal lawyers, must sometimes be actors, making their case with conviction and passion when they’re representing a loser.

In the most highly stressed projects, people at all levels talk about the schedule being “aggressive,” or even “highly aggressive.” In my experience, projects in which the schedule is commonly termed aggressive or highly aggressive invariably turn out to be fiascoes. “Aggressive schedule,” I’ve come to suspect, is a kind of code phrase — understood implicitly by all involved — for a schedule that is absurd, that has no chance at all of being met.

Tom DeMarco, Slack

Many people organize the various types of software into three general buckets: shrinkwrap software (that’s sold in retail stores), enterprise software (that’s sold directly to a business), and web-based software (usually consumer oriented such as eBay or Yahoo).

Some years ago Joel Spolsky expanded on this in a great essay about the “five worlds” of software, in which he describes the how the context for a particular software project defines many aspects about the nature of the project — from how requirements are gathered, to how the project is managed, to the relative importance of getting it right the first time:

I think there are five worlds here, sometimes intersecting, often not. The five are:

1. Shrinkwrap
2. Internal
3. Embedded
4. Games
5. Throwaway

When you read the latest book about Extreme Programming, or one of Steve McConnell’s excellent books, or Joel on Software, or Software Development magazine, you see a lot of claims about how to do software development, but you hardly ever see any mention of what kind of development they’re talking about, which is unfortunate, because sometimes you need to do things differently in different worlds.

I think there is another world of software development, one that somehow seems hidden from the mainstream: telecom software development; that is, software developed specifically for carriers such as Sprint, AT&T, Verizon, Deutsch Telecom, etc. Here beats the true heart of geekdom; here are the systems that make up the fantastically complex networks at the heart of the Internet and of cellular telephony systems.

I’ve been thinking about the best way to describe how and why software development for carriers is different, when Marc Andreessen wrote a blog post that did the job much more eloquently than I ever could. Marc was writing about the challenges of working (as a start up) with large companies, but his insights are perfectly applicable to small companies that aspire to sell to carriers:

There are times in the life of a startup when you have to deal with big companies.

Maybe you’re looking for a partnership or distribution deal. Perhaps you want an investment. Sometimes you want a marketing or sales alliance. From time to time you need a big company’s permission to do something. Or maybe a big company has approached you and says it wants to buy your startup.

The most important thing you need to know going into any discussion or interaction with a big company is that you’re Captain Ahab, and the big company is Moby Dick.

The gist is that large companies do what they want, and you (as an Ahab-like small company) are totally helpless to control them, predict what they will do, or even make sense of what they have done.

A small company attempting to sell software to carriers (and there are many), this problem is magnified many times over. Not only are your customers akin to Moby Dick, but you are often working with (or attempting to work with) the other huge whales that keep Moby Dick happily swimming along.

For example, imagine you are trying to sell British Telecom (or whomever) some content, or services, or mediation, or analytics, or OSS/BSS system, or whatever. Of course you have to contend with the mind bending bureaucracy of huge carriers, their unique software requirements (NEBS compliance, 5-9 availability, scalability to 100s of millions, n+1 failover and geographic redundancy) , and their endless sales cycles. But you also have to manage relationships with the huge equipment providers that are often your best channel into carriers (Ericsson, Nortel, Nokia, Siemens, etc.).

Unusually difficult, onerous requirements. Huge, fickle customers. Huge, fickle partners. Grinding, painful, glacially slow sales cycles. Not for the faint of heart, and worthy of a special category all its own.

Interesting essay from Andrew McAfee about Tom Malone’s Future of Work. Future of Work talks about how information flow was once associated with decision maker; that is, because information was expensive to gather and transmit, it was made available only to the persons that needed it to make a decision. With the emergence of internet technology, the cost of distributing information is effectively zero. With huge amounts of information available to anyone within an organization, the organization becomes more decentralized, less hierarchical.

McAfee points out a flaw in this argument, essentially saying that a general availability of information is not necessarily correlated with decentralized decision making:

Let’s say that a mortgage company realized that a few of its loan officers were just better at assessing credit risk than all the others. For whatever reasons (intelligence, experience, intuition, etc. ), they just had superior specific knowledge. In that situation, it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers. All the general knowledge (income statements, credit histories, etc.) would be sent to these few people, who would apply their specific knowledge to it and made decisions. In this example low information costs are still important; they allow all the general knowledge to be zipped to the few good officers. But the effect of low information costs isn’t decentralization and greater empowerment. Instead, it’s centralization of an important decision right and reduced autonomy for most loan officers.

Thought experiments like this one indicate to me that the net result of disappearing information costs won’t necessarily be decentralization. It will instead be the decoupling of information flows and decision rights. Organization designers will be able to allocate decision rights without worrying about how costly it will be to get required information to deciders. Leaders will be able to ask “Who should make this decision?” without adding “Keeping in mind that it’s going to be slow, difficult, and expensive to get them the general knowledge they’ll need.”

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case. I agree with him that we’re at a very interesting point in the history of technology and the economics of information, but I’d label it a great decoupling (of information flow and decision rights) rather than a broad decentralization (as decision rights lateralize along with information flows).

I’m a big proponent of making information available to anyone in an organization; I have posted before about the importance I place on an online product requirements tool and a product information wiki to encourage and enable collaboration. I do this because markets are dynamic and technology is complex, and I believe that multiple inputs on product definition is larger than the sum of it’s parts. Certainly of a much greater benefit than can result from the efforts of a single centralized product “decider.”

To me, the mortgage example given above doesn’t hold the same implications for organizations as it seems to for McAfee

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case.

I think it is true that some decisions will always be centralized because it requires tacit knowledge that only a few possess (as in the mortgage example). But strategic decisions, such as a product evolution, will always benefit from the input of multiple perspectives.

Further, efficient dissemination of information enables the development of tacit knowledge and enables contributions from persons that would otherwise not have the opportunity. In this sense, too, the mortgage example seems to fall short: common information flow enables the development and identification of more people that happen to be very good at a particular role. McAfee’s comment that

…it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers.

It’s important to place decision making responsibility in the hands of those that will make the most effective decisions. But it’s also important to nurture superior decision making skills so that the decision workflow avoids a single point of failure. Instead of taking away the decision making rights of lesser-skilled workers, why not leverage the information flow to enable a sanity check of their decisions? The burden on the more-skilled worker will not increase, and the organization benefits from growing the (forgive me) “competence footprint” associated with a particular skill.