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.

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.

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.

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.

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. 

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.

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.

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.

I imagine a group of marketing professionals sitting around a white board in a fancy conference room. There are probably women in the room too. After all, marketing is one of the few specializations in technology where women are somewhat well-represented (a blog post for another time!). And patriarchy just wouldn’t be patriarchy if women weren’t complicit in their own oppression, now would it.

I’m sure it doesn’t go down like this:

“Well, we tried giving an iPad away last time. But EVERYONE is giving away iPads now. Everyone already HAS an iPad.”

_”Or maybe we should give away a car.” _

Then some fine prodigal (seriously, go look up what prodigal really means, right now) specimen of the marketing breed says:

_”You know what. We should hire some women from a modeling agency, put them in some scanty clothing and heels, and parade them around the exhibition floor.” _

Someone else goes: “Yeah, you know what, we’ll do more than heels. We’ll put them in STILTS._” _

Someone records this on the whiteboard:

Step 1. Objectify Women.
Step 2. ?????????
Step 3. PROFIT.
Everyone gets a gold star. A req form is created for the girls and the skimpy logoed tank tops. Someone prints out data sheets for the girls to memorize on why our cloud is more cloud than their cloud, and all systems are a go.

Oh. No. You. Didn’t.

Back up. Let’s look at a few reasons why this ISN’T OK and why NO ONE should get a gold star.

The booth babe practice is unacceptable because:

1. It situates women as an object for male bonding around objectification of females.
Booth babes are presented as adorned and removed objects of heterosexual male gaze and a congress point for male socialization. You will see more conversations ABOUT booth babes than WITH booth babes, because they serve in large part as a public conversation piece, inviting voyeuristic sexist bonding around women as objects. After all, the ultimate point of booth babes is to start conversations between men- the men selling, and the men buying. The center and origination of this transaction is the female body. She serves as a novelty for men that use her as both the shiny object and broker.

2. It normalizes patriarchal displays of female sexuality in an industry that is trying to break out of male dominance.
The booth babe “dress and behavior code” is ripped straight from oppressive stereotypes of female sexuality. Booth babes wear tight, thin or not enough clothing, lots of makeup, and are encouraged - no, paid - to flirt and provoke. This display of sexuality is kept strictly within the framework that they are there for male entertainment, to sell products, to “look good” for the cameras (male gaze). End game, the sexuality is expressed as a function of economy, material gain and male pleasure rather than a realization of actual female desire. This normalizes despicable representations of female sexuality in a male-dominated industry that many men and women fight everyday to make more equal.

3. It reinforces that notion that women’s bodies can be used to sell unrelated products.
Five bucks to the first person who can explain to me what women in tanktops and stilts have to do with cloud computing. Yet booth babes, by their very existence, perpetuate the idea that it is OK to use women’s bodies to sell…. well, anything at all. Belief that this is OK - or even a successful marketing technique - is a menace to women and to the industries they contribute to.

4. It suggests that women don’t have real buying power in the technology field.
By orienting persuasion entirely towards a heterosexual male audience, “booth babes” negate the presupposition of a female buying power as an audience. In marketing blatantly aimed at a single gender, the practice effectively silences the reality or potential of a impactful female viewer. Advertising CREATES its audience as much as it serves it, and “booth babes” create an image of an entirely heterosexual male customer base. It both reinforces, reflects and creates buying power in the industry. Booth babes not only market to the technology buying base, they create an image, and a stereotype, of what that buying base is - a buying base that women aren’t a part of.

The No Booth Babe Pledge

We can argue for hours about where the lack of women in the industry gets started. We can punt blame around the court like a bunch of college kids at a drunk game of football. We can console ourselves with Carol Bartz and Marissa Mayer, whose successes obviously indicate that the supposed Glass Ceiling of Technology for Women is top-notch propaganda campaign by the pervasive institution of radical feminism in America.

Fine. Let’s talk about something we all can do, right now, to make incremental improvement towards a tech community where women are treated as equals. It’s the No Booth Babe Pledge.

I will not spend money hiring women as objects to sell my products at tradeshows. I will not work for a company that hires women as objects to sell my products at tradeshows.

( Your Signature Here )

CA Technologies, I’m looking at you. For shame.

Now we’re in a brave new world, the Facebook generation, and we give birth to infants who will never know of time before the iPad. The social web changes the mundane experiences of our lives…. the way we put together birthday parties, the way we stay in touch with long-distance friends, the way we find jobs… and get fired from them. (RE: photo sharing. Constant vigilance is the only way.) But it also defines the more profound experiences of our lives. Falling in love, falling out of love, finishing school, getting married (and divorced), having children. The lasting mark of the social web isn’t felt in transitory devices and applications that fight for momentary ascendency in the everlasting battle of the valley, but rather in how they shape core human experiences-  and death is foremost among them.

Talkin Bout My Generation
****I’m part of a new generation that won’t know death in absentia of the social graph. I never knew anyone who died before I had a profile. My first loss was my grandmother.  I had a cell phone, three kinds of instant messenger and a Friendster page, pink and purple striped hair, and more piercings than my parents knew about (sorry Mom, I know you google me, love you). I probably texted a few friends and updated my Friendster feed. Still, the social web was young, peripheral to the more intimate rituals of family grieving.
After that was high school and college- the age of MySpace and Facebook. Meth swept the Midwest and I lost friends to drugs in so many different ways. In the worst ways, I lost them in the most final ways. As time passed and I moved to Chicago, then to Prague, then to Pittsburgh, now to San Francisco, my social network became increasingly distributed, connecting me in several- sentence blurbs on activity streams to people I hadn’t talked to in months or years, people I would never again share dinner with, or even cities. In the Facebook era we travel through life amassing gigantic nets of correspondence that are simultaneously ephemeral and historical. We build digital homes for ourselves decked with pictures of our friends, memories from the past, notes passed back and forth in HTML hallways. People stay with us long after physical and temporal separation would recommend otherwise.

Somewhere along the way, that social web became the fastest, the farthest- reaching way to share when we’d lost someone. It let us touch, influence, organize an infinitely larger web of connections than could be incited by an obituary in the newspaper or the list of people you would think to call. The kid who went to karate camp in 8th grade with your sister? No one would ever think to drop him a line or invite him to the funeral. Hell, he lives across the country now and hasn’t seen her in 6 years. But they’re friends on Facebook. He’s going to part of it now.

Losing Friends… for real.
****It marked a fundamental change in my relationship with death when I found out a classmate had passed in a car accident, and I found out on a MySpace page. In many ways we weren’t so intimate that I should have expected anything else. We’d always promised to hang out, we texted back and forth a few times and once she SMSed me from winter break. She told her parents I look like an ice princess. We should hang out when we get back.
Now it all comes down to that one day when everyone goes to her profile to talk to her, and to each other, and I go to wish I’d made more effort to do that vegan lunch we’d always said we’d do. In those moments that carry into today I remember how vibrant and alive she was, how I envied her natural ease and confidence, how slim and beautiful she was, how young.

She stays with me because she streams across my social graph even now, years later. I would like to say I would remember her so often even without these apparitions. But I’d probably be lying to myself.

Digital Graves
It continues. Kids I went to elementary school with. Their photos on walls, with pages of comments: We love you, we miss you. We’re so sorry. Heroin ain’t the same without you. Nothing is the same without you. Wish you were here. Remember that day when we skipped school and the sun was out and we listened to that CD? And god, if I could have that day back. I would tell you how I really felt. I would warn you about what was going to happen.

Profiles become the digital equivalent of flower-strewn gravesites or those crosses they put up on the highway where everyone leaves notes. Every year on those awful anniversaries my feed fills up with their faces. It becomes part of our ritual of death.

These things are complicated, and neither good nor bad, but only so.

There are few things so antithetical to the finality, the severity of it than learning through a 140-character update that on more average days contains details of meals and movies, miscellany and mundanity. Yet without these tools so many of us would be left in the dark or isolated from those that share our loss, no matter how far removed. Sure it is a special kind of pain to reload those Facebook profiles, hoping that somehow they would change their status from that one last time. But at the same time it is hard to argue with anything that brings them closer to my life even after they are gone.

What is the Rogue Clouder?
Devs and other IT peeps experimenting with, implementing and testing IaaS and cloud platforms at work and with work “stuff” (dolla bills, time, data, apps, workloads) but outside the purview of corporate structure. In the real world, this plays out in a number of different scenarios- running some workloads in EC2 without the boss, CIO or security team knowing; testing out a few apps on the Rackcloud without seeking any formal permissions; throwing some files up into S3 without getting sign-off; doing some early-stage deployments using a cloud abstraction API without explaining to anyone what a cloud abstraction API is- end game, it varies in commitment, scope, and ultimately in consequence.

The emergence of this user type has gotten a lot of attention- and not just because it is has enough drama and controversy to fill a Tom Clancy novel or at least a TweetDeck column-  but because it is INEVITABLE and IMPORTANT.

The Inevitability of Rogue
It’s INEVITABLE because you can buy cloud with a credit card and get it in variable amounts. Like a beer sampler plate, this permits an unprecedented ability to experiment with radical new approaches to IT. Cloud is a process innovation in the delivery of infrastructure that makes the lab rat psychotically pounding the food dispenser button look like a study in delayed gratification. Unlike previous infrastructure changes (virtualization, new server architectures, etc) that have required lots of up-front cash and elaborate processes of discovery, research and implementation, with cloud, you can just play around a little bit and then ramp up- no task force required. This obviously has enormous implications for sales cycles but also just means it changes the process of how people engage with cloud and services and tools delivered by it and with the “aaS” model. Rogue is now POSSIBLE and cloud’s seductive promises to eliminate provisioning and scalability pains- as well as to provide the enormous pleasure of massive responsiveness at the infra level (I CAN SPIN UP A SERVER ON A PLANE OMG THIS IS BETTER THAN EITHER SEX OR CANDY), means that the possible has quickly become the unavoidable.

The Importance of Rogue
It’s IMPORTANT because it indicates a new phase in the cloud market. Companies creating, distributing and selling products in the infancy of new markets- like cloud- are tasked with creating hypotheses for how adoption will happen in an unrealized and yet nonexistent customer base. This involves a lot of conversation, a lot of studying the market- but eventually it comes down to coming up with informed guesses about who is going to want it, how they are going to find it, how it is going to lead to larger adoption and how you can nurture that. This is why you saw so much discussion and debate a year ago about who you were going to sell cloud to- the CIO? The CEO? Well, at least no one proposed selling to the CISO. That would just be crazy talk.

It shows we’ve reached a new phase in the evolution of the market that we are able to form more substantiated user profiles based on user stories, data, and connecting the dots of patterns across the board and in different communities- from business audiences at Structure to developer audiences at other events. The ability to segment and analyze cloud adopters and more importantly their processes of adoption leads to a new wave of major opportunity in the market.

But the Rogue Clouder is also problematic for a number of reasons, not the least of which being that he is hated and hunted by security teams across the globe. But don’t worry. I have reduced this problem to a Chasm Analogy. (You’re welcome).

The Rogue Chasm
Here’s the problem. Having leagues of rogue clouders inside the enterprise DOESN’T smoothly translate or transition to large-scale enterprise adoption. Unsanctioned cloud experiments aren’t just going to happily work their way up to the CEO, who shall declare: And Now, Thanks to Rogue Clouder, AKA Employee of the Month, WE CAN ALL HA__S CLOUD. No. In fact, it might be a perfect recipe for Crash and Burn if the “higher ups” start deciding that the way to deal with this problem is to squash rogue once and for all with various Death Methods such as firing and security policies.

The point is that while the cloud generation and the aaS model has theoretically enabled a new process and ramp for adoption (try a little, pay as you go, scale up when you are ready), this is not matched by process innovations inside the enterprise that accommodate progressive, sanctioned experiments in new technology. Again, the speed, ease and flexible scale of IT experimentation that we have today hasn’t existed before, and so the enterprise naturally doesn’t have a methodology for initiating, dealing, securing, evaluating results, and eventually transitioning to larger and larger levels of adoption. This leads to increased levels of isolation, siloing, and antagonism between, for example, the Rogue Clouder and the security team. And for cloud sellers especially who are hoping that bottom-up adoption started by Rogue Clouders will lead up the command chain, this should be especially troubling. Vendors have a vested interest in helping Rogue Cloud Adopters cross the internal chasm into higher levels of sanctioned adoption.

What Next?
It is my personal opinion that the emergence of this “chasm” is leading to an acceleration in conversations around internal IT processes (like agile, devops, etc.). Either way, it is important that companies, devs and everyone can safely evaluate and benefit from escalating rates of change in the space and the new opportunities they afford by implementing formal, audit-able processes for Trying New Things, Fast. I think these conversations are necessary and at greater and greater levels of maturity and formality.

I don’t have an answer to the problem, but I do know that enterprises need to evolve processes that bring the Rogue Clouder- who really isn’t trying to be disingenuous or dangerous but just trying to find better ways to do their job- under corporate purview in ways that enable SAFE and WELL CONSIDERED experimentation with things that might just have the ability to revolutionize your efficiency and speed, make you rich and allow you to buy a fleet of ponies. (Ponies are the new yacht.)

There is urgency around this for a simple reason: Abstinence-Only doesn’t work.

On Abstinence-Only Education
Abstinence-only education in the school system doesn’t work because it denies the inevitability of hormones, the ubiquitous opportunity of unsanctioned after-school congress, and the general corruption of the youth by television and music videos. Abstinence-only education doesn’t work for public cloud either: it denies the inevitability of curiosity, the ubiquitous opportunity of unsanctioned congress with EC2, and the general corruption of developers by Twitter and tech bloggers.

It is what it is. And just like you don’t want the first time you explain “The Birds and the Bees” to your teenager to be six weeks after spring formal, you don’t want the first time you have “The EC2 and S3” talk with your developers to be when you are digging through their expense reports and find a series of suspicious Amazon invoices. So while you might not be ready for a process yet, but it IS, at the very least, time for a conversation.

A Small Request
That’s all I have. Please don’t skewer me. This is my first blog and I’m emotionally fragile.

Thanks.