How I got here, how it went, and what happened along the way. I didn’t want to start a company. But I had no choice.

I was a SysAdmin after college, because I tried everything else and got fired from them all. I had seven jobs in two and a half years. I’m very fireable. System administration was just the chair where I happened to be sitting when the music stopped. More a safe, fun place than a source of deep passion.

By that point in my career, I was a little easier to keep around. More importantly, I had become worth the hassle. I did good work because I liked the puzzles.

I had a particular way of working. My boss would say, “You should do this thing, and you should do it this way.” He did not look at how I worked, only the result. That gave me the freedom that made the job worth it. When I told him I had finished he would say, “Great, how did you do it?” and I’d say, “Look, is that a bird?”

I automated everything I could, whether it needed it or not. Automation has a built-in reward mechanism. I would take this well-paying but stultifying job - Type this command 1,000 times - and I would reframe it: How about I tell the computer to type the command 1,000 times? It will work. I’ll watch. Bam! Now I can move on to other fun stuff.

Over time I did so much automation I kind of ran out of work. I was in Nashville at the time, while my wife was getting her PhD, so there were no interesting jobs that needed my skills. Hmm.

I could go to business school, but - sorry! - I don’t have any respect for the MBA. Everything I hear about business school is how valuable the network is. If I want that, I’ll take a cruise. I thought about going to law school, but it is so expensive you have to become a lawyer afterward. I didn’t want to be a lawyer. I just wanted to change my career.

So I was like, I’ll find someone who’s doing what I want to do-building a product to help people like me-and I’ll go and help them.

Oh my god, that was miserable. I lasted five months.

Commuting back and forth between Boston and Nashville did not help. I also had the brilliant idea of commuting seven miles each way by bike. In the winter. In Boston. I gave myself permission not to ride if it was under twenty-seven degrees. Being on the road in Boston is dangerous in a tank. On a bike, in the snow, was a cruel joke.

But mostly I just hated our software. I hated what we were building. At one team meeting, a senior developer said, “What does it matter what our customers think? They’ve already bought the product.” Reaction to that statement - nothing at all - told me I was in the wrong place.

So I left.

I got home. I said, I have a little money saved up, and I’ve tried everything else, and now that I think about it, I guess my dad was kind of an entrepreneur. I mean, he did run his own business for thirty years. Technically. I suppose.

Maybe I should start a company?

I know everyone in the world who is building automation tools for sysadmins, and none of them are going to build a business. “I built this, so, obviously, it’s the best.” But they’re only interested in publishing papers and getting academic tenure. Their software was already perfect, so they saw no reason to listen to anyone’s reasons for not using it.

I thought, what if I build something? And then listen to the people who are using it? (And maybe those who aren’t?) Hmm. Could work.

I quit my job. Well, I quit my job first and said, “Eh, I should probably find a way to eat.” So after trying everything else, I started a company.

We lived on my wife’s generous graduate student stipend of $23,000 a year - the job I quit paid $110,000 a year - and, like I said, I thought I had some money saved up. At some point the IRS sent me a letter that said, “We disagree,” and it turns out when the IRS disagrees with you, well, you know how that goes. And even if you’re right, by the time you prove you’re right, “Ok, I had ten grand, and I spent ten grand on a lawyer proving I have ten grand, and…” Just send them the check.

So I was broke when I started my company.

As a sysadmin, you’re not a developer. People will tell you: In DevOps, everyone’s a developer. Those people are lying to you. Or selling something. Which, you know. So I had to become a developer. I had written some code before Puppet, maybe 5,000 lines total. But by the time I handed it over, it was 130,000 lines of code.

The people I handed it to regretted my learning experience.

I adored it.

I learned a lot. It was, to be frank, super fun. One of the densest learning periods of my life. Programming is the best puzzle. I find it harder to step away from it than anything else I’ve ever done. It’s been two days since I ate, I think my wife has been trying to get my attention for the past twelve hours, I should probably … and then I try to move, my legs don’t work. I’m lightheaded from hunger and my feet are tingly.

Good times.

After about ten months I got my first paying customer.

I often advise other entrepreneurs. Much of what I tell them is to avoid what I did. I only had a vague idea for how to make money. I figured, “I’m confident I can make something valuable. I kind of have a plan, but I know my plan is stupid. If I bring my plan to people and listen to them, that could help make my plan less stupid.”

This is not that bad of a strategy! But it’s not exactly specific.

I didn’t really ask myself: What is my overall business going to look like? How will I get there? I started with services, because I’d been consulting for a while, and I was confident I could make enough money to eat. I know investors are down on services businesses, or anything that doesn’t look like a founder throwing themselves off a cliff with what they hope is a parachute. But you gotta eat. And services are a fantastic way to make money while you’re figuring things out.

I had a lot to figure out.

At the time - 2005 - there were a lot of open source companies out there. When I say a lot, there were four. I thought, “They’re doing well, I will copy one of them at some point later on.” That was not that great of a plan. Two years later Red Hat was the only one left. They’re a software powerhouse today, but they went public during the bubble as a T-shirt and mug company. There’s no copying that.

I did start making money, though. We consulted for three-and-a-half years. “We.” I was the only employee. About three years into the company, I discovered one day that I was incredibly burned out. This was the first of three major burnouts for me at Puppet.

Burnout Strikes

I distinctly remember realizing I was burned out. I was standing next to my wife, at the doctor’s office, looking at an ultrasound. We just learned we’re going to have twins, and I get a sudden flash of insight: My life is unsustainable.

I personally can’t recommend, when you’re in a bootstrapped startup, planning to have a baby. I would work especially hard to avoid having more than one at a time. But that’s what we did.

(Speaking of which: All you people who had your babies serially, you’re lazy and you don’t know what you’re doing. You think you had it hard. We were tested. Y’all are amateurs.)

The technician said, “Oh, you are going to get scanned a lot.” Um. You’re going to have to explain that one. She told us we were having two. We laughed. She must be incompetent. Just because you have twins (she did) doesn’t mean you can recognize them in someone else. While using an ultrasound wand. Which is your job. Scan… scan… BING! The two fetuses clearly popped into view. My wife would have fallen over if she weren’t already lying down. My knees shook. I thought, I can’t do this anymore.

I had been working every hour I could. I counted once: It was about 72 hours in my busiest week. There are people who say, I work 100 hours a week. You might stand there 100 hours a week. I’m skeptical you’re working. Based on what I know about productivity, I hope you’re not.

I couldn’t do it anymore. Since February 2008 or so, coincidentally the same day I found out we were having twins, I haven’t worked more than 40 or 50 hours a week. No evenings and weekends. I might dabble sometimes, but I won’t let it become a pattern.

Don’t worry. I managed to burn myself out two more times without those extra hours. It can still be just as bad. Pack that intensity into fewer hours, and you’re all good.

So. I need help. How?

Getting Help

I had tried to hire people in the past. Both of them were misses.

The first hire was the most notable. In the three months it took to figure out he wouldn’t work out, the best person I could possibly have hired became available and then unavailable. This guy’s biggest impact was ensuring I couldn’t hire the person who would have been most helpful.

There’s one more crazy story about him. In the middle of his interview at my house there was a drive-by shooting next door. He had taken a bathroom break when the shooting happened. They weren’t trying to hurt anybody, just shooting up a car to send a message. One of the bullets ricocheted off the car, then my porch, and broke my front window. He came out of my bathroom, and I said, “Are you ok?” “Yeah, why?” “No reason.”

I needed him to work in my house.

(Yes, I did actually tell him. Eventually.)

When he didn’t pan out, I concluded, I guess I just can’t hire. I’ll do it all myself.

Pro tip: Don’t do that.

Puppet worked in spite of these decisions, not because of them.

Things had changed, quite suddenly. I needed help, and now.

I hired the only people I could think of who might do me a favor: my college roommate and my best friend. Two separate people. Again: Don’t do this. I paid them full salaries.

Years later, I realized, “Wait a minute, if I was paying them full salary, they weren’t really doing me a favor, were they?”

Burned-out people make low-quality decisions. Your brain is gone, and you’re stupid. You work too many hours, you get burned out. You hurt your business doing this kind of thing. Get sleep, eat well, get exercise, step away from work. It’s good for you.

We were making a few hundred grand a year. And by “we” I mean “me.” I’m the only person consulting. I’m getting a little help with the code and stuff.

But now I’m going to hand all the consulting off to my best friend. “Ahh. I can see the light.” And by light, I mean impending twins.

The transition is bright in my memory. He was shadowing me. Μy last gig, his first one. “Hey, funny story, tomorrow this is your job.” We were in San Francisco, my only development gig fueled by Red Bull. I had made a promise to Stanford University, in exchange for some money. If I did not keep that promise by - I think it was - August 31, the Sunday after my gig ended, I had to give the money back. Of course I didn’t have the money anymore. I had to give them the code instead.

I’m at my client’s office during the day, and back in my hotel room at night pounding energy drinks and my keyboard. My kids are due any day, it’s my last flight, my last trip before they are born.

I finish it. I ship it at 1:00 a.m., send Stanford a note with all the details, and go to sleep.

My wife calls me two hours later and says, I don’t think it’s a drill, my water broke.

Well. I’m in San Francisco, and she’s in Nashville. You cannot get from San Francisco to Nashville fast enough to catch a baby. Everyone told me, “Now don’t worry, it’ll take 24 hours.” The kids had other plans.

Seven hours.

I was a father before I landed in Dallas. Cell phone pictures in 2008 were terrible, but they were enough to make me cry in the aisle.

Once again, things not to do, but it mostly worked out. My kids didn’t even notice.

My mother-in-law is actually thankful. She got to be in the delivery room instead. She would have been staring through the window if I had been there. It was great for her, and a great bonding experience for them. It was just, you know, complicated for me. If I’m going to flail at fatherhood, I could at least be present for it. Absent bad father is just a step too far.

That was summer of 2008. We were a little over three-and-a-half years in at Puppet. Lots of change all at once. We added two people and two babies. The business was picking up. I was spending more of my time at events and out in the community than writing code. Mostly this meant that the code wasn’t getting written, rather than that I had delegated it.

Again, my wife was getting her PhD. Nashville is kinda my hometown, and so as a result I, you know, hate it. I always told her I wouldn’t be at her graduation, I would be in the U-Haul honking the horn.

But she was pregnant with twins when she graduated. I was running a bootstrapped startup. We couldn’t afford to go anywhere.

What it all means

The birth of our kids was more than a turning point for our family. It transformed Puppet. It forced me to acknowledge I could not do it alone. I brought in help before they were born, and by the time they turned one I’d raised a funding round and moved to Portland.

In the four-and-a-half years of bootstrapping, we went from zero to around $250k a year in revenue, and from one to three people. In the seven years after funding, we grew to five hundred people and more than seventy million dollars in revenue. More importantly, we had an impact on thousands of people and thousands of companies.

I think founder stories are important. They’re usually educational, and often inspiring.

But they’re myth. They are a specific version of what really happened, refined and presented. Often, the myth so obscures what really happened that the lessons are dangerous rather than helpful.

This is a key story in my founder myth. For better or worse, I’m not afraid of you making catastrophic mistakes by trying to emulate me.

They say you can either be a good example or a horrible warning.

I think this story proves you can be both.

A single drink perfectly captures the weirdness of raising money for the first time. Photo courtesy of Dylan de Jonge

I found myself at a hotel with some friends. I was visiting Portland for a conference. Puppet’s first investment round – and mine! – was closing. The money was being deposited.

Have you seen a David Mamet movie, like The Spanish Prisoner? They’re fantastic. But eerie. Disquieting. They build up a story, brick by brick. Then they yank a few bricks away, exposing the whole story as a lie. Only a hollow truth remains, unrelated to your built up belief. It makes you question everything.

I’m waiting for the closing in this hotel, and I order a Macallan 18 to celebrate. This was back when it was only expensive, not egregious. I lift the glass, and I think:

The money is being deposited into my bank.

I think it’s a real bank.

I mean, they had, like, a website. And websites are pretty hard to… wait a minute.

Who introduced me to the bank?

The investors introduced me. They specifically wanted me to work with this bank. They’re the ones giving me the money. They wouldn’t say they’re giving me the money then give it to someone else. That’s a silly kind of fraud. I just have to trust them.

I sit there. Sipping my whiskey.

I think it’s a real bank.

I think I’m getting $2.25 million.

I had never seen a bank account with that many zeroes - and I still may not at that point! I have no idea what to do.

So I sit there. Savoring that delicious, delicious whiskey.

I didn’t mean to raise money. I was just focused on running the company. We had bootstrapped for almost four and a half years. I figured we were going it alone.

I had talked to people in the past about raising money. It was like Groucho Marx’s joke about clubs: I wouldn’t take money from the investors willing to give it to me. “Wow, I would love them as an investor,” you get nothing. Or, “I would happily give you money and ruin your life.” Hmm. Not really the deal I’m looking for.

One day at an event, an investor tracked me down. He said, I’d like to invest in your company. I said, That doesn’t sound right. A lot of investors say, We should talk. He said: We should talk on Monday. That specificity made all the difference.

He made a very confusing offer: We would like to write a $1.75 million check into a $2 million round. I said, how can you be that bad at math and work in finance. He said, Go find other, rich people that you know to give you the rest of the money. I said, you are, literally, the only rich person I know. He said, I just joined this firm. I am not rich. Then we’re stuck, I said.

I lived in Nashville at the time. There are a bunch of rich people there. But they’re all musicians. They don’t do technology. We most emphatically did not hang out. We weren’t going to fill this round through my network.

Eventually, by connecting me to their network of rich people, I was able to raise $2.25 million. Mostly through luck not skill. I didn’t build a deck. I didn’t run a formal process. I didn’t pitch multiple investors to get competitive term sheets. I pretty much did the exact opposite of the play book. The investor who filled out the round turned me down at first, but I heard his wife persuaded him. I don’t know if she liked me or was cursing him.

Once all of the investors are in place, you wait.

The things you learn in your first round.

Closing takes about thirty days. Five rounds later, I have no idea why. It takes thirty days, and it costs $30,000. One of the terms in the term sheet you get from your investors states that you pay for closing. “We’re going to give you this money, and then you’re going to give some of it to the lawyers.” Investors cap the fees, and the lawyers coincidentally hit that exact number every time.

I honestly don’t know what the lawyers do at closing. The documents are massively long, but they’re pretty much the same. At a late-stage company, I can understand: There is diligence to do (although not by the lawyers), financial data to look through (done by analysts, not lawyers), customers to talk to (by the investors, not the lawyers). At an early stage, though, there just isn’t much information. I don’t know what they do.

But it takes thirty days. And costs thirty grand. Says so on the term sheet.

So you wait.

But when that waiting stopped, boy howdy did things move.

The money did get deposited. It was a real bank after all.

Within a month I’d moved from Nashville to Portland. Within two months, I had my next three employees. And within six months I had a team of ten.

Raising money set us off like a rocket. Bootstrapping for more than four years provided a fantastic foundation for quick growth.

Looking back, I’m glad we raised money. I only wish we had done it earlier.

The drive for social status created the worst, most important part of the Iliad. Now it’s filling up investment announcements. Picture by Mikuláš Prokop

My fancy liberal arts school hazed me, like it does all students: I had to read The Iliad and The Odyssey.

We did more than read. We wrote. We talked. We dissected, for meaning and history. Me, and a dozen other kids I’d just met. It was school, after all.

The Odyssey is great. A proper story. Easy to read, and easy to see why it stuck around.

The Iliad is… not. It’s hard to read. Everyone in it is kind of a jerk. The biggest jerks are the biggest stars. The entire story rotates around a woman - Helen - without giving her agency. Maybe she didn’t want to go home?

For all its difficulty, it’s the more important book. Studying it taught me a lot.

Founders could learn from it even today.

In a hard book to read, one section is by far the hardest, weirdest, and seemingly most pointless. We called it the Parade of Ships, but Wikipedia uses the less glamorous “Catalogue of Ships.” It is exactly what it sounds like: A description of a lot of ships. More than a thousand. You know. Because Helen’s face was so beautiful it launched a thousand ships.

This gives us the millihelen: Enough beauty to launch one ship.

The Catalogue is scintillating:

First the Boeotians, led by Peneleos, Leitus, Arcesilaus, Prothoenor and Clonius; they came from Hyrie and stony Aulis, from Schoenus, Scolus and high-ridged Eteonus; from Thespeia and Graea, and spacious Mycalessus; from the villages of Harma, Eilesium and Erythrae; from Eleon, Hyle, Peteon, Ocalea and Medeon’s stronghold; from Copae, Eutresis, and dove-haunted Thisbe; from Coroneia and grassy Haliartus, Plataea and Glisas, and the great citadel of Thebes; from sacred Onchestus, Poseidon’s bright grove; from vine-rich Arne, Mideia, holy Nisa and coastal Anthedon. They captained fifty ships, each with a hundred and twenty young men.

That’s just the first paragraph! Every time I read this I delight in its nothingness. Now that I don’t have an essay due.

This litany, 2,500 years later, wakes our deepest fears about dusty old books. You’re probably feeling pretty good about skipping it. Yet it drove people to tell this story again and again. Being in it mattered. To your family. To your village. To everyone in Greece. Without the Catalogue of Ships, The Iliad might not survive.

Retelling a great story would always draw a crowd. (Remember: Both of these books were told in oral form long before they were ever written down.) But giving every listener a chance to brag or shrink because of the behavior of one of their ancestors… jackpot!

I was reading a funding announcement recently, and was struck by this:

Investors in the $10.1 million round for the company were led by ArcTern Ventures and joined by new backers Capricorn Investment Group, Incite Ventures. Previous financiers in the company included Wireframe Ventures, Congruent Ventures, Ulu Ventures, Energy Foundry, Hardware Club, 1/0 Capital, and Wells Fargo Strategic Capital […].

That’s a long list. Especially so for a company likely raising only its second round of funding (based on the amount).

Then it hit me:

These investors are listed for the exact same reason the ships are catalogued in The Iliad!

The Greek warriors were fighting for timé, a kind of honor and fame. The stories helped them pass it on to their descendants.

Investors are fighting for the modern equivalent (named, ironically, after a different, also unpleasant Greek story). Now it’s earned in investor announcements on sites like TechCrunch, not ship descriptions in stories told in the town square.

This is more funny than bad. There’s value in being able to track down which investors work with what kinds of companies. More openness is a great trade-off for a little exposure for the investors.

Still. Seeing the parallel was a delightful lift to the morning. I have a science degree but a liberal arts education. I love what the combination has done for my career. It’s nice to have it be a source of humor, too.

The parallel provides a lesson for founders:

The catalogue of ships describes a thousand vessels, and far more people. But most of them were never mentioned again in the story.

Don’t look for those involved in the investment. Look for who helped the company succeed. Who wrote the first check.

Science has a problem.

It’s kind of broken.

Well. Not all of it. Mostly the social sciences and medicine. And I don’t just mean the fact that they consider Freud canon.

It started with a trickle. A retracted paper here. A study that couldn’t be repeated, there.

Then someone decided to get systematic. It opened the floodgates. A study in 2016 showed that 70% of scientists had failed to replicate another scientist’s work, and fully half had failed to reproduce their own work.

Reproducibility is fundamental to the scientific method - it’s supposed to be a study of the natural world, which doesn’t change all that often - so what does its absence mean? Are we incompetent? Can we trust anything? Do we know anything?

The high failure rate of venture-backed startups is its own kind of replication crisis: “How could my company fail? I followed the growth-hacking, blitz-scaling advice from the founders who made it big!” I don’t mean to give blogs and podcasts the weight of peer-reviewed science. But our industry seems to trust them as if they deserve it.

What does it mean if a founder can’t get similar results when following the practices of another?

Science has begun to heal itself. It’s time for startups to go through their own reckoning. Their methods are failing most people. It’s time to learn why and how to get better.

What’s wrong with science?

The crisis in science has multiple, interconnected causes. A lot of them come down to taking techniques from simpler systems and applying them to the far more complex study of humans. The practices useful for studying minerals also worked great on metals, but with people? Not so much.

One of the most famous examples of these studies that fizzle under scrutiny is the marshmallow experiment, conducted at Stanford University in 1972 on the children of students enrolled there. It produced original, important conclusions on the ability of children to endure delayed gratification, and later studies showed that ability was highly correlated to success later in life. Suddenly we’ve got a new tool for understanding how successful you’ll be at a very young age.

Or… maybe not. Further studies showed the original work was actually just exposing the socioeconomic background of the kids. If your family is well off, you are comfortable with delayed gratification and, just coincidentally, are also likely to be well off when you’re older. If you’re from a poor family, delayed gratification is harder to accept and, huh, you’re also more likely to be poor than those kids of rich parents.

Once someone reran the study with a larger group of kids (900 instead of 90) and controlled for socioeconomic background… the effect largely disappeared. It’s not all that surprising that kids with no food insecurity are better at delaying gratification and also will be more successful in life. It certainly doesn’t grab the headlines like announcing that kids who can wait five minutes to eat a marshmallow will earn more money than those who can’t. No HBR article for that one.

It’s been almost fifty years since this study was published. That’s five decades of science based on flawed work, five decades of science that has to be unwound and retried. The longer these mistakes last, the more expensive they are to fix. And like that HBR article above, many conclusions never get retracted.

One particular “technique” has helped trigger the crisis in science. Many a growth-hacking product manager has fallen into the same trap. They can only be rescued through discipline and rigor.

The how and why of P-hacking

Abusing data is a sure way to get bad results. Unlike startups, scientists rarely just make up their data. They make more subtle mistakes, like P-Hacking. This probably sounds pretty cool, but it’s actually a common form of data misuse. Wikipedia describes it this way:

…performing many statistical tests on the data and only reporting those that come back with significant results.

It works like this:

A researcher comes up with an idea for a study. He collects a bunch of data, runs the experiment and… no dice. The idea didn’t pan out.

Hmm. “I have all this data. I can’t just throw it away.”

So he starts slicing the data looking for something that stands out. After a while, sure enough, he finds some correlation that is strong enough to stand up - usually its P-value is under 0.05, and thus considered statistically significant. He publishes this in a paper and looks like a genius. It gets big exposure in the press. Journalists love weird and surprising science. They can report on it without understanding it.

But no one can reproduce the work. The paper gets retracted. He gets uninvited from the big conferences. (Don’t worry. The papers never follow up and publish the retraction.)

What went wrong?

He left out one key piece: How he got the data.

Let’s say he thinks breastfed kids are healthier than bottle-fed kids. He sets up a study that tries to isolate just these variables, which means he wants his population to be reasonably homogenous (similar quality of life, similar locations, etc). Put simply, the difference being researched should be the only material one in the population (unlike in the marshmallow experiment).

But then he looks at the data and - like most of these studies - find there’s no significant difference in health outcomes between breastfed and bottle-fed kids.

He could just toss the data. But, well, he’s already paid to collect it. He’s got all these graduate students who are working nearly for free. He might as well try something. So he puts a student or two on trying to find useful results.

They nearly always do, but… that success kills his work. All those controls to make it work for his original experiment fatally bias it for other studies.

Let’s say he discovers that the study participants who were bottle-fed tended to move around a lot more than people who were breastfed. He concludes, oh, wow, getting bottle-fed causes you to hate your parents and move away. (Yes, this is exactly the kind of headline that would get picked for a result like this.)

He has not proven that. All he has shown is in this particular - probably small, and certainly narrow - data set, that happens to be the case.

He should throw away all existing data. Start from scratch controlling for everything except this new variable under test. Only then can you look for correlations between how a baby was fed and mobility.

But he was too lazy or scared to do that. He found a match in that smaller, biased data set, and then published the results without admitting the problems in either his data or his methods. A few decades ago he would have gotten away with it: A big splashy result on publication, and then everyone just assuming this was true, with no attempt to reproduce and no real questioning of the result.

Today, no chance. Science has developed defenses against this kind of malpractice.

Preregistration of experiments is a key tool.

Researchers register with a central database that they are going to study the health of breastfed vs. bottle-fed babies. When they get results, they point to that registration and say, see, this is what led to my data collection.

If they then wanted to publish some other study, people would say, no, you didn’t pre-register this, which makes us suspect you’re p-hacking, so we’re going to do a deep dive on how you got your data. On second thought, we’re just going to reject your paper. Come back when the results hold on a clean dataset.

From social science to startups

This might not initially seem to have anything to do with startups. Product managers and marketers aren’t commissioning studies - and they certainly aren’t controlling for variables!

Hmm. If you look at it a bit funny… Every data-backed marketing campaign and feature launch is an experiment.

Let’s build an analogous example.

A product manager builds a new feature, and because he’s growth hacking, he has lots of telemetry to tell him exactly how people are using it.

His theory is that people will use this new feature in some specific way. But he builds it, ships it, and observes, well, hmm, no, almost no one is using it. It’s a bust. I’m sure you’ve never worked on a project like this, but trust me, it happens.

Except… hey, there’s this small group that is using it, and widely. He looks into it more closely, and realizes they’re using it at 10x the rate people use the rest of the product. So he changes plans, and he rebuilds the feature around the specific thing those few people were doing with it.

Wait, what? No one uses that feature, either, and even worse, the people who originally used it aren’t any more, now that it’s focused on their actual usage!

What went wrong?

You got caught p-hacking

The data set from his failed feature is bad data. He got the most important result: This feature did not work well for his users. He wasn’t willing to let go of failed work. Just like the scientists, he went looking for some other way to reuse it. And instead of developing new hypotheses and running new experiments, he took his biased data and tried to find new correlations cheaply.

Unfortunately for him, he did.

But when he published the new feature, he is faced with a harsh truth: Those few people who were using the feature in unexpected ways don’t look like the rest of his users. A new feature built for that purpose doesn’t help everyone else. And because he relied on data to make his decisions instead of talking to actual users, he learned too late that those unrepresentative users were doing something even more weird. His simplified feature actually removed that weirdness in the name of simplicity that everyone can use.

So now he’s two features in and nothing to show for it. So much for growth-hacking.

How do I fix it?

The solution is very similar to what science has done.

Connect your data to experiments. With discipline. You must get new, clean data for each new test. I know this is anathema to modern data-oriented product management. But it’s the only real way to trust your results.

That word discipline is key. You don’t need to build some international central registry. Whatever your mission statement says, you’re not really saving the world, and you’re not actually doing science. You’re just trying to build a product people love. What you need is rigorous internal practices, and to hold each other accountable so you can’t cheat at statistics.

Unfortunately, this requires you let go of one of Silicon Valley’s most cherished and wrong beliefs.

No, you don’t learn more from failure than success.

Experiments fail. This might be an important part of the process, but it’s not very valuable. Congratulations. Of all the possible ways you could fail, you’ve discovered one of them. Don’t let it go to your head.

Don’t work too hard to salvage that failure. You’re p-hacking, and just making it worse. Yes, obviously, you get personal lessons. You might be lucky enough to learn something that triggers your next experiment. But you have to go run that separately.

You can’t build on the detritus of failure.

So my data is now worthless?!

Of course not. I still rely on data for all kinds of problems. One of the great things about building a company today is how easily you can get information at scale.

But never let yourself forget that your data is heavily biased, especially by how it was collected. One of my favorite examples is from when YouTube dramatically reduced response time. Their average response times went up! Suddenly people with much worse connectivity found it worth using, making the average worse. The developers thought they were helping existing users, but the biggest impact was in creating new ones.

You have to recognize your job isn’t to find some way to make the data valuable. Your job is to make high-quality decisions. Use data when you can. If you don’t have data, go get it.

But the job of the data is to inform you, not give you answers. Use it to hone your instinct, to improve your decision-making. When something doesn’t add up, go talk to the actual humans who are the source of the data. And even, spend some time with people not represented in it.

If you’re working at a software startup, you’re not doing science (even if, like me, you have a science degree). But you should still take advantage of its discipline and practices.

Don’t stop at protecting yourself from P-hacking. One founder’s success might be hard to replicate for many reasons. Gain what lessons you can. But don’t blindly trust others’ story of their work.

Because failure on your part won’t be paired with the retraction of a Nature paper, it’ll be an announcement of layoffs in TechCrunch.

Automation is not to blame for all the job destruction and wage stagnation. But you can still do great harm if you build it for the wrong reasons.

We’re told that automation is destroying jobs, that technology is replacing people, making them dumber, less capable. These are lies, with just enough truth to confuse us. You can have my robot washing machines when you pry them from my cold, wet hands.

I’m not some Pollyanna, thinking tech is only ever positive. Its potential for abuse and hurt is visible across the centuries, and especially so today. But I’m more optimistic about the upside than I am pessimistic about the down, and I’m uninterested in scaremongering screeds against it.

And yet. Technology and automation are not forces of nature. They’re made by people. By you. And the choices you make help to determine just how much good or bad they do. Even with the best of intentions, you might be doing great harm. And if you don’t have good intentions at all, or you don’t think ethics are part of your job, then you are probably downright dangerous.

I’m here to convince you that you have a role in deciding the future impact of the technology you build, and to provide you - especially you founders, tool builders, automators - some tactical advice on how to have the best impact, and avoid the dark timeline.

As I was building Puppet, explaining that I was developing automation for operations teams, execs and sales people would think they got it: “Oh, right, so you can fire SysAdmins!”

Ah. No.

When prospective customers asked for this, I offered them a choice: You can keep the same service quality and cut costs, or you can keep the same cost, and increase service quality. For sysadmins, that meant shipping better software, more often.

Their response? “Wait, that’s an option?!” They only knew how to think about their jobs in terms of cost. I had to teach them to think about quality. This is what the whole DevOps movement is about, and the years of DevOps reports Puppet has published: Helping people understand what quality means, so they can stop focusing on cost.

And those few people who said they still wanted to reduce cost, not increase quality? I didn’t sell to them.

Not because they were wrong. There were real pressures on them to reduce costs, but I was only interested in helping people who wanted to make things better, not cheaper. My mission was completely at odds with their needs, so I was unwilling to build a product to help them fire their people.

This might have been stupid. There are good reasons why a CEO might naturally build what these people want. The hardest thing in the world to find for a new product is a motivated prospective customer who has spending authority, and here they are, asking for help. The signal is really clear:

You do a bunch of user interviews, they all tell the same story of needing to reduce cost, and in every case, budgets are shrinking and the major cost is labor. Great, I’ll build some automation, and it will increase productivity by X%, thus enabling a downsizing. The customer is happy, I get rich, and, ah, well, if you get fired you probably deserved it for not investing enough in your career. (I heard this last bit from a founder recently. Yay.)

This reasoning is common, but that does not make it right. (Or ethical.) And you’ll probably fail because of your bad decisions.

Let’s start with the fact that you have not done any user interviews. None.

The only users in this story are the ones you’re trying to fire. Executives aren’t users. Managers aren’t users. It seems like you should listen to them, because they have a lot of opinions, and they’re the ones writing checks, but nope.

This has a couple of consequences. First, you don’t understand the problem if you only talk to buyers, because they only see it at a distance. You have to talk to people on the ground who are doing the work. Be careful when talking to them, though, because you might start to empathize with them, which makes it harder to help fire them.

Even if you do manage to understand the problem, your product will still likely fail. As much as buyers center themselves in the story of adopting new technology, they’re largely irrelevant. Only the people at the front line really matter. I mean, it’s in the word: Users use the software. Someone, somewhere, has to say: Yes, I will use this thing you’ve built, every day, to do my job.

If you’ve only talked to buyers, you have built a buyer-centric product, rather than a user-centric one. Sure, maybe you got lucky and were able to build something pretty good while only talking to managers and disrespecting the workers so much that you think they’re worthless. But I doubt it. You’ll experience the classic enterprise problem of closing a deal but getting no adoption, and thus not getting that crucial renewal. Given that you usually don’t actually make money from a customer until the second or third year of the relationship… not so great.

Users aren’t stupid. Yes, I know we like to act like they are. But they aren’t. If your value promise is, “Adopt my software and 10% of your team is going to get fired,” people know. And they won’t use it, unless they really don’t have a choice. Some of that is selfish - no one wants to help team members get fired, and even if they’re safe today, they know they’re on the block for the next round of cuts. But it’s just as likely to be pragmatic. You’re so focused on downsizing the team that you never stopped to ask what they need. Why would someone adopt something that didn’t solve their problems?

What’s that you say? You ignored their problems because you were focused on the boss’s needs? This is why no one uses your software. Your disrespect resulted in a crappy product.

Call me a communist, but I think most people are skilled at their jobs. I am confident that I can find a learned skill in even the “low skill” labor. I absolutely know I can in most areas people are building software.

I was talking to a friend in a data science group in a software company recently, and he was noting how hard it was to sell their software. He said every prospective buyer had two experts in the basement who they could never seem to get past. So I asked him, are you trying to help those experts, or replace them?

He said, well, our software is so great, they aren’t really necessary any more.

There’s your problem. You’re promising to fire the only two people in the whole company who understand what you do. So I challenged him: What would your product, your company look like if you saw your job as making them do better work faster, rather than eliminating the need for them?

It’s a big shift. But it’s an important one. In his case, I think it’s necessary to reduce the friction in his sales process, and even more importantly, to keep those experts in house and making their employers smarter, rather than moving them on and losing years of experience and knowledge.

The stakes can get much bigger than downsizing. In his new book, Ruined By Design, Mike Monteiro has made it clear that designers and developers make ethical choices every day. Just because Uber’s and Instacart’s business model requires that they mistreat and underpay workers doesn’t mean you need to help them. While I don’t think technology is at fault for most job losses, there absolutely are people out there who see the opportunity to make money by destroying industries.

This is not fundamentally different than the strip mining that happened to corporations in the 1980s, except back then they were making money by removing profit margin in companies and now they’re making money by removing “profit” margin in people’s lives. Jeff Bezos of Amazon has famously said your margin is his opportunity, and his warehouse workers’ experiences makes clear that he thinks that’s as true of his employees as it is of his suppliers and competitors.

Just because they’re going to get rich ruining people’s lives doesn’t mean you have to help.

I think your job matters. I think software can and should have a hugely positive impact on the world; not that one project can by itself make the world better, but that every person could have their life improved by the right product or service.

But that will only happen if we truthfully, honestly try to help our users.

When, instead, we focus too much on margin, on disruption, on buyers, on business problems…. we become the problem.