Wednesday, August 28, 2013

Why Your Contractors Will Never Create Your Community

@spartovi - Sal Partovi

The arguments for curating a community around your company, products, and/or API are pretty simple and clear. Software is eating the world. APIs are the new business development medium. Developers are the new kingmakers.

It only makes sense to curate the kingmakers. The problem is the disconnect between building a community, while simultaneously contracting out work.

This concept reminds me of one my favorite scenes from the Godfather Part II:
-- Michael Corleone: We saw a strange thing on our way here. Some rebels were being arrested, and instead of being arrested, one of them pulled the pin on a grenade he had hidden in his jacket. He took himself and the captain of the command with him.
-- Guest: Ah, the rebels are insane!
-- Michael Corleone: Soldiers are paid to fight; the rebels aren't.
-- Hyman Roth: What does that tell you?
-- Michael Corleone: They could win.
It's a common story throughout history. Groups of folks fighting for what they are passionate about defeating much more daunting foes who are simply performing a job.

Back to development, the current "development problem solving" thought process is as follows:
  1. Um, we have a problem to solve / a solution we need
  2. Let's find someone who knows how solve it
  3. Profit?
When you hire a contractor for development you're hiring a soldier. When you contract someone for a task, assuming they're competent in that field, you're going to get that task completed. Nothing more, nothing less. Historically this has not been a terrible strategy. It works with some limitations. 

It just doesn't drive community engagement. 

The same company that has a meeting on one side of the building trying to find a way to increase community engagement around a new API or product, is concurrently having another meeting on the opposite side of the building to contract out the latest mobile app. Because that makes sense... (?)

To look at the situation another way, is it possible to "contract a community"? Can you imagine an audience at a concert that's paid to be there? It would work - but it wouldn't be a community of enthusiastic fans all excited about the same music.

The only glimmer of hope in this situation thus far has been hackathons. Hosting a public event to bring interested folks, with prizes instead of contractual obligations, competitions instead of designated tasks, has thus far been the pinnacle of community engagement events. Hackathons, believe it or not, are a form of crowdsourcing.

How can an organization get work done while also driving community engagement? Simple: Crowdsourcing.

Crowdsourcing applies all those juicy "community engagement benefits" of hackathons to day-to-day work. Public challenges? Check. Prizes? Check. Competition? Check. Enthusiastic self-selected experts showing up to participate? Check. It probably sounds a little counter-intuitive at first, but crowdsourcing is a better method for building long-term relationships than contracting.

Ignoring data that shows that crowdsourcing is 62% more effective than methods like contracting, the basic logic is as follows:

(A) Crowdsource it, get work done, and engage and build your community of fans

 -- or -- 

(B) Contract it, get work done, and that's about it

Contractors don't create communities.

2 comments: