Technology and Organizations

There are no silver or “magic” bullets for organizations.  Google Wave was a single technology bullet.  The introduction of Wave had no organizational practice wrapped around it and little indicating consideration of how people would perceive it.  Organizations are complex systems and betting success on any single dimension is unlikely to work. There was no implementation. There were limited use cases.  Even access was limited until recently, meaning you couldn’t drag others along with you in your experimentation. (Wikipedia version of the history here.)

As I understand Google’s approach with Wave, it was to give Wave to the world as a platform.  Developers were expected build tools around Wave that normal people would use (perhaps as email platforms are built around Intenet email protocols).  I bought into that approach and followed the Google Wave Interest Group so I’d be ready when the developers got it all together.  I tried to get some other generally early adopters to try it out, to no avail, and many others were similarly frustrated.  Conferences were where of I heard the most success as the real-time/rich communication aspects were highlighted in that focused environment.

According to a Google announcement, Google will stop their own development of Wave and may shut down the site after the end of the year. Open source access to some of the capabilities will remain and aspects may be included in other Google products. Jeffrey Mann, writing for Gartner, points out that developers and users may be less likely to spend effort on Google products given the apparent lack of long-haul commitment.  Wave was only fully open to the public as of May 2010 and the cited reason for shutting it down is low user adoption.

The folks at Google are smart.  They’ve done (and do) amazing things. But they do seem to have technology bias that may be getting in their way.  In Kathryn Schulz’ recent interview with Google Research Director Peter Norvig we get some clues:

From a story about the founding of Google:

One of the venture capitalists came to [company founders] Larry [Page] and Sergey [Brin] and said “OK, the first thing you have to decide is, is this company going to be run by sales or by marketing? They said, “We think we’ll take engineering.” He laughed and said, “Oh, you naive college kids, that’s not the way the real world works.” And they said, “Well, we want to try it.” Ten years later, that experiment is still running; engineering is still the center of the company. And it seems like it’s worked.

I’ll argue that this single-minded approach sometimes works because some of Google’s products are so good, or fit into existing systems so well, that they can get away without implementation.  But I think Wave (and perhaps Google’s other visible failures) indicate that they could do better by stepping away from the myth of the silver bullet.  Om Malik says, “I’m not sure Google is capable of understanding people on that level, and that’s the reason why the company strikes out whenever it tries.”  For added success, Google needs to understand people and the organizational systems we all live in.

Google seems to need more systems savvy.  Systems savvy management is the opposite of a silver bullet approach.  Like the woven fibers of a bullet-proof vest, systems savvy management intertwines technology tools, organizational practices, and people for flexible strength.

What did I want from Wave?  I liked the idea of a persistent activity stream that could handle multiple file types.  I saw it as a way of consolidating project documents with their history and discussion.  We have this to a degree with products like Socialtext, and given Socialtext’s careful consideration of the broader issues, I expect they’ll be tracking the Wave experience.

I’ve been following Elance, one of the first (maybe the first?) web-based freelancing markets, since 2000 when it was a start-up of the tech boom. When I saw their booth last week at Web 2.0 Expo, it was a great chance to ask them how things have changed over the last ten years. Think about these particular last ten years: Many of us live and work via the Internet rather than a desk; outsourcing is an assumption for many firms rather than an experiment; Moore’s law is still with us; and Emeritus Prof. Edgar Schein of MIT said in 2004, “..we bascially do not know what the world of tomorrow will really be like, except that it will be different, more complex, more fast-paced, and more culturally diverse” (p. 331).

Elancing is an organizational design tool that should be in all our toolboxes. Elancing, and freelancing in general, provide organizational flexibility — but not just about basic staffing-levels. Companies like Elance provide access to staffing for jobs you haven’t even thought of.

Jaime Mehl of Elance (featured in the video below) opened my eyes to this issue. She says there are “..going to be projects posted that we don’t even know about yet — or [that haven't] even [been] invented yet.”

From a recent Elance report:

While the U.S. Department of Labor reports that the nationwide unemployment rate held steady at 9.7%, the Elance Online Talent Report shows online work continues to grow at a steady pace as its talent pool earned more than $20 million in the first quarter of 2010, surpassing a total of $260 million of work completed to date on Elance. This represents a nearly 40% increase year-over-year and demonstrates that businesses are increasingly turning to online talent, an important and thriving employment segment, to drive their economic recovery. Companies are turning to online talent for mobile development, open source, social media and cloud computing, making these the fastest growing skills in demand on Elance.

Kudos to the managers who take advantage of virtual freelancing. These managers are responding to the added complexity (and cultural diversity according to the Elance Report) that Prof. Schein predicted. They have developed the systems savvy to work with the technologies that enable elancing and have the skills to design organizational practice to take advantage of the flexibility. I welcome examples in the comments below. Have you been able to integrate elancing into your organizational design? What are the technical and organizational skills you feel are most critical to your success?

—–

More background on Elance from their site: (founded in 1998, following the publication of Malone and Laubacher’s, Dawn of the E-lance Economy.)

Today, Elance is the most widely used application for Services and Contractor Management. More than 200,000 employees are using Elance to find, buy, manage and pay external services and contractors from more than 2,000 suppliers across 50+ services categories, including information technology, consulting, contract and temporary labor, marketing, print, human resources, engineering, maintenance and facilities.

I’ve noted before that I live in my browser, that Google hosts my life, and I’ve questioned the meaning of workspace in today’s environment. Yesterday at Web 2.0 Expo my workspace got a bit bigger. Microsoft is giving us the cloud form of Office 2010 as Docs.com and its integration with Facebook.

From the Docs.com site:

Now you can discover, create, and share Microsoft Office documents with your Facebook friends. Built using Microsoft Office 2010 – Docs for Facebook provides the best possible document service for the Facebook environment. Seamless integration with Facebook means that the service is all about sharing your documents. Finally docs can be friendly too!

For me, this is all about going where my audience/teammates are. Technology is a tool and Microsoft and Facebook just gave me a new one. How I use the tool depends on the people (where they are and their skill set), and the organizational policies and procedures. TOP Management (technology, organization, and people) means I take all three into account as we build a workspace for a project. The idea of workspace is used broadly here, and will only get broader as time goes on.

The tricky part is how the rest of the world views “workspace.”

I’ve asked undergrad students if they use Facebook in support of homework or projects. The blank stares were interesting. I think the Doc.com/FB integration may change things. Not sure if students will like the work/social crossover, but I expect it will be a benefit in giving them a better space in which to work. No more missing the revision request because you’re on Facebook, it will find you there.

What about our corporate workspace? Many companies block Facebook and other social media sites. Rumor has that some even block sites that provide the option to use Facebook Connect as a logon – whether or not the user tries to use Facebook Connect. How do we, can we, separate a communication platform from its social uses? Consider this:

Play at work is substantively interesting in its own right. It also has obvious management implications. Some organizations prohibit employees from using electronic mail for “nonwork purposes,” presumably because such uses would consume network resources such as disk space and would interfere with peoples’ work activities. Conceivably extracurricular electronic groups might distract employees from their jobs and thereby reduce both the quality of their work and their affiliation with the organization. Alternatively such groups could ultimately increase the quality of work through providing new information resources and increase affiliation with the organization through providing new opportunities for employees to discover things they have in common with other employees. (Finholt & Sproull, 1990, pdf)

Yes, we’ve been working on these issues for over 20 years. It’s not an issue of email, Facebook, or whatever comes next, but rather how people and organizations design their workspace and work process either behind walls (physical or metaphorical) or not. The most powerful organizations will use all the tools at their disposal and they will help employees understand how to be productive – wherever they are and with whatever tools they have. Perhaps we need to demonstrate our systems savvy and systems responsibility to be earn this flexibility? Suggestions or examples of how to do this?

I had the great pleasure of meeting Ben Kepes to talk about systems savvy – peoples’ capability for seeing and weaving together technical and organizational opportunities. This was a perfect first meeting: quick understanding of the basics and then exciting new extensions as we talked about how people in different roles may have very different forms of savvy, and the impact this can have in the organization.

Ben is the principal and founder of Diversity Analysis, a consulting company helping companies work with the cloud and business strategy. He works as an industry analyst, consultant, and journalist. I had seen Ben’s Change the System, Not the Technology post and was thrilled to see he was in San Francisco for SuiteCloud2010. A few emails and tweets later, we were talking in the lobby of his hotel.

I asked Ben about his experience with technology, organizations, and people; how these three dimensions are woven together in organizational settings. He talked about the common problem of an organization trying to implement “some whiz bang technology, but it doesn’t work, or the culture doesn’t accept it.” We’ve all seen this silver bullet approach and know it doesn’t work.

Our conversation turned to how the situation could be improved. Ben gave me an example that made a lightbulb go off:

One of my businesses is a manufacturing company. White collar and blue collar. Slowly we’ve been implementing some collaboration technology. Really simple tools: email, calendar, manufacturing planning. It’s interesting to watch our facility managers (blue collar) grasp the stuff. The technology doesn’t work the way they think.

My initial interpretation of Ben’s comment was that the technology doesn’t work the way the blue collar folks think it does, versus, what Ben was actually saying, that the particular technology doesn’t work the way the blue collar folks think! The mental models held by people in the two roles are different. One is not better or more sophisticated than the other, but they are different.

White collar [management] deploys a tool that they [believe] is entirely obvious. Unfortunately that’s not the way it works for the [blue collar] workers. Difficulty [for the people supporting the implementation] — is there is a blanacing act. To a certain extent the blue collar folks need to use the tools, but you have to balance between requiring them to use and the underlying the cultural aspects.

I asked what would happen if the implementation support team didn’t understand this balancing act: “Huge disconnect, blue collar workers would feel alienated; people deploying the tools, really concerned.” The problems could span the organization even to disenfranchising the people making the purchasing decisions as they see the investment causing conflict.

Ben suggests two solutions:

1. Focus groups — though groupthink could be a problem if the focus groups give the answers that they think you want to hear.
2. Better is to build transorganization groups from lots of different departments from the beginning. “You need some idea about the problem we’re trying to solve. We’re trying to ensure that communication and collaboration can happen across disparate geographical teams. Let’s get them in a room and watch them work toward the goal. Goal driven rather than tool.”

Version 2 seems to me to highlight an understanding that the members of the different departments and organizational roles (blue collar/white collar) will have different ways of understanding the technology tools and organizational practices in play. How these groups think differs by their context and goals. By working together on the task the teams can learn who knows what, learn who needs to know what, and learn how to coordinate in the given setting, with the given tools. (Experts on groups would call this a great way of developing transactive memory, a valuable group capability.)

The different roles have different types of savvy, ways of thinking, that lead them to these different perspectives. Their practical understanding, their wisdom, is set in different contexts. Even if they all have systems savvy around the connections between technology and organizational practice, their systems savvy will be set in their unique context. Only by working together to create a common context, as Ben suggests in the transorganizational group approach, can they gain value from their diverse perspectives and build a system of technology tools and organizational practices that adds value for all.

I haven’t talked about the importance of context in systems savvy and I thank Ben for this enlightening example. I expect to push on this idea more with a focus on how to integrate high, but different, systems savvy capabilities. Looking forward to Ben’s insights on this and other topics.

In July of 2008 I wrote a post called Kill Email, Move to a Platform of Pages and Applications/Widgets. A lot has happened since then. I’ve had the opportunity to offer a seminar with Socialtext’s Scott Schnaars about gaining value from communication and collaboration tools (we were kinder and “put email in its place” rather than trying to kill it in public) and the collaboration offerings, for the most part, keep getting better. I think it’s time to revisit the issues in light of these changes, and in light of peoples’ experience with reducing their reliance on email.

Gary Orenstein’s recent post, The Cloud Collaboration Wars Ramp Up, sets the stage:

Cloud collaboration has now expanded beyond the core of e-mail communications to include social networking, group content creation and management, presentation sharing, project management, integrated voice and video, calendaring, scheduling and more. Let’s take a look at the big players and other possible entrants….

Luis Suarez, an IBMer who has worked for two years to create a “world without email,” shows us how it can be done. Luis has a real job, at a real company, and yet has gotten his email traffic down to 14 per week! He does it by being an evangelist for collaboration and knowledge management (I think that actually is his job) and helping people find better ways to work. No, this isn’t always easy for him, but it does seem to be working and his following grows.

Jeremy Sluyters, Director of Business and Collaboration Systems at JMP Engineering Inc, also gives us a real-world window into how each of us can can play a role in work transformation. From his blog:

I was onsite with a customer making some changes to their production system, and I was trying to figure out how to get a “program running” status from a robot, and pass it to a usable input on my controller. I posted this question on www.controlsoverload.com, a site I have recently started for the controls and automation community. Since this site is just starting out, I also emailed a couple people that I knew would know the answer, and included a link to the question. And I knew who could help me because I have been in this business for a long time – how many times do you know exactly who to ask to get an answer?

The next morning I had two answers to my question, and was able to map the status from the robot to the controller. Yes email would have worked just fine, but now this question and answer is alive and well in the cloud, and one day if you ask Google about monitoring the program running status of a Fanuc robot, you might just get that answer. By the way, at the time I asked Google the same question and did not get anything close to the answer. If you ask now, Google will give you the right answer!

For all my efforts to shift to a world of collaboration platforms, I still dealt with 13 emails in the first hour of my day. Four of them were signals (as per Andy McAfee’s SLATES acronym for Enterprise 2.0 technologies) — these let me know about changes that had been made on a wiki, and that a stock price had moved. Signals emails are good. As long as email is part of work, it serves as a great dashboard for tracking signals that can trigger your attention to particular collaboration platforms to do the actual work. Two other emails were short coordination questions that would have been great for Twitter (if Twitter had an easy way to direct message multiple people). The other five were interesting as they were from a group where we’ve actually tried to find a way to use a collaboration platform and failed. This is a cross-organization, cross-interest, cross-level of technical experience project with shifting membership. We’ve stuck with the lowest common denominator (for now!) and I dutifully cut and paste the info into a wiki.

The idea is that email is not for doing work (see Sluyters’ example above regarding the value-add if the work is done within the community’s platform). Email is good for signals (especially automated ones). Email is good for initial contacts — though often those emails end up failing as they are trapped by spam filters. Email may even be good for mass communication across multiple communities, but wouldn’t it be better if we just cross-posted the information to the communities’ sites?

My current strategy is to be open with project collaborators about my preference for working via collaboration platforms. I strive to use my systems savvy and explicitly consider the technical and organizational realities with each group. I’ve sent emails discussing alternative forms of communication to my University President and have had thoughtful conversations with his communications director about our students’ work settings and whether or not we are effectively preparing them given how workflow is managed on campus. I tend to take the initiative and simply set up a project site when asked to participate in something new. I can’t say that I’m always successful in shifting the project work to the site, but I hope that by raising awareness I at least bring us one step closer to more effective and efficient communication and workflow.

One project at a time…