1. Library
  2. Arrow Icon
  3. Rules for Radicals and Developer Marketing
  • Marketing
OCT 14, 2014 - 37 MIN

Rules for Radicals and Developer Marketing


Rachel Chalmers is a principal with boutique early-stage venture capital firm Ignition Partners and a former industry analyst with 451 Research. She lives in San Francisco and wonders if you’ve realized how truly magnificent horses are.

  • Background
  • Rules for Moderates
    • Identify Influencers
    • Reward Early Adopters
    • Empower Evangelists
  • Rules for Radicals
    • Saul Alinsky Background
    • Your Expertise
    • Your Enemy's Expertise
    • Ridicule as a Weapon
    • Creating Good Tactics
  • Q&A
Download slides

It's a pleasure to be here. I've been haunting these halls for the last year actually, since I switched careers and became a VC and I've been learning about start-ups from the other side. I switched one kind of evil for another, but I'll get into that a little more later. Today, I have some evil that I wanna share with you.

I'm going to introduce myself and give you an idea of what it is that we're talking about today, talk about the parameters of the conversation. Then I'm going to tell you how good companies or, you know, companies that are getting a passing grade, empower their enterprise end-users, whether devs or dev-ops or IT operations, and three strategies that they use to do that; a cycle of identification, reward, and empowerment.

Then at the end, I'm going to talk about what the 10X and 100X start-ups do that's different from all of that. If you follow the rules for moderates, you'll get your enterprise end-users to sell, your VC will probably keep talking to you, you probably won't make the Christmas card list, but they won't cross the street to avoid you.

You'll be keeping up with your competitors. But, if you want to stand out, maybe think about using the rules for radicals.

So, who the hell am I and why should you care? It was one of those right place, right time things. I happened to be be employee number 10 at 451 Research, and I was employee number 10 for a long time because we stayed very small.

Because we were starting an industry analyst company in 2000, and Gartner and Forrester and IDC already existed, the way we decided to try and differentiate ourselves from all of the other industry analysts was by being nimbler than they were, by being a mammal to their dinosaurs.

We looked at emerging technology and start-up companies far earlier than Gartner could get to them. This was an incredibly fun gig and if you ever get a chance to do it I do recommend it.

Among the companies that I was the first analyst to cover were the ones listed here that you may have heard of. My team also covered New Relic, Heroku, and AppDynamics. A lot of the insights that I will be sharing with you today are gleaned from having worked and consulted with and covered those companies for many years.

Being an analyst is a weird job. Analysts are perceived to have power in the industry that far outweighs what the analysts themselves perceive that they have. As a result of this perception, this whole cottage industry of analyst relations has grown up to manipulate what analysts think.

A day in the life of an analyst these days is wake up, take three or four briefings in which people that you know socially and hang out with and have beers with, play four truths and a lie with you. Then you spend the afternoon sitting down with your notes and trying to figure out which one was the lie. So, the people that end up staying in analysis for a long time and end up having a good reputation are the ones with the really sensitive bullshit detectors.

One of the tricks that they and that I used as an analyst that stood me in really good stead was to listen less and less to anything that sounded like marketing and to listen more and more to disaffected people in the industry, to people who felt that they were marginalized, people who felt that their voices weren't being heard.

Because if one of those people came to me saying, "Have you heard about this Docker thing? It's actually really cool," then I knew Docker was gonna be huge. That happened 15 months ago, not in quite enough time for me to capitalize on the insight but I live in hope.

Getting lied to at that frequency and that rate actually wears on you after a while so even though being an analyst is really fun, I spent a couple of years looking around and I went and talked to Splunk and I went and talked to Cloudera, so when the guys who invested in Splunk and Cloudera asked me if I was interested in trying investment, I decided to make the jump and so I exchanged one kind of evil for another.

When we talk about go to market within ignition and the ignition portfolio companies, this is the cycle that we talk about. We talk about acquisition, engagement, monetization and referral.

You will have an intuitive understanding of what that feels like. You download a piece of software or you sign up for a service, you play with it for a little while, if it fails to thrill you in the first 10 minutes you forget you ever signed up for it. If it delivers some little piece of value to you, maybe you're gonna fall in love. Maybe this is the one.

Monetization and referral means persuading someone within your organization to actually plunk down some cash for this and then benefiting so much from that acquisition that you're gonna tell your friends about it and get them to do the same.

There's quite a lot of literature about the first two, my favorite resource in that area is Kathy Sierra's blog, now defunct, "Creating Passionate Users," it's still all archived online. It's fabulous and it comes from a place of deep empathy for the people using technology. It's all about trying to put yourself in the head of your users and trying to give your users what they want, not what you think they want.

That refinement of the golden rule, you don't necessarily treat others as you want to be treated, you want to treat them as they would like to treated.

Because there's actually a fair bit of literature about acquisition engagement and because you're all Heavybit companies, I'm going to assume that you've got that stuff down.

I'm going to focus on what I'm noticing is a much more difficult problem plaguing a lot of really excellent software companies. It's effectively our generation's crossing the chasm, especially now that they developer is king.

There's a lot of start-ups that I've talked to over the last year and before that, but particularly over the last year, that have managed to achieve really significant customer attraction and customer engagement and customer delight, but there's still this huge gulf between having all of that accomplished and getting anyone to pay for it.

It can be really, really difficult for companies. On the one hand, you have all of the web-scale companies, which use a ton of technology but are really cheap, and will use open source where they can, and then on the other hand, you have the enterprise, which we've spent forty years carefully domesticating into these giant beasts that will happily pay seven-figure purchase orders for good enterprise software.

There's a known route to selling into those organizations, but a lot of the developer-oriented, web-focused start-ups have no connections with those roots into the enterprise. That's part of what I want to talk about today.

There's a few companies, and I had them on a previous slide, that have really cracked this transition from being really, really good for the people on the ground, making those people much more powerful and effective in their jobs, and then translating that into a story that the CIO and the CFO can understand and that Fortune 100 businesses will make as part of their infrastructure. It's that particular trick, that conundrum, that is really key to building billion dollar software companies I think.

First, we'll start by covering the basics. This is stuff that is probably familiar to you from business courses. This is stuff that all software companies do to a greater or lesser extent.

I'll talk about the way it's traditionally done today, abunch of practices that have been tried in the field and are moderately successful. I'll also crucially pick out the anti-patterns for each of these and exhort you not to do them. You'd be astonished at how many even quite good companies fall into some of these anti-patterns.

As I mentioned, the cycle is to identify your influences, to reward your early adopters, and then to empower them to be evangelists within their organizations. Identifying your influences is not actually that hard. The definition I use of influencer is the person who has just become ten or one hundred times more productive and effective at their job because of your software.

The really canonical example of this is VMware. Once hardware assist for VMware came out in 2006, Shaniqua, in system's administration, could download the software overnight and then next morning she could manage ten times as many server images off the same hardware. Shaniqua became Shaniqua, the virtualization admin.

All of the other companies that I put in this class do a comparable feat of making the people on the ground much, much better at their jobs. There were all of these lovely stories, in the early days of Splunk, of log managers suddenly becoming much, much more effective and the boss coming in and the log manager saying, "Look at this! Ask me anything! There! There's your answer. Ask me something else."

As I say, you're Heavybit companies. There are, ideally, users that you've made 10X more productive and those are the people that we're talking about in the context of this conversation. The trouble is those people aren't typically buyers. This was very true in IT-ops, it was very true of VMware and Splunk. It's even more true in this day of developer plays.

App-dev teams within the enterprise are not like Silicon Valley start-ups. App-dev people in the enterprise, particularly outside the technology corridors, are tragically downtrodden, let's be honest. Coders for systems administrators in the Midwest or for systems integrators in the Midwest or for insurance companies, or for oil and gas, you know, if they're not actually writing the software that finds the oil, they are a downtrodden people and they don't have access to a lot of resources. The decisions about the allocation of capital are made several steps up within the organization.

The only way to reach those people credibly, the people who write the checks, is to turn those 10X employees into passionate users who will up-sell within the organization on your behalf.

If you can do that, you suddenly have this incredibly leveraged sales force that you don't have to pay. If you're trying to build it the traditional enterprise way at the scales that we're now facing, you're gonna spend a lot of VC money and have very little to show for it.

The anti-pattern here is that people think that downloads or signups or engaged users are going to effortlessly translate into purchase orders, and they really, really don't. Some of you already have this problem.

Traditional software marketing rewards those early adopters and there's a bunch of recognized ways to do that, of which the most obvious is certification and education. There's also placement on an enterprise advisory board and there's more recently this idea of a meet up in a box and making funds available so that you can throw an evening of beers around a piece of technology.

These are all good and these are all used very effectively by some organizations and sometimes they're used diabolically bad. It comes back to Kathy Sierra talking about empathy. There's a tendency on the part of marketing organizations that come from, shall I say, less passionate industries, to just throw stuff at people and assume that it will stick.

Having been to more conferences than I can actually remember, I no longer accept backpacks or t-shirts. I just give them back to the puzzled conference staff who are, like, "Free stuff, why don't you want the free stuff?" I will never accept as a gift another squish toy, because otherwise my house would fill up with them.

Rewards have to be meaningful to the people receiving them. Again, with the golden rule, not the stuff that you want, the stuff that they want. Cloudera, interestingly, was exceptionally good at training and certification, still is. It's users said that the Cloudera University material was on a par with that of actual universities.

This, actually, was making something of a virtue of necessity, because Cloudera, being an open-source distro, was struggling to monetize its pure software lines of business in a way that VMware and Splunk, being proprietary software businesses, didn't necessarily have to.

Hot tip for those of you who have an open-core business training and certification, or as my boss likes to say, t-shirt and mug businesses, will take you a long way towards proving your market and finding product market fit, as long as they're t-shirts that your users actually care about and would want to wear.

Similarly, with the enterprise advisory board, I have witnessed, and indeed served on, what I call potemkin enterprise advisory boards, which are entirely PR exercises. Nothing could be more destructive to the moral of your stand-out users than to know that they're assembled to waste their time and have no input into product and strategy decisions of this technology on which they depend. Please, don't do that.

Then there are all the traditional ways of empowering evangelists. As software companies, you are bilingual. You speak the language of business as well as the language of technology.

Again, with app-dev shops within large enterprises this is not always the case. A lot of these kids came straight out of Microsoft certification courses or straight out of CS departments. This may be their first job out of college. One of the most valuable things you can give them is a way to understand return on investment and a way to communicate that to people with a business background.

There are a lot of different ways to do this. The venerable PDF, this is one that Splunk prepared with the assistance of enterprise management associates and it's good. This is AWS's return on investment calculator. It's live. You plug your own numbers into it. It's way better. Stuff that you play with will always, always out-compete stuff that you have to read or watch.

That's for my video watchers at home. Hi! So many empowerment anti-patterns that they've got their own slide. The number of software companies that have committed these anti-patterns in my presence is responsible for many of my gray hairs.

One of the most egregious errors is just to fail to listen.

Even to assemble a group of end users and then speak marketing language down at them from a stage instead of doing un-conference stuff and letting them hand the microphone around and letting the hallway track take over. I've become a big proponent of un-conferences because at least it changes the conversation from a command and control structure to something that's hopefully a little bit more agile.

People who came out of marketing school, particularly people who came out of marketing school in other industries, love to have one-size fits all collateral and to hand tablets of stone down from the mountains. That doesn't work in this industry. You've gotta give people tools.

Developers and IT-ops people and dev-ops are all tinkers and they're happiest when they're tinkering and they enter a state of flow and when they enter a state of flow and you've fascilitated that, they will start to feel warm feelings of attachment and love for you. When that happens, and when you have empowered end users who are getting the 10X improvement in productivity, give them center stage. Make it all about them. Put the spotlight on them. Don't pull focus. Don't try and make it all about your own company.

That's assuming that you have 10X and 100X users who are empowered by your software. I'm gonna assume that you all do, because that's your job. That's the bare minimum expectation of what a San Francisco software company ought to be accomplishing for its community.

The question then becomes how do you, yourselves, as employees of software companies, and as founders, become 10X and 100X? How do your companies become 10X and 100X start-ups?

Well, those of you who grew up most in open-source, as I did, when you need to solve a problem like that, you do a literature review. You poke around, you Google to see if anyone else has run into this problem and tried to solve it. The problem that we're trying to solve has a name, it's called community building and it has been solved before, many times actually.

But I'm gonna dig into one of the particular classics of the literature, Saul Alinsky's "Rules for Radicals." If you've heard Alinsky's name at all it was probably in connection with the 2008 Obama campaign. He was a historical precursor to Obama in many ways. He was the child of Russian Orthodox Jewish immigrants who grew up in Chicago, went to U Chicago and, like a lot of you Chicago grads, turned hard left instead of hard right.

He took degrees in Archaeology and Criminology, of all things, and like Obama, turned away from an academic career to work in the south side of Chicago. He actually ended up working in the same meat packing plants that Sinclair Lewis had exposed in "The Jungle" thirty years early.

What Alinsky did was he went into communities and he listened. His great innovation, if you want to distill it down into one idea, was to go to disempowered groups of people in ghettos or in neighborhoods that were cut off from political capital and access to resources, and to find out what was on their minds, to get to know people and to go house to house and talk about the problems that people were trying to solve.

He did this for forty or fifty years. He did it in Chicago. He did it in Oakland. He did it with indigenous communities in Canada. He was extraordinarily successful. His admirers, although he was a leftist, his admirers spread across the political spectrum and include William F. Buckley.

After he was credited with part of the success of the 2008 Obama campaign, "Rules for Radicals" became required reading for the Tea Party, so, there is a sense in which he's a bipartisan shit-stirrer. There are thirteen rules for radicals, or twelve depending on how you count them. Wikipedia says twelve but the book says thirteen, so there's crowd-source knowledge for you.

I picked five of them as the most applicable, but, in fact, you can see ways to apply all of them to this problem domain. Never go outside the expertise of your people. I talked about how in the early days of 451 we were competing with Gartner and Forrester and there was no way we could do what they did directly.There was no way we could go into the CIO's office with a magic quadrant and say, "Buy this."

We just couldn't do it and so we found the thing that we could do. We were all really interested in early-stage start-ups. We all understood technology. We all knew how to write for a generalist audience.

So we found the thing that our team was the only team on Earth that could pull together. That's the basic problem that every start-up is trying to solve. This is something that you've already thought through, and that you've already had to face.

If you have 10X and 100X users then it's a problem you've already started to crack. But here's the thing, there's a second derivative of that. There's a way to tackle this problem of marketing to those users within the enterprise that your company is the only one that can figure out.

Part of what's difficult about framing this talk and about giving this set of experiences to you is that all of the companies I listed earlier, VMware, Cloudera, Splunk, Heroku, Chef; they all solved this problem in different ways and none of the ways in which they solved this problem will be quite right for you. You've gotta find a unique way of galvanizing your community, something akin to Chef calling its scripts "recipes" and compiling them into "cook books," that appeals to your community's sense of humor in a way that it becomes an inside joke and galvanizes those people into recognizing their solidarity with one another.

You can't do it if you tell lies and you can't do it if you overreach and go beyond the thing that you're natively capable of doing. That is the anti-pattern here. The number of software companies I've seen wrecked because they tried to expand into adjacent markets without understanding that their particular end-user, their particular buyer, had absolutely no authority over this piece of software that looked functionally really similar, but actually belonged to a completely different cultural group within the organization, is high.

It's significantly higher than the number of companies I cover that had good exits. It's probably 100 times higher than the number of companies I covered that reached IPO. Don't do that.

If you're scaling, scale in a way that makes sense for your team. Scale in a way that's within the expertise of your people. And your people's expertise is bigger than you think it is, but it's not infinite. Know where your weak spots are.

Conversely, you could use exactly this tactic to draw out your much bigger enemies and turn their strengths into weaknesses. There was no way Gartner could compete with us in emerging technology because they were just too big and too slow. Their processes were too sclerotic and they couldn't be quick enough.

When you can get an incumbent on the defensive, because their stuff is too expensive and too cumbersome, and it always is by definition, that's why they're the incumbent, you have more and better marketing than you could possibly pay for by traditional means.

Remember when Steve Ballmer said that open-source was a cancer on the software industry? It was fantastic! You can't pay for that kind of validation. It was awesome. It's aikido, you're using the enemy's weight and center of balance against them. It's something that software companies can always default to by virtue of being small and nimble and able to move very quickly.

Ridicule is your most potent weapon. As you can probably tell, I could not get through a day without making sardonic jokes. I believe comedy is as essential to human sanity as oxygen. But I want you to be very mindful about how you harness and deploy ridicule.

A conversation that grew up in the stand up comic community about rape jokes recently produced this very provocative phrase: "punch up." The argument was whether rape jokes could ever be funny, and I'm firmly of the camp that thinks they can as long as the joke is on the rapist. And that's what "punching up" means. It means never turning the weapon of humor against the disempowered, the disenfranchised, the people who are already socially marginalized.

It means, if you're gonna grab some social capital away from somebody, make sure they can afford it. Make it a tax on the privileged and the powerful. That's when it's most effective. That's especially when it's most effective in galvanizing communities.

Splunk was ridiculously good at this. I would have steered away from the ninja shirt myself, but I will always embrace a shirt that mocks my commonwealth neighbors up in Canada. Hi, Lee!

These were the first shirts I saw people wearing, not because they looked cool or because they identified with the company, but because the jokes were actually, you know, very nerdy but very funny and very specific to that sys-admin sense of humor that dates back to Eric Raymond and "The Hacker Dictionary," and even before that to the early days of Usenix.

It was a really good way of tribal bonding for Splunk. That is really what I attribute Splunk's success to and Splunk will always have a special place in my heart because it was the only company that went from three guys working out of a garage that I met to ringing the bell at NASDAQ in a straight line without selling itself to EMC halfway through and going through all that rigmarole.

It was the one that had that perfect trajectory. There were lots of missteps and complications and interesting side trips along the way, but the thing that Splunk did was it found those log managers who were hand-wading through these ridiculous bodies of machine-generated data who just needed a tool like grep, and it gave them a tool like that. It instantly made them the smartest guy in the room.

They took it and ran with it. They built the next five years of their career on it. That's what software companies are supposed to do. They're supposed to give you a tool that makes you brilliant and, when that happens, when the stars align and it all comes together, it's a beautiful thing. I will always love Splunk for that.

In that vein, a good tactic is one that makes your people feel warm and fuzzy.

Inside jokes are great. Lionizing heroes is another great one. This needs to be done with a little bit of discretion. It needs to be empathic. It needs to be done in a way that the user feels as praise and not as pressure.

Speaking of which, be wary about overusing your customer references. One of the other experiences that I had as an analyst was getting really familiar with talking to customers who had clearly been coached in how to talk to analysts.

What's much more convincing is somebody speaking from the heart and somebody speaking in a way that's very authentic and genuine. It's really easy to tell the difference when you're doing five customer calls a week.

Strong symbols are another way to pull a community together.

This can be something as simple as Docker's whale or something as subtle as Docker's whole notion of making containerization something that everyone can use, something that's really democratized. Face time is obviously one of the most effective things you can do to community build, but it needs to be done with discretion.

I'm a huge proponent of safe spaces for many reasons, but not least the fact that the start-ups that I observed to make an intentional effort to recruit people of color and women, invariably out-perform start-ups that didn't put that much effort in. When I say, "safe space," I mean don't ever serve alcohol unless you have an anti-harassment policy.

If you need anti-harassment policies and codes of conduct, they're available from the Geek Feminism wiki. The ADA Initiative will also help you out with ally workshops if you need it. The ADA Initiative, of which I'm an Executive Board member, is currently fundraising. Please give them some cash if you can.

Any tactic that drags along too long becomes very boring. I'm not picking out any software company in particular that's based in Redwood Shores, but there comes a point when you succeed and the temptation to be arrogant and self-agrandizing and to make it all about you and put the focus on how brilliant your founder is, is overwhelming. If you catch yourself doing that it's either because you've been very successful or because you've become complacent.

In the first case, you can probably get away with it, but in the vast majority of cases when people do that, it's really boring and nothing kills a community faster than the perception that the vendors and the end users interestsare misaligned.

These are my contractually obligated, five Heavybit take-aways. Don't be predatory. The people that you've empowered within the organizations are your BFF's. The Shaniqua's of the world. They are the ones who will go and fight for you. They will evangelize for you. They will convert their peers. They will fight their managers to get the purchase order written.

You really need to respect that there are no software companies without Shaniqua's. Shaniqua's are awesome. They are the heroes of this industry and they are unsung. User experience is always better than a PDF. Give them something to play with. One of the other reasons Docker is doing so well is you can go to their site and you can start playing and you can create a Docker container and you can register it with the Rep-O and it makes you feel super excited and empowered.

Go ahead and read Saul Alinsky's "Rules for Radicals", it's very short and it's funny and it's good. "Punching up" and creating safe spaces are both subcategories of having user empathy. Don't dump on people who are already being dumped on. Those people are our natural constituency, we should have solidarity with those people. We should give them shiny software because they deserve it.

If we're not creating safe spaces, if we're not inviting in the disabled and queer people and people of color and women then we're literally dropping more than half of the human potential available to us on the floor. It's actually fiscally irresponsible to do that so please, don't. I have been Rachel. I am ready for your questions.

How do you avoid being a super troll? You don't want "punching up" to define you in the future.

There's actually a really cool story, from Saul Alinsky about that in "Rules for Radicals." He talks about how he was community building in San Jose. One of his students became a mentor to Cesar Chavez. He was getting to know the Mexican community, this would have been in the '60's. They would take him along like they took all of the white guys that came to visit them in community organized from the top down.

They fed him this really elaborate Mexican meal. He's like, picking at it. You know, he's Kosher. He's an Atheist but he was always culturally Jewish. He's picking at these beans cooked in lard with ham hock in it and he's going, "You know, this food is really awful," and the Mexican guys all burst out laughing because every other white guy that dragged through their community was like, "Oh, this food is so great! It's so authentic. I love your culture," and Alinsky told the truth and he goes on to say, "This wouldn't have worked if I hadn't just spent 12 hours with them, hanging out, meeting their kids, meeting their wives, talking about what was on their minds. But because we had that bond of trust, I could actually come out and say something irreverent and honest and they would find it funny."

Humor does need to be contextualized. It does need to be part of a larger relationship which includes a lot of trust and a lot of authenticity. Even "punching up" needs to be never truly mean-spirited. Mean-spiritedness is mostly "punching down" but "punching up" can also be mean-spirited.

Looking for generosity, not only in humor, but in everything that a company does, I think is a laudable goal.

This comes down to one of my core beliefs, which is that living and working here in Silicon Valley, having all of these resources available to us, having the internet, having Moore's law working on our side, makes us the most privileged and lucky group of people that have ever existed on the planet. If we can't afford to be generous, who can?

Super interesting question, is it possible to sell to people who are not disempowered within the enterprise?

The language that I'm using, because I'm drawing it from leftist community organization, is slightly misleading because it's not quite congruent with the language that you're familiar with. When I talk about disempowered and under-served populations within the enterprise, I'm really talking about solving problems. I'm talking about scratching people's itches.

Is it possible to sell software to people who think they're already on top of things and have everything that they need? No. Ever tried to push a rip and replace solution for Oracle? Well, Oracle's a bad example because a lot of people want to rip and replace it now, but for a piece of software that's working and that has a lot of fans and that people feel is really good, very, very difficult to do a direct competitor.

Very difficult to persuade people that a slightly different feature set is worth more to them than the familiarity and the learning curve that they've already invested in the software that they already have. That said, everyone who's trying to do a job is under served in some way. Salesforce would be the canonical example of this.

CRM software already existed, but it was difficult to deploy. It was difficult to learn. It was difficult to use. It was nightmarishly difficult to integrate with other CRM solutions when you had big organizations that were undergoing multiple mergers, like every single bank in the '90's and early 2000's.

Mark Benioff's innovation was to make it cloud-hosted so that it was much lighter weight. It was much easier to start so he could target mid-sized enterprises that couldn't afford a full Siebel Systems deploy.

There's always something about the incumbent that makes them vulnerable. There's always some chink in the armor where you can come in underneath with something that's lighter weight, more agile, and then gradually build out the enterprise features.

There's always somebody within the heirarchy of the organization who's looking for something cheaper, easier, and simpler to get up and running. If it's not the manager, it's someone in line of business who had a departmental credit card, which they can throw down on a couple of AWS instances.

As organizations scale, there's always gonna be disenfranchised people within them. The trick is always finding the people who aren't being well-served by the existing infrastructure. There's always going to be people like that.

Funny and awesome point that I actually had in my notes and didn't hit on, should you sell to the log manager to have them impose it on the log analyst or should you sell funny t-shirts and hope that the log analyst will sell up?

The reason Splunk succeeded was because of the funny t-shirts. Any time you sell software that the managers are imposing by fear on the people underneath them, that software will fail. It may fail very expensively but it will be hated and people will figure out ways to route around it. Anything that's mandated from above is interpreted by the rank and file as damage and they'll route around it. I'm always for the bottom-up sell, never top down.

The question is, instead of a big incumbent and a little scrappy start-up, there's two start-ups around the same age...

-It's like open-source software.

Right, so two alternatives, the user communities of both are early adopters. Do not attack the early adopters who are using the other guy's stuff. Chef and Puppet users are friends. They have all the same problems. They have all the same issues that they're dealing with within the organization. They have far more in common than they do dividing them.

Early adopters of any technology, even if it's your near rival's, are potential customers for you, and if they're not using your software, but they're familiar with it and have friends who use it, they might go and say to another friend of their's, "Well, I use Puppet, but given that you're doing web scale stuff and that you don't necessarily want to invest the time in learning a domain-specific language, maybe Chef."

The question is can you counter-market against a near rival in ways that won't antagonize them? I've seen it done. It's a really delicate balance to pull off. It's very hard. I would not do it unless it's completely hilarious, and honestly, if I had that relationship with the founding team of the other start-up, I would check in with them first.

Which, again, touches on a much more deeply held conviction of mine, which is that candidly, I've been in the industry 20 years. Companies come and go, relationships endure. The people who are in the Valley, a lot of us are lifers and the configurations of the groups that we're allied to shift over time. This is a big part of why I'm really into not lying and being generous, because I want to continue working with awesome, smart people and I don't want to burn them just because they happen to be working for a competitor right now.

In 10 year's time, who knows? Relationships, both within the Valley and with your customer, are impossible to fake and is really the only social capital you have left when you die.

I am large. I contain multitudes. The question is, how do I go from being a lefty and obviously my background, I studied English at University. I ran around with a Marxist theater company in Ireland for a while. I ended up in technology backwards by getting into journalism.

The truth is, when you're born lower-middle class in suburban Australia, you end up with a very strong class identity, and the fact that you're both incredibly bookish and incredibly technical means that you wash up on the shores of San Francisco, still with a very strong belief in the underdog, but with a set of skills that's actually very effectively and profitably deployed at the service of VC.

It's a funny story. To be continued. Thank you very much.