The Language of Social Networks

Posted: September 26, 2011 | Author: | Filed under: business strategy, consumer internet, social apps, social networks, social psych | Tags: , , , | 4 Comments

Facebook and Mark Zuckerberg have established near monopoly control over the language that we use to talk about social networks.  Think about the words that we use to describe social network sites — terms such as “like”, “share”, “connect”, “transparent”, “more open”, etc.  I’m not saying that Facebook were the first company to use these terms and they certainly didn’t invent them.  But I do believe that Facebook have been the most effective and the most consistent at using those words to frame the conversation about social network policies and features in moral terms.

The moral framework they’re creating around their social network site is really key to focus on.  Facebook are saying: It’s *good* to be liked, right?  It’s *good* to connect to more people, right?  You’re a *better* person if you’re willing to share more transparently, right?  And, conversely, if you’re *not* willing to share a thought or action openly, then what are you hiding; are you doing something that you *shouldn’t* be doing?

Facebook have purposefully created this moral linguistic context for their service.  As Zuckerberg masterfully puts it:

At Facebook we have a deeply held purpose […] Our mission: “Give people the power to share and make the world more open and connected.” In the world we’re building where the world is more transparent, it becomes good for people to be good to each other. That’s really important as we try to solve some of the world’s problems.

Source: http://www.insidefacebook.com/2008/07/23/live-notes-from-mark-zuckerbergs-keynote-at-f8-developer-conference/

George Lakoff, professor of linguistics and cognitive science tells us that, in any debate, if one side manages to dominate the moral framing of the issues, then they’ve already won the debate before it even begins.  Facebook appear to have learned Lakoff’s lessons well.  By framing the debate about social network policies and features in their own moral terms, Facebook could be walking away with victorious dominance over the social internet without firing a shot!  Every other social internet company has been forced to define themselves using Facebook’s terminology of “sharing”, “openness” and “social graphs” (i.e., attempting to beat Facebook at their own game) or to contrast themselves against Facebook’s feature functionality (i.e., attempting to convince the world that sharing, openness, and transparency are bad things).  It’s a lose-lose proposition either way and that makes it really hard for other companies to market and differentiate themselves using the language and concepts that Facebook own.

What are your thoughts on how the social network industry should move forward from here?  I’ll jot down some thoughts in my next blog post.  Would love to hear your thoughts in the meantime.

Crafting Code Across the Stack: 3 Benefits of Cross-Technology Engineering

Posted: July 7, 2011 | Author: | Filed under: consumer internet, engineering, product management, social apps, startups | Tags: , , | 8 Comments

One of the engineers in my startup asked some thought-provoking questions in a hallway conversation today:

Should engineers own end-to-end implementation of features that cut across multiple layers of our technology stack?  Or should engineers focus/specialize on specific layers of the stack and collaborate with each other to develop each feature?

I’ve repeatedly observed that small teams of developers run circles around large teams in every company I’ve ever been in.  [Caveat: I focus on consumer internet software, so my observations will be biased towards that industry.]  I have a strong preference for company cultures that encourage individual engineers to develop as much of a featureset as they can on their own.  If there’s a front-end user interface to be created as well as a backend API required to support a particular feature, I’d like to see the same engineer coding it all.   Obviously this isn’t always possible for either technical or personnel constraints, but it is the ideal in my mind.

Today’s announcement of Facebook’s integration with Skype is a timely example of this principle in action.  I wasn’t a direct part of that integration project, but knew the folks on both sides.  With two big companies like Facebook and Skype coming together, there were dozens of people involved in the overall project.  Even so, it was really remarkable to me to see how much of the integration really hinged on two key individuals — one on the Facebook side and one of the Skype side.  Both of those individual engineers are really amazing “multi-lingual” developers who were able to make key coding contributions across multiple layers of technology ranging from Java applets and compiled desktop executables to in-browser Javascript and CSS/HTML to server-based API’s and cloud services.

Seeing that reminded me of the three main benefits of getting engineers to own entire featuresets, even (or maybe especially) if they cut across multiple technologies…

1. Motivation

When an individual engineer works on a feature that they know is going to impact large numbers of users, they viscerally feel the huge contribution they’re making to their company (and society!).  Nothing is more motivating than feeling like your work really makes a difference.

2. Quality

An engineer who really understands an entire featureset front-t0-back is able to grok critical dependencies between technology layers more effectively than a team of multiple individuals.   I assert that the ability to see the whole picture enables the single engineer to more effectively write test cases, identify likely breaking points, and ultimately deliver higher overall quality code that is defensively coded against future commits.

3. Iteration

This is a key advantage for individual engineers: the engineer who designed and coded an entire featureset on their own will be more likely and much faster to modify/iterate their designs when presented with market feedback from real consumers.  In contrast, a team of engineers who each only coded parts of a feature (and therefore relied on some other person, usually a project manager or a product manager, to provide a holistic view and integration guidance) will be much slower to collectively process market feedback and iterate.

Now, this may all be much easier said than done…   For one thing, it’s hard enough to recruit great engineers in any given technical area, much less a team of cross-technology superstars.  And in practice, there are significant friction points to the lone-ranger style of development.  E.g., if every engineer is a gun slinger they may unwittingly produce a lot of conflicting or redundant code that at some point needs to refactored.  Furthermore, even if an engineer is capable of contributing code across many different levels of a tech stack, that doesn’t mean they will always *want* to do so…

Even netting out those potential disadvantages, I think that cross-technology development has a strong positive impact; especially in the consumer internet space where companies actually have a decent shot at recruiting engineers who can effectively contribute code across the entire LAMP (or insert your favorite mobile or web development framework here) stack.  And even if your company doesn’t, in practice, hand over entire featuresets to a single engineer to execute, I think it’s still really important to foster cross-technology understanding.  It can only benefit your team if the javascript front-end wizard really understands the database impact that all her AJAX calls are going to produce; or if your backend API engineer really understands how often and how quickly his REST services will be requested by a mobile client; etc.

Have you ever worked in a company that had a policy of “single engineer owns an entire feature”?

Payments: Critical for Social Network App Platforms?

Posted: March 20, 2008 | Author: | Filed under: social apps, social networks | Tags: , , | Leave a comment

I recently had the pleasure of connecting with TS Ramakrishnan.  Super smart guy and clearly one who know a thing or two about how to launch app platforms/APIs for social networks.

TS has an interesting short-list of four requirements for a successful social network app platform:

  1. Users — the social network must be large enough to bring lots of distribution to app publishers
  2. Language — platform must be backwards compatible with existing web development languages/frameworks
  3. Marketing — the social network must expend significant effort to recruit, retain, and support app developers
  4. Transactions —  the social network must facilitate secure transactions (i.e., payments)

I found his last requirement to be really thought-provoking…  It sounds like a pre-requisite for ecommerce transactions, but we haven’t seen a whole lot of apps pursue ecommerce models yet on social networks.  The vast majority of social apps are 100% ad-supported, but we’re starting to see some “freemium” models develop.  For instance, Slide’s SuperPoke app has Premium poke actions that users can get access to via a monthly subscription.

Even in an advertising-dominated economy, I wonder if the social apps on Facebook might monetize more efficiently if Facebook were to facilitate the payments/collections process between ad networks and app publishers?  E.g., would social ad networks operate more efficiently if ad units were rendered in FBML and Facebook provided standardized tools for measuring impressions, clicks, follow-on actions, pathing; and financial transaction support for buying/selling social ads…