Toxic lies about culture are afoot in Silicon Valley. They spread too fast as we take our bubble money and designer Powerpoints to drinkups, conferences and meetups all over the world, flying premium economy, ad nauseam. Well-intentioned darlings south of Market wax poetic on distributed teams, office perks, work/life balance, passion, “shipping”, “iteration,” “freedom”. A world of startup privilege hides blithely unexamined underneath an insipid, self-reinforcing banner of meritocracy and funding. An economic and class-based revolt of programmers against traditional power structures within organizations manifests itself as an (ostensively) radical re-imagining of work life. But really, you should meet the new boss. Hint: he’s the same as the old boss.

The monied, celebrated, nuevo-social, 1% poster children of startup life spread the mythology of their cushy jobs, 20% time, and self-empowerment as a thinly-veiled recruiting tactic in the war for talent against internet giants. The materialistic, viral nature of these campaigns have redefined how we think about culture, replacing meaningful critique with symbols of privilege. The word “culture” has become a signifier of superficial company assets rather than an ongoing practice of examination and self-reflection.

Culture is not about the furniture in your office. It is not about how much time you have to spend on feel-good projects. It is not about catered food, expensive social outings, internal chat tools, your ability to travel all over the world, or your never-ending self-congratulation.

Culture is about power dynamics, unspoken priorities and beliefs, mythologies, conflicts, enforcement of social norms, creation of in/out groups and distribution of wealth and control inside companies. Culture is usually ugly. It is as much about the inevitable brokenness and dysfunction of teams as it is about their accomplishments. Culture is exceedingly difficult to talk about honestly. The critique of startup culture that came in large part from the agile movement has been replaced by sanitized, pompous, dishonest slogans.

Let’s examine popular startup trends that are being called “culture” and look beneath the surface to find the real culture that may be playing out beneath it. This is not a critique of the practices themselves, which often contribute value to an organization. This is to show a contrast between the much deeper, systemic cultural problems that are rampant in our startups and the materialistic trappings that can disguise them.

We make sure to hire people who are a cultural fit

What your culture might actually be saying is… We have implemented a loosely coordinated social policy to ensure homogeneity in our workforce. We are able to reject qualified, diverse candidates on the grounds that they “aren’t a culture fit” while not having to examine what that means - and it might mean that we’re all white, mostly male, mostly college-educated, mostly young/unmarried, mostly binge drinkers, mostly from a similar work background. We tend to hire within our employees’ friend and social groups. Because everyone we work with is a great culture fit, which is code for “able to fit in without friction,” we are all friends and have an unhealthy blur between social and work life. Because everyone is a “great culture fit,” we don’t have to acknowledge employee alienation and friction between individuals or groups. The desire to continue being a “culture fit” means it is harder for employees to raise meaningful critique and criticism of the culture itself.

Meetings are evil and we have them as little as possible.

What your culture might actually be saying is… We have a collective post-traumatic stress reaction to previous workplaces that had hostile, unnecessary, unproductive and authoritarian meetings. We tend to avoid projects and initiatives that require strict coordination across the company. We might have difficulty meeting the expectations of enterprise companies and do better selling to startups organized like us. We are heavily invested in being rebels against traditional corporate culture. Because we communicate largely asynchronously and through chat, it is easy to mentally dehumanize teammates and form silos around functional groups with different communications practices or business functions.

We have a team of people who are responsible for organizing frequent employee social events, maintaining the office “feel”, and making sure work is a great place to hang out. We get served organic, vegan, farm-raised, nutritious lunches every day at work.

What your culture might actually be saying is… Our employees must be treated as spoiled, coddled children that cannot perform their own administrative functions. We have a team of primarily women supporting the eating, drinking, management and social functions of a primarily male workforce whose output is considered more valuable. We struggle to hire women in non-administrative positions and most gender diversity in our company is centralized in social and admin work. Because our office has more amenities than home life, our employees work much longer hours and we are able to extract more value from them for the same paycheck. The environment reinforces the cultural belief that work is a pleasant dream and can help us distract or bribe from deeper issues in the organization.

20% of the time, or all of the time, people can work on whatever they want to

What your culture might actually be saying is… We have enough venture funding to pay people to work on non-core parts of the business. We are not under that much pressure to make money. The normal work of the business is not sufficiently rewarding so we bribe employees with pet projects. We’re not entirely sure what our business objectives and vision are, so we are trying to discover it by letting employee passions take root. We have a really hard time developing work that takes more than a few people to release. We have lots of unfinished but valuable projects that get left behind due to shifts in focus, lack of concentrated effort, and inability to organize sufficient resources to bring projects to completion.

We don’t have managers and the company is managed with no hierarchy

What your culture might actually be saying is… Management decisions are siloed at the very top layers of management, kept so close to the chest they appear not to exist at all. The lack of visibility into investor demands, financial affairs, HR issues, etc. provides an abstraction layer between employees and real management, which we pretend doesn’t exist. We don’t have an explicit power structure, which makes it easier for the unspoken power dynamics in the company to play out without investigation or criticism.

We don’t have a vacation policy

What your culture might actually be saying is… We fool ourselves into thinking we have a better work/life balance when really people take even less vacation than they would when they had a vacation policy. Social pressure and addiction to work has replaced policy as a regulator of vacation time.

We are all makers who are focused on shipping.

What your culture might actually be saying is… Features are the most important function of our business. We lack processes for surfacing and addressing technical debt. We have systemic infrastructure problems but they are not relevant because we are more focused on short-term adoption than long-term reliability. We prioritize fast visible progress, even if it is trivial, over longer and more meaningful projects. Productivity is measured more by lines of code than the value of that code. Pretty things are more important than useful things.

Closing

Talk to your company about culture. Talk to other companies about culture. Stop mistaking symbology and VC spoils for culture. Be honest with yourself, and with each other. Otherwise, your culture will kill you softly with its song, and you won’t even notice. But hey, you have a beer keg in the office.

The Love of Launch

When I first started my career in Silicon Valley, I made the profound mistake of getting an entry-level job in tech PR, a generally sycophantic industry that is, among other things, a sprawling ghetto for women, a crutch for bad products, a sworn enemy of plain English, and a pit of lies and incompetence. There I launched all of the things until quitting in disgust and rage, which is the only way to quit anything.

A year later I managed to crawl my way out of one gutter only to behold a much broader and more institutionalized launch sickness. Here in technology we launch all of the things: funding, companies, products, betas, GAs, 2.0s, APIs, affiliate programs, contests, features and versions. Launching is a cash racket. Reporters, analysts, editors, PR firms, social media experts, party planners, sponsorships, advertising and SEO black magic are just a small cross-section of what amounts to a billion-dollar tech launch machine.

Launches can do good things for you. More users, more partnerships, more funding. But launching will also infect culture, cost a fortune, distract teams, mislead users, screw up metrics, and keep startups from building successful products. Tonight we investigate how launches will fuck you up.

Launches Lead to Addictive Metric Spikes

Most of us have experienced a crazy traffic spike from a launch: hit Reddit, HackerNews and TechCrunch on the same day and watch your Google Analytics graph reach heights only previously rumored. Get some of that all-over bodybuzz as Twitter mentions, notes from VCs and partners, and your top users (if you have any yet) come in. The top of our funnel overflow’th! Teams feel rewarded for their hard work and effort; VCs are pleased with the buzz; marketers thrill over coverage wrap-up emails to the entire company.

One month later. We’re trending normal again. The traffic spike is followed by an inversely proportioned traffic dip. The marketing team experiences internal and external pressure to get “up and to the right.” A number of possible scenarios unfold in which the long-term impact on metrics from launch (sign ups, users, qualified leads, sales) are unknown, ignored or buried, making it extremely difficult to determine or acknowledge the actual value of the launch, including:

• The product or feature launched is not instrumented, poorly instrumented, or too early-stage to have a good indicator of longer-term success (active usage, qualified lead, etc);

• The launch is not tied to a call-to-action or meaningful goal like driving leads, partner opportunities or early adopters; - the launch IS the meaningful indicator;

• Indicators exist but aren’t positive - the launch drives visits but not usage, traffic but not signups, or related breakdowns in the funnel; still the launch is imagined to be an indicator of “market demand” or “product market fit” and is considered a success;

• The excitement of the launch is so gratifying that your team ignores any indicators of long term success whatsoever. Witness advanced and seasoned executives become so giddy over the attention, tweets and blog traffic that they immediately put together the machinery to create a repeat performance without any rational thought given to whether the act of launching is driving the health of the business.

At the end of the day, the conclusion is the same: This launching stuff is good.

The company devotes many resources, brains, and effort to create launches. Many more. In extreme launch sickness, companies alter their product roadmap to produce an “event” around which a launch could be created. Time, money and energy is devoted to launching or “building thought leadership” when it should probably be spent elsewhere: listening to users, watching what they do, measuring behavior, adding meaningful features, iterating in safe places, discovering and nurturing customers and working the other parts of the funnel. Oh yeah. Building shit that works.

How many products do you know that have had conferences before production users?

That.

Launches Let you Fake It

There are honest launches. Launches where teams have worked really hard on a product that they’ve been dogfooding or want to test, launches where something meaningful is being communicated. But there are often launches that lie. Companies launch products which don’t exist yet, create gimmicks, invent noise-machines, throw parties, pay-for-play, exaggerate and manipulate their way to news articles. There are a number of cultural and economic incentives that lead or allow this behavior:

• “Keeping up with the Joneses.” Your competitor or other companies you relate to is in the Magic Quadrant, winning startup competitions, presenting on stage and issuing press releases every other week. The pressure to compete with launches is tough to ignore.

• Launches can create the appearance of traction - both inside and outside a company - that can cover up stagnation or disappointing progress in other core indicators.

• Launches capture attention - deserved or not. In a news-obsessed culture where everyone - reporters, users, and companies are rewarded for being either in “the now”, or in “the know”, launching can be one of the only ways to look and feel relevant.

• Launching doesn’t need content to succeed - money, skill and luck work too. You can buy consultants, PR firms, elaborate sponsorships, and massive events that will create a launch in almost complete absentia of meaningful content.

The Truth About Launching

In isolation, all metrics are lies. The press release is a lie. The traffic spike is a lie. The hype machine is a lie. Launch real shit, responsibly, then go back to doing real work.

Sample post - I’m moving my blog to Octopress. <3

I’m in London this week as we set out to grow @Apigee in the UK and throughout Europe. With the aid of sleeping pills, alcohol and the in-hotel gym, I’m fighting the good fight against jetlag and managing to stay sober for scrum calls and 2:00 am BST meetings with developers and designers in the US, all while meeting with customers, prospects, users and community people here. This is hard, I want to go shopping.

Good news though: I’m about to make status on my airline despite now much- regretted trysts with Virgin [because it’s sexy] and Alaska [because it’s cheap], a good sign I’ve been really busy working with startup and tech communities across the country - New York, Atlanta, Seattle, San Diego, Chicago, D.C., more. Tonight I attended the Hacker News London #hnlondon meetup, and talking to startup people there got me thinking about the “startup scene” across, well, everything. I spend more and more time working with startups, organizers, and aspiring entrepreneurs in emerging tech centers, and they all want to know what strong startup communities have in common, and how they can boot up those same conditions. So this post is about where emerging startup markets can invest to build a better ecosystem.

Create promiscuity*

*which lines the virtuous road to community. 

Every healthy tech community is mad promiscuous. Promiscuous in the sense of variate __and frequent coupling - of companies, startups, students, technicians, hackers, weavers, schemers, groupies, marketers, spaces, locations. Promiscuity is what underlies our experiences of “richness”, “diversity”, “creativity”, “vibrancy,” “buzz”.

The promiscuity you find in mature startup communities is only possible with:

• Available, highly permissive common spaces
• Adoption of low-barrier online tools that describe communities and their interactions
• Promiscuous, open, accessible, extensible product ecosystems

Emerging startup scenes must invest in the growth of each to succeed. 

Common Space 

Successful startup communities have anywhere from 4-5 to many dozens of spaces or organizations that serve as the physical and social “home” of communities. In San Francisco you’ve got gems like Hacker Dojo, willingly loaned corporate spaces like PayPal and LinkedIn, coworking hubs or the offices of startups who open for tech events, office hours, conferences and hackathons. PROTIP: these places are available free or cheaply, with adequate resourcing for good wifi and comfy seating, and a permissive attitude towards content and hopefully booze. Available space is, at its core, an economic issue.

Successful common spaces are created by one of two models: a.) benefactor [typically a large, profitable company with a benevolent interest in community building and innovation];  b.) estate [space-focused organizations that are financially invested in community building of small businesses/startups, i.e. coworking spaces, coffee shops, etc.].

London has beautiful examples of both. It is palpable how on one side TechHub (a coworking center), and on the other the Guardian (yes, the media company) have fostered community by providing this necessary space. Excitingly, you see the beginning of this community infrastructure in emerging startup hubs like Chicago- Morningstar is one company making powerful gifts to the community in the form of open, accessible space.

In the weakest tech communities, appropriate space for community-building is extremely difficult to find, expensive, or suffering from content control of large corporate sponsors.

Online Community is Predictive of Offline Community. 

Another common theme in successful startups scenes is the adoption of community tools (Meetup, Eventbrite, Lanyard) that serve as logistical centers as well as social, cultural repositories or breadcrumbs into people, what they are doing and why.

Weaker tech communities have much more fragmentation in tools usage, much higher use of tools that are proprietary or highly segregated from a larger network, and tools that don’t do a good job of showing you the other people in your community and what they are up to.
Tools matter. Online visibility into communities is predictive of the offline community. Use tools that illuminate the community and you will grow it. I encourage community organizers in smaller markets to really think about pushing adoption of a small set of appropriate tools to gain critical mass of adoption on a limited set of distribution engines, weather that be a mailing list, a fancy social network or something you build yourself.. Having 100 or 200 people using a common tool is much more powerful than groups of 30-40 using 3-6 different tools each.

Promiscuous product builds community too. 

Silicon Valley is the shining example of how promiscuous products hinge great communities. Promiscuous product ecosystems inherently encourage community. Promiscuous products are ones with open APIs, with source code, with awesome documentation and GitHub accounts, with extensible hooks, with integrations of data services, with visible opinions but viable options. Promiscuous product ecosystems have a focus on transmitting knowledge, sharing best practices, and enabling other products to benefit from yours. Promiscuous products hook into a vaster technical, social and cultural fabric that inherently predicts community.

Early startup markets tend to have more clustering around proprietary, inaccessible and high-barrier technology and lack promiscuous startups built with promiscuous technology. They have less focus on knowledge sharing, and skew towards experts (the few), not learners (the many).     

Tim Falls of SendGrid predicted in our Twiliocon panel on developer community management that the future would see more cross-pollination of API communities as we tear down technical and adoption barriers to community (better interface design, standardized authentication, adherence to REST) and find synergies and, therefore, more effective ways to work together from a community and marketing perspective. This is a fantastic example of how technical trends are actually key to the cultural development of startup scenes.

There is no questions that light-weight BD, extensibility and permeability offered by open tools and open APIs contributes to healthy startup scenes - for example, one of the startups that presented tonight at #HNlondon was Stickygram, a company built on the Instagram API that lets users easily order fridge magnets of their photos. In doing so, Stickygram tapped into a significant local ecosystem of users as well as an international community of Instagram users. Their success helps build interest, content and activity in APIs and “lean startup” companies in London. ITS LIKE A VIRTUOUS CIRCLE OF PROMISCUOUS BEHAVIOR. I encourage people invested in building a startup community in their city to think about how to leverage product promiscuity and education about promiscuous technology into broader community engagement.

At #HNLondon, Harj Taggar of Hacker News spoke about the need for emerging scenes to support experimentation, “failing fast”, and rapid release. He commended one of the startups that presented as an example of the cultural attitude emerging markets need to cultivate: “It started with someone who had an idea… hack together a very quick prototype, release it, and find out that people are actually interested in it.”

This gets to the heart of the promiscuous product ecosystems that predict amazing startup culture: adoption of technology that supports lean, agile, rapid bootstrapping; and accessibility to the knowledge gained from fucking around with it.

Tap Into The Hive Mind. 

Technology is a hive mind. Jack in. Living in Silicon Valley, it’s super easy to forget ALL THE OTHER PLACES IN THE WORLD. But then you go to London, to Atlanta, to Haystacks, Squirrels and Misquitoville Minnesota, and you realize we are all talking about the same things. _Lean startup. Launch early. Iterate often. Listen to users. HTML5. Touch. Geolocosocialplatformification. _

Successful startup communities align with global trending. 

We are separated by vast differences in location but we are often united in extremely powerful ways: use of the same mass media and distribution tools (Hacker News, StackOverflow, tech news outlets, Twitter), global dissemination of trends (mobile hardware, cloud computing, open APIs, high-level languages, HTML5). Successful s__tartup scenes have more proportional attention to the trending hive mind. They have more meetups and education on things like open APIs, mobile frameworks, new languages. They are trendy. Trendy works. Invest in fashion. Bring the hive mind home. Successful communities feel engaged in building some kind of future, connected to some kind of global happening. They show up because they are scared if they don’t, they’ll miss out on the next big thing. When they go home and read Hacker News, they now see themselves. They feel aligned. There is a sense of vitality and movement. If you’re trying to build startup community, bootstrap it on the back of global trending.

But Do Reinvent the Wheel

I haven’t been to a single tech event in a single city where I couldn’t do a conference call in the women’s bathroom. Why? It’s quiet in there.

The underrepresentation of women in the startup community is at a fucking monumental global scale. All tech communities I’ve encountered similarly struggle with issues like outsourcing, lack of racial diversity, lack of accessible education, prevalence of elitism and social media douchebags.

I have a lot of hope that emerging startup scenes will take the opportunity to create a better model that is both more inclusive and diverse. So as much as new scenes should try to emulate the conditions and successes of others, they also shouldn’t forget they have the chance to build the world anew.

Fall is bringing tons of travel and events. If you’ll be in SF, New York, London or DC - let’s meet up!  

This Wednesday I’ll be moderating a panel at Twiliocon, Twilio’s first-ever conference. Over the course of the panel we will endeavor to answer the question: Developer community management, how does it work?

I’m really psyched about the speakers: Jason Costa from Twitter, Sara Ford from Black Duck Software and Tim Falls from SendGrid, plus I have it on good authority that Twilio’s Danielle Morrill will have a front-row seat to ask the hard questions. I’m particularly interested in speaking with the panelists about where community management fits into product development. Join us on Wednesday at 1:20 pm and @ sign me if you have questions in advance - but we’ll be taking lots of audience questions too. I’ll try to write up a blog on the panel afterwards so STAY TUNED.

Shanley Goes to London. We are expanding Apigee’s presence in the UK and Europe, which means I’ll be traveling “over the pond” more than I usually have an excuse for. There are a number of fantastic startups with APIs and enterprise platforms both established and emerging that call London home, so I’m excited to get a chance to smooze up the local scene. I hope to get a chance to do more international travel - there are, after all, Apigee users literally all over the globe (really makes you realize the global scale of the so-called “API Economy”.) Anyways, in London you can find me checking out the mobile developer conference Over the Air on September 30 and on Saturday, October 1 we’re hosting API Developer Day, a one-day coding events highlighting presentations from API teams including Twitter and Pusher (which I wrote about in my blog on FdeveloperUE). It’s sponsored by BlueVia, hosted at TechHub and even though we’re ALL FULL already, still looking for a few more APIs to present, so shoot me a note if you want a demo slot - shanley @ apigee.com

I’ll be making a brief stop in New York for one of my favorite conferences - Web 2.0, October 10-13. My colleague Sam Ramji will be giving a talk on successful API strategies and I will be meeting with customers and scouting out the local scene. Alex Donn (my co-organizer at Mobile App Hackathon) are looking to host an event there early next year, so I’m looking for space, local contacts / friends and general API party people.

After New York, I’ve got two weekends in a row with Mobile App Hackathon. Hard to believe that in January Mobile App Hackathon was just an idea, and now we’ve held events in Seattle, Redmond, Chicago, San Diego, Atlanta and Silicon Valley - we’ve seen hundreds of amazing developers, dozens of great apps and business ideas, and mind-blowing support from sponsors. On October 15th we’re coming to Washington, DC; and on October 22nd we’ll be getting back to basics in San Francisco (with a great lineup of super hot Valley startups including Twilio and Heroku).

 GIVE SOME SATISFACTION! 

“First developer experience.” I’ve been thinking about it lots lately, in my day-and-night-job at Apigee and alter-life as a brownie-eating code princess in a trice-weekly knife-fight with Ruby. This post is about 5 developer frameworks/APIs/tools/platforms that give great FUE, my fav 5 inspirations of the now.

They all do something awesome: They get you to request/response, action/reaction, bell/salivation, to their own personal Hello World as fast as possible. They constrain TTFHW (Time To First Hello World), if only in a test environment, to get you to the I TOLD YOU TO DO SOMETHING AND YOU DID IT moment, that moment of I SEE WHAT YOU DID THERE. If we  subscribe to Matz-ism, “We are the masters. They are the slaves,” then we shall call this “accelerating the master/slave moment.”

These 5 examples recognize the innate pleasure of machine responsiveness to human touch, the weight of speed in net pleasure, and the value of that pleasure as a conversion catalyst. And they are getting biblical delivering some seriously fast Hello World satisfaction.

1. PUSHER API  

The Pusher API. Realtime events for mobile and web apps. Right on the FRONT PAGE of this sucker they have this big beautiful button that says “Test It Out” and when you do, it gives you this code to paste into your terminal, so you do, because you’re a conformist, and you press enter and voila. A notification pops up in the browser. TIME TO SATISFACTION: SECONDS. (Thanks to hot-shot designer @itchymutt for sending this one my way).

2. SINATRA 

First let me say I’ve had a beautiful experience withSinatra. Actually it’s the only thing I’ve loved so far about Ruby. Sinatra is to Ruby what skinny boys who play guitar are to high school. Even being super Explain this Clarissa with Ruby frameworks, I was able to Hello World real fast… in part because their ENTIRE FRONT PAGE is about getting you there. TTFHW. Get sum.

3. PAPER.JS 

Just let me say that if you are trying to build a great first developer experience, the first time you check out Paper.js might be emotional for you - it was for me and my team. It’s “an open source vector graphics scripting framework that runs on top of the HTML5 Canvas.” And it is beautiful. When you first load the page, your mouse can manipulate the graphics. And when you click “Source” you can NOT ONLY SEE, BUT ALSO EDIT the code, then run it. And there are tons of fun examples, including ones that involve rainbows. #winning. Paper.js uses CodeMirror to make the magic happen.

4. BASHO 

Riak (open source scalable data store) is a slightly different flavor from the rest, but I picked it as an example of addressing complexity and varying knowledge in FUE , while still getting users to “Hello World”.  The “Riak Fast Track” is a 45-minute course to get started and on step 2 they’ve already got your sweet n00b ass building a cluster. They also have an information scheme for getting around to the parts and complexity levels that are relevant to more knowledgable users. Despite all the Paper.js rainbow-fanciness that is emerging in the world, good solid text/video documentation that focuses on getting to a first moment of triumph is still super important… and sometimes more appropriate.

5.  JS Bin 

It’s a few years old now, but JS Bin is still a shining example of the value and addictive quality of play, touch, responsiveness and rapid prototyping in developer tools. JS Bin is a pastebin with the added sex of YOU CAN RUN THE CODE. A super slick collaborative debugging/sandbox tool that is still much beloved today. I love how when you load the page THERE’S CODE THERE ALREADY BRO, which makes it super easy to figure out what-exactly- is-going-on-here. I think that at some point we’ll see code you run, prototype/preview, and edit in the browser become more and more expected by first users but in the meantime, JS Bin offers a simple, shining view of a better future.

** OK not quite “Good,” but good enough to bat the 90th percentile most of the time, which would technically be “Good by Relationship to Other Startups, Most of Which Totally Suck at Communicating,” but you’ll take it, because you know in your heart that consistent mediocrity is almost like winning. 

Let us begin. One of the first things that they tell you when you learn to write is that you must imagine the reader. Sounds like basically a stroke of genius, predicated on the perfectly sound theory that when you write something, you should do it with an audience in mind that is gonna read your shit. 

This would be totally fine and you would merrily ascend to startup marketing superstardom except for one tiny little logical fallacy, which is that this whole magical parlor trick of “imagining your audience” assumes there is a “reader”, which of course depends on having someone-who-reads, and pretty soon you are running around like an idiot with this mythical archetype in your head of someone-who-reads,  AKA one of the biggest lies in the history of the world since they invented Geocities.

People Do Not Read 
How do we know this? People who ostensibly DO READ (hint: people who work at universities), study people like you and me (who DO NOT READ) and figure out stuff like this:

52% of all web page visits, including repeat visits, are shorter than 10 seconds. Almost 50% of visits to new pages are less than 12 seconds.   Not Quite the Average: An Empirical Study of Web Use

The other 50%? Not a whole lot better, and made up of lots of people leaving their browsers open while they do other things like take showers. So what are people doing if they aren’t reading your shit? Basically here’s what happens when someone loads something that has words on it:

Looks like a toddler went batshit in some spaghetti. But no. It’s a graph of a ton of aggregate data that tracks eye movement on webpages. If this picture had a caption, it would be: People aren’t reading your shit. In fact, they are barely scanning it. They are looking at anything that is either big, colorful or moving and then they are looking for the next place to click. If you study users at all, you will quickly find out something fundamental about people: They hate to read, but boy, do they love to click shit.

Simple lesson: Stop writing things for people who read. Start writing things for people who don’t read.
Now I hope you’re ready for some more knowledge to get dropped on you. Here it is.

People Want to Get Shit Done 

There are only four reasons why people do anything on the internet:

• Fix shit that is broken
• Do shit that already works better   *
• Stalk people
• Acquire sex, music or television **

* “faster” is part of “better”

** “food” is covered under the category “sex”

Good news: these things provide the only incentive there could possibly be for anyone to read your stuff in even the half-assed way that typifies “reading” online. (In language theory, we have a fancy word for half-assed called ‘satisficing’. It’s a combination of ‘satisfy’ and ‘suffice’. Amazing.)

Here’s where it gets rough. The Golden Rule of Users (people want to complete TASKS) is in conflict with the Golden Rule of Reading (people don’t want to read), even though you usually have to Read in order to Complete a Task. We can express the resulting behavior in the following graph, where “Pain of the Status Quo” refers to  a.) how painful the broken shit is b.) how painful the shit that sortof works is c.) how strong the desire to stalk people or d.) how extreme the compulsion to acquire sex, music or television.

As the graph clearly shows, there is a point at which the pain of reading your # Ruby gem documentation  shit grows so unbearably painful that it doesn’t matter how much original pain or desire I’m in, I’m going to stop reading it. Guess what? This threshold is way, way lower than you think.

In summary, your writing only has two possible goals: 1.) Convincing people that your stuff can help them do something they want to do AKA intensifying the pain and desire of the status quo 2.) Give them what they need to finish the job AKA sate the pain and desire of the status quo.

And you must do this WITHOUT making them ragequit (see: Point at Which It Does Not Fucking Matter how Bad the Status Quo Is).

Minor Lesson: Pain and desire. A necessary part of every unhealthy relationship. And you know. reading.
Major Lesson: Your writing must help people get shit done while allowing them to read as little as humanly possible. 

Conclusion

I know by now you’ve reached the only logical conclusion there is to reach, which is.

There is never any reason good enough to merit writing a press release. 

No seriously. STOP THE MADNESS.

*** thanks to @solidsnack for fixing my dyslexia in this post. 

This a thought experiment in examining programming communities as cultural, semiotic and socioeconomic artifacts. The main goal is to explore the analysis of emerging languages outside of technical criteria, which while imperative, often fail to explain the complex causes and consequences of trends in our sector. It focuses on Ruby as an example of radical culture functioning as a constructive agent of code. NOTE: This post is both US and Silicon Valley- centric.

PREMISE:  The Tangled Web of Code and Culture
1. Programming languages are economic forces.

Code provides the basis for ecosystems that are fed by, and feed on, investment, revenue, careers and education. In many ways, languages are distribution networks for libraries, tools, platforms, packaging and licensing, communities. Thus the viability and spread of programming languages is not at all disinterested in economic factors.

2. Programming languages are political and socioeconomic.

Coding is, at its core, the ability to control machines and ultimately, to control users and shape their lives and behavior. Historically the barrier to power inhered in programming has been extreme. In the United States, programming and its associated culture, power and economic benefits have been restricted to middle America white males. Where programming as craft can be moved further towards the commodity line, it is outsourced as cheap labor in acts that skirt imperialism in their mildest form; in their extreme represent the systematic exploitation of foreign resources and the gutting of domestic ones. All specialized, non-commodity knowledge with economic bearing risks must serve a wealth distribution model, often patriarchy and nationalism.

3. Programming Languages are Cultural Artifacts

As a cultural artifact, race, Manifest Destiny, criminality, education, gender, war and pop culture all affect, intersect, and are projected, fetishized, commoditized and absorbed by coding culture.

4. Programming languages are inherently viral and massively resilient.

A language’s foundational political and socioeconomic contexts and consequences are codified in proportion to its rooting in the technological fabric. Code spreads. Code bases are shared, forked, modified, copied, re- purposed, built on top of. Code is spawned in underlying infrastructure, embedded in stacks, shared inside of and on top of a thousand intersecting stacks and networks. In its most contemporary form, it propagates in a social graph rift with economic, social and sexual consequences. Code is hard to rip out, it is costly to rewrite. It grows webs of dependencies. Code carries its political and socioeconomic consequences into the technical infrastructure, where it can enforce and maintain the power systems that contextualize it.

Radical Constructions of the Actor in Programming
Coding communities both reflect and construct an actor base - or the people who use and implement code. As much as primarily white, male coding communities REFLECT an actor base, they also CREATE and PROJECT an actor base. Most coding communities functionally eliminate the possibility of a female actor except as a sacred and/or sexualized exception.

The fact is:

The vast majority of the technical infrastructure has been created by men.

The technical infrastructure….. as in, all of it.

Against the culture backdrop of a male-made global technical infrastructure, Ruby as a community is unique in constructing the possibility of a female or minority actor, with several emergent institutions specifically addressing adoption in the gender group, and perhaps more importantly, a consistently inclusive rhetoric:

Common Descriptive Words

open source simplicity   general purpose lowering barriers learn fast easy newcomers beginners human

Look at these words as opposed to those that appear most frequently  in Java:

Sun Oracle expert certification JVM Applets Applications Runtime specification Technical

The Big Shift
While very basic, this list of word typifies the ongoing friction between the programming languages of the traditional enterprise and high-level, “humanistic” languages such as Ruby, specifically as they relate to the construction of an actor.  Today, technological ubiquity (the iOS platform, mobile networks, massively scaled social sites, etc) is not only possible but births a volatile and virtuous tension between the caustic, newborn socialist/capitalist hybrid clusterfuck of Free (massively scalable social networks, open source) and the patriarchal elitist vanguard of luxury, capex prohibitive hardware and white male bourgeoisie machine control.

As an economic, viral organism, Ruby lacks the historical legacy, the deep roots in infrastructure, the corporate control, and the barrier to entry that would make it profitable on yesterday’s programming ecosystems and business models-  models which emerged in part as a function of programming as a highly specialized, expensive or outsourced skill functioning as an agent of patriarchy and racial supremacy. (Systems that are reliant on extremely specialized knowledge breed business and economic models that make that specialized knowledge highly profitable. See: Maintenance contracts. Services. Training. Lock-in. Proprietary technology. Computer science degrees). As a result, Ruby focuses on amplifying its inherent virality through the more democratic, social community values that have emerged alongside “Web 2.0” (Systems which are reliant on making knowledge (services, tools, etc) more highly available breed business and economic models which make adoption highly profitable. SEE:  Advertising. Software libre. Social applications. Open source. API platforms. The new large-scale adoption imperative.)

This in part explains why Ruby is unique, even among higher-level languages, for its focus on making coding more accessible and inclusive. Descriptions of the language and its community often focus on learning, speed, and ease of use. Ruby is a front-runner in education of beginners and enabling under- represented or emergent populations, such as women and children, to program. Ruby as a cultural artifact and semiotic object represents the emergence of programming  - and thus machine control and the access to power & wealth it implies – as a viable, available, community-enabled tool for minority populations. It is a step in re-creating how we construct gender as a function of, and actor of, programming and technical ability, and how we conceive programming and machine control in the context of actors.

MYTHOLOGY, FETISHISM AND CULTURAL TENSION
The technology industry, especially in most magnified and concentrated form factor (Silicon Valley), is equally if differently subject to the same fetishes, mythologies, sexualization, xenophobia and xeno-fascination as popular culture.

Machine Control Fetish
Mankind has a bizarre, normalized and omnipresent machine fetish that pervades every aspect of culture high and low, technical and consumer. Apple is a classic example of the sexualization and fetishification of machine power; this is also seen in consumer products like Svedka Vodka.

Ruby is constructed as a sexual, sensuous, and exotic language as a function of its core rubrics and the semiotic/anthropological contents of the ecosystem built around it. The names used to describe it have a certain luxury and rarity: Ruby, its libraries Gems.  Two of the most popular Ruby PaaS platforms, Engine Yard and Heroku, illustrate the semiotic duality of the language: Engine Yard with its highly industrialized codification and Heroku with its visual sensuality, elegance, and appropriation of Japanese cultural symbols.

Race and Code
The Ruby community itself has been significant in the commercialization of the geek pop culture meme of “beautiful, elegant, simple code” and variations. In Ruby, programming is constructed as an aesthetic art, its ecosystem blending the dehumanized austerity of machine control automation with the evocative fetishification of Japanese culture and a new or reborn aesthetic sensibility of programming as art – all semiotic tactics that can flourish in the mass- marketing opportunistic breeding ground of a high-level, accessible programming language.

Whereas many programming languages appear ethnically neutered, Ruby’s heritage as a Japanese-originating language is a pervasive element of how it describes and documents itself. The strong ties between the US coding community and the Japanese Ruby community, as well as theongoing geo-centricity of Ruby core maintainers, has presented both a unique marketing opportunity and the need to navigate cultural tension through symbolism.

The pervasity of Japanese culture in the symbols and language used by US Ruby coders borders the practices described in Said’s Orientalism. The co-option and re-contextualization of stereotypes, which often serves to ease racial tension by the reduction of complicated racial relationships to simple linguistic and visual signs which can be used as (often sexual) propaganda by the dominant culture.

The Collision of Geek with Mainstream
While problematic for a number of reasons, including the reduction of cultures to objects in the service of differentiating machine control systems, Ruby’s Japanese fetish does indicate something about the larger trends and context of programming languages as they spread beyond their roots in search of large- scale adoption as a basis of economic viability.  _As higher-level languages and frameworks which increasingly abstract from the binary language of bare metal into something which everyday resembles English and simple games more and more, geek cultures normally defined by technical differentiators will encounter, co-opt and blend with the established propaganda of pop and consumer culture. _

The Role of Founding Mythology
The centricity of Japanese culture in the Ruby community seems deeply related to the technical community’s fixation on founding mythology. Successful companies will build or discover the cult of personality – I was only in Silicon Valley for a few months and I had already heard more than I ever wanted to know about how Twitter and Apple were founded, about the cultures and philosophies of their founders, etc. Blown to new proportions by the availability of founder personality in the form of media, social networks, and events, the “founding myth” of a company, whether true or not, can play a large role in how we view a technology either favorably or disfavorably, and how we determine a technology’s relationships to our own lives and its future path.

In this climate of technical community obsession with founder’s stories and mythologies, it is no surprise that Ruby’s founder “Matz” has become something of a cult object, and his origination (Japan), a central part of the “Ruby story” that is told and marketed in the community.

Conclusion

• As programming languages and machine control become increasingly accessible to minority populations, the impact they have on constructing actors, power and community is a critical area of inquiry.
• With the increasing ubiquity and availability of machine control made possible through innovations in high-level languages, coding communities will increasingly be associated with, both opportunistically and by force, a larger propaganda machine.
• Programming is about sex, gender, money and race. Evaluating programming languages and their communities as merely technical artifacts obscures and silences a massive range of context and implication.

There is a whole science behind user feedback. If you’ve ever gone to grad school to learn about product design, you understand how Maoism, Feminism, Neo-Radical-Feminism, Objectivism, Bertolt Brecht and gamification impact user feedback.

But shit is about to get real. We’re out of grad school. Or we never went to grad school. Hell, we barely finished high school. Either way, its time to ship some software now and we just don’t have the time or the resources to conduct exhaustive user interviews. And while it would be nice to “provide our users with a safe, comfortable location and plenty of water,” we only have enough funding to “make sure our users survive the session without dying of starvation or a bladder infection.”

This is a post about quick, dirty, cheap ways to get user feedback. Because we don’t have the money. And our users don’t have the time, either. We’re all busy here!

1. First User Experience: The Street Team Strategy

Remember the early 90s? Remember those seriously committed punk kids working the corner outside the concert with a cardboard box of mixtapes and a cassette player? “Hey man, hey. I got this really great new band, man. I got a mix tape man. You can have one. Take two. Hey brother, take a listen, borrow my headphones.”

Yeah. That punk kid could be you. And that concert could be a hackathon, Google I/O, the time you crash that VC party, whatever. Walk up to someone. Start talking. In the real world, aka “The Internets,” that’s how it’s gonna be. Your user is going to be on Twitter, or Facebook, or StackOverflow, or their buddy is all “hey dude check this out”, and then they’ll go to your website. But they’ve got work to get back to and you’ve got 3 minutes. So thrust your laptop in someone’s face, respect their time (and their personal space) (also take a shower first), but ask if they can take a look and tell you what they think. Be the interrupt driver that your user experiences in the world. Then thank them and peace out to go write a better riff re-do that sign-up process. FUE in a Flash!

2. Massively Distributed… User Feedback!

Sometimes we make the mistake of thinking that only one person - or a group of people - in the organization are responsible for getting user feedback. Watch out for a blog post soon on the 7 Concentric Circles of User Feedback Hell on why this is an AWFUL mistake but let’s focus on the ruthless efficiency part of making sure everyone in your company is involved in talking to users and understanding how they feel, what they want and what SUCKS about what you’re doing.

Let’s say you have six people. Make it a requirement for everyone to talk to 6 users every week. THAT’S 64 USERS/WEEK if you trust basic math skills. Let’s not belabor the point. But get everyone on your team to talk to users, all the time, in their own quick and dirty ways - and maximize the user generated goodness.

3. Release the Kraken Top Secret Preview Edition!!!

Inside, we all have a sneaking suspicious that we’re The Next Big Thing, or that we’re building it. We read about all those artists who never let anyone see their work until they died. Then we get all precious about our Next Big Idea. WHAT IF THOSE BASTARDS STEAL IT!!!

But let’s be honest._ If someone can steal your customers, your business model or your secret infrastructure sauce from seeing some mock-ups or the top three bullet points on what you’re releasing next month, you’ve got worse problems.

An easy, low-cost, efficient way to get fast user feedback is to openly Tweet, Facebook, or blog initial thoughts around new features, a mock of a new interface, a few choices of how a process could work… you get the point. Give people a quick and dirty way to respond and get super valuable feedback at low cost.

If letting all your junk hang out makes you or your investors nervous, consider assembling an email list of “beta testers” that you can shoot quick “hey guys, what do you think of this?” notes to. This lets you control distribution but achieve similar results - with the caveat that your user feedback might not be as diverse, instant or organic as a more “open” strategy.

4. Feedback Using Zombie Machines!

One thing I’m really interested in around user feedback is this old - but remerging and reimagined - concept of including in-page widgets that let users give really fast, easy, anon feedback on what they have questions about, how they feel, what they wish you would do better, and more. These take really good design and foresight to incorporate well, but Get Satisfaction has a good example of the basic concept - and you can definitely build your own as well.

The idea is providing users a really easy way to send you those fleeting thoughts, dreams and suggestions as they come. I’m not a huge fan of taking the human element out of user feedback, but I hate live chat (which is a ghetto hack hybrid of IM and feedback widgets), and I like how widgets can remove a lot of the barriers to entry of engaging person-to-person while allowing you to capture that super precious “in the moment” feedback - all the stuff a user wishes they could say but doesn’t have time to email you about.

5. Get Religious with the Pizza + Beer on Thursday Afternoons

There are tons of meetups out there. One of my favorite things is user meetups, where you, your team and some of your users (and hey, invite some non-users for fun!) a chance to meet, network, talk about ideas and share new ones. Provide pizza, beer and a bathroom key. Keep it informal. Let your designers go crazy with all the In-Real-Life A/B testing they want. Encourage people to go to your strategy guru and delight her with their wildest hopes and dreams. Let the engineers risk pissing someone off with their plans for the code base, in the flesh.

Be religious about having and keeping these, even if only a few people show up. You’ll get there, but only by being there. Be disciplined and persistent and you will amass more feedback than you imagined, more ideas than you can build, more champions than you deserve, and a really close relationship with your pizza joint.

The end game? Never let lack of time or resources, an impending release date or over-obsessing  prevent you from getting the user feedback you need to avoid massively screwing up your product, wasting your funding, and completely missing out on the next big thing.

For all of the talk about “web 2.0”, “enterprise 2.0,” the new “collaborative, distributed workforce,” and don’t get me started on “cloud 2.0,” collaborating online is basically full of excessive, unending, ragequit pain. This is a blog about what collaboration software needs to learn from MMORPGs.

Some Context

Surprisingly, the best collaboration platform I use is…. World of Warcraft. World of Warcraft is a Massive Multiplayer Online Roleplaying Game. You pick a character and fight demons. With other people. Here are some things World of Warcraft nails that I wish collaboration software would take to heart:

1. Actual Collaboration Requires a Shared Experience
When playing WoW together, you are looking at the same landscape. When something new happens in the game space or one of the characters does something to modify it (like starts attacking a demon), the rest of the players can see that action, as it happens. If Warcraft can do it, why can’t my document collaboration software also update the document as others make changes to it?!!? If I’m trying to book a flight or explore flight options, why do I have to email someone through a booking platform so they can see the options I’m looking at?

I’m not talking about screen-sharing, either. I’m talking about maintaining independently accessed “instances” of a shared problem space that is subject to the modifications of all parties, in real time. Most collaboration software or collaboration features end up resorting to some version of screen sharing. Screen sharing  is not a collaboration tool. Screen sharing violates user autonomy, creates a hierarchy of control rather than a flat collaboration space (only one person can make changes), and is basically a ghetto hack to overcome a real problem.

Without ripping into specific platforms (nudge Google Docs), this does reveal an underlying theme that collaboration software just doesn’t get - users need to be able to share an experience, object, document, problem space, media, etc - and  share control over it.

2.  User Autonomy is Possible. Complexity is Manageable.

While in World of Warcraft you are operating on a shared environment, you are able to configure your version of the problem space with your own setup. You can set hot keys for different weapons and spells, add plug-ins that 3rd parties have built with the API (oh hey, we love that!), try out different screen perspectives…. the list goes on. Not all users are forced into the same config just because they share a problem space.

Collaboration software addresses the complexity issue by… well, completely removing complexity so everyone has to deal with the same n00b settings! The way Warcraft does this is much better. There is a separation between how the user experiences the problem space and the problem space itself- a separation that doesn’t impact the group experience.

3. Communication Features != Collaboration App
World of Warcraft has a ton of awesome ways to communicate. Wanna chat with just one of your friends? Done. Talk to the local castle defense channel? Done. Talk in a dungeon raiding group? Yep. Voice? Yes. (OK, WoW voice sucks, we still have to use Skype for that, but you get the point.) World of Warcraft understands that people want to communicate in different ways around the problem space. It doesn’t need you to run other bulky apps alongside it just to have a conversation about what’s going on inside of the game app.
Collaboration software has set itself to the lowest bar possible: letting you communicate. “Twitter for The Enterprise” is not a collaboration tool. It’s a messaging feature. Collaboration is about objects and problems spaces (a document, a business plan, a piece of content, etc.), not the ability to instant message someone or make a phone call. We’ve had that stuff for awhile. Nothing new.

So why are we focusing on communication features instead of actually making it possible to experience the internets and its objects in a shared and collaborative way?
The Final Countdown
The internet has largely been designed as an individual experience. You access content in your own way, on your own time, from the privacy of your machine. Hey, if you wanted to like, work with people, you’d leave the house, right?

Well as we all know things have changed. We’ve broken down the individual- oriented nature of the web in only the most superficial of ways - basically, allowing you to share what you are seeing with others. A link-based World Wide Web, emerging and established social networks, and screen sharing technology are all geared at getting people to look at the same things, not create things together.

People talk a lot about “where the internet is going.” My hope for the future is about making the internet a place not just for individual experiences, but for shared experiences. A web that recognizes that individual users are not the only units to calibrate for. A web that’s only designed for users to share things is really prejudicial against people in long distance relationships ignores the larger potential of an internet that lets users experience and create things together.