Now that we've posted the outline for our study of thought leadership in the technology industry, it's a good time to take stock of our success so far. It's important to start the retrospection process, even if we're not completely done with the project yet, because we're using this study to pilot a different way of doing research. As we said in the document explaining this approach, Agile Research Development, we set the following goals (shown in order of priority):

1. Ask the right questions.
2. Enhance the quality of the answers.
3. Maximize the voice of the customer.
4. Make adjustments quickly.
5. Be even more relevant to our clients.

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.)

"Follow The Money"

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.

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.
• Drafted the interview guide. We now have a list of questions that we'll ask the interviewees, including both vendors and 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.