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.

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.

I was recently re-reading Jeff Bigler’s funny essay about why engineers and “normal people” can have trouble communicating.

It would be nice to install tact filters on my Outlook. Certainly it would make reading email more pleasant. More importantly, it could nicely transform email sent after grumpily returning to my hotel room following 12 hours chirpily repeating the same spiel on some convention floor.

“Goodness knows,” the newly-tactful email would begin, “I would love to participate in the 9-11 pm meeting you scheduled at 8:51. I thank you for the opportunity to contribute; sadly, I may be unavailable…”