Archive for business

Update on Nomicly, Alpha Available

On Monday, I released an alpha version of my project Nomicly by sending the public link to friends.

Feedback has been generally positive. More than one person has either given me affirmation that they see business value or that it would be a useful place to interact with communities and peers, both of which are key to Nomicly’s success.

I’m really happy with the state of Nomicly now. One major goal was to end the year with a demo-ready product that can help illustrate where I want to go with Nomicly. That is certainly the case with the alpha.

The alpha is admittedly super-simple, and that for me is an example of the platform’s founding principle of simplicity. I’m also taking a fairly lean approach with a mix of calculated incremental design—for the last few years, I’ve taken a “it’s like a game of pool” approach to product design. If the ball just sits there for a turn or two, that’s okay so long as it’s still setting you up for a future shot to the pocket. (I think an old boss at Meltwater may have said that about sales actually–which also illustrates the goal of Nomicly to cross-pollinate people and problems to get really good ideas.)

That said, the progression of Nomicly to a business entity is not going to be easy, and it’s just getting started. Reminds me of a hobbit or two that I know of.

Please feel free to take a look at Nomicly and let me know what you think. :D

Special Thanks

Many thanks go to my wife Adria Mooney for her immense help in making Nomicly something worth looking at as well as her unending patience and support.

Bug Report

Despite my best efforts to ship a completely bug-free alpha, a few things were missed. By my accounts, four bugs were identified within 48 hours, three noticed by friends/me, one unnoticed (i.e. just me being a nitpiker):

  1. Twitter Login (disabled) — I thought this was working. I realize now it may never have been working (bad testing). I attempted to get a fix in quickly but to no avail. Feature disabled for the time-being.
  2. Modifying Ideas (fixed) — A core concept in Nomicly is to modify (and hopefully improve) other people’s ideas. Due to a subtle mistake in the site setup differences on staging and production, the feature didn’t work. Luckily we were able to locate the mistake in a few minutes and get it working.
  3. Timestamps (tbd) — For some reason I thought it would be fine to use gmt. I realize now that the time presented should be relative to the person viewing it. (Duh) Bug? Maybe more of a half-implemented feature…
  4. Idea Creation on the Me Page (fix coming) — This is likely a small regression: idea is submitted, but it doesn’t show up in the feed. (unless you refresh the page. lame.) Nobody’s noticed (AFAIK) but the fix will be going out shortly.

Changing Your Mind, Advice from Jeff Bezos

This post is a response to a blog entry by Jason Fried of 37signals, where Amazon founder/CEO Jeff Bezos visited yesterday.

You can read Fried’s entry here.

Helpful Quotes

He said people who were right a lot of the time were people who often changed their minds. He doesn’t think consistency of thought is a particularly positive trait. It’s perfectly healthy — encouraged, even — to have an idea tomorrow that contradicted your idea today.

What trait signified someone who was wrong a lot of the time? Someone obsessed with details that only support one point of view.

Perhaps I simply need more context to be convinced, but I do not believe it’s good for leaders to change their minds very often. (Note, *often*.)

How can a team make meaningful progress if the premises can change on a whim?

I’ve seen this in organizations actually (the leader changing his mind every couple of minutes). It’s a large source of wasted productivity. If life and business is a battle (ala SunZu et Machiavelli), the war will not be won if the marching orders and focus of attack change daily. It really is that simple (imho).

While I absolutely, vehemently agree that ideas and directions should be mutable over time, this act of self-evaluation can not come at the cost of meaningful progress. The risk is too quickly abandoning ideas that may foster large, meaningful results if executed through completion. To explore the adjacent possible we have to fully commit ourselves to unlocking the first possibility.

To some degree, changing your mind a lot (in major ways, not on details) is a sign that you’re not adequately thinking through scenarios—you’re merely piloting by reaction.

I will go so far as to make this claim: All major innovations and accomplishments in human history were not completed by people who changed their minds every few minutes.

Despite the romanticism we conjure when we think of Newton or Darwin, their ideas did not come in flashes of radical re-evaluations, but rather slow, methodical evaluations of a core idea/belief that grew to become a break-through idea.

These individuals looked for real reasons to change their ideas or beliefs, but for the most part they were looking at evidence as a tool guiding them to their breakthroughs*.

Even art is not created quickly and purely through intuition—painters for example have quite a bit of time to make small adjustments as they work the canvas. The core ‘what’ doesn’t change but some of the approaches or techniques may as the artist more and more surfaces the image.

Plans, Ideas, and Strategies can and should change over time but not on whims and not without considerable thought.

*If this is interesting to you, I would recommend checking out The History of Innovation by Steven Johnson or (from a ‘creative, art’ perspective) Little Bets by Peter Sims.

What Have I Been Up To?

This summer has been insane for me.

First, I went to Europe for 3 weeks this summer. That was an amazing trip that I will never forget. Aside from 3 lovely absolutely-no-work-weeks, I was able to visit some really old friends, some in Germany (I use to live there) and a few in Barcelona (US-born ex-pat friends). 3 weeks isn’t just enough time to catch up on sleep and unwind from the stress of a startup, it’s also time to do some introspection.

One of the realizations I came to was that I was ready for a change. I wasn’t sure what that change would be or the form it would take but I knew I was ready for something new. It helped that I’d been putting some feelers out on the job market and knew that there were a lot of other really interesting projects out there for me–if I just took one.

Resigning was one of the harder decisions I ever had to make. I kept almost backing out in the last minute. Servio was a fun place for me. I knew everyone, got along with everyone and loved the projects. To this day, I think crowdsourcing is awesome stuff and will have deep impacts on society in the future (like all disruptive technologies and processes, culture and society change forever).

But in the end, I knew that to keep growing I had to move on. I couldn’t stay in my comfort zone and keep growing. I had to make myself uncomfortable. I had to get out there and challenge myself. So, I resigned and ended my tenure at Servio.

By the end of July, I was able to find a new gig with a Big Data startup. I’ll call it B.D.S. for reasons outlined below. BDS was going to be perfect for me. Pre-launch so it was early (which is when a company is most scrappy and can best leverage a super scrappy guy like me), I had friends there, the project is super interesting (Big DatA) and I was making good money.

Unfortunately, after two months with BDS, I left the company.

BDS was not going to work for me longterm and it was obvious by week 4. It was a really bad culture fit. This was surprising and very disappointing for me. Again, I thought it was going to be an amazing place to work.

This is hard to say but my hope in saying it is that the people still working at BDS work quickly to resolve it: BDS may be the most mediocre place I’ve ever worked.

Now, I’m not referring to any of the people; the culture and work dynamics were what created mediocre outcomes.

It’d be easy to blame a few people in the organization but after taking a step back it feels more appropriate to conclude that the culture did not instill a constant drive for execution, rather than blame people for being lazy and crapy. That said, upper management clearly plays a major role in shaping the culture and setting the tone for execution and I will not pull the punch for them: they are failing.

For me, this was a really good example to see how poor management processes lacking environments of accountability coupled with even worse planning and prioritization results in poor performing company cultures. The easiest to remember example is that I constantly heard “not my responsibility” or “oh it’s ___’s fault.” I personally find the “pass the buck” mentalities to be particularly base and mediocre.

Failure here is predictable and expected in situations like this. Nobody would be surprised. It’s also interesting to see it play out in reality though.

I understand everyone wants and expects examples after the statements like that but I don’t think that would be appropriate. I want the team to succeed and many of the people I know at the company recognize that they are failing to execute. They know why, and there’s certainly no need to rub their faces in it.

It was a really interesting experience to work at BDS after Servio. The main takeaway for me is to stand by high standards and that mediocre work shouldn’t be tolerated.

What I’m Doing Now

Being flung far from the orbit I had planned to be in at this time, I’m now moving forward with Plan B. While at BDS, particularly when I realized things were going poorly, I started focusing a bit on the development of a Plan B.

My Plan B is to continue working on the Nomic Game full time, with some consulting work from time to time.

While it’s not likely that my wife or I would have justified leaving a job to work on the Nomic Game two months ago, we’re feeling okay with this being my full-time project now.

It has to do with where were are in our lives and the realization that I won’t be happy until I try. I already know from personal experience that I will never say, “I’m worse for trying” or “I wish I hadn’t done that.” I have too many successes to point back to

It helps that we don’t have the burdens of a mortgage or the worry and responsibility of children (yet). But, ultimately, it comes down to me wanting to see what I’m capable of. My loving wife knows I want this from myself and she supports me. But, like all great wives, she has high expectations. Adria is my greatest cheerleader but also my most exacting critic.

So, other than manufacturing more Dragon’s Eggs and taking a few courses (like Statistics and Gamification), that’s about all I’ve been up to.

Quite the summer of change!

Top Three Challenges for Crowdsourcing Companies

After two and a half years focused on crowdsourcing, I’ve had plenty opportunity to reflect on the challenges for businesses, both new and established, looking to introduce crowdsourcing projects. Here’s a short list of what I consider to be the Three Challenges for Crowdsourcing Companies.

Building Crowds

One of the first challenges a crowdsourcing company will encounter is building a crowd to sustain the business model. In many ways, this is the same challenge any business starting out has always encountered: getting people to use the service.
Building a crowd for your business is a marketing activity. It is not an engineering activity.
There’s often a misconception about this but make no mistake, if people (“crowds”) do not know about your crowdsourcing site, it will fail.
Now, just because the acquisition of users to power the crowd is a marketing activity does not mean engineering should be the “go-fers”. Quite the opposite is true.
Strong engineering and metrics-focused product teams help provide the discipline and face-based processes that really enhance marketing teams’ efforts at acquiring and sustaining users, customers and crowds.

Maintaining Crowds

Maintaining Crowds is similar to Building Crowds, except that after you get a crowd to your site, the challenge is keeping them there.
It does not matter whether you pay users in real money, coupons, points, bitcoins or coconuts, your crowd is a set of free software users visiting your website. If you want to keep these people, arguably the most important asset you can posses, it’s important your crowdsourcing site offers a combination of stickiness (through pay, rewards or infrastructure), autonomy, achievement, community, notoriety, and personal-attainment. The exact combination for your site can only be determined through experimentation, so getting started early in the process of reevaluating site interactions and direct user feedback is important.
For crowdsourcing companies conducting business, the quality challenge is not to just to ensure accuracy but also to create a sensible, fair system under which the crowd’s work is evaluated.
So, while Facebook has to provide stickiness, community and autonomy, it doesn’t have to worry (too much) about the output from its user base.
People on Mechanical Turk or CloudCrowd are judged constantly on output quality, so if the crowdsourcing business does not provide the right environment for people to be judged, the users will feel ostracized or unfairly punished, invariably resulting in an exodus.
Whereas acquiring new users is more heavily weighed by marketing efforts, product and engineering efforts are the focus for sustaining crowds (i.e. once the marketers get people to the site, do the engineering and product teams provide people a great site for doing work or participating in crowdsourcing projects? or do they find a confusing site or one with unclear rules or unfair community interactions?)

Building Consistency (at scale)

The holy grail of crowdsourcing is the scale of potential output. How many “manhours” can your crowd produce in a single hour? How many millions of workitems were completed last month?
The on-paper math for crowdsourced labor is staggering.
What we have to keep in mind is that the users are humans, not machines.
This results in a variance of output. Crowdsourcing processes, while perhaps fashioned after assembly lines, does not always produce output like one.
This is an area where the most innovation for crowdsourced labor is occurring.
My advice, to be concise, is to explore balancing algorithms, crowd peer-reviews, high-reward for good work, and real risk of expulsion or penalties for poor work.

Aligning Incentives & Expectations When Crowdsourcing

I’m happy to report that over the last week we transitioned all of our writing projects at Servio to a modified workflow.

Before explaining the change and why I’m happy (and how it relates to incentives and expectations), it’s important to understand how all work gets approved on CloudCrowd, Servio’s crowdsourcing platform.

Luckily it’s quite simple: all work is peer reviewed a minimum of one time, and frequently up to three or even four times, depending on context or work complexity. This means that if I, as a worker, am instructed to “go find an image of a camera on a white background measuring 300 by 300 px” then another worker will verify that the image I’ve submitted meets all the criteria outlined in the project instructions.

The peer worker reviewing my submission makes a determination to approve my work or reject it. If approved, I get paid. If rejected, I do not.

Here we can see that workers have a very strong economic incentive to provide quality, accurate work because failure to do so means any time devoted to the project is a waste of time. I think of this process as creating and leveraging social accountability to ensure quality. The peer review process is one way Servio guarantees quality, and it’s extremely powerful. I discuss a few other quality control techniques here and here.

Prior to the change in workflows, the writing process at Servio followed this same two-step process:
1st — a writer would receive instructions on what topic and length to write on. There would likely be structural and tone requirements too. (You can view a fairly extensive set of options for custom content writing on Servio.)
2nd — the “peer” in this case would be an editor, not a writer.

On the surface this seems fine. It even mimics the real-world in many ways. Writers write and editors edit. Seems fine because we’re mimicking the real world and known social forms—one of my (personal) requirements for how crowdsourcing workflows should flow.

So where’s the problem you ask?

The editors reviewing written content were instructed to approve a document if there were less than two grammatical errors. If there were more than two or if there were any spelling errors, the document should be rejected. In this case, the writer would receive no payment for the work.

At first glance, this may seem totally acceptable. Of course the writer shouldn’t be paid for submitting writing that has grammatical or spelling errors. However, we have to remember the perspectives of a writer and an editor are very different. Editors know all sorts of nitty-gritty details on grammar, frequently details the common writer, including myself, won’t remember (or even care to). Editors on Servio are pretty hardcore. You have to really know your stuff if you want to keep up.

This situation created an expectation imbalance in which the editors were holding writers to unrealistic expectations. I’m not trying say that writers shouldn’t know as much about grammar as possible. I am saying that small slips in grammar rules should not be a determination in whether you get paid for the bulk of your work.

Remember, if the submitted writing is rejected because of a couple of comma splices and a misuse of parallelism in a series, then the writer gets nothing. If the writing project was for a 2000 word article on the risks of Oxycontin/Oxycodone addiction or Lithium withdrawal, subjects that would require fairly extensive research to write on, then a writer may have two hours of work thrown out for fairly minor reasons. Talk about a negative incentive to participate! The result is low worker morale, low throughput, and frustration between editors and writers.

I’ll go into detail on other techniques Servio uses to avoid wasted work like this another time—we’ve released a series of really, really awesome feature/workflow enhancements starting in 2010 to address this overall problem.

For now, we can contrast the prior workflow (the editors reviewing writer work) to the new workflow.

The New Workflow

Rather than having editors reviewing writer work directly, writers review writer submissions. After a writer’s article is approved (by another writer during the peer-review process), the article is automatically routed to an editor who is responsible for addressing deeper facets of the writing. Here’s a portion of what we expect from editors:

Proofreading: Proofreading is merely to check a written text for errors in spelling and grammar.
Editing: Editing is the process of selecting and preparing language. This means, editors are required to make improvements to word choice and sentence structure, otherwise it’s merely proofreading.

Note that we don’t expect a trivial proofreading of the content. We expect the editors to focus on improving the writing, from sentence structure to word choice.

By isolating these project expectations—that is, by allowing writers to remain responsible exclusively for adherence to topic/focus/tone requirements and routing completed articles to an edit-only work queue—we’re able to achieve a much higher quality in final article while also better aligning expectations for both writers and editors.

The result is a lot less stress for the writers (no longer held to unrealistic expectations) and better pay (less rejected work for small errors means the average earning per submitted article will go up). Another result is faster completion of each writing assignment (primarily due to lower rejection rates). In a business that sells on quality and scale, this is a pretty big deal.

For business reasons, I cannot explain why we originally started with the first flawed workflow, but I can say that I’m extremely happy with where we are now. (Feedback on the worker support forums indicates workers are happy with this too!)

The Important Lesson

When designing the workflows and writing instructions to workers, it is important to properly aligned expectations and incentives (pay, points, rewards, etc). And as I illustrated above, small changes in the workflow can have major impacts on quality, worker satisfaction (hugely important) and throughput.

Game Theory and Nomics

Stanford University is offering a free game theory class that I’m enrolled in. I’ve been interested in game theory since reading The Art of Strategy last year.

As a quick aside, I actually read the book because I wanted to be sure to properly align the incentives of Servio’s workers on CloudCrowd. That is to say, on CloudCrowd we have some really awesome workflows that involve allowing workers to receive bonuses for correcting work they’re reviewing (rather than rejecting the work and only getting a low-base rate for rejecting flawed work). We also have a workflow that sends rejected work back to the original worker for “self-corrections.” Our workflows are quite fascinating to me because we’re building a work platform that (as long as I get to contribute) will continue to align itself more and more with how “the real world” works. However, because of the complexity in our workflows, it was important (as the product manager determining payouts, expected user behavior, policies around eligibility, etc) that I have a fairly strong handle on the relevant game mechanics governing worker interactions.

When I read Cognitive Surplus late last year, I first learned about the “Nomic Game.” I’ve been a little obsessed with how we can leverage the Nomic Game, as a principle if nothing more, to create a collective consensus building platform ever since. I think I’m on to something here, and hearing the founder of Votizen speak at a TedX conference (via YouTube) affirms this belief. Remember, one of my first inspirations for the Nomic Game was the Occupy Wall Street movement and their inability to create an actionable, cohesive consensus—it’s worth noting that a “leap of faith” assumption, to use Eric Reis’ term, is that social movements of today—political involvement methodologies of contemporary society—need to “catch up” with normal business and consumer technologies. I mean, we’re still using an electoral college for presidential elections, and from what I can tell the system was only in place because of the technology available during the 1800′s (i.e. horse drawn carriages). We’re still using horse drawn carriage paradigms for elections!? This is mind numbingly retarded to me. (If that bothers you too, check out what Jennifer Pahlka is working on. It’s pretty awesome.)

Coming full circle to the Nomic Game, the concept was originally proposed by a political science professor Peter Suber in The Paradox of Self-Amendment, and Suber used the game as a way of illustrating how The Constitution works for his students. One of the main lessons of the game is that through self-amendment, “unalienable rights” can be revoked through a consensus of modification of the “unalienable-ness” of a right. It’s a very interesting read, albeit a bit dense.

One of the first questions I had when thinking through the Nomic Game was “What are the game theory implications of the Nomic Game?”

This question isn’t as straight forward as you might expect. To understand what I mean here, let’s walk through a simple mental game.

Particularly in the fashion I plan to implement it, the Nomic Game helps people establish consensus around ideas. Another word for “idea” in this scenario is “belief,” and this is an important point. (Background: In game theory, beliefs and motivations play a key role in understanding games where players play multiple rounds before completing the game. And, the Nomic Game is exactly that.)

At first we may think (without the math, aka “a priori“) the (weakly) dominant strategy is to simply agree with ideas so that we can arrive at a consensus and move to the next problem. That is, if we all agree with an idea, then as a society we will (presumably) receive the same utility. But, as an additional premise, we’re not just working with bland ideas like “let’s go get a cup of coffee,” we’re dealing with important ideas like “we should stop the production of nuclear arsenals.”

Now we’re treading into a contentious area.

My beliefs about the implications of stopping nuclear arsenal production come into play. Tangential beliefs about what it means to no longer produce nuclear arsenals need to be evaluated. Moreover, is it a weakly dominant strategy for me to agree with an idea that does not properly align with my belief system even though I may access some utility by doing so?

If we take a step back for a moment, we can see this same weakly dominant strategy at play in our political election system today: Your choice for the next president (or Senator or whatever) is Twiddle-Dee from the Republican Party or Twiddle-Dumb from the Democrat Party. To be a bit more explicit, the argument, “I don’t want to throw my vote away” is a tacit consent that the the political actor (the voting citizen) is taking the weakly dominant strategy of choosing the “most likely person to win.” This is playing the dominant strategy.

Whew, I went over a lot here but I didn’t reach my main goal. I wanted to explore a formula for the utility of a Nomic Game player but I have to go to work. Next time!

(Btw, I’m still looking for a better name than Nomic Game. What do people think of “nomic.ly”?)

Car Ownership Unpopular With Younger Generation (Because Car Ownership Is Stupid)

My mother-in-law sent me this article from the NYTimes on Sunday. It’s an interesting piece on the decline of car ownership among the “younger generation”—basically Gen-Y’ers/Millennials. I think this makes sense and it’s a topic she and I discuss frequently.

Here is my response (as it relates to crowdsourcing two paragraphs down):

It’s scary (and kind of hilarious) to imagine what this means:

The five-year strategic vision that Scratch [a consulting arm of MTV] has developed for Chevrolet, kept quiet until now, stretches beyond marketing to a rethinking of the company’s corporate culture. The strategy is to infuse General Motors with the same insights that made MTV reality shows like “Jersey Shore” and “Teen Mom” breakout hits.

I imagine people fist pumping as they walk down the halls screaming “where are the guidos!?” :p

I hope the car industry goes the direction of the horse-drawn carriage. we need better solutions to transportation than stupid cars. there’s no scale.

GM is kidding itself if they think they’re going to attract young purchasers with stupid lemonade colored cards–and Scratch probably knows it but wants the consulting fees (i.e. “just doing their job”).

The real trend for “the young generation” will be around collective ownership—sharing assets to reduce costs.

Consider: if it costs 60 to 80k to get a decent college education, arguably the bare minimum needed to even start getting into the “middle class income brackets,” and most of this money is procured through student loans, then the “youth of today” will have debt considerably higher than “our parents’ generation,” hence postponing starting family, purchasing homes and cars, etc. outside of home ownership, 20 years ago people would be hard pressed to find 22 year olds carrying debt in the 80k range. That doesn’t even count the people who choose to go to graduate school.

So, yeah, while it’s the right decision to “…abandon the hard sell,” it doesn’t affect the long term trends or take into account the social changes happening due to the internet and an awareness that “collective ownership” is viable and doesn’t have to look like some scary vignette from 1984 or “the evil Soviet Republic.”

On a slightly unrelated note, did everyone checkout Bill Moyers & Company this week?

Occupy Wall Street, Developernomics and Management

A couple of articles from Forbes caught my eye yesterday and I wanted to spend a few minutes reflecting on the articles.

The first, “The Rise of Developernomics,” really dug deep into how developers are shaping society and are becoming the most important contributors to economic reshaping on the planet.

To some degree I agree; however, I think the author Venkatesh Rao exaggerates a little. He said more than once that all other professions were nearly unimportant to society. Rao also claimed that developers, on the whole, have not figured out how to actualize their true value. (Developers in San Francisco/Silicon Valley make a ton of money, so I’m not sure where Rao gets the impression that developers are underpaid.)

The two most salient points, from my perspective, were first that developers are underpaid and under appreciated. Rao’s second point, which I fully support, is that society better quickly recognize that developers are shaping the planet. Moreover, if your company is not participating in this revolution then you’re at risk of being completely marginalized and forgotten.

Rao writes:

And god forbid, if you don’t have a skill, like baking, which the developer-centric economy can actually use, you are in deep trouble. One reason the Occupy Wall Street movement is not having the impact it seems like it should, based on sheer numbers of people involved, is that many participants simply have no cards left to play in this national game of economic poker.

Absolutely agree and here’s why.

A few weeks ago, I took a cursory look into how the Occupiers were organizing themselves. I wanted to know how they were communicating with each other. Were there channels for Occupy Movements in Oakland to engage in political discussions with Occupiers in NYC? How were the Occupiers focusing their efforts and formulating political discourse that was less transient than their makeshift camps and drum circles?

Turns out there wasn’t much. Other than a few Facebook pages (notably with hundreds of thousands of ‘Likes’), I didn’t find much. Not even a simple phpBB online forum for capturing everyone’s perspectives. In all honesty, I wasn’t too surprised. My view of the occupiers is that they don’t have any real technical skills.

The sad part, in my opinion, is that setting up basic social interactive systems is pretty easy. It doesn’t take a star developer (a “10xer” as Rao refers to them).

Let’s turn to the second article and it’s relation to ‘developernomics’. The second article is “Now Every Company Is A Software Company” by David Kirkpatrick, also published in Forbes.

For me, the idea that all companies are software companies is not what I would consider a fresh idea. It’s a rather obvious trend.

What caught my eye was the following passage due to its relation to crowdsourcing and the flaw with the Occupy Movement I highlighted above. Kirkpatrick writes:

This transition to a new world of responsiveness and agility will be painful and require a new mind-set. “We can build organizations that are far more adaptable, far more inspiring places to work, far more innovative than anything we’ve seen so far,” says management thinker and author Gary Hamel. “But there’s a huge ideological challenge in doing that, because inside most huge organizations is a bureaucratic caste that believes it’s their role to make decisions.” Scott Cook, founder and chairman of ­financial­-­software maker Intuit, concurs: “The kind of leadership my dad learned in World War II—where the leader makes all the decisions and tells everybody else what to do—that’s the flaw in organizations.”

Kirkpatrick is right to point out that previous leadership models are coming under intense pressure.

I recently read Clay Shirky’s new book Cognitive Surplus, How Technology Makes Consumers into Collaborators and one of his primary points in the book is that previous models of social organization have come under intense pressure and are on the whole no longer valid. Shirky is a Journalism professor so he focuses heavily on media-related changes. However, I do not believe it is a great stretch to see how our digitized and networked world is reshaping itself as a reaction to the technological capabilities and changes of the last two decades. Shirky calls the heavy consumerism of the 20th century an “accident” occurring because the media communication channels were heavily one-sided and that this accident will be fixed now that we’ve broken down the communication channels to allow anyone to contribute to the creative discourse. My blog here is an example of how “just about anyone” can participate in wide-net discussions.

It stands to reason that if society is changing because we’re now all contributing to the discussion that management practices will need to change too. And why shouldn’t they?

Maybe it’s ego, maybe it’s presumptuous but old top-down management practices seem extremely archaic to me.

We don’t live in a world that even needs a dictator (i.e. CEO or executive staff) to make every decision. “Crowds,” positioned correctly, are capable of self-governance.

It’s probably scary as hell to shareholders to think that “regular old employees” are making the decisions at companies (or could be were management able to let go) but this is certainly the direction we’re heading in. I will go so far as to say that companies in the future will be collaboratively managed and new social organization tools will emerge to help focus the collaborative efforts of all (interested and willing) people at a company to make decisions and execute on those decisions.

Relating this concept back to the Occupy Wall Street movement, what we see is a lack of what Apache and Linux used to propel forward into something sustainable: a technological infrastructure. The Occupy Movement has the support of the people but it fails to see that it is 100% dependent on technology (what Rao considers the number one survival risk presented to anyone who does not respect the need for technology) and what Kirkpatrick is positing: All companies are software companies.

Rather than looking at the Occupy Movement as a “company” we could re-read Kirkpatrick’s statement as follows, “All organizations, movements and communities are software organizations, movements and communities.”

I am pulling heavily form Shirky’s Cognitive Surplus for an under-riding premise that all communities and movements of the future will rely upon digital networks for cohesiveness, and it’s this reason that I am seemingly taking the “people” out of the “movement and community.”

It may feel slightly dehumanized to read it in this manner but if we never forget that the software we build and use are merely tools for helping us accomplish some goal then the humanized aspect is a given. Meaning, I am not taking the people and society out of the Occupy Movement (or any social movement). I am simply trying to highlight that social activists need to start learning some coding skills if they want to remain relevant (and retain power) in the coming years.

So, in conclusion, yes we are living in a world where all companies (and movements) are software companies (and movements) and yes this is the rise of developer-centric economics.

Buliding Better Crowds, Part 3 of 3

If you read part one and part two of building better crowds, then you understand there is quite a bit that goes into building a crowd.

After you’ve declared war on ambiguity by putting in clear processes and solved for quality control and created transparent forums for discussion, it’s now time to start building a business to sustain the crowd.

That may seem to imply that you start with building the crowd before you start building the business. I apologize for that implication because it’s certainly wrong. For any business or activity which requires a crowd, the crowd building efforts should occur in parallel with the development of the business. Essentially, the business isn’t just your life line to success, it’s the crowd. And for crowd-based businesses, what’s “good for the goose is good for the gander.” (I’d go so far as to say the crowd is the goose and the company is the gander, btw).

My under-riding premise is that you need to build a business to support the crowd. This is perhaps more subtle than you realize. Most people start businesses to support themselves—and crowdsourcing isn’t necessarily an exception; however, you do need to understand that without your crowd, you have no business. Crowdsourcing companies are just middleman between “labor suppliers and labor doers.”

The interesting complication for crowdsourcing companies is that they have two customer sets: (1) the traditional, we-pay-the-bills-by-buying-your-service customers and (2) the people in your crowd (who get your work done for you).

It’s great (and absolutely necessary) that you pay significant part of your time focused on the ‘we buy your service’ group, but if you think of your crowd as a knowledge base or an expertise provider that makes customers from the first group possible, then it becomes apparent you need to promote the interests of your crowd as well.

There are a number of “user experience” enhancements that will make doing your work for you appealing to workers but I actually think that isn’t the place to start (but when you get the big ticket items in place, it is a good place to get some easy morale wins).

Rather than focus entirely on “UX improvements,” I think it’s better that you focus on building a business that will sustain the crowd. The crowd pretty much does not care about your company. At all. And they never will. (At least not 10% as much as you do.) There is no loyalty on the internet. As soon as a better service comes around that offers your crowd a solution to their problem, they’re leaving.

And when it comes to building a crowd, this means your investment is leaving.

This isn’t a business factor that many traditional companies needed to grapple with very often because, outside very rare cases, entire workforces do not leave a company all at one time—I think of the labor movements in the early 20th century when I think of mass picketing and assembly line abandonment. This isn’t to say that companies today do not worry about building strong cultures because they do. Most companies recognize that a strong company culture fosters higher productivity and increases company retention. Traditional, brick-n-morter businesses focus on these two areas (productivity and retention) because they see their employees as an asset worth protecting.

In time, crowdsourcing companies too will come to see that their crowds are assets worth protecting. For example, this is one of the main points Matt Johnson CMO of uTest made at CrowdConf 2011.

How do you build a business to support the crowd?

I can’t give you a direct answer, unless you’re happy with “focus on building a strong business” as your answer (I suspect you’re not).

I can provide some clues that I’ve been able to suss out from working with crowds over the last two years.

Clue 1 — Focus on business models, customers, processes and markets that will sustain the crowd for more than one project, preferably dozens of projects.
The absolute worst position you can be in is having to build a crowd from scratch for every project. If you’re trying to create awareness for a niche cause, then maybe it makes sense to bounce around building special-purpose crowds but for the majority of businesses this is a recipe for failure. And that is a larger business lesson in itself: focus on building a sustained business.

What this means in practice is that you need to ascertain where you’re gaining traction and focus in on that area with all your effort. This takes massive discipline. It means reigning in your marketing and sales team from going out and finding those random “they really think we’re awesome, want to buy but we have to build a crowd to {{xx, yy}}.” In most cases, that {{xx, yy}} is going to be more expensive than it’s worth. I know from personal experience that it is immensely difficult to turn away business, especially when a business is just starting out. But if that “new customer” is in an area where you have no expertise, then it’s not likely to be worth it because you’re setting yourself up for failure.

Clue 2 — It’s better to have an oversupply of work than an under-supply of work.
For the business manager looking to meet customer orders this is an extremely difficult to situation to be. It’s very stressful to have more work to get done in less time than the “factory” can deliver. All very true but this isn’t looking at it from the crowd’s perspective. Also, if this is the situation you find yourself in then congradulations! Your business is growing. :)

It is very frustrating to go to a freelance job site like Guru.com looking for work only to find that most of the work is bid on by dozens and dozens of people—or to be one name among 50 that responded to a Criagslist ad. Crowds are looking for work and if your site no longer provides that work, they will find the site that does and quickly leave never to return. As a measure to protect the investment in the crowd, it is far better to have too much work than too little, assuming an ideal equilibrium between demand and supply cannot exist. (Note the difference between a traditional company that simply won’t hire anyone if there isn’t a need whereas with crowdsourcing the companies are essentially “always hiring.” It makes for a much different labor market.)

To achieve this state (more work than demand), you need to be out selling and marketing your services. Selling and marketing are not passive activities. I’ve been at more than one company (unfortunately) where the necessity of sales and marketing was ill understood, leading me to clue three.

Clue 3 — It’s not enough to build it; you have to sell it.
Our culture is obsessed with “Build it and they will come” mentalities, and I’m not sure how we became so obsessed with this type of thinking. It’s easy to build and so we pin all our hopes on “well, they’ll come after I finish this…” It’s true that we’ve had a few examples of businesses that really took off after only a small sub-set of users were on the system (MySpace/Facebook, Twitter) come to mind. But I can’t think of another business where this was the case. This means that once you finish building the minimum viable product, it’s time to get off your butt and start selling. :)

Clue 4 — It takes commitment.
Selling a product is not easy. Marketing a product is not easy. There are going to be days when you think, “Man…I’ve tried everything. I don’t know what to do. Does my product suck? …Or maybe I just suck. Maybe I was wrong and this is not a good business.”

All the thoughts that plague any entrepreneur are going to haunt the crowdsourcing startup. To see your way through this long night of doubt, you need commitment. To have commitment, you need to know that there is indeed a market large enough to support you and your crowd. (You also need to have strong character to resist backing down at the first hundred instances of obstacles.)

The people with good character are the ones who dust themselves off, get out a clean sheet of paper and start thinking up new marketing and sales plans.