Power Relationships and Collaboration

Posted on Published by Eugene Eric Kim

At the Open Collaborative Services Initiative meeting three years ago, I met David Hartzband, who at the time was VP of collaboration technology at EMC. We had several fantastic conversations, including this thought-provoking claim: True collaboration cannot exist in a hierarchical relationship.    (LQK)

I disagreed with him then, and I disagree with this now, but I think I understand why he made this point. I was reminded of it again a few months ago, when Eugene Chan and I were having a conversation about the foundation world. He said that he wished fundees would be open with their program officers about the challenges they faced, but that the natural power relationship between funder and fundee discouraged it.    (LQL)

This, I think, was the essence of David’s argument. Would you approach someone with a problem if that person was in the position to punish you for being in that predicament in the first place? This scenario applies to both hierarchical relationships within an organization and relationships between competitors. It’s further complicated by the presence of money.    (LQM)

Even if your answer is yes, the fact remains that power relationships affect interpersonal dynamics. When you’re trying to improve collaboration, it’s better to be explicit about these relationships than to wish them away.    (LQN)

A great example of this phenomenon emerged from the CIA workshop last September. Upper management there both encourages internal blogging it and are some of the most active practitioners. However, as the workshop revealed, there is still a tremendous fear of blogging amongst the analysts. The roadblock? Several people blamed middle management, whom they claimed actively discouraged blogging, even while upper management said and did the opposite. Many also cited an incident where an analyst got punished for writing something. (Others insisted that this was an oversimplification of what actually happened.)    (LQO)

In response to these and other comments, Jerry Michalski (my hero when it comes to pithy wisdom) said, “Familiarity and fascination trump fear.” The fear in this case was a consequence of the power relationships. A more accurate (although less alliterative) word for “familiarity” is “trust.”    (LQP)

Today’s San Francisco Chronicle reported the following stats from a recent Florida State University study:    (LQR)

  • 39 percent of employees surveyed said their supervisor failed to keep promises.    (LQS)
  • 37 percent said their supervisor failed to give credit when due.    (LQT)
  • 27 percent said their supervisor made negative comments about them to other employees or managers.    (LQU)
  • 23 percent said their supervisor blames others to cover up mistakes or minimize embarrassment.    (LQV)

The problem isn’t that power relationships are inherently bad for collaboration. The problem is that most organizations do not have enough trust. Building trust is hard and takes time. But it’s possible.    (LQQ)

Are Lurkers Bad?

Posted on Published by Eugene Eric Kim

At the OCSI meeting yesterday, David Hartzband asked Johannes Ernst how many people he expected to have on the online workspace. Johannes said that we should keep it small for now, adding, “Lurkers don’t help us.”    (X5)

I’m probably being a bit unfair to Johannes in mentioning it here, but it got me thinking:    (X6)

  • Do lurkers help?    (X7)
  • Do lurkers hurt?    (X8)

My answer to both: Sometimes. Lurkers are part of a group’s latent energy; good things happen when that energy is activated. Lurkers are part of the all-important weak-tie network, and it’s important to keep them engaged, even if engagement does not translate to participation. However, having lots of lurkers as a community goes through its nascent “sausage stage” can hurt if it drives lurkers and other potential participants away.    (X9)

Here’s another question: Are lurkers members of a community? This question is left as an exercise to the reader.    (XA)

OCSI Meeting Synopsis

Posted on Published by Eugene Eric Kim

I was in Anaheim yesterday for the Open Collaborative Services Initiative (OCSI, pronounced “oxy”) workshop, which was part of the OMG Technical Meeting. Johannes Ernst, one of the OCSI organizers, invited me to present my manifesto on collaborative tools (which will be published in Dr. Dobb’s Journal and on the Blue Oxen Associates web site).    (WI)

OCSI is an attempt to get collaborative tool vendors to make their tools more interoperable. One of its early goals is to develop a shared architectural blueprint for describing collaborative tools, perhaps initially in the form of a white paper. This has been a refrain of mine for quite some time, and so I was very glad to participate in the group’s second meeting.    (WJ)

As it turned out, there was a tremendous amount of conceptual synergy in the room. I suppose I shouldn’t have been too surprised. At the beginning of my talk, I explained that one of our beliefs (also known as the The Blue Oxen Way) is that Shared Ontology (which results in Shared Language) is a prerequisite to effective collaboration. OMG is a very strong proponent of Model Driven Architecture, which is essentially an instantiation of Shared Ontology. Not surprisingly, there was universal consensus in the room about developing a shared model of collaboration — both on the human-level (e.g. Blue Oxen‘s work with Pattern Languages) and the system-level (the topic of my manifesto).    (WK)

In his introductory remarks, Johannes made several interesting points:    (WL)

  • The word “collaboration” means many different things to different people. This simply underscores the need for a common vocabulary.    (WM)
  • Collaboration seems to be an “it” topic among CEOs and CIOs. However, as often as they mention collaboration and as important as they claim it is, the collaborative tools market has been flat the past few years. At first, this seems to be a contradiction. However, the number of corporate downloads of free IM clients over the past few years indicates that the need for collaboration is real. One of the problems is that tools are not interoperable enough.    (WN)
  • There is no horizontal industry initiative for improving interoperability of collaborative tools. However, several vertical industries have expressed interest. One of the challenges is to get the different industries to realize that they share common needs so as not to duplicate efforts.    (WO)
  • Johannes chatted with a few tool vendors about this problem. Their response: “That sounds great, but I have a product to get out.” The way to get vendors more serious about interoperability is probably bottoms-up — via the user community.    (WP)
  • In this regard, the Open Source community could play an important role. The prequisite for standards is Shared Language and free implementations. We have the latter, but we don’t have the former. If we created Shared Language and if Open Source tool-builders adopted it, we could build a compelling case for standardization. Johannes feels that it is vital to involve both the proprietary and Open Source communities in the OCSI effort.    (WQ)
  • Collaborative interfaces should be as transparent as telephone numbers. When we see a telephone number, we know what to do, regardless of the underlying service provider, protocol (POTS versus VOIP), type of telephone, etc.    (WR)
  • Cut-and-paste is a type of interoperability between collaborative tools. (A poor one, as I and others noted later in the workshop, but also a relatively effective one — a good example of loose-coupling.)    (WS)

Other talks of note:    (WT)

  • David Hartzband, VP of collaboration technology at , provided a four axes view of collaborative tools: synchronous, asynchronous, inline, and contextual. He also observed two trends in the collaborative tools space: business communications convergence (e.g. telephone integrated with email integrated with your documents, etc.) and enterprise application functional convergence.    (WU)
  • Carol Burt, CEO of 2AB, shared her vision for model-driven access management. Not only could such a model have ramifications for those developing secure applications and those selling security software, it could also potentially plug in to an OCSI model for collaborative tools.    (WV)

At the end of the workshop, Joaquin Miller (the other OCSI co-organizer) led a discussion about the next steps within the OMG umbrella. The consensus seemed to be to propose the formation of an OMG SIG, which could potentially evolve into an OMG Task Force. Not being an OMG member myself, the conversation both baffled and fascinated me at the same time. Nevertheless, the folks there seemed to know what they were talking about, which is always an excellent sign.    (WW)

The next meeting will be at the next OMG Technical Meeting in St. Louis next April. We’ll continue to collaborate via an eRoom set up by David and via the OCSI web site. Our action item for now is to share our individual high-level models of collaborative tools in order to identify commonalities and to serve as straw men for additional discussion.    (WX)