Comments and Questions after Getting Slashdotted

Slashdot has been a nexus for nerd news, and nerds themselves, for several years now. It summarizes and links to stories and sites, and hosts comments below the summaries. Summaries are proposed by readers, but evaluated and approved by the site’s editors. So there’s a hurdle to get over before content appears on Slashdot, where the slogan is "News for nerds. Stuff that matters." Because of the site’s popularity and the editorial hurdle, it’s a point of pride in many quarters to have your work ‘slashdotted.’

So I was pleasantly surprised when my recent Harvard Business Review article was summarized there. The self-congratulatory feeling lasted a few hours, until one my colleagues emailed me: "I’ve been looking over the comments on Slashdot; you don’t seem to have a lot of fans there. First Wikipedia and now this — why do people enjoy disagreeing with you so much?"

He was referring to the debate about whether Wikipedia’s "Enterprise 2.0" article should be deleted or not (The end result of this articles for deletion process was that the article should be kept, but an administrator then decided to change its title to "Enterprise social software." ). I participated in the debate (taking a predictable position), and was impressed by the extent to which this debate was about the merits of the article itself, and about the merits of the arguments for keeping or deleting it.

As I looked over the comments appearing beneath HBR article’s summary on Slashdot, in contrast, I wondered how many posters had bothered to read the article at all (this would not have been hard; the full text is available online free of charge during November). And if they had read it, I had a deeper concern: did I not make it clear enough that the article was not in any sense about managing IT professionals or software development efforts?

I was trying to help non-technologist business leaders feel in control and capable when it comes to IT; I was trying to help them get "wired." And as former MIT Media Lab director Nicholas Negroponte said a little while back, "Being "wired" does not mean becoming "computer literate" any more than driving an automobile requires becoming "combustion literate.""

I agree completely. Most drivers, including very good ones, know little about how their car’s engine works, if the vehicle was assembled using just-in-time techniques, whether or not the manufacturer’s labor practices were particularly enlightened, or where the assembly line was. These are important topics, and of interest to a lot of people (particularly in the auto industry), but they’re just irrelevant to the people driving the cars.

IT products are getting more and more like cars in this respect. Their production can be tidily separated from their use. This is clearly the case for almost all hardware, and also for two of the three IT categories I discussed in the article: function and network IT. Adopting enterprise IT requires extensive configuration work which can edge into coding, so use can’t be completely divorced from production. But it’s getting closer and closer.

I think some of the Slashdot commenters have a point when they say that IT managers, at least for some development activities, need to have good technical chops themselves. Whether or not generalists can manage specialists is something we management educators think a lot about, and I’m often of the mind that they can’t, or at least shouldn’t. It’s part of the reason I don’t try to turn my MBA students into CIOs (another big part of the reason is the fact that most of them don’t want to become CIOs).

But as I read them, most of the /. comments seemed to miss the point that this was not an article about developing technology products. So The Mythical Man Month (great book) isn’t that relevant, nor are PMP certification, ITIL, etc. 

I was puzzled and a little disheartened to see that so few of the comments engaged with the contents of the article at all. "Indeed, the whole article scores a giant, "DUH!"" is as close as most of them came.  

And this brings up an interesting point.  Let’s assume for a minute that the article is in fact completely unoriginal, and does nothing more than summarize and present to businesspeople what’s actually been common knowledge among nerds(a term I’ll keep using, ’cause Slashdot does) for some time.  If this assumption is accurate, what does it imply?

To speak bluntly, it implies some combination of stupidity on the part of the suits inside companies and poor communication skills on the part of nerds.

The belief that suits are stupid was, to put it mildly, detectable in some of the comments:

"[in the ideal world] the IT staff would make the decisions and then tell management/sales/paper pushers what they are to do. Judging by the comments on Slashdot over the years, I am not the only ubergeek that thinks the IT people should be the high paid personnel and the management a*****s should be the underpaid paper pushers that we all know they are."

"For most IT projects you could better categorize them as: "decreases costs and adds efficiency to the business", "increases costs and makes things more difficult", and "is huge Enterprise overhead purchased by someone at the CxO level who’s clueless… Oh wait, that third one falls into the second category, but the magic of "I’m in charge, do what I say" comes into play and suddenly the need to determine whether or not the project is worth the money being spent flys out the window."

"Here are the real parts of IT management:

1) Risk aversion: throw amazing amounts of cash at an external vendor to manage "risk". This way, when something goes wrong, you can point your finger outside of your domain.
2) Kickbacks: because you are throwing tremendous amounts of money around in step #1, you’ll quickly find that the external vendors are willing to throw some back – strictly off the record. They’ll also pay for your prostitutes.
3) Blind decision making: since you’ve paid external vendors to take on the bulk of the risk, there is little reason for your reward (see: risk/reward). This means that you can NOT delegate decisions to the people who have the knowledge to make them as you would be left to do nothing at all. Instead, subscribe to Gartner. They’ll tell you what to do. They’ll even tell you what to do after you realize that what they told you before was wrong (see: outsourcing, buy instead of build, etc).

Rinse and repeat. Posting anonymously for obvious reasons."

The main reason to spend time on comments like these is to reflect on whether they’re actually representative of how IT people think of their roles, and of their colleagues. If they’re representative at all, they go some way toward explaining why the business-IT dialog is so broken. 

The following exchange in the Slashdot comments places a bit more of the onus for improving the dialog on nerds themselves, implying that they need to improve their communications skills:

Initial comment: "I dont think this article says much to the Slashdot audience. It is really targeted at poeple who find IT confusing and needs to get an idea of what it is. It categorises and simplifies – maybe in a useful way for people who need an introduction. But again: not for the slashdot audience. Move on."

Reply: "Or maybe for someone who has been a geek for years and is now coming into the business oriented side of things this is a good read."

When you publish a set of ideas, one happy outcome is widespread agreement about their novelty and acceptance of their importance.  Another welcome outcome is (or, at least, should be) lively debate.  This is what I experienced around Enterprise 2.0 at Wikipedia, and during a back and forth with  Nick Carr around the HBR article.  If both sides in the debate have skins thick enough to tolerate opposing points of view and minds open enough to accommodate them, then real progress can be made.  

I was eager to see what progress could be made around my ideas after they were put in front of the Slashdot community. And I’m sorry to learn that the answer is ‘not much,’ apparently because the article’s ideas aren’t novel enough to merit consideration or debate.  If that’s the case, I hope I’ve at least done the world’s IT professionals a service by writing something they can give to their colleagues on the business side to facilitate communications with them.

Could I ask a favor in return?  Could someone point me to prior work that did what I was trying to do?  At a recent conference on teaching IT to business students, my fellow B School academics largely agreed that we lacked unifying theories and frameworks to help general managers understand the range of things IT can do for them, and the different things they can do for IT.  A lot of my recent work, culminating in the HBR article, has been an attempt to address this lack.  As part of this work, I read and tried to incorporate a lot of prior literature, and didn’t find the ‘silver bullet’ article, book, or site that had already accomplished what I was working toward.  Did I miss something?