Knowledge Transfer vs. Support

I caught a bit of flak over my last blog post, suggesting that Google’s relationship to developers amounts to “benign neglect”. As I noted, individuals at Google, including everyone I have met or otherwise interacted with from Developer Relations, are exemplary.

However, I was not especially clear in that post as to what I thought constituted the “benign neglect”, and I think I understand where the discrepancy lies between my expectations and the expectations of others. It is a question of knowledge transfer vs. support.

The Developer Relations group for Android does a number of things to help the rank-and-file developer, including posts on the Android Developers blog, posts on personal Google+ accounts, and various bits of sample code (hats off to Roman Nurik, in particular, for the latter). They also contribute to the SDK documentation (e.g., the Android Training series of pages), speak at events (from Google I|O down to smaller affairs), and so on.

This is all wonderful, and I am grateful for every byte of it.

It is knowledge transfer, one to many. In effect, it is all part of the overall Android documentation, just housed in a disparate set of locations.

However, knowledge transfer is not support.

Support is getting individual answers for individual questions, as those questions arise. Support is a fairly commonplace need with technical products, and so having means of asking questions and getting answers is pretty much expected for lots of products, including those designed to be used by developers.

Occasionally, the two constructs overlap. For example, Developer Relations has been holding various Google+ Hangouts. On the surface, they represent support, insofar as they take questions from developers and answer them. However, they only have time for a couple of dozen questions per week across the hangouts — StackOverflow gets that many questions in a couple of hours of a typical month. Hence, the value of the hangouts is more in knowledge distribution, as many more people can watch (or listen to the podcast editions). Any support structure that results in publicly visible answers has a knowledge transfer component, and the knowledge transfer may be more valuable than the support overall.

The question then is one of scale.

Presumably, Developer Relations focuses on knowledge transfer because there is no way they could hope to handle all incoming Android development questions while serving in a front-line support role. StackOverflow collects over 10,000 questions per month, and there are countless thousands more in other support venues like the android-developers Google Group. Even if they add some staff, keeping up with questions would be a challenge and would hamper their ability to due pure knowledge transfer (e.g., sample code) due to lack of time.

That being said, we have a reasonable number of non-Google employees fielding questions on StackOverflow and the other venues. However, to some extent, we are the blind leading the blind. We can only answer questions based upon our experience and what we have learned from existing knowledge distribution channels. When those trying to help do not know the answer, or do not understand the question, at the moment, we are in trouble.

It would be awesome if there were some way to turn to Google for some questions in a structured, measured fashion. For example:

• Use the StackOverflow bounty system as a means of indicating questions needing answers, with Google staff tackling the N highest- bounty questions per week

• Have a means for designated community members to be able to “escalate” questions, with Google staff serving in a second-line support role

• Offer a paid support service, where spending some modest sum can “escalate” a question on StackOverflow or an issue on the issue tracker or whatever

And, of course, there are any number of other ways that Developer Relations might be able to help more “at scale” beyond these ideas, not to mention other groups that have “at scale” issues (e.g., Play Store developer support).

It is entirely possible that some of this stuff is happening in an unofficial way (e.g., if you comment on a G+ post with a link to a StackOverflow question, you might get lucky and get Google input). Unofficial is nice, but tough to prove, tough to scale, and access-controlled (e.g., must be a Google+ member, must attend the right events to be able to ask questions). It is also possible that Developer Relations is doing various forms of support in ways that I do not recognize, for one reason or another, and for that I apologize.

Finally, Google can do whatever Google wants, because to a large extent, Google won. Android has certainly succeeded beyond any realistic hopes that I have had, so they clearly do not need to do anything more than what they have done to date.

My point in the previous blog post — the lesson for newcomer mobile OSes to consider — is in figuring out how they are going to scale their support. How will, say, Firefox Mobile OS or Windows Phone support 100 developers? 10,000? 1,000,000? Google’s approaches worked for Google, insofar as Android has been a raging success. However, it is risky to assume that a development community can be largely self-sufficient at scale for getting questions answered, without some structured means of getting expert advice where needed.