The question of the week from non-DRG colleagues in BlackBerry as well as numerous new friends in the mobile industry is how did we launch BlackBerry 10 with the largest catalog of apps for a V1  platform?  Something no one knows is we also grew the *old* BlackBerryOS catalog 300% during the same time period.  It’s worth noting I don’t get this question from old Microsoft friends and you begin to realize the answer to this question.  Talk with any former ‘Softie of a certain era, and they’ll tell you about the “Evangelism Playbook”.  No, it’s not a real book, it’s a hard won set of strategy and tactics passed along in the organization.

There are now great blogs and websites like the “Developer Evangelism” site (Well done Chris Heilman! @codepo8) that cover the tactics of Evangelism, like use of social media tools, working barups & meetups and truth be told this constitutes a significant portion of the old  MS “playbook”.  However, with multiple OS platforms, PCs and different device offerings, server apps platforms, cloud app platforms… how do you cut through the noise and reach the developers that will take adoption of your platform or service to the next level?

In my experience fundamentally what makes an Evangelism team succeed or fail is not the number of hackathons or meetups attended, it’s building a culture of success  through empowerment.  Ok, I know this sounds a bit too Tony Robbins-esque for comfort, but I’ll explain.

Assuming you’re starting with the same set of tools, budget, staffing as the start up in your category located down the 101 from you, how do you differentiate?  In a funny way, it’s applying agile methodology to Evangelism.  View each campaign as a sprint, debrief & debug based on results, recalibrate and relaunch.  The “scrum” is really ideation, finding new solutions as a team, but, it’s always up to the evangelist on point to make the call.  In this case, each evangelist must control his or her fate via innovating fast, without fear of failure.  Simple to say, hard to do.   There was a period of time at MS where evangelism was managed very prescriptively, evangelists were tracked by a spreadsheet full of metrics, and surprise, MS lost enormous developer intent scoring during this period of time.  Folks on my teams will hear me say things like “always get better”, wow, what an insight Bob.  I’m really saying, “go try” and I’ve got your back.

For me this best practice stems from an old Microsoft product team project “post mortem”.  Before any product team launched design on their next release, Engineering, Test, Program Management, Marketing and Product Support would sit down and discuss what went well, what didn’t and together as a team they decided ultimately what to do next.  Takeaways were assigned to individual owners who were empowered to make decisions for the team, not in a vacuum,  but it was first and foremost their decision.  This was the secret of old Microsoft, empowered teams.

Does this work?  Yes.  Over the last year there are innumerable examples of the BlackBerry Developer Relations team taking an industry wide tool or tactic, and then quickly tweaking it to deliver unheard of results.  Very often the insight that changed everything didn’t come from the owner of the campaign, rather, another team member who felt empowered to provide the feedback and then worked with the owner to make the relaunched campaign a success.

Does this sound like your team?   If so, congratulations and I look forward to seeing your great ideas out in the Ecosystem.

NEW: Alec discusses reinventing Porting Labs as an example of rapid innovation: