Abstraction

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.

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…”

Knowing what works isn’t the most important thing. The most important thing is knowing what ought to work, but doesn’t.-paraphrased from Arnold Kling

One of the best books I’ve read in recent years is Nassim Taleb’s Fooled by Randomness. It’s one of those rare books that can forever impact the way you think about the world. In a nutshell, it talks about the fundamental role that random events play in every aspect of our lives, and how people are blind to that randomness. In particular, how successful people are blind to the role that randomness plays in their success.

It turns out that successful people attribute their success to their own choices and abilities to a much greater degree than is warranted. Further, other (less successful) people assume that successful people got that way because they are smarter, more experienced, somehow better, than they.

I was thinking about this in context of my assertion that a product manager is judged based on the success of the product being managed. Perhaps this isn’t true; there are simply too many variables to account for a product’s success. A product manager’s ability should be judged based on the efforts made to improve the likelihood of success, but this is something that’s much more difficult to measure. Besides, I’ve presided over some failures myself; surely these were random events that occurred despite my world class abilities and heroic efforts.

A corollary to this line of thought is that all the “best practices” and checklists associated with a particular activity (including the ones I write) are, at best, activities meant to reduce risk of failure. More to the point, they are activities that have reduced such risk in the past, and so it seems like a good idea to keep doing them.

Or have they? As Arnold Kling points out in this interesting TCS article “best practices” typically are regurgitated, repetitious, and have questionable value.

Articulating what works [...] can have surprisingly little value. Taken out of context, what works will seem obvious. What readers need to know is the larger context, especially what ought to work, but doesn’t.