Create a dual-mode organization to explore options

What is the next new technology that might change how we work? To some, this may seem like a simple question, but actually, it’s very difficult to predict how outside forces may shift the technology landscape and dramatically change how we work. You might see general trends in technology, especially around major players, but you cannot predict the next Big Thing that changes everything. Instead of trying to predict the future, you should instead build a flexible framework to prepare for it.

My past example

In the late 1990s, I joined the then-new Web Development team at the University of Minnesota. The Web was still new, and our team did not want to be burdened by old processes. Developers frequently incorporated new technology in their projects and adopted the latest technology trends. While we were on the cutting edge of technology, we soon realized that we implemented some of our technology without fully understanding how it worked or the benefits for using it—or the difficulties of long-term support.

We needed to do better investigation into new technology. I wrote a proposal to establish a new sub-group within the Web Development team, called Web Advanced Labs, to examine new technology. I proposed to lead this effort and identified two other team members who were most interested in exploring new technology. These members also understood the need to do a proper examination of future technology.

We realized that to be nimble, we couldn’t be bogged down with a heavy process. Yet we needed a framework to capture our experiments and results in a way that would be useful to others.

A flexible framework

Working together, we compromised on how much documentation to add and created short documents that tracked progress and explained what we learned. We created a five-step process to examine new technology, with each step a separate document:

1. Introduction and Theory

Before starting any experiment, we documented the goals of our experiment. What were we trying to accomplish? What technology did we want to research? How will the new technology be helpful?

2. Background Information and Possible Options

Having defined the research, our next step was to discover what information we could find about the new technology. What options exist with the technology? For example, have others already created a library or other sample code that we could use? What are the pros and cons of each option?

3. Design of One Possible Solution

After we explored several available options, we crafted a simple prototype to exercise the new technology. Avoid a complicated prototype. Seek the valuable insights in an example program.

4. Experiment

By learning from the prototype, we were able to build a larger functional demonstration. This was usually limited to something that exercised just the new technology, rather than fully integrating the new technology into an existing project. The experiment typically demonstrated several options available in the technology, such as different ways to process an XML document, or parsing different XML documents.

5. Lessons Learned and Recommendations

Finally, we documented the key topics and lessons learned from the research topic. This document introduced the new technology and provided an overview of recommended best practices and included sample code to demonstrate how the new technology could be applied to existing projects. Other team members could reference this document as a starting point to integrate the new technology in their own projects.

Dual-mode organizations

The Web Advanced Labs project was one example of converting an organization to operate in a dual-mode: one team to work according to a standard process and another team to explore new solutions. This duality is an important feature of flexible IT organizations of the future: One part of your group should move at “enterprise systems” speed: slow and steady to support your enterprise systems well. Meanwhile, another part of the group operates at a faster pace,  explores new technology, and responds nimbly to new challenges.

Some organizations allow staff to examine new concepts as part of their standard work week. Google is famous for their “twenty percent time” policy where engineers can use twenty percent of work time to work on whatever they please. Google’s Gmail, Google Maps, and Google News have their origins in these side projects. If Google did not have this policy, Gmail might never have been created, and Google would simply be yet another web search company.

Minnesota-based multinational manufacturer 3M also has a similar policy to reserve part of an engineer’s work week to explore new ideas. This “twenty percent time” policy has provided the freedom for engineers to explore new methods and technologies, which later became new products. 3M’s Scotch Brand Tapes, Scotchgard Fabric Protector, automobile window treatment films, multi-layer optical films and silicon adhesive systems for trans-dermal drug delivery can each trace their origins to “twenty percent time” projects.