I am one thing, however. I am a use case.

In the post linked above, Dennis Howlett gives the so called crock of E2 a lashing of epic proportion. I saw it go up and sort of delighted as the powers that be reacted to his assertion. I really chuckled out loud when one commenter referenced Karate Kid in her reply. Read it for yourself to form your own opinion, but best I can tell, the very debate itself, regardless of what side you are on, is the real crock.

While the critics and advocates go back and forth, wrangling for (what appears to me to be) pole position in the Blogpost Hit Count 500, there are those of us who have work to do. And, despite Mr. Howlett’s claims, we accomplish it using not only the tools of Enterprise 2.0, but via the ethos of a transparent enterprise.

I would consider the majority of the posts Jay and I have written to be evidence of our collective use case. We now work in a different way. Our organization, or at least the parts that need things from us, have changed the way they work as well. Sure, we may have speculated a bit on the evils E2 could cure, but all of them are based on real problems we faced on a day to day basis. The only criticism or advocacy we can provide for E2 is the sum of our experiences. Furthermore, if those experiences didn’t in some way improve our value to the organization, increase efficiency, drive additional revenue, whatever, we sure as hell wouldn’t continue to have them. After all, employment is my primary concern. Not the soapbox I am often accused of standing on.

Similar to the work I have to accomplish, the punditry will undoubtedly continue. While the debate rages on, there is in fact, actual change.  There are people like Jay and me everywhere, faced with “pressing business issues”, working via the tools and tenets of E2. Evangelism or criticism of the outcomes by the uninvolved is moot. Mr. Howlett asked, what problem is E2 trying to solve? For me….all of them.

Bookmark It

Hide Sites

Man. Aint that the truth.

This quote is from a recent blog post by one of my favorite Enterprise 2.0 authors, Paula Thorton.  It literally jumped off of the screen, landed in my mint julep, and was ported directly into the underwhelming organ I refer to as my brain. I can count on one hand (finger?) the number of business applications I consider great experiences. As such, it has been stewing there for the past little bit and I have been trying to figure out why. Not necessarily why it has been stewing (that part is easy – I am simple), but why the statement is true.

I have also been stewing on a rallying cry I continue to hear while waging the undying E2 adoption battle. People seem to be transfixed on the idea that things (technologies) “must be easy to use” in order to opt for a change. I hear this in bunches and have sort of reduced it to ‘a technology must be relatively easier to use in order to induce change”.  For argument’s sake I mean change in the most binary of senses.  As in stop using SharePoint and start using Confluence. Forget all the other stuff like organizational transformation or culture shift or <insert change buzzword here>.

So when these two stews came together, I asked myself the following question:

• Does a great experience with a business application imply that it is easy to use? Moreover, should it be?

In attempting to answer this question I thought about experiences I consider “great”. What are the attributes of an experience, professional or otherwise, that inevitably make it great? After sifting through my collective experience of persistent mediocrity, it boiled down to a couple things. They usually entail some sort of hard work, possibly even pain, and a sense of accomplishment. For example, I hiked up Mount Washington with Brother Nash this past winter. In one day with temperatures well below freezing, we covered 8 miles, gained and lost a mile of altitude, and carried a sweet ice axe. Hard work? Yup. Sense of accomplishment? For sheezy. Great experience? Check. Another example is my obsession with CrossFit. Most weekdays, the fine folks at Primal Fitness DC are kind enough to hand back my ass after a seriously proper kicking up and down New York Avenue.  From Fights Gone Bad to dancing with the clown, there is definitely both pain and a sense of accomplishment. Mark another in the “great” column. Finally, the time I spent working in the Middle East was definitely a great experience. We accomplished many things and well…the reason why life might be a bit hard in Baghdad is pretty self-evident.

So how does this translate to business applications? The only app I really consider a great experience is our wiki. I have never really thought about it until now, but why is that? Why do I think it’s great? For the longest time, I thought it was because it was easy to use. But the more I think about it, while the tool itself may be easy, the experience is anything but. It is hard. It is sometimes painful. And frankly, it should be.

When we write professional content (like deliverables) in wiki form, we are forced to expand our minds beyond typical expectations. We must increase our understanding of context, look for the bigger picture, and understand where the content we are producing fits into it. What does this link to?  Where else are people writing about this? What are they saying? Am I wrong? Are they wrong? What should this link to?

I would posit that none of these questions existed so blatantly until I had a tool that exposed them to me. I worked away in my little silo of knowledge (more of a shed really) and never had to consider the bigger picture. Maybe there was some other eRoom with similar content, but I sure didn’t have access to it. Even if I could link my document to the other, what did that do? It didn’t help the search engine. It didn’t provide trackback for the other author. It would also usually break if either doc was moved or renamed. Now those were the easy days. So why bother?

Well…I didnt. And most people still don’t. Even though there is a clear option to  produce a great experience, people are still slogging through version control nightmares fueled by email attachments and track changes. Why? Because it is easier??? No. Ease of use is often a foil for thought laziness. Email attachments are easy. But they don’t precipitate a great experience. Why bother to expand your perspective when the siren of a paperclip icon (or a folder upload) calls so sweetly? Silo shmilo…I have Facebooking to get to!

My great experiences with business applications (or anything for that matter) always require some level of hard work. Authoring in the wiki provides for a great experience, but when the content is at its most powerful, it is in no way easier to produce. It forces me to think beyond what I usually think about. Isn’t that what organizations want out of their employees? Isn’t that what employees want from their jobs? Challenging assignments? Big thinking? I know it’s what I want.  And yes, it can be hard. But, just like the feeling you get from a correct choice in the Big Mac vs. spaghetti squash conundrum…it is great.

Bookmark It

Hide Sites

This is key. While the drive to do IT differently, more cheaply and more transparently is clearly emanating from the folks now holding the reigns of the government, this notion easily be lost somewhere deep in the opaque depths of the IT procurement process. If there is one thing that some government technology contractors have come to appreciate, it’s that building a system that is expensive, difficult to retire, and complicated can often serve to lock in years of future revenue. As one presenter put it, some companies consider building bad enterprise software “a competitive advantage”. In some cases, this has become the only way they know how to operate. Think of the billions in contracting vehicles now rendered useless by a government who only wants to buy lightweight, open source software built on flexible data exchange standards – software that many of its legacy contracts aren’t able to provide.

Some will adapt. Some won’t. But, this opens a tremendous opportunity for smaller, more agile firms that have concepts like OSS, sound UX design, and web services built into their DNA. At Government 2.0, people like Peter Corbett of iStrategyLabs showed the feds that massive, data-intensive websites can be built quickly, and even crowd sourced to citizens who feel engaged by this approach. His Apps for Democracy project exemplifies this (in fact, Vivek Kundra sponsored this project when he was DC’s CIO). I’m confident that we’ll see the new administration work with IT vendors that can deliver projects that follow this model, big or small.

Bookmark It

Hide Sites

Needless to say, I am stoked. After 3 months of a painful regression through file uploads, track changes, and hourly knowledge assassinations from email, I could not be happier to again, author content in Confluence. I mean really though…how do people do it? I haven’t been removed from that world for decades but Jesus Murphy…I almost missed my handball game with Gordon due to the total time suck of outdated and inefficient tools and methods.

So…I have been a thinkin’. Thinkin ’bout 2.0 and what not. Know how people say ‘If I had to do it all over again…”, and then ramble off a litany of mistakes from their latest project? (Or complete life in my case). Sometimes they even go so far as to turn these pricey little gems of consulting pontification into deliverables we call “Lessons Learned”. Strangely, for as introspective and growth-oriented as this process appears, I always get the sense no one actually “learns the lessons”. They are more just an embarrassing admission of failure recurrence when “learned” again on the next project.

So with that, I figured I would put down on paper (monitor?) a few lessons we learned from our multiple 2.0 implementations over the years. We are essentially starting over in the adoption marathon at our new company, and maybe, just maybe we won’t have to learn these lessons again.

• Lesson 1 – Completely disregard anything said by anyone referring to themselves as a social media expert, selling only a social media strategy, or claiming that it’s not about the technology. The real “experts” out there are the employees with their heads down, screaming like a banshee for a better way to work. They don’t need a strategy.  They need permission and a tool that will enable them to serve as a vanguard for the organizationally elite .  They will guide the rest of the herd, knowingly or not. And don’t call them early adopters. Call everyone else late.
• Lesson 2 – Realize you probably know way less about “how your organization works” than you think. “Culture” can be a tricky devil in the world of limited choice. Maybe your organization hoards information because they have never been given an option otherwise. Don’t presuppose any of the actions of the crowd. Go into projects with a focus on flexibility and agile adaptation to the movements of the masses. This is social software after all, and I know I am not nearly smart enough to accurately predict anything a society might do.
• Lesson 3 – Convince yourself you are never informed enough to always be right. You are only informed enough to sometimes be present. If you ask more questions than you answer, you reduce the risk of looking like a complete knucklehead and increase your chances of getting a second date. Wait…that’s not a lesson I learned at work…definitely learned that in Adams Morgan. Seems to sort of work both places though.
• Lesson 4 – Start a blog and make fun of yourself for being a 2.0 zealot. I mean…we are kind of nutty, right? And just like Dairy Queen, everyone loves a little substance dipped in crunchy self deprecation.

I can say with absolute certainty that I have committed the mistakes driving these “lessons” dozens of times. Hell, I might be committing one of them by writing this post.  As we move ahead with Wiki Part Deux, we’ll keep the scoreboard updated on how we are doing.  Put on your rally caps though, because if my writing is any indication of my ability, I am coming from down a ton and need all the help I can get.

Bookmark It

Hide Sites

Best I can tell, the difference or relationship or commonalities or whatever between Web 2.0 and Enterprise 2.0 kind of look like this:

From Blog Pics

From the point of view of an enterprise, the E2 stuff typically engages people inside some sort of organizational boundary.  Like our internal Confluence implementation. The Web 2.0 stuff, while using the same technologies typically engages people outside an organizational boundary. The Web 2.0 stuff can (and probably should) engage people inside an organization, but it is not necessarily as deep or pervasive as the E2 stuff. An example of this might be something like my company’s corporate blog. We author, but the majority of the readers and commenters are supposedly outside the firewall. Also, there can be some crossover between the two. Twitter might be an example of that, but the jury is still out for me. Yeah I know…this is a gross oversimplification and “stuff” isn’t the most technical of terms, but (hopefully) you get the point. 

But in listening to round table discussion on Government 2.0, it sounded like this was the concept.

From Blog Pics

There was seemingly a mixing of “stuff” engaging both sides of an organizational boundary at once. Maybe this is less confusing to some, but to me I think it tended to get people bogged down in technologies and approaches, rather than community engagement. For example, a particular audience member was turned off by the entire 2.0 concept, merely because she thought every taxpayer in the world would see her mistake if she ever incorrectly edited a wiki. While this is a valid concern, it sort of depends on where that wiki is, what it is used for, and who it is engaging. To have a potential convert write off an entire concept because of this minor misunderstanding is unfortunate, and might possibly be avoided by drawing some corrollary Web/Enterprise 2.0 lines for the public sector.

Who knows though….Maybe I am trying to put too much structure around something that is inherently unstructured and emergent. What do you think?

Bookmark It

Hide Sites

All in all, the event was a bangin’ good time. In addition to my blathering and Jay’s wisdom, Ken Olofsen was on hand from the Atlassian mothership to give product updates, company overview, etc to the attendees consisting of government and private sector types from around the Beltway. Also, shout out to the guys from Blackboard who gave a neato rundown on their Atlassian stack to SilkCentral integration. 

Thanks to everyone at Atlassian (especially Jessie Curtner!) for throwing down a righteous shindig in the District. Well…as righteous of a shindig that can be had with a bunch of geeks like me. Looking forward to doing it faster, better, and with even more consultanese at the Summit.

Bookmark It

Hide Sites

Most importantly, E2.0 foreshadows the eventual transformation of IT from the people who provide your desktop applications to the people who run the machinery that keeps all the user-provisioned, in the cloud apps talking to one another. We all know utility computing is the future – where does IT fit? It becomes a provider of shared services, provisioning user profiles and authentication out to cloud apps selected by end users. Moving to this model will let IT focus on what it does best, and let users focus on what they do best – making their own decisions about what technologies work best for them.

Bookmark It

Hide Sites

“They can learn to listen. Listening to each other is core to our culture, and we don’t listen to each other just because we’re all so smart. We listen because everyone has good ideas, and because it’s a great way to show respect. And any company, at any point in its history, can start listening more.”

- Eric Schmidt Reveals Google’s Secret

So it’s not just the fact that Google has a bunch of people with “145 IQs”. There is something more – decisions are collaborative, and not the exclusive territory of the CxO.

What makes this level of collaborative decision making possible? Enabling technologies are naturally important. But, an open management organization that’s conducive to dialoguing with staff is even more key. Achieving this in modern enterprise is where things get tricky. What Enterprise 2.0 technologies make possible, Management 2.0 should embrace.

To start, I’d suggest organizations try the following:

• Look at areas of your operation where embracing employee input is critical to a successful outcome. Innovation around internal processes, products and service offerings immediately comes to mind. Create islands of managerial flatness here, supply enabling technologies, and create incentives for participation. Enabling technologies here might include an innovation market, like Spigit.
• Break the ice by putting management on the same footing as employees. At my firm, we’ve had a positive experience using the commenting and discussion features of Confluence to allow employees to post questions, and inviting the VPs to answer. The resulting knowledgebase is a searchable way for future employees to get up to speed.
• Give employees a voice: Give any employee who so chooses the ability to blog internally. It’s quick, cheap and an easy way to make employees feel more connected and less alienated. It also gives management a new insight into the ebbs and flows of communications within their organization. The blog post that has 100 + comments and has been read by thousands might be worth listening to.

Bookmark It

Hide Sites

What can government leaders can do to improve the situation?  For starters, mandate transparency. OMB publishes a list of high risk IT projects, innovative state governments are making their project performance dashboards publicly available and some government agencies are publishing their project’s failure analysis out to their constituencies. Work to open a dialogue about ongoing and past IT projects at your agency, and allow any staff member or the public to participate. Create a citizen community that allows your project staff to interact directly with members of the public that might be impacted by your project. The technology to build these types of communities is getting more sophisticated.

Your government agency should consider exposing the inner workings of its projects to the public; show them what they are getting for their money. Make your internal IT teams sweat a little, transparency will help to focus them on project success. Most of all, transparency can help better align project stakeholders. When all of the actors in a project – political appointees, staff, contractors and taxpayers – share in the same information, better decisions will result, and the outcome of the project will be closer to its original objectives.

But, there’s no reason to wait until after a project has failed to begin uncloaking it – start early in the process with a public project blog or wiki, that allows both project stakeholders and the public to provide feedback on the project’s goals and progress. If you take this approach, bad projects are likely to fail earlier, and good projects will attract the positive attention they deserve.

Bookmark It

Hide Sites