A company’s success is highly reliant on peer validation of investor decisions. This stunts diversity and must change if we want the best founders working on the biggest opportunities.
Software has as much potential as electrification or steam power, but instead the industry ignores markets and whole classes of people, which stunts how much it can affect our world
The ubiquity of the smartphone and the cloud have convinced the world of the value of great software design, but we’ve over-reacted to their needs for simplicity.
Our intuition around productivity is flawed when it comes to physical goods like cards, but it’s downright pernicious when dealing with digital products like software.
You can either be a good example or a horrible warning. When it comes to enterprise sales, I had two horrible warnings before I started Puppet.
In 2000, I worked at Bluestar, a business DSL startup in Nashville. Pretty much everything that can go wrong with a startup did with this one: Founder was pushed out the week I started (I swear it wasn’t my fault), they raised too much money ($450m) and then spent it badly (e.g., on hardware that didn’t work and on salespeople that didn’t sell), they brought in a big business CEO who had no idea how to run a growth company, and then the regulatory framework shifted to highly advantage monopolies again so they all went broke. But in the meantime, I got to learn a lot, both about the problems that eventually resulted in my starting Puppet, and also about what does and doesn’t work in business.
At one point, the company decided to buy a new product. I honestly can’t remember what it was for. Something related to asset tracking? Or maybe some kind of operational monitoring software?
I don’t know. I just know I shifted from being a sysadmin to responsible for making it work. I wasn’t part of the team that decided whether to buy something, and if so, which one to buy, I was just designated to put their decisions into action. In the months I worked on it, I don’t think we ever even got it installed anywhere except on a test server, and at some point we just, ah, decided we didn’t need it any more. The project went away, so I returned to my old job. The executive who had made this horrible decision had the gall to say my moving back to my old role was a strike against me, and it would reflect on my tenure at the company. No worries, he was gone the next month.
This wasn’t just a software problem. While the company was slowly dying, they had an argument with EMC over a storage array they never should have purchased. A million dollars of hardware sat in a receiving warehouse for almost a year, because we would not accept it, and EMC would not take it back.
The second warning was during my brief stint at Bladelogic. I worked there for less than six months, but I learned a lot. Again, mostly what not to do. I was ostensibly a product manager, but in practice they just wanted me to maintain their lab and maybe write some justifications for how their product worked. Certainly they did not want to listen to me. My most memorable experience is being in an all-dev-team meeting when the most senior engineer said something like, “What does it matter what the customer thinks? They already bought the product.” Astoundingly, the CTO did not fire him on the spot, and instead just moved on, ignoring the comment entirely.
It was clear Bladelogic’s business model enabled them to just not care what their customers thought. Only_prospects_ mattered. Once the deal was closed, meh, they got paid, no biggie. You literally could not upgrade their software without losing all of your data - you know, the stuff you’re using to build and deploy your whole infrastructure - and doing any real work with the system required that you do everything twice, once to deploy and the second time to update. But you’d never discover that unless you actually used the software, which would be long after their salespeople left, so who cares? Not them.
You can maybe see why I lasted less than six months. It didn’t help that I was commuting between Boston and Nashville, and I’d managed to rent an apartment at the center of a cold vortex in Boston where my roommate collected Grateful Dead grape juice.
So when I started Puppet, I didn’t know much, but I at least had some anti-patterns. I knew we had to care more about our customers successfully using the product than we did about closing the initial deal, and that selling to people who would not use the software was a bad idea.
It turns out, that’s not quite sufficient to develop an effective sales strategy. Who knew?
I was lucky enough to hire the best sales leader in Oregon, who was not only incredibly skilled and experienced, he was also used to entrepreneurs and found me relatively sane compared to bosses he’d had in the past. Where a bunch of our engineers complained every time I opened my mouth, this guy quietly soldiered on. That made our years-long argument much easier to manage.
Early on, I didn’t know enough to break down what I wanted and what I didn’t, or how to talk about the individual behaviors, so I just wrapped up everything I hated and called it “enterprise sales”. We weren’t doing that. Ironically, our sales leader agreed with most of my concerns, so it wasn’t a real fight in the normal sense, but there were multiple areas he was convinced we needed to change, and it’s hard to do that when your ignorant CEO just puts up a ward against the evil eye and changes the subject.
Within a couple of years, he wouldn’t even say the word ’enterprise’, because I would jump down his throat, proverbially speaking.
In the first few years of building Puppet, I tended to focus on preventing sales from skewing our product plans. I wanted to be sure we built products to be used, not sold, and I didn’t trust myself or the team to be able to tell the difference. I think this was basically right, but today, I would know that you should treat ideas from sales like you treat those from customers:
Always listen to what customers tell you, but never do what they say.
The sales team has a limited lens into the product world. They are smart and highly educated about your customer, but that doesn’t automatically translate into good solutions.
This is a general risk at any company with sales teams, but you have an even more pernicious variant with enterprise sales teams: Being confused on who your customer is.
Are you building the product for the person who buys it, or the one who uses it?
Remember back to that product I tried to set up at Bluestar. It was purchased to solve a business problem, and the person who decided to buy it did so based on discussions with sales and, probably, looking very closely at a grid of check marks comparing it to its competitors.1 Actually using it was someone else’s problem.
In fact, I was not going to be the user either - I was supposed to be its administrator. Some other team (support or installation, probably) was going to actually use it. So they were even further from the buying decision.
If you’re selling to the enterprise, getting a deal done requires that you convince the buyer that your product is a winner. That makes them the most important person at the customer. Now, a quality company would also involve users, administrators, and many others in a buying decision, but in the end, buyer decides. Two or three decades ago, these decisions were mostly made on the golf course, so schmoozing was the most important feature. Today, it’s a lot less corrupt, but not a whole lot more functional.
This brings us to the other problem in this separation between user and buyer: Enterprise sales is a team sale, not selling to one user. Suddenly you succeed based on your ability to manage the interpersonal relationships of warring sub-teams at your customer, instead of the strengths of your product. I distinctly remember a dinner with tens of customer employees, and there was almost a flashing DMZ between two teams, who had differing opinions on whether our solutions was the right one. Salesperson quality and experience begin to matter more than anything else, because you’re basically managing internal politics to get a deal done.
Where did the focus on our product go? How do we stay focused on building something our users love?
We don’t, really. It’s hard to sustain an effective a feedback loop that includes sales if they’re focused more on people and politics than products. Not impossible. But hard.
At a big company, you can begin to navigate this kind of cognitive dissonance - listen to your sales team, but don’t build the products they demand. But in the early days of Puppet, I knew I couldn’t handle it. I am not good at dissonance in general - I’m a bit too fond of the idea that there’s just one truth - but I especially knew my organization could not handle it. We needed to be 100% aligned, and that meant sales needed to be working on the same problems as our product teams. Thus, no enterprise sales.
As we got bigger, the other big problem with enterprise sales starts to show up: Wow is it expensive. Lew Cirne of New Relic told me the primary reason he sold Wily when he did is because he needed to $150m just to build out the sales team and it wasn’t worth it.
If you’re doing inside sales, you’ve probably got someone who can talk through most of the product, they can talk to ten or more customers a day, and only once in a while will they pull someone in to help get a deal done. Once you go enterprise, you have field reps who might be covering thousands of square miles of territory, so if you’re lucky they’ll do three meetings a day on average, and they need a sales engineer on almost every visit. They pull in an expensive executive for meetings as often as an inside rep would pull in a cheap sales engineer.
Yes, you can get much bigger deals done this way, but think about the disruption to your organization: Essentially everyone on your leadership team is taking time away from running the business, not to learn from customers but just to make them feel loved enough to write a big check. Your deals start taking nine months to close instead of six weeks, and getting a check signed begins to look more like a challenge level in a video game than a partnership to solve customer problems. And the boss fight of that game is the worst part of enterprise sales: Procurement.
I’m not in the habit of disrespecting roles or teams, and I think procurement is often staffed with experts who play a vital role in their company. But they are generally paid based on how much money they “save” the company. All that discounting that you have to do for enterprise clients? It’s because procurement’s bonus is based on how much of a discount they force you to give. Absolutely everyone knows this is how it works, and that everyone knows this, so it’s just a game. I offer my product for a huge price, you try to force a discount, and then at the end we all compare notes to see how we did relative to market. Neither of us really wants to be too far out of spec; I want to keep my average prices the same, and you just want to be sure you aren’t paying too much.
But because companies compensate procurement based on saving money rather than making good decisions about what to buy, we can sell crappy products at a steep discount but not good products at list price.
It’s a helluva boss fight.
There’s often a miniboss, too: Legal. They just want their pound of flesh, and often this seems more like a puzzle level than a direct fight. I recently saw a deal that had been in legal for a year. That’s too much puzzle for me. (Incidentally, I worked on that same customer more than 4 years ago. Talk about long sales cycles.)
So now you begin to see why I fought against enterprise sales: It encourages you to build the wrong product for the wrong person and then sell it the wrong way at the wrong price.
Why, then, is it so popular? Or rather, why is it so hard to avoid that despite my best efforts we ended up in an enterprise sales motion, which I then ran away from?
Well, first and foremost, if it works it’s incredibly lucrative. For all that Lew Cirne built New Relic in response to his experience at Wily, and pointedly avoided enterprise sales for years, once they went public they went through a dramatic transformation and added it in, because the money was just too appealing. The biggest companies buy the most software, and, well, the biggest companies want to be sold a specific way.
In many cases, you just can’t avoid it. That’s a lot of what happened at Puppet: Our products were built to solve problems that big companies have. Heterogeneous environments, every operating system and application known to man, complex networks, and heavy compliance needs. Turns out it’s rare that a company has all these problems but buys large software products like you buy toilet paper.
Our first deals at companies did tend to look very consumer-like. But once they wanted to expand to other teams, and especially if they wanted to cover the whole company, the relationship naturally switched to a team sale, where we’re having to work with legal, procurement, executives, and then reps from three or four other teams. Ideally someone inside the org is an advocate for our product, so it’s more facilitation than direct selling, but the problem still stands: This is a clear enterprise sale.
But when it works… wow. You start closing $100k deals, then $300k, then $1m, then $10m. This starts to add up.
And for all that I’ve said this is hard… it’s actually the easiest way to sell.
What’s actually hard is having the best product, and only ever winning based on merit. Enterprise sales is the default motion, and in many cases it’s chosen to paper over weaknesses in the product. After all, only the user would actually notice those; in a meeting with the CIO, procurement, legal, and project management, no one’s going to install the product and give it a runout.
We’re still super early as an industry in our understanding of how to build a product that doesn’t rely on enterprise sales. For all that Atlassian relies more on sales than it has said, there’s no question that they managed to avoid an enterprise selling motion. I’m hoping the next generations of software companies will learn from them instead of Workday.
In the meantime, hopefully this story of how I fought enterprise sales, and why, will help you make better decisions about how to build your own teams. At the least, maybe I can just be a horrible warning.
These feature check lists are bad ideas. Don’t trust them as a user, don’t make them as a product marketer. ↩
I started a daily writing habit two years ago. If you look at my output since then, it’s a bit haphazard: Lots of advice to founders, discussion of venture capital and the blockchain, and a bit of telling my own story.
My own review of my writing is mixed. I think the writing is good, and in most cases I think the topics are important and my viewpoint adds something. But the writing style is painfully far from how I talk, and thus too far from how I think of myself. There’s little humor in it, as one example, which is counter to how I present, or even just talk with friends. I have found a voice, but not my voice, nor one I’m terribly fond of. Maybe I read too much fancy writing in college, and too many Serious Business Books since then, but not enough that didn’t take itself seriously.
I expect one of the main reasons I struggle to include humor is that my jokes tend to be self-deprecating, but I still don’t feel comfortable writing much about my failures and problems at Puppet. I’m still involved, but can’t claim to be a spokesperson or any such thing, so a lot of topics aren’t available. Yes, these are my stories, but I recognize how much of an impact I could have on the company, its employees, and its community if I were flippant about my failures of the past. This was manageable when I was running the company, but doesn’t really work in this state. That can’t be the whole explanation, though, and I plan to do more experimentation this year to begin to suss it out.
I have mostly chosen topics by focusing on beliefs I have that others don’t. Some of this is insight I think is special to me, such as one of my favorite essays, Where Does Your Work Live, and some is straight disagreement, as in No, You Don’t Learn More From Failure. I still run into this last one all the time, and I love having a well practiced argument for how silly this popular belief is.
My series on VC was very different: An attempt to share with a wider world what I’ve learned about how venture works from the inside. Of course, I’m not inside venture in the normal sense: I raised a bunch of money, and spent a ton of time with investors, but have never been an investor myself. But my own learning over those years didn’t seem to be represented anywhere, and based on how often this is brought up, it seems people found it valuable. A year later, it’s a bit unclear even to me how much this series is an explanation of venture capital or an indictment. I truly do believe venture is totally broken, and it seems much of the rest of the world has now come to agree, based on the conversations I’m seeing. Even so, it is actually a fit for some people, and they should know how it works internally. Hopefully the series helps them.
I did a series on the blockchain, too, and this was much more an exploration on my part than an explanation. I had plenty of education and opinions going in, but I didn’t really know what unique insights or beliefs I had until I started writing. This is probably my best example of learning by writing. I started with the knowledge that the blockchain was primarily full of fraud and black market sales, and that I was more interested in the crypto legacy of git and BitTorrent than Bitcoin, but I learned a heckuva lot more in the course of exploring this area in more depth. I’m not sure anyone else learned anything; I’ve never had anyone mention these posts to me, nor seen them reposted anywhere. I am not sure what to take away from that.
My most frequently shared piece is Strategy is Culture. Even after all this time it still gets shared roughly weekly, which is more than all of my other pieces combined. This article took me more than a year to write; every week I’d try to write it, give up, then dash off something simpler and less important. I had to figure out a lot to get to the point where I could successfully explain how closely linked I think strategy is to day to day execution, and how that, in the end, is your company’s culture. It still feels like a fundamental insight that most other people are missing, something so important that my struggles at Puppet all make sense suddenly.
Unquestionably my most popular piece was Why We Hate Working for Big Companies. It was the only one I wrote that got mainstream visibility (albeit just a reposting on a sub-brand of CNBC), and it got shared far more often and widely than I could have hoped, especially given its length. Weirdly, after a big splash it has almost completely dropped off.
In addition to it getting the most reach, it also had the biggest impact on me. It forced me to express my weird combination of beliefs. In doing so, I realized how rare they are, and how important they are to what I do. It took a lot more work, but I eventually realized this essay introduces the topics I need to focus on, both in my writing and in my company building.
My interests today are at the intersection of economics, technology, and the individual worker. I’m educated and opinionated on each of them, but only by considering them together does a complete picture of my opinions and drive start to emerge. This piece on why it sucks to work at big companies is the first time I brought it all together, and I think that’s why it worked so well.
It’s also a longer piece than just about everything else I’ve published. I’ve tended to write articles around 1200 words, mostly because that’s right about what people recommend you write on a daily basis. But the success of this one began to make me think I might do better with longer works, and my struggles to get hard topics out over the last six months has helped validate that for me. It’s really hard to bring together a bunch of ideas into one coherent whole - it’s much easier to instead just write one article on each concept - but it’s more valuable and better work to do it all in one.
After two years of writing, my goals for the next year are, in no particular order:
Come closer to my real voice. This means being more funny, but also more relaxed. I feel like my writing style is too stiff, too formal, which is hilarious given how informally I speak.
Write more about what I think about. I have written a lot of things I believe, but mostly not written much about what’s filling my brain. I hope to do better on that this year.
Write bigger pieces. I think I’d worked through the bite-sized ideas that were fighting to get out, and now any effort to produce something easily digestible seems to require compromising the work, rather than making it better. I think it’s holding me back, not being a helpful constraint. I’m going to be a bit more willing to go long, and pull a complete thread together, even if it means plenty of people will skip it because of length or complexity.
Thanks for reading so far this time. I hope to keep you entertained this year, too.
I’m a tech founder and recovering SysAdmin. I helped found DevOps and grew up in open source. These days I am convalescing from a decade of physical and mental neglect while running Puppet.
Read more
