It was 1997 and the World Wide Web was catching on. I was a magazine editor in charge of a medical technology publication with a readership scattered across Latin America. Miller Freeman, our publishing house, was building simple home pages for the bigger magazines, but my tiny niche was not a priority.
There was no explicit rule about websites, however, so many of my colleagues and I were having fun exploring HTML on our own. I quickly became obsessed and, despite my boss’ insistence that the Internet was a low priority, had soon built a website, forum and the world’s first (as far as I know) online bilingual radiology glossary. Though—shockingly—my effort was passed over for recognition by the Nobel committee, the website lived on for another decade as I became editor in chief of Software Development magazine. There, we continued to evolve our Web presence, albeit under stricter IT guidelines.
The Web and Java were special cases of technology that were not only revolutionary, but also accessible to the masses. Could the iPhone or social media applications be today’s equivalent? Even if they are, in 2010, there is a daunting ecosystem of software, hardware, platforms, vertical domains and methodologies to choose from. While technology land grabs still occur, most organizations don’t face such dazzling options when it comes to making a major change. And employees are practically inured to novelty, now that it occurs 24/7. In the face of these challenges, how do you bring your team up to speed quickly, smoothly and cheaply?
Let them play with it: Autonomous motivation
Fostering change organically is an explicit strategy for some companies. Google is famous for letting its employees spend 20% of their time exploring technology or working on projects of their own design. The science of workplace motivation seems to support such an approach, too; some studies have found that creative solutions to problems actually decrease under external pressure such as deadlines, bonuses or major prizes. But allowing employees to simply explore often makes managers nervous.
“I worked for IBM Research in the 80s, and we were supposed to take some part of our time off for exploration,” said Salt Lake City-based software development author and methodologist Alistair Cockburn. “As far as I know, I was the only one who actually did it. My boss was totally terrified because 20% was being siphoned off into non-productive activity.
“You hear rumors of how Google works, but how they say they work and how they really work are two different things. The problem with this approach is how many people are really doing it and how much management nervousness they absorb in the process.”
For a more predictable result, Cockburn recommended giving developers a certain amount of free time to explore a specific technology, such as developing iPhone apps. The goal is for the effort to be distributed across your organization. “Have everybody go take two days a week, every Thursday and Friday, for the next month, and program whatever they want for an iPhone app. At the end of the month, you have a bunch of people talking about it—everyone is on the same topic,” he said.
If the budget is a concern, try making the exercise profitable to begin with. David Leigh-Fellows, Silicon Valley-based principal consultant at ThoughtWorks, described a client that required every new project in order to reapply for more funding at the end of three months. “But you had to have built a new variation on the business case. This mentality forced people to think, ‘How do we get into the market? This is what we’ve built and tested, we think it will give us this revenue, and we’re ready to launch.’ It worked beautifully.”