Thought Leadership: Measuring Our Success

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.
Read more

Thought Leadership: Outline Ready For Comments

For those of you who have been following our thought leadership research project, we're now in the final stages of this project. I've posted the proposed outline here for your comments. If you're not familiar with this project, here's the development document that summarizes the topic, working hypothesis, and research method. Also worth reading is this blog post, which explains why we're using this piece of research to pilot an Agile, community-based approach.

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.

The Paranoid Style Of Developer Support

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"

Read more