Tag Archives for Management

Great Vision, Great Execution

I may be BlackBerry’s Evangelism Team’s Sensei, but I’m not the Sensei of all things smartphone or even mobile devices.  Lucky for me, I get to work every day with colleagues who literally invented the smartphone category.  For example, I just had dinner with colleagues from the Enterprise Products team at BlackBerry and gained insights about how the requirements of operating mobile devices connected to the Enterprise lead to what we think of as core BlackBerry strengths re: security and manageability.

What I’m struck by as I’ve learned more about the evolution of BlackBerry’s Enterprise products is how the team’s very forward looking initial product vision continues to make product feature decisions easy to make even in today’s BYOD world.   In fact, it appears to me this makes BlackBerry the most “BYOD Ready” platform on the market today, yet “BYOD” wasn’t on the radar when the team crafted their product vision many product cycles ago.

What can we learn from this as Evangelists?  As a team, a strong shared vision and mission provides clarity for the team every day, but especially in moments of crisis or indecision.  At BlackBerry our team’s mission is to “Make BlackBerry the best business partner for App Developers.”  Period.  To begin with, this means many different things to us, like are we making things easier, faster and more profitable for our developers?  Are we helping them see additional opportunities worldwide with their apps?  You get the idea.

Up front clarity of vision and mission enables you see more clearly your desired end point, hence, helps you reach your destination faster and with fewer detours and false starts.

What’s your team’s vision and mission?

Evangelism question time #1

First, thank you for all your comments, feedback and questions.  I’ve really enjoyed hearing from old industry colleagues and new friends in DevRel roles around the world.  Thought I’d share some questions we’ve discussed that I think are of general interest in a round up post.

We don’t have the resources to build an Evangelism team like BlackBerry’s, can I hire a Community Manager to run my developer program?

Well, maybe.  Developers can spot other developers in a heartbeat, they can also spot someone that’s not a developer  just as quickly.  If your community manager is a developer and has participation from your Product Development Team, this may work but I’m assuming that you’ve built out an SDK, developer portal, blog, forums (yours or Stackoverflow and their ilk), Twitter and Facebook presence as prerequisites.  Your team needs to build a thoughtful and targeted key influencer program to help you scale out your message.  Evangelism is active and participatory, so, you should build a company wide understanding of your engagement model because everyone is an evangelist.

What about breadth vs. depth programs?

The funny thing about this, I get a lot of pings from former ‘Softies on this one.   This question is a classic “can I have my cake and eat it too?” resource investment problem.  Simple answer, I didn’t find the silver bullet at BlackBerry,  we bit the bullet and did both to the best of our abilities and resources.  Mind you, BlackBerry took ecosystem building seriously and invested on the order of a 10X increase in investment over anything RIM had done before but still pales in comparison to investment levels at my former employer.

Should we charge for our Developer Program?

We decided that information and SDKs should be free, however “App Certification” is paid (our Built for BlackBerry program).  I believe the time to “Hello World” is critical, once you’ve captured a developer’s attention, so for BlackBerry we’ve focused on speeding and simplifying our programs as much as possible and still have more work to do here.

Come on, your other posts about what tactics and strategies you used are the same as everyone else, where’s the secret sauce?

Well, really there is no secret sauce, perhaps a quick summary will help.  Your single most critical success factor are the people on your team, they have to all be great hires.  All my Evangelists must be interviewed by me and Alec and have the key skills, background and “intangibles” we’ve seen in our high powered Evangelists.  Next is consistency, both in your approach on engagement, but your product design must manifest what you’re evangelizing to the community in terms of value prop and experience.  Does your firm  believe your ecosystem is strategically key to it’s success?  Believe me this commitment, or lack thereof shows through to developers and won’t invest if they feel you’re making a temporary investment.  Be approachable, the “anonymous evangelist on a forum” persona is a recipe for failure, people respond to people.  Yes, we’re in the technology business but Evangelism is a People business, it really is about hearts and minds.  Have fun, take risks and be memorable.

What do you think of what “fill in competitor name here” is doing with their Evangelism program?

Most often I get asked about my former employer, and the honest answer is I don’t know and you’ll have to do the research and form your own opinion.  If you’re asking me to benchmark what we do vs. others, something I learned at my former employer and my read of the Steve Jobs biography is that Apple also observes, adopts and “owns” strategies and tactics we all see in play developed by others in the industry.  You should too.

 

“So, how did you guys do it?”

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: