During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
Even if our executive's assumptions about how the military operated were correct, that formula might spell doom for the project. What happens when the general in charge moves on to another post? No assignment is forever, and the next officer in charge might have a far lower opinion of our product. The crisis might happen earlier, if the current general got impatient with the progress of the project. Fearful of these potential outcomes, this executive bet the entire project on maintaining good relations with the general and his immediate subordinates, including the irascible project lead, whose view of technology adoption was summarized in his comment during a meeting with us: "Users are stupid, so they don't know what they want."
Who's responsible for adoption?
Technology adoption is a tricky thing. The authors of a recent book on innovation, The Innovator's Way, make a strong case that trust is a critical ingredient. We all have reason to be skeptical, after enduring technology that didn't really help us, for all kinds of reasons (clunky design, unintended consequences, etc.). Therefore, the next person who tells us what hardware or software we should be using must earn our trust, not simply tell us what to do.
Unfortunately, here's where the innovation process, in practice, get a bit murky. Who's responsible for adoption? The business analyst? The project manager? The department head? The IT manager? Adoption sometimes winds up being everyone's responsibility, which is another way of saying that it's the responsibility of no one in particular. In these cases, organizations may look to product managers (PMs) as a new kind of adoption expert, focused on the connection between business outcomes and technology development in a way that these other roles are not. (There are other reasons for bringing in product management, but that's a topic for another post.)
But it's not enough to assign "change agent" to someone's job description. No one is born with an innate knowledge of the steps needed to make innovation successful or a flair for getting people to trust you. It takes time to learn the tricks of the innovation trade and even more time to figure out how to put them into practice in a specific organization. While the business section of your local bookstore might contain a few good books on this topic, far too many of these would-be primers on innovation overlook a much bigger literature that already exists. Some of it is directly applicable to innovation; the rest touches on some of the individual elements of innovation, such as the difference between power and authority. Or, to put it another way, if you're reading one of these books and the only authors they cite are Peter Drucker, Jim Collins, and Malcolm Gladwell, you're missing out on a lot of useful insights.
And why should I listen to you?
Take, for example, the "soft launch" of new features or applications. I've known some university IT departments that are especially good at this technique, because (1) they hire really good people, (2) summer and winter breaks provide a window of opportunity for pre-launch testing and deployment, and (3) they've learned how to make IT services appealing to a diverse audience of faculty, staff, and students. As a result, when they put something new on the university portal, they can bank on the trust they've earned among potential users.
No one is obliged to try the soft launch. Power is not the instrument through which adoption will happen. Legitimacy is the tool on which the IT department depends for the soft launch to work at all. When switching to a hard launch, authority, built on a foundation of legitimacy, is what gets people through potentially disruptive changes that they might otherwise resist.
Authority is hardly a new topic. It's at least as old as Machiavelli and at least as famous as the Milgram experiment. The question of why someone should listen to suggestions or directives from a person with no formal power, just because that person has a title, a uniform, or a clipboard, has inspired mountains of social science research. These observations have a clarity about the difference between power and authority that even some of the most popular management primers lack. That clarity is critical for anyone who wants to exercise either power or authority during the innovation process. Just as the generals, or executives, and IT managers who have cultivated all the habits of successful people but still failed to compel anyone to use the technology they're pushing.