Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
If you’re following the world of Enterprise 2.0 closely, you might want to take a close look at the results of this new study on office productivity
“According to a groundbreaking new study by the Department of Labor, working—the physical act of engaging in a productive job-related activity—may greatly increase the amount of work accomplished during the workday, especially when compared with the more common practices of wasting time and not working.”
I think there’s something in that for all of us…
A friend of mine was lamenting the corporate blog phenomenon the other day:
“It’s the ‘I would like to have a lovely conversation with you. About snake oil.’ tenor which so many of them seem to have. It’s so… demeaning. “
Hmmm. Consider:
- Steve Rubel suggests that the tech blogosphere is drunk on its own Web 2.0 Kool-Aid.
- Chris Anderson gives up and publishes the email addresses of the PR hacks who pester him with spam press.
- Whole Foods prohibits its executives from any kind of blogging or online forum participation
- Even Robert Scoble seems to have lost a bit of his enthusiasm.
Corporate blogging is a weird subset of the blogosphere, and maybe its bubble is about to burst. It does seem to have come to some kind of introspective adolescent crossroads.
(Mind you, corporate blogging is what I’m doing now. It’s alive and well here at infovark.)
Corporate Gord says: “Buy This!”
(Cartoon via Hugh Mcleod)
Personally, I still see plenty of value in corporate blogs. I don’t have a problem with crummy “Your Call Is Important To Us” press-release-style astroturf content. It tells me that their organization doesn’t understand permission marketing. It tells me that they follow internet trends without truly understanding them. Companies like that aren’t the kinds of companies I want to buy things from.
But I’m glad that I can see this on their corporate blogs. It makes my purchasing decisions a lot easier. As an example, the OpenText Blog tells me nothing personal or insightful — it just presents lots of case studies and PR stuff about how clever OpenText are. Similarly, the Microsoft Enterprise Content Management Blog contains nothing but detailed technical information about SharePoint.
On the positive side, lots of companies are better because of blogging. As an example, I’d always felt that Oracle were a bunch of cold, mean, database robots who delighted in making software so complicated it made me cry. But after reading the blogs of people like Billy Cripe, Bex Huff. and the Oracle Apps Lab team, I’ve come to view them in a different light. (Now I realize the robots actually have feelings!)
I predict the more boring, hype-laden, PR-driven blogs will disappear as old-school companies gradually realize they are doing themselves more harm than good. They’ll go back to older, safer ways of pushing as little content as possible while hoping that their customers will still turn up to buy stuff.
Best of luck with that.
In a recent post, Gordon talked about deploying Enterprise 2.0 tools in an emergent way. But what about the software itself? What characteristics make software emergent?
Emergence can mean several different things. The classic definition is that something has emergent properties when simple interactions lead to complex results. It usually carries with it the notion of repeated interactions. While you generally hear it used in a positive sense, as in “the sum is greater than the parts”, in can also lead to negative effects, as the designers of the Tacoma Narrows bridge discovered. Emergent doesn’t necessarily mean unpredictable, however. Many fractals have emergent repeating patterns but can be fully described by simple mathematical or geometric operations.
As a buzzword, emergence is often paired with social media. (Probably because geeks have a hard time with the idea of limited social interactions leading to complex group behavior.) But it’s true that sometimes a team can accomplish more than individuals acting alone. And it’s also true that rational individuals can get swept up in a mob, or fall for an investment bubble. Or that a short document listing founding principles can lead to a complex, multi-layered government system.
Writing software that exhibits emergent qualities is both very easy and very hard. It’s easy because there’s not much to program: Put your handful of rules in place and ship the product. But it’s also very hard, because once your audience starts working with the software, they may discover things you never intended.
Companies making computer games often release patches to tweak game mechanics, balancing the game so that no opponent has a greater advantage. Supporting a massively multiplayer online game requires constant monitoring to keep the experience just right. I think those of us writing emergent software for the enterprise could learn a thing or two from these games. If you’re interested in being an emergent software vendor, you can’t think like a manufacturer of shrink-wrapped boxes. The old programming joke becomes reality: The software isn’t done until the last user dies. You are an important part of your user community.
It also provides added incentive to avoid feature creep or featuritis. After all, if simple interactions can lead to complex behavior, where will complex interactions take us? Adding unnecessary features can add clutter to the interface, confuse users, introduce bugs, and ultimately cause unintended errors. All of which will drive your customers to adopt a smaller, cleaner product that does just what they need.
Most of all, writing emergent software requires a new attitude. The traditional way of thinking about software programs is that they are the means by which a user instructs a computer what to do. It’s a common trap that software companies fall into because that’s the way their programmers interact with computers. But the goal of your customers is not to tell the computer how to do things, but simply to get things done. The fewer instructions a user has to give the computer to get the job done, the more responsive and intuitive the program will feel.
To write emergent software, you have to shift your focus from the user interacting with the machine to people interacting with other people.