I’m sorry, but the title of this post is accurate. A bunch of my work is hitting bookstores, newsstands, and the Interwebs at present, and I feel the need to publicize it all here. I promise to revert to less self-regarding blog posts after this one.

I came back from a trip to find the first copy off the press of my book Enterprise 2.0 waiting for me in my office. I’ll leave it to others to discuss its content (hopefully in uniformly glowing terms); I just want to say that Harvard Business Press did a fantastic job on the book itself. It looks great, and I’m really grateful to my publisher for creating such a lovely container for the ideas. I love my Kindle, but I also still love physical books. And it’s a great feeling to see this one sitting on my desk.

Enterprise 2.0 should start shipping shortly from Amazon and 800ceoread (for bulk orders). It’ll also be available at next week’s Enterprise 2.0 conference in San Francisco, where I’ll be signing copies. I hope to see you there.

Also available now is my Harvard Business Review online article “Shattering the Five Myths of Enterprise 2.0,” the content of which is not hard to guess. It deals with common misconceptions around the deployment and use of emergent social software platforms. It is not an excerpt from the book, or a rehashing of ideas covered here; it’s novel work based on recent research and observations. I hope it’s useful and thought provoking, and I’d appreciate hearing any reactions. Please leave them here in the form of a comment.

And please also check out and comment on my new blog over at Harvardbusiness.org.   I’ve joined their family of bloggers (which includes many heavy hitters and fresh voices), where I’ll concentrate on IT’s impact on the business world. My ‘Hello, World’ post is called “Bridging the Geek-Suit Divide,” continuing my recent run of boring, self-explanatory titles.

I’ll use my HBR.org blog to talk to suits (in other words, managers) about how geek tools (information technology) are changing their world and their jobs. I don’t think enough attention has been paid to this topic, and I want to use the blog to make clear the depth and breadth of changes brought to the business world by computers. I use the word ‘digitization’ as a broad label for this change process.

I believe that digitization is one of the most important phenomena taking place in the business world now. I believe the data back up the previous statement. And I believe that most executives, and managers don’t fully appreciate how big a deal digitization is, and how critical is their role in harnessing the power of IT instead of getting blindsided by it. So I’ll use my Digitization Blog at HBR.org to try to drive all these points home to the site’s readers.

I’ll continue to blog separately here, of course, and I’ll also repost here all my HBR.org posts after a two-week delay. So if you’re happy just visiting andrewmcafee.org, you can continue to do so. But if you want to join the conversation over at Harvardbusiness.org or point your colleagues there, please do. I look forward to hearing from you no matter which venue you choose.

And if there are tech topics you really think the suits need to hear about, please let me know. I’d value your thoughts on what they need to hear about.

As I looked back over some recent blog posts and thought about some recent conversations, I realized that they’ve been pointing to a single broad conclusion. I think it’s time to state it explicitly instead of having it remain in the penumbra of the discussion around Enterprise 2.0.

Before doing this, I need to re-draw my E2.0 target picture, which I explained a while back: “The… figure below is an extremely simple and not-to-scale representation of the relative size of [four groups of people], from the perspective of our focal knowledge worker. The small core of people with whom she has strong ties is at the center, surrounded by her larger group of weakly-tied colleagues. Potential ties are in the next ring, and co-workers —  people with whom valuable ties do not and will not exist —  make up the outermost ring. My intuition is that for most knowledge workers the four circles in the figure are nested accurately  —  that the number of potential ties, for example, is greater than the number of weak ties —  even if their relative sizes are way off.” (This post explains the picture and its purpose in more detail.)

The conclusion I’ve arrived at recently is easy to state: Enterprise 2.0 is most valuable at the outer rings of the target.

I don’t mean to imply that emergent social software platforms (ESSPs) aren’t useful for strongly-tied colleagues (in other words, close collaborators). I’ve seen plenty of examples of dedicated teams making effective use of wikis, Sharepoint, and other forms of 2.0-style groupware. I get the impression, in fact, that at present ESSPs are most often deployed to support the work of people who are already strongly tied to one another.

I don’t think that this use case is bad, short-sighted, or uninteresting in any way. But I do think that it’s less interesting, and less valuable, than the deployment and use of ESSPs that span the outer rings of the picture above, where people are weakly tied or not yet connected at all.

I say this for two main reasons. First, prior to the arrival of ESSPs the IT toolkit available at the outer rings was both small and ineffective. Before the 2.0 era, what technology did we use to keep up to date with what our weakly-tied colleagues were doing, or to update them on what we were doing? How many of us sent out weekly emails to all of our ‘professonal acquaintances’ letting them know what we’d been up to?    How many of us would have read such emails from others?

And were there good digital tools to help us figure out who we should be working with, who could answer a question or solve a problem, or put hours back in our week? Throughout most of my professional life I figured such things out by asking my strong ties, who would consult their mental rolodexes and tell me if anyone came to mind. This technique worked sometimes and failed sometimes, but it certainly wasn’t technology-enabled.

Because of ESSPs like social networking software, microblogs (like Twitter), and a blogosphere that’s densely interlinked (and so navigable and searchable), the digital toolkit for the outer rings is no longer lousy. In fact, it’s now quite good. We can keep in touch with our weak ties, and find good potential ties — people we should be interacting with. And as I wrote earlier, prediction markets are great tools at the outermost ring, where people are strangers and will remain so. Prediction markets let strangers trade securities with each other, an activity that yields weirdly accurate forecasts of future events.

The second main reason for my conclusion is that outer-ring ESSPs bring substantial benefits, and ones that are difficult to achieve any other way. In other words, it’s not just that good outer-ring tools are new; it’s that they’re new and powerful.

Outer-ring ESSPs allow authoring, or writing for a broad yet unspecified audience. When knowledge workers author and link to each other, searchers can locate them and assess their knowledge and expertise. These same tools allow people to publicize not only what they know, but also what they don’t; seekers can use ESSPs to pose questions and let an undefined and arbitrarily large group of people see them. I’ve quoted Eric Raymond before that “with enough eyeballs, all bugs are shallow.” The new tools let people put their ‘work bugs’ in front of lots of eyeballs; if some of them belong to people who are informed and good-willed, solutions will be forthcoming.

ESSPs also let people build and maintain large social networks. An interesting possibility, discussed in my book, is that they might let users get past Dunbar’s number, the theoretical maximum number social group size. Dunbar’s number has been estimated at around 150 for people, yet many of us have more Facebook friends than that. It could be (but is by no means sure) that ESSPs let us keep up to date with more people than we could with our gray matter alone. A final demonstrated benefit of the E2.0 toolkit is collective intelligence, or the ability of crowds to come together and, with a bit of technology glue, generate good answers.

After a company deploys outer-ring ESSPs and acquires these capabilities, wouldn’t you imagine that it becomes significantly more productive, more efficient, and less plagued by waste and redundancy than it was before? I’d also imagine that it becomes more agile, responsive, smart, and innovative than was previously the case, but I realize that these are bolder claims.

One final thought experiment: take the same company, and imagine that it deploys ESSPs aimed only at facilitating the work of colleagues who are already strongly tied. Now how does your before-vs.-after comparison look?   Mine doesn’t look nearly as impressive; the company still achieves some real improvements, but they’re not in the same league as those realized when outer-ring ESSPs are in place.

Do you agree? Are you with me that the real benefits of E2.0 come when the outer rings are colonized by ESSPs, or do you believe something else?  Leave a comment, please, and let us know.

In a happy coincidence, blogger-who-needs-no-introduction Robert Scoble wrote about attributes of email just a few days before my Wednesday post on the same topic. Scoble’s succinct conclusion was that “email sucks,” and that Google Wave might well be worse. He makes an interesting argument, and I urge you to check it out.

Scoble lists the tools he uses for collaboration, and as I read through them I realized that I’d left an important item off my own list of email’s strengths. Scoble uses, in addition to email, at least six tools: Skype, Twitter, Friendfeed groups, a document repository like SharePoint or Dropbox, wikis, and domain-specific collaboration tools like ConceptShare.

He doesn’t describe any problems with this state of affairs, but I can only imagine what would happen if a similar collaboration suite were proposed at the consulting company I mentioned in my previous post. If a CIO or collaboration specialist told the partners that they’d soon be using seven collaboration tools instead of one, that person would very soon find himself exploring other career opportunities (I’d say “fired on the spot,” but the company I’m thinking of is too classy for that).

Like a lot of executives, consulting partners are in almost constant motion, very busy, and pulled in about eight directions at any time. They keep a death grip on their inboxes for one main reason: because it’s the one place they can go to find out what’s new and what the current state of affairs is, and also to respond, react, and initiate. Email is perfect for none of these purposes, but it’s perceived as good enough for all of them. As a result, it’s currently used for all of them; it’s one-stop shopping for collaboration at lots and lots of companies.

I want to be clear: I agree with Scoble, Luis Suarez, and many others that it’s possible to much better than all email, all the time. I’m trying to make three points with this post and its predecessor. First, that all email, all the time yields many problems but also one benefit: one-stop shopping for all collaboration activities. Second, that that benefit is highly valued by busy senior managers. And third, that these managers get to call the shots for the collaborations they’re involved in.

Let me sharpen that last point by floating a hypothesis about digital collaboration and immodestly naming it after myself:

McAfee’s hypothesis: Within organizations, collaboration technologies are dictated by the most powerful person involved in the collaboration.

This hypothesis only applies to technologies used for collaboration, which is defined by Merriam Webster as “work[ing] jointly with others or together especially in an intellectual endeavor.” So blogging, tweeting and retweeting, tagging, voting, linking, and trading in prediction markets aren’t really collaborative activities, while working as a team to prepare a client presentation or develop code clearly are.

A couple implications follow from McAfee’s hypothesis if it’s true. First, email’s going to be around for a while yet, and to continue to be the main collaboration tech in many (if not most) corporate settings for some time to come. As the incumbent technology, it’s the beneficiary of the 9X effect and the status quo bias, both of which are part the basic psychological wiring of most people and so hard to overcome. And as long as powerful people value the status quo and one-stop shopping, email will persist as the engine of collaboration. A lot of us might not like this fact, but there’s not a lot we can do about it, at least in the short term.

Second, blogging, tweeting, tagging, &etc. can take off in an organization even without the involvement of powerful people. This is because, as discussed above, they’re not collaboration technologies, and so less subject to the preferences of the powerful. It’s easy for me to imagine a big consulting firm deploying microblogging software, having it take off among junior associates, and realizing a lot of value even if no partners get involved.

As I wrote in my previous post, the continued dominance of email is in no way a death blow for Enterprise 2.0. In my book I describe six business benefits from Enterprise 2.0: group editing, authoring, broadcast search, network formation and maintenance, collective intelligence, and self-organization. Of these, only group editing aligns closely with the classic definition of collaboration. The others are all examples of technology-facilitated interaction among people, but as we all know there are many types of interaction.

A third implication is that email-light and email-free collaborations like the ones Scoble describes are absolutely possible, but only if the involved powers that be want to work this way. Even big traditional companies, teams in the IT department use wikis heavily for project management and bug tracking. This occurs because the head geek (term of praise, remember) likes wikis and wants to use them, and often says “I’m not reading emails about project status; use the wiki for updates.”

The hypothesis further implies, though, that if a more senior manager gets added to the project and wants to get all updates via email, then this is what will happen.

There’s a lot more to be said on this topic, I’m sure, but let me stop here and ask for feedback. Does McAfee’s hypothesis make sense? Does it correspond to your experience and intuition? Have you seen glaring violations: situations where a collaboration technology flourished despite the wishes / preferences of the most powerful people involved? Leave a comment, please, and let us know.

---

Now for some fun on a Friday. In my October 2 post, I threw out a challenge: “How many… English words can you come up with that are derived from the names of people in myths and legends who are neither gods nor the children of gods?”

A few word geeks self-identified by posting responses.

SamW made the sharp observation that “the hard part is remembering whether someone was a god or related to a god or not. I’m pretty confident about: arachnid, odyssey, narcissism, tantalize… less so about: echo” Excellent work all around. Arachne was a woman who committed the unpardonable sin of hubris, boasting that she was a better weaver than Minerva. For this, she was turned into a spider, thereby giving her name to an entire class of eight-legged invertebrates, the arachnids. “Odyssey” comes from the hero Odysseus, who had a long strange trip home.

SamW is also smart to be less sure about Echo, who in myth was a nymph who fell in love with the beautiful boy Narcissus, who only wanted to look at his own reflection. Unrequited love caused her to pine away until only her voice remained. However, since nymphs are commonly considered minor deities she doesn’t count, although he does; narcissism is now a word for excessive self-regard.

I thought tantalize was a great answer at first; he was a mythical Greek king who tried to fool the gods into eating human flesh. Zeus saw through this right away and killed him, then gave him a nasty eternal afterlife. As Wikipedia puts it, “Tantalus’s punishment, now proverbial for temptation without satisfaction (the source of the English word “tantalise” – US “tantalize“ ), was to stand in a pool of water beneath a fruit tree with low branches. Whenever he reached for the fruit, the branches raised his intended meal from his grasp. Whenever he bent down to get a drink, the water receded before he could get any.” The only problem here is that Tantalus was himself a son of Zeus, and so disallowed for this challenge.

Carl Frappaolo proposed narcissistic, herculean, echo, and homeric. Hercules, though, was also a son of Zeus (who really got around), and so disallowed. “Homeric,” meaning heroic or epic, is tricky. If Homer was an actual person he’s disallowed (the question is only about figures from myth and legend), but his existence is very much in dispute. So let’s accept “Homeric.”

Digiphile went with “Narcissism. Sisyphean task. Chimera. Delphic. Labyrinth.” “Sisyphean,” meaning endless and ineffective, is a great answer. It comes to us from Sisyphus, a Greek king and jerk so epic that he displeased the gods. They condemned him to roll a rock up a steep hill; the rock would always roll back down, and he’d have to do it again, over and over for all eternity. “Delphic” and “Labyrinth,” though, refer to places, not personages, so they’re out. And a chimera (modern meaning: an organism or organ made by grafting or genetic engineering) was a monster, not a person. So no dice.

Jmcaddell proposed “Titan, odyssey, jovial, atlas, bacchanalian, martial, herculean, nymph, music, lyric” Digiphile (who was really into this challenge, evidently) responded with “John, you’ve got a fine command of language …but nearly all of those are derived from gods or their children. Titan was an old school god, jovial refers to Jove or Zeus, martial is from Mars, Hercules was the son of Jove and the Muses were minor deities.”  So there.

After I thought about my own challenge, I came up with:

Stentorian, meaning very loud, from Stentor, a herald on the Greek side in the Trojan war.

Procrustean means rigidly conformist or “marked by arbitrary often ruthless disregard of individual differences or special circumstances.” Procrustes was a bandit who, according to Wikipedia, “had an iron bed in which he invited every passer-by to spend the night, and where he set to work on them with his smith’s hammer, to stretch them to fit. In later tellings, if the guest proved too tall, Procrustes would amputate the excess length; nobody ever fit the bed exactly because secretly Procrustes had two beds.” Wikipedia also tells me, though, that he was a son of Poseidon, so I lose on this one.

Adonis was a beautiful man born from the myrrh tree (in most versions). His name is now a generic term for a mimbo.

Pander, meaning to provide gratification for others’ desires, was the best one I came up with. It comes from Pandarus, who faciltated the illicit love between Troilus and Cressida. Googling around taught me that that story is not actually part of Greek mythology, but instead was invented in the 12th century. I’m still giving myself full credit, though, because Pandarus does appear as a character in the Iliad, and his name does give us that verb. Plus, it’s my challenge, and I’m still mad about ‘procrustean.’

A very smart friend of mine said “Are we confined to Greek and Roman myths and legends? Because if not, I propose ‘maudlin.’” Maudlin, meaning overly sentimental, is an alteration of the name of Mary Magdalene, who in some Christian writing is portrayed as a reformed prostitute who weeps much as she seeks forgiveness. A brilliant answer, and I’m giving it full marks even if Mary Magdalene was a real person.

Let me know if there’s appetite for more word geek challenges. If so, I’ll see what I can come up with…

I was talking a little while back with an IT manager responsible for the technology package used by the road warriors at a large global consulting company. She told me about all the different digital meeting rooms (DMRs) she and her team had tried to deploy, and about how none of them had ever caught on.

As at most big consultancies, analysts, managers, and partners in this company work together in relatively stable teams for the life of a project. Team members communicate extensively and intensively with each other, but long ago stopped using voice mail to do so when they weren’t in the same room. Email, of course, has replaced voice mail, and has been for some time the company’s communication backbone. Email is used for collaboration, coordination, updates, conversations, private chats, and almost every other form of interaction at a distance.

This was considered an issue for a couple reasons. Heavy email volumes increase storage requirements and make backup and synchronization a pain. More fundamentally, many at the company believe that email is a lousy tool for generating group-level knowledge and sharing it. I got the sense that the IT manager and many of her colleagues had come to the conclusion that, as Bill French put it, “email is where knowledge goes to die.”

This is a problem at a consultancy, where the only valuable assets are knowledge assets (assuming that the shiny downtown offices are leased).  Email is also a pretty lousy technology for keeping track of any particular extended collaboration, the elements of which are invariably chopped up and distributed across many messages, replies, ccs and bccs, and so on.

Because of all of this, the company had at several points introduced technologies that were supposed to do better a job than email of supporting a group’s interactions and harvesting its fruits. These tools had included dedicated wikis, virtual team rooms, and related offerings from Groove, Lotus, Microsoft, and others.

The IT manager estimated that she and her team had rolled out at least ten different DMRs in recent years. And she was clear that all of them had failed. None were widely or deeply used, and none had made any serious dent in the company’s steady torrent of email.

I don’t think her experience is atypical, and I don’t think it should be ignored. In fact, I think it’s time for Enterprise 2.0 enthusiasts to give up their frontal assault on email –  their war on words (it’s your father’s technology, it’s a dinosaur, it’s where knowledge goes to die) and their attempts to build and/or deploy replacement technologies.

I say this for two main reasons:

Email has some positive attributes. As I wrote a while back, “Email is freeform, multimedia (especially with attachments), WYSIWYG, easy to learn and use, platform independent, social, and friendly to  mouse-clickers and keyboard-shortcutters alike.” It can be used effectively by everyone at the consultancy, from a junior associate with a laptop in a hotel to Blackberry-addicted partner hopping among airports. It works well enough on both big and small screens. I admire Luis Suarez for his experiment in living his professional life without email, but I don’t want to replicate it.

Email is the incumbent technology. It’s beneficiary of the 9X effect, and so hard to uproot. It’s the collaboration technology of choice for lots of knowledge workers, particularly older ones. And these older folk are generally the people in charge. They’re the ones responsible for defining, executing, and delivering the work of the organization. This means that they get to call this shots, and if they want to communicate with colleagues and receive in-process and finished work product via email, they will.

When this is the case, the value of using other group-level collaboration technologies goes way down. A group of collaborators and I once started to write a paper using a wiki to hold drafts, to-do lists, supporting documents, etc. Things went swimmingly until one of the senior folk in the group started asking questions and sending thoughts via email. Because she was a valuable contributor we didn’t want to ignore her, and because she was senior we couldn’t dictate what tools she had to use to collaborate. The rest of us soon saw that it was at least twice as much work to maintain two parallel work streams, and eventually walked away from the wiki.

I appreciate that Millennials have different technology preferences and often prefer to use emergent social software platforms (ESSPs) instead of email and other channel technologies. But I also appreciate that almost without exception they enter the workforce in junior roles, and so are in no position to dictate terms about digital tools or anything else. Yes, there is a war for talent, including young talent. But there’s also a severe recession on, and plenty of talented people looking for work. With US unemployment around 10% and talk of a jobless recovery in the air, I wonder how many members of Generation Y will actually walk away from a paid gig just because the communication tools in use don’t suit them.

So does acceptance of email mean abandonment of Enterprise 2.0?  Of course not. Email might have a long tenure ahead as the communication technology of choice for strongly-tied colleagues, as well as for sporadic communications (especially private ones) among weakly- or non-tied people. But that’s not any kind of death blow for Enterprise 2.0.

ESSPs do things that email just can’t. Blogs and microblogs (like Twitter and Yammer) let us narrate our work and broadcast our expertise. Microblogs and discussion forums let us do the opposite, broadcasting our questions and requests and giving everyone, close colleagues and strangers alike, the chance to help us out. Social networking software lets us stay current with lots of people with little effort. And prediction markets harness collective intelligence, providing clear and accurate answers to difficult questions about the future.

All of these activities have proved valuable, both on the public Internet and on company’s private online properties.  They’re all examples of ESSPs’ ability to knit people together in novel and productive ways, to harness, collect, and share knowledge (without formally trying to ‘manage’ it like we used to) and to increase the degree of self-organization in an organization. And email supports none of them. It’s good for a lot of things, but it doesn’t deliver the benefits discussed here (which are covered in more detail in my book on E2.0).

I find that facilitating small group collaboration among strongly-tied people is a fairly uninteresting use case for ESSPs, because it’s already covered (imperfectly? haltingly? adequately?) by email. Many other activities aren’t. And because we don’t have any track record of supporting these activities with technology I think we tend to ignore or at least devalue them a bit.

In a later post I’ll talk more about why doing so is a really bad move. I want to end this one by asking if I’m making an important mistake by, as this post’s title suggests, stopping worrying and learning to love (or at least declare a truce with) email. Is this a copout? Does email need to go in order for Enterprise 2.0 to take off?  Leave a comment, please, and let us know what you think.

---

p.s. I’ve just started using Google Wave, a collaboration support technology from the folk who brought us the PageRank algorithm, Gmail, and Google Scholar (OK, that last one is a parochial choice, but it’s so much better than previous tools for sifting through academic literature). I like what I’ve seen so far, but need colleagues to experiment with. My gmail identity is amcafee – reach out and let’s start messing with this thing.

Wave or something like it might be the better mousetrap we’ve been waiting on for supporting unstructured team work, but that’s very different than saying it’s the one-stop shop for Enterprise 2.0.

p.p.s. I’ve changed unessential details about some of the people and companies described above in order to preserve privacy and confidentiality.

I posted a little while back about how hard it is to design tech products that appear simple, and said that I’d write more later about how to add complexity to them over time. So here are a few proposed ground rules on how to increase technology complexity without frustrating or alienating users (who value simplicity more than they think they do). These rules are just conjectures, based out of personal experience and observation; please don’t interpret them as peer-reviewed or empirically validated.

The best single resource I know of for dealing with complexity is The Laws of Simplicity, a small but deep book by John Maeda, president of RISD and former professor at the MIT Media Lab. I’m not trying to take issue or compete with Maeda’s insights at all here; I’m just adding a few thoughts on the relatively narrow topic of adding complexity over time to technologies like websites, applications, and devices.

Here are four rules of thumb. I hope they make sense and are useful:

Evolve, Don’t Upgrade. A series of small changes executed over time can be perceived as no change at all. A single great leap forward, in contrast, is hard to disguise as anything but that. Erosion and typhoons both alter the landscape, but a lot more people notice the typhoons.

This implies that if technologists want to add a bunch of new features and functionality to their offerings without being obvious about it they should introduce them in dribs and drabs over time rather than dumping them on users all at once.

This is comparatively easy to do with websites and harder for client-resident applications, especially because frequent app revisions strike many as an annoying hassle (I’m tired of typing my Mac’s password every time I get a new version of iTunes, Office, Tweetdeck, etc.). And it’s pretty close to impossible to do with hardware.

Keep the Core Interface Constant. Device makers like Apple and RIM have done a good job of keeping the user interface consistent over generations of releases. I think Amazon’s done the same. I know its home page and other pages have changed a lot over the years, but it feels like the search box, shopping cart icon, and ‘your account’ link have always been in the same places on the home page, as have the reviews and buttons I click to buy something on product pages.

These constants anchor me as I navigate around the site; if they wandered all over the place I might well get disoriented and confused, which is the last thing I and Amazon want. And even thought the navigation tools changed a lot from the first generation of the Kindle to the second, enough other aspects remained the same that I didn’t find the switch too disorienting.

I find that iTunes is not doing a great job following this rule. Important parts of the interface seem to migrate over time, and do so in unpredictable and jerky ways. And the worst case of interface inconsistency I’ve ever seen was Office 2007 for Windows, which with its Ribbon menu system pulled the rug out from under users in a deep and meaningful way. I felt my productivity plummet as I hunted around Ribbon to accomplish standard tasks, and never got back close to my previous comfort or proficiency.

Don’t Even Talk About It. If the first two rules are obeyed, complexity added over time can be just about invisible to the user. When that’s the case, why not let them discover it on their own instead of placing it front at center right after each enhancement? When my iPhone software was updated to version 3 I didn’t notice anything much different until I held my finger down on a text message inadvertently. The text soon changed color and a little ‘copy’ balloon appeared over it.

I inferred from this what I’d read elsewhere; that the iPhone had finally included cut and paste functionality. This news wasn’t delivered to me in any mandatory or even obvious tutorial, README file, or series of “what’s new” screens. Instead, it was delivered to me subtly, during my normal use of the technology.

This rule applies to feature sets in general. I don’t know if the iPhone has always interpreted two quick taps on the space bar as a period and start of a new sentence complete with initial capital letter, but I found out the other day that it does just that. I’m sure this is covered in some owner’s manual, portion of the Apple site, and/or blog posts, but I couldn’t be bothered to look at any of them, and my iPhone didn’t try to tell me everything it could do. It let me figure out over time what it was capable of.

Let Users Opt In. The iPhone / iPod ecosystem became vastly more complex when the App Store opened, but users could ignore it entirely if they chose to. The products continued to work fine with only factory-installed functionality activated, and all the additional apps were just icing on the cake.

Similarly, Gmail users can ignore labels and their folder-like attributes if they wish, and can also keep downloading attachments instead of opening them as HTML or in Google Docs. People can opt in to these features if they want (however, they’re forced to opt into to Gmail’s technique of grouping all messages with the same subject into a single conversation; I like this, but I know others who wish they could turn it off).

“People don’t like change” is both a tired old saw and a useful mantra for technology designers. So let them opt in to changes as much as possible, and keep using the same old same old if they want to. Following this rule means forcing change on users as rarely as possible, which is not an approach most technologists are familiar with. Instead of pushing their innovations on users, they need to master the art of letting people pull them in when ready.

Apparently simple technologies are blessings amidst the hectoring¹ distractions of modern life. Could we please have more of them?

I don’t mean to imply that the examples above are the only technologies or companies that have done a good job of complex-ification. They’re just ones that I use a lot, and so am familiar with. I think, by the way, that part of the reason I use them so much is the great job they’ve done with adding complexity over time. The iPod and iPhone, Gmail, and Amazon’s site are all much richer and feature-laden now than they were when I started using them, but in my head they’re still clean, simple, accessible tools. Neat trick, that.

What are the other ground rules for intelligently adding complexity over time?  What have you observed or learned from firsthand experience?  Leave a comment, please, and let us know.

---

¹ I was giving a talk a while back and used the word ‘hectoring.’ Right afterward a colleague threw down a great challenge: “‘Hectoring’ comes from Hector, the Trojan hero of the Iliad.  How many other English words can you come up with that are derived from the names of people in myths and legends who are neither gods nor the children of gods?” I got a few; how many can you come up with?   Leave your answers in a comment, and no reference works or Googling allowed…