Technology and Organizations

This is a continued response to my infrastructure audit: What activities does an innovation infrastructure for open innovation need to support? My prior short answer was that “innovation infrastructure must keep the project’s top goals… top of mind…” Here I provide the promised longer answer and point to both team and organizational activities. For the organizational activities, I focus on the new book, Robert’s Rules of Innovation.

Team Activities:

Gibson and Gibbs give us a summary of the innovation activities needed by innovation teams. They note:

The ability of teams to innovate depends on how well they generate, import, share, interpret, and apply technological and market knowledge, particularly of local markets, economies, and customers. That knowledge is a combination of information, experience, context, interpretation, and reflection (Davenport, De Long, and Beers, 1998). It must be openly shared across contexts through relationships and networks, and there must be confidence in the value of that knowledge for achieving the objectives of the collaboration (Kanter, 1988). Once these requirements have been met, innovation involves dissemination and application of the knowledge, including combining and integrating it to develop novel insights, solutions, processes, or products (Obstfeld, 2005).

Applying the above to an innovation infrastructure suggests that we need to apply systems savvy and weave together the technology, organizational practice, and human motivations. We need systems that allow for the wide part of the innovation funnel: a wide and diverse set of information ideas. At the same time, we need systems that then allow the innovation project to be effectively and efficiently managed. I suspect that a project dashboard (next post) that shows both current project status and has a variety of news and discussion streams is one way to both keep project goals in mind and support the wider ideation activities.

Organizational Activities:

Robert Brands (with Martin Kleinman) recently released Robert’s Rules of Innovation: A 10-Step Program for Corporate Survival. I’ve been following Robert (here and here) for a while. Now I have a one-stop opportunity for his insights. Speaking at the organization level (with specifics also related to teams), he notes the following as “the imperatives to deliver profitable growth through innovation”:

Robert’s Rules of Innovation helps you develop both energy and structure around organizational innovation activities. The presentation provides a broad set of examples: from how to create an innovation culture to a clear discussion of intellectual property issues. I was especially happy to see a discussion around the evidenced based management of innovation:

Observation, measurement, and tracking of NPD results are essential to optimal ROI. Create your baselines first, with initial observations and measurements. Then capture the time to each gate, the time spent inside each gate, and so on. (p. 36)

Building on the idea of a dashboard within our innovation infrastructure, we need ways to track our experiments. Brands asks, “Do you have a set of metrics to serve as an innovation dashboard and track your innovation activities?” (p. 43). These metrics may be general (applicable to all innovation efforts — participate in the Innovation Coach survey here), or they may be specific to the particular effort. We also have to be aware that how we expect an innovation to play out may not be what happens in the wild — thus our observations need to be openended.

Have you had success, or even surprise, in tracking an innovation? What did you do that put you in a position for effective tracking? Do you know of any summaries of surprising innovation outcomes? Comments and links appreciated below.

Tweet This Post

In August 2009 Stewart Mader wrote a blog post focused on expanding our thinking of enterprise wikis beyond wikipedia-style documents. As I think about many of the E2.0 projects my organizational design students are taking on this quarter, I’d like to share Stewart’s 8 ideas here and see if we can’t add a couple.

Here are Stewart’s 8 (please see his full post for his explanations. Comments and links here are my own):

• 1. Meeting Agendas
• 2. Meeting Minutes & Action Items
• 3. Project Management

These top three are my top three as well. A wiki is “a website that allows the easy creation and editing of any number of interlinked web pages via a web browser….” They are my top three partially because the use is so straight-forward. We all know what the task is; this is just expansion of how the task gets done. They are also my top three because they are so important — and yet often overlooked in organizational practice. No agenda means that it’s impossible to come prepared to the meeting, yet agendas are left out every day. A wiki approach is emergent and social (and thus at the heart of Enterprise 2.0) and intertwines a simple technology into the critical organizational practices of good project management. Please see an earlier post for some basic examples.

• 4. Gather Input — Keep in mind that wikis are all editable websites/documents. This means Google Docs and Google Spreadsheets are in the mix (as well as other web-based document tools provided by other companies). I see at least two dimensions here: gathering input from a group of people (Stewart’s focus) and gathering information from yourself. Regarding the latter, I recently avoiding paying over $100 for an iPhone/on-line logbook capability by building it myself using Google Forms. Any basic survey can be built in Forms and then the form tool deposits the information directly into the on-line spreadsheet (also available off-line if you are using Google Gears.) The iPhone/smartphone capability comes from saving the survey’s web address as an icon on the screen.
• 5. Build Documentation -- I see this one as being useful both in terms of meeting output and in terms of all written work-products. I have moved from being an evangelist of wikis as how to run group writing efforts to being not so passively aggressive about wiki-based group writing as my only approach. I’ll be the first to acknowledge that you often eventually have to move the document into a real word processor for final formatting -- but I bet this won’t always be the case (and I suspect isn’t the case for purpose-built tools like ZOHO Writer -- hmmm. I’ll have to check out the Microsoft Word support…). I’ll also be first to acknowledge that you and your co-authoring team have to become comfortable with sharing “alpha drafts.”
• 6. Assemble and Reuse Information -- Link away! Not only can you cut and paste easily if you have access to all of your organization’s documents — but you can also help your documents live through links. Linking (rather than cutting and pasting) means that the material stays in sync.
• 7. Employee Handbook -- I was in a waiting room for a while Sunday night and happened to sit by a TV playing Undercover Boss — Waste Management. In the episode, the President & COO of Waste Management, Larry O’Donnell, anonymously takes on a variety of entry-level jobs within his company. This is an eye-opening experience for him and he seeks ways to reduce some of the frustrations he finds in the field. What if he opened the Employee Handbook up as a wiki, at least for comments (and maybe they do…)? Is there risk for misuse? Sure there is a risk, but according to Andrew McAfee (Chapter 6), the incidence of bad behavior on wikis and blogs seems to be inconsequential — these are typically not anonymous.
• 8. Knowledge Base — Stewart distinguishes this use from Documentation in that he faces it externally. He gives an example of a moderated (the company checks changes before they are added) wiki that allows customers to see the help wiki and make contributions.

So, how many items can we add to Stewart’s list? I suspect the number will become quite large as more and more of our work moves to the web, but for a start:

• 9. Make Decisions -- Not only can we gather input, but we can make the decision via the wiki as well. The result is that we can always go back and track how we got to the decision we made.

You knew I’d get to ten…

• 10. Work — Over the last year, my bias has become wiki unless proven otherwise. My documents are in the cloud and I share files or full folders as default. As a result I am pushed to practice TOP Management (weaving together technology, organizations, people) as I think about the tools I have available, the practices the working group should focus on, and the skill set of the people in the group (see discussion of how to do a team audit here). Ideally our transfer of material to the cloud/wiki/team portal occurs passively — as part of just doing the task — rather than as a separate action. For example, if we are communicating via email with attachments of our working document, we have to actively save and sync our work. If we instead just work via the cloud/wiki/team portal the work and conversation are already there — passively with no extra effort.

What I missed?

Common Craft’s Explanation of Cloud Computing:

Tweet This Post

We all understand that talent, especially software talent, is spread world-wide. We all also have a basic understanding that the virtual work form required to harness this global talent is different from face to face work — even with all our fancy technologies and increased experience at working “together apart.” Successful virtual work requires explicit consideration of the technology tools, the organizational practices, and the people involved — T-O-P Management. For Stuart DeSpain of Microsoft, the intertwining is very explicit in the form of: One Team, Many Places.

Stuart is the Principal Program Manager Lead in the Excel for the Mac group at Microsoft. Suzanne Kirkpatrick had referred me to Stuart as “one of the pioneers” when I asked her if she knew of people who practiced TOP Management. I knew Suzanne was right the minute I got on the call with Stuart.

Stuart, like most of the people I talk to who practice TOP Management, has a strong dose of systems savvy. He is able to see all three categories of his technology, organization, and people options, and then can envision how these options could be intertwined for a strong result. But where did he get this system savvy and how did he come to weave the pieces together in practice?

I posed the following to Stuart:
“It would help if you could tell me a story or relate to me an experience you have had in which you learned an important lesson about technology, organizations, and people. Something where you learned something that you wouldn’t find in a book.”

His initial response was that he didn’t think he’d approached the issues systematically. But as he got into his example — the expansion of the Excel for the Mac group — I could see both an explicitness and intentionality around how he thought about the group’s overall design and practice:

[Virtual work is] part of our DNA: For fifteen years the Mac business unit has spanned two locations: Redmond [Microsoft HQ in Washington state] and Silicon Valley [California]. This was not so much a plan, it’s just how it happened. So we’ve built up a lot of comfort with the phone and video conferencing. That [background] helped us think about building additional capacity abroad….

We decided that one of the big centers of talent was Beijing. Great graduates, eager people…. our challenge was to set it up right. I’ve observed that when engineering campuses aren’t located across the street from each other that there’s a desire to treat the [away] campuses as vendors: give them specific tasks, throw them over the wall… “call us if there is an emergency, otherwise, call us when it’s done.”

I didn’t think that a “vendor” approach would work well for us. We really couldn’t just box up Excel as it’s an integral part of a system; it’s part of Office. We wanted to do it right. Initially leaders sat down as a group and set out clear a vision statement as collective: One Team, Many Places. We use this phrase all the time: presentations, meetings… hammering that that is what we are. Not Excel in Redmond and Excel in Beijing. An Excel team across many campuses.

Catchy phrase and the key to effective distributed development success. The phrase acknowledges the role of people in TOP Management. As people we focus on people who are close to us. We have to work, be intentional, to focus on people who are afar.

But Stuart and the Excel team didn’t only think about the social psychology of the situation. They also carefully considered the role of technology tools and organizational practice.

We worked hard on how to translate that high level goal into very specific unifying actions. At every stage — One Team Many Places. How are we going to deliver that no matter the situation? Travel, teleconferences, other tools… We settled on the idea of summits. The idea is to treat it like a trade show. Every six months one side or other would fly — spend a week, like a family reunion, catching up. If there were presentations that one side or other didn’t get to see, we’d show them. We’re walking into our 4th summit next week.

Even more impactful are the one on one or small group interactions. These lead me to see a lot of benefit to sharing a meal or drink or social experience. Summits included a lot of activity around tech problems, but evening social experiences bond the team so they think of themselves as a single tribe. Our pulse for summits is about every six months. But in a team located in the same hallway you’d see people once a week or daily….

To manage the time between the summits they focus on individual travel from both sides and high interaction teleconferencing. Even the teleconferencing is intentional, not just casual. The team is well aware of how one side could dominate the conversation and that there may be compromises due to bandwidth issues, configuration, the need to use the screen to show software features rather than faces, etc. There can be a heavy premium to using video, but they think it’s worth it and design practices to manage the complexity:

We made it clear that it’s worth 15 minutes of set up if that’s what it takes. We have a note taker who scribes the meeting and projects the notes as subtitling. In addition we have an instant messaging conduit — if someone can’t interrupt another way, they can use that.

The note taking and additional instant messaging conduit are their “fall backs.” The team is well aware of the limitations of video conferencing and actively manages the process to get keep the best “pulse” for the team no matter what the communication mode. They actively weave together each of the technology, organization, and people dimensions of their work and interaction.

I asked Stuart how he knew that they needed to focus on One Team, Many Places. Basically, where did he get this systems savvy? A critical experience seems to be the key, as it was for Earl Lawrence, Eugene Lee, and Suzanne Kirkpatrick. Ten years ago he’d worked on a team where his group was in the role of being the smaller, afar portion of a virtual project. The “center of decision” was not at his site. Objectives would be set, then change, then change again. “We were miserable. We were disconnected from our own fate.”

Hindsight has been valuable. On reflection Stuart says he came to understand that the partner company was great, but didn’t yet understand how to work with remote campuses. What his local group thought was an issue of lack of communication given their remote location really had more to do with the youth of the partner firm. They were still in a growth mode that meant objectives would change:

It had nothing to do with geography, just their being a new company. If we’d just talked about it, if we’d gone out for drinks during a visit and just talked about the mission. It we’d had the single conversation it would have changed the dynamic.

So, Stuart says he is always aware of that experience and is sensitive to the fact that the larger portion of the team will always be perceived as “where the good stuff happens,” unless there is intentional effort to be One Team, Many Places.

Tweet This Post

Tuesday morning I’m representing the sociotechnical view on a panel focused on virtual work. This panel is part of the 2009 Academy of Management meetings in Chicago and will be attended by both novice and expert virtual work researchers. The goal of the panel is to help the group think about important next steps for research and practice. My goal is to raise the issue of individual responsibility in work design.

To prepare for this session I went back to early sociotechnical discussions of work design. In 1951 Trist and Bamforth used the “longwall method of coal-getting” as a backdrop to call for the joint optimization of social (structure & people) and technical (task and technology) systems in work. They call for “those in authority” to take task and social structures into account. In 1977 Bostrom and Heinen (here and here presented a clear sociotechnical approach to the design and implementation of information systems. They speak of the role of the “steering committee” in the integration of social and technical systems for work. In 2008 Chen and Nath note that “Organizations need to understand” the interrelated roles of the social and technical systems.

These approaches highlight the role management plays in work design. In my presentation I’m going to highlight the role the individual can play in work design. My colleagues and I acknowledged the role of the individual in our paper Information Technology and the Changing Fabric of Organization – but in Tuesday’s talk I’m going to make the individual the focus. This is a chance to bring my perspective of “all of us as systems designers” into a formal research setting. My past blog discussions have touched on ideas of owning your own tools, the extent to which individuals have the systems savvy to see both organizational and technical opportunities, how individuals can get more from learning by understanding their own learning styles. The point is that many of us have much more control over our own work design (thanks to increased flexibility in both technologies and work practices), yet little sociotechnical work design research has looked at how individuals can be sociotechnical designers for their own work. (Parker, Wall, & Cordery, 2001, note that work design models should include how individuals might mold the job, but do not point to particular research findings.)

As managers we are responsible for providing our employees with the skills to do their jobs. I’m going to argue Tuesday that, especially in the world of virtual work, managers are responsible for providing employees with the skills to design their jobs as well. Anyone care to start the discussion a couple days early?

Tweet This Post

Yesterday was Reid-Hillview Airport Community Day. One of the activities was a tour of the Control Tower. Great experience. Thank you to Vincent and Spencer for taking the time to explain the process that keeps hundreds of flights going in and out safely. Thank you to the rest of the team for letting us observe you at work.

I was surprised by how physical the process is, versus my high tech expectations. Yes, they have access to radar and a huge portion of the work involves radio communication with the pilots going in and out of the airport. But they also make heavy use of those big windows and a unique physical tracking system.

They track planes by type, tail number, and request for inbound or outbound route — by writing the information on plastic “pucks” with a grease pencil, and then physically sorting that puck onto the taxi and runway slots. We weren’t allowed to take pictures, so I’m showing a similar process below using wooden blocks.

When I asked about the process, using the plastic pucks versus keeping track on a computer, I was told that sometimes “elegant is best.” Great point! The solution is elegant in that the physical blocks trigger sensemaking (in my words) more than a screen version might. They can push a puck slightly out of its track to highlight that more action is necessary. All the members of the team can immediately step in to provide relief given their common understanding of the system. Elegant, green (no need for power or paper), easily visible to all in the room — good for team visualization.

Beautiful approach to a complex problem. Sometimes systems savvy means using elegant, but less high tech systems. Comments appreciated describing other examples.

Tweet This Post