James Dipadua

What Have I Been Up To?

October 7, 2012 business, culture No comments

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!

Designing User Interfaces, What to Do (and Ask) Before You Start

June 8, 2012 UI/UX No comments

Creating new user interfaces (UI) is super fun.

For me, it’s among the most exciting parts of working on a website or a piece of software—this is what your users and customers are going to see and manipulate! It’s the part of your work that is immediately noticeable, unlike back-end work that may not be noticed by users¹.

When caught up in the excitement of a new UI project, thoughts of grandeur gripe us, visions of high user engagement and new records of conversions overwhelm our senses and we begin with an impulse to start drawing boxes with smiling faces and arrows pointing from one box to another.

Mistake.

I’m not sure if it’s a mistake born from habit or from instinct because I see UI designers, both new and experienced alike, dive right for the whiteboard or the local copy of Balsamiq whenever a question of UI comes up.

If we start with drawing pictures, we lose sight of our goals.

We start focusing on the balance of elements or proper grouping of elements to communicate association, rather than making sure “the box” we’re pixel-pushing and designing around should even be given a single pixel of screen real estate.

So where should we start?

Start by asking one simple question: What is my goal for this page?

In other words, what do you want your user/customer to do on this page?

The strongest UIs actually avoid the software company’s perspective entirely and instead focus on what your user/customer is trying to do if they ever find themselves on this page.

There is a subtle difference between the two, but there need not be a difference if you consistently design with the end user in mind first.

Remember: Users are Goal-Oriented

The key is to have a very firm understanding of the goals of the page/screen/help-message/etc. What action do you want the user/customer to take? What is the customer trying to achieve?

These are the most important questions to answer before starting on a UI design.

If you do not have a clear boundary in your mind, you will likely end up with a design that pulls the user in two different directions. You may not achieve the conversion rates you’re looking for. Users may “get lost” or frustrated and leave (and likely never return).

In a world of limited attention, having muddled goals (as reflected through poor or confusing UI) may ruin your one chance to get and keep a user/customer.

Summary

Avoid the common impulse to start immediately “designing” the layout of the page or the interactions users will have.
Discipline yourself to start with a deep understanding of your goals.

This is still design, even though it might feel more like brainstorming or “discussing the obvious” if you’re in a group. It is and it isn’t.

Even if it’s not quite as fun as drawing boxes and balancing said boxes on a screen and patting yourself on the back for coming up with “the Best Design Evaaaar”, the process of clearly delineating goals contributes immensely to a well-designed UI. If the process yields nothing else, it will show you what you really don’t want included and what you forgot to include.

For group designs, it is also a key ingredient to achieving consensus on the page/screen—and a lack of consensus can lead to heated discussions and frustration among the team.

So, I highly recommend starting with the goal-asking phase long before the first box is drawn on a whiteboard.

¹Regarding Back-End Engineering: My statements shouldn’t be taken in any way to diminish the importance of back-end work because if a system isn’t responsive due to poor query or model design, your user will absolutely notice the sluggishness and likely think your software stinks. For any back-end readers, the key isn’t to focus on hardware performance but responsiveness, and there are more than one way to tackle a responsiveness problem. In fact, responsiveness is the number one influencer on whether people think your software is “good” or “crappy”. Responsiveness is the number one influencer, not colors, drop shadows, fancy buttons or neat pictures!

Top Three Challenges for Crowdsourcing Companies

May 29, 2012 business, crowdsourcing No comments

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

April 27, 2012 business, crowdsourcing at servio No comments

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

March 29, 2012 business, crowdsourcing, experimental ideas, nomic game No comments

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)

March 28, 2012 business, sorta-crowdsourcing No comments

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?

Pushing Forward on the Nomic Game

March 27, 2012 crowdsourcing, experimental ideas, nomic game No comments

I was able to get a few more hours into the Nomic project today. Not quite to the point where it’s even remotely presentable (even for this dirty of an experiment) but some good progress.

It took me a few minutes (as in 60) to get back into the groove of writing code, but I’m now recording new ideas and just about ready to start allowing voting. I forgot to implement a few things with regards to the ancestry of an idea but getting that in will only take a few minutes.

The Nomic Game will be a pretty clunky version even when I get voting in because I won’t have a notion of “people” yet. :p I’ve been waiting to get the bulk of the ideation process in place first before moving on to user identification. Then I can address issues such as “who gets to vote” and “limiting votes”.

To identify people, I plan to use Facebook and make the Nomic Experiment a Facebook app so that I can leverage their authentication process.

Ideally I’ll have time to setup the Twitter API so that users can auto-feed their ideas to Twitter. I’ll probably “ship” the prototype without it though because I’m eager to get feedback on the base concept.

Hopefully this prioritization (ideas and votes before people) doesn’t bite me in the butt. I tried to make sure I had some design thinking in place to account for people and I believe the highly modularized approach I’m taking to the code will give me the flexibility I need. I haven’t built any unit tests yet, but I plan to! (I say this knowing I’ll probably rely on ad-hoc testing for the foreseeable future.)

You might have noticed that I keep referring to the project by different names “nomics”, “nomic project”, “nomic experiment.” This is the result of not having a name for it! It really only occurred to me recently that I’m probably the only person who wants to call this “Nomics”.

Got any ideas? Maybe Idea Factory? That’s what I put in the meta description. But I haven’t even spent a lick of time looking for domains. I’m figuring that has to be the least important aspect of the app–at least until a day or so before I want to release it.

If you somehow stumbled across this post and have no idea what I’m talking about, read my first post specifically on the Nomic Game or this post where I first started contemplating the need/value of the Nomic Game.

The Nomic Game Schema

March 26, 2012 crowdsourcing, experimental ideas, nomic game No comments

So I haven’t updated on the Nomic Game since the first post.

For the reader who was perplexed by the “philosophical design” of the Nomic Game, here’s where I took this crazy ramble:

Reflecting on the “philosophical design,” I produced this set of notes:

Don't mind the handwriting. I can read it!

From these notes, I created these tables:



+-------------------+

| Tables_in_nomics  |

+-------------------+

| community_admins  |

| community_list    |

| community_members |

| error_logs        |

| following         |

| ideas             |

| people            |

| votes             |

+-------------------+

I have another table to create called “plans” which are just going to be collections of ideas. Long story short, I reasoned that a “plan” is really just the collection of a number of small ideas. I felt ‘plans’ were an important notion to capture because if the Nomic Game can generate real action (as I hypothesize is possible), then there needs to be some way to collect “ideas” into a “plan”.

What I thought was particularly interesting about my contemplation of ideas was the exploration of “sentiment.” Related to another project I’m working on, I’ve been looking through different models to understand “decay” rates. I’ve been studying up a bit on Normal Distribution, and some other fun things.

When I applied some of this decay and Normal Distribution thinking to the notion of a “sentiment,” I arrived with this basic behavior:

Two models for measuring sentiment.

Without divulging the exact formula(s) that I’ll be tweaking to measure sentiment, the general idea is that as an idea moves from neutrality to agreement (or disagreement), it’s also building up an “area” proportional to the number of people participating in the idea. This is important (imho) because not all ideas will garner the same attention and so we wouldn’t want to present relatively unimportant ideas to people.

Using those two models, I think I can measure “consensus” (general agree/disagree) and also “impact of consensus” (how many people actually give a sh*t).

Anyone want to help me with this part of the project? I’m not an expert at statistical modeling and it’d be great to get some pointers.

Nomics – A Game for Finding Consensus

March 12, 2012 crowdsourcing, experimental ideas, nomic game 2 comments

As I mentioned in a previous post, I’ve been interested in how we participate in the policy decision making process. I went so far as to state that both the Tea Party and the Occupy Wall Street movements were a reflection of deep frustration with our political process. I say this because, despite differences in demands and world views, the two movements are populist in nature.

From my perspective, the big “ah-ha” moment was when I started looking around for how the Occupy Wall Street group was organizing itself. There were websites here, Facebook fan pages there, but nothing cohesive. Moreover, nothing that I could find represented a “this is what we believe and this is what we want”.

Of course, I then asked myself, “What would people use to reach a consensus?”

I thought of the Nomic Game.
Eric Reis, author of Lean Startup, once said (something along the lines of), “People spend a lot of time worrying about their ideas being stolen…need to just get it out there…and I’ll bet that even if you tried to have someone steal your idea, you couldn’t.”

I’d like to take that bet. I’m going to present some initial conceptual thinking I’ve done on the Nomic Game as a tool for organizing political though. I feel comfortable doing this because I agree that it’s highly unlikely that someone will steal my idea. Or more accurately, if the idea is “stolen,” it was “stolen” because the person who originally thought of the idea didn’t do anything to move the idea from “idea” to “reality.”

In terms of what is built, I have the database (mostly) designed/implemented and will likely have something “poke-able” by the end of the week. That’s my goal at least.

When reading the conceptual overview, you’ll note a bit about “community” at the end. A big challenge that we deal with at Servio is, “How do we know that particular person is qualified to participate in this project?” I’ve put in a smidgen of initial thinking in this regard and see “communities” as a v.future feature set. I believe a little thinking about “how to protect an idea from the wrong people participating” (i.e. people who aren’t qualified) because I think a major mistake at crowdsourcing companies is that they don’t think about “project guards” up front. (I spoke about at CrowdConf last year; here’s a blog post on it).

Conceptual Overview of Using Nomics to Solve Political Engagement—my notes

There are people.

People can create or modify ideas.

People can agree with an idea.

People can also disagree with ideas.

Goal: Find the best idea with the most consensus.

——

This means there needs to be a way to associate one idea with another, as in an anscestory of ideas.

That implies we have a root idea, partent ideas, and children ideas.

The root is a parent but not the parent of all ideas.

The root is the parent of itself.

The root can have many children but no ancestors.

The root idea is the ancestor of all present and current ideas.

Some parent ideas are children of the root idea but others are children of children of the root idea.

The root idea is a mere proposal for more proposals.

The root idea cannot be agreed with or disagreed with.

The root idea can only create children ideas.

Once a child idea is created, it can be modified, agreed with or disagreed with.

A modified child idea is a new child idea.

The new modified child idea’s parent idea is the one from which the modified child idea originated.

At some distant time in the future, ideas can be merged with other ideas to create new child ideas–child ideas with two parent ideas.

Also in the future, a child idea can be merged with its parent idea or ideas.

—-

To track the consensus of an idea, the count of moment of agreements or disagreements must be tracked.

A moment of agreement or disagreement is a point in time when a person evaluates an idea and decides to either agree or disagree.

There can only be one moment of agreement or disagreement per idea per person.

A person can change his mind from/to agreement or disagreement.

If agreement changes, the count of agreement or disagreement should equally change.

Another word for moment of agreement or disagreement is vote.

—–

A simple idea is a belief.

If a belief cannot be stated simply, it is likely ill-understood.

Complex ideas originate from a lack of understanding.

Ideas should be simple, at least to start.

Ideas should have a one sentence-ish summary.

Ideas should have a three to five sentence description.

Ideas longer than this are likely too compelex and should be revised to be consise.

—

Access to ideas may require guarding.

All people do not have authority over all ideas.

There are communities of people.

People belong to many communities.

People who belong to some communities do not below to other communities.

People who do not belong to a community may or may not be allowed to access an idea.

Access to an idea is a decision of the person or community who propose it.

—-

An idea’s creator is the person who proposes it.

If two ideas are merged, the new merged idea’s creators consist of the originating ideas’ creators.

The root idea has no creators.

If the root requires a creator, the root idea is its own creator.

—

People are known or unknown.

Unknown people belong to a community of unknown people and no other communities.

Only known people can belong to communities of known people.

—

A community is a self-selected group of people.

Self-selected means that the people see themselves as consistently coming to consesus on ideas.

People can discover or create communities by identifying people who consistently agree or disagree with the same ideas.

An idea is only priviate to a community if the person who proposes the idea decides to make it so.

—

A consensus is the current balance of moment of agreements and disagreements.

There is no definitive consensus with an idea.

A consensus is a spectrum of agreements and disagreements.

There should be transparency into the specturm of agreements and disagreements.

There may also be a summary consensus which translates the spectrum consensus into either Agreement, Netural or Disagreement.

An agreement is when over 55% of moments of agreement occur.

If there is no majority of agreement or disagreement, 55%, the consensus is neutral.

People should create new ideas or modify ideas to resolve neutrality.

—-

People should be able to see what the parent or child ideas of the current idea are.

Occupy Wall Street, Developernomics and Management

December 8, 2011 business, crowdsourcing, experimental ideas 3 comments

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.

« Older Entries Recent Entries »