Since there's no systematized, look-it-up-in-your-economics-textbook definition of thought leadership, people generally lapse into metaphor when they try to describe the concept. The language usually gets very Joseph Campbell-ish. Thought leaders might be visionaries, Delphic conduits into some shared future. Or, they might be heroic trailblazers, clearing a path into places that no one knew existed, or they were afraid to venture.
Our recent research into thought leadership points to a different metaphor. Thought leaders are not seers, like Cassandra or the Sibyl. They're closer to trailblazers or founders, like Romulus or (less mythologically) Alexander the Great. But even that's not exactly right, since thought leadership depends critically on communication. Alexander got a lot of good press; Cyrus the Great, the founder of the Achaemenid Persian Empire, got much less (at least in the West). As a result, people are still sifting through Alexander's career for nuggets about successful leadership. Cyrus the Great? Not so much.
Thought leaders are, to a big extent, more like Homer than the people whom Homer chronicled. They're good story-tellers, which demands far more than relating a collection of incidents.
Just ask anyone reading a success story on a tech vendor's web site.
The words of "War," Edwin Starr's 1969 Motown classic, began ringing in my head this morning. It was brought on by a Harvard Business Review blog post by Steve W. Martin, "Why Sales and Marketing Are at Odds — or Even War." Within tech vendors, sales and marketing teams often fail to communicate or align go-to-market strategies. Forrester's sales enablement visionary Scott Santucci discussed the different languages of sales and marketing in his blog over two years ago. As for my own experience with sales and marketing:
A few years ago, I sat with the chief marketing officer and chief sales officer of a Fortune 100 tech vendor. The conversation didn't focus on customer problems, which should be the starting point for sales enablement professionals. The conversation didn't focus on sales efficiency issues such as sales cycle duration or win rates, which should be critical imperatives for all sales and marketing professionals. Each of these executives controlled massive budgets but neither one sincerely trusted the other. Their words were about aligning sales and marketing programs, but the real conversation, when read between the lines, was about control, boundaries, and politics. They were at war!
Realistically, comments will have an impact on the final document if you post them by the end of the week. After that, I'll be writing the actual document.
Also worth mention: in drafting the outline, I realized that some of our earlier work on B2B evaluation, selection, and adoption is applicable here. Expect to see a cameo appearance from some of that interesting research in this document.
As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)
When it comes to home improvement, I'm barely competent. My biggest hurdle is ignorance: when I was growing up, no one in our family was a do-it-yourselfer. Unless I had the opportunity to watch the handyman, electrician, or plumber fixing a problem, and that person was patient enough to let me observe, I had zero experience with these tasks.
Fast forward to a couple of years ago, when I signed up for installing hardwood floors in our home. Friends had said that it wasn't as hard as it looked, and the staggering quotes from contractors provided the incentive for forging ahead, despite my ignorance.
After buying the tools and digesting the instructions, I started on the first room. My first attempt was a hilarious escapade, which resembled a horizontal variant of Jenga more than anything that you could describe as "home improvement." After taking a break for a few days, I figured out where the project had gone wrong, made adjustments, and finished the room.
You might be surprised to find out how worked up I can get about an issue like switching costs (a.k.a. lock-in). It's a question worthy of at least a little emotion, since it affects the fortunes of technology companies: Under what conditions would a customer switch to a different vendor for the same product or service?
The question has returned with a vengeance with the increased adoption of SaaS and PaaS technologies. Tech vendors are happy to use the cloud as an easy way to attract customers, as long as it doesn't turn into an equally easy way to lose customers.
What gets my dander up is the simplistic, puerile way in which people sometimes discuss this issue, particularly in regard to SaaS implementations. Here are a couple of examples.
Cost Of Switching
How do the switching costs of an on-demand solution compare to an on-premise alternative? Clearly, the cost of switching from an on-demand solution is not zero, and yet you still find in some discussions of SaaS the assumption that customers will leave willy-nilly. Nor is the cost of switching the same as an on-premise solution, but you'll find people speaking about the two as if they presented the same migration and implementation challenges.
As I said in my last blog post, we're looking for feedback on the questions we're asking about thought leadership in the technology industry. At the same time, we realized that it has been a while since we held an open house in Forrester's Foster City office. (If you're not aware, we did a few informal sessions for product managers and product marketers, to give people in that role an opportunity to talk amongst themselves about topics of interest, sprinkled with whatever useful information an analyst like myself can provide.) Suddenly, a spark leaped across the two neurons carrying these separate ideas.
We're now in Phase II of our first venture into Agile Research Development, an investigation of thought leadership in the technology industry. Phase II is when we start the actual primary research, and again, we're looking to the community for their help and guidance. The story so far:
Published the development document, which explains how we'll proceed. Supporting documents, such as this overview of Agile Research Development, are also part of the project dossier.
Incorporated feedback from the community into the development document. Many thanks to everyone who provided suggestions and criticisms of the original research plan, as described in the development document. In fact, if you haven't read the comments on the development document, I strongly recommend that you do. There are some real nuggets in there about a thought leadership, a topic of vital importance to tech vendors, their partners, and their customers.
How You Can Help
First, we need another round of review. This time, we're looking for your feedback on the interview guide. Are these the questions you want answered? Have we missed anything? I've annotated the interview guide to explain some of the reasoning behind the current draft, which is my way of getting the discussion going.
Today was our first official update to the research plan (a.k.a. the development document) for our project investigating thought leadership in the technology industry. A quick refresher: this particular piece of research is our first venture into Agile research development, which (1) applies Agile principles to our research, and (2) opens the project to the community to participate in the research process from start to finish. In other words, we're using the newly-launched Forrester Community as the forum where the voice of the customer will speak directly to us about our research as we're doing it.
You can see the current development document, including the updated text and the comments that inspired those changes, here. As promised, we're also maintaining a change log for tracking these changes over time. (The development document is also versioned, so we can look back on the history of edits through that mechanism, too.)