How to destroy a tech startup in three easy steps

I created the rough draft for this book by copying and pasting all of the relevant corporate emails and Slack messages. Then I added in much of the text I’d written for the blog post “What happens when the Board Of Directors begins to panic”. Then I wrote out a several scenes that were not covered by either of those three sources.

This gave me 100,000 words, which was far too much. Corporate email tends to be the dullest kind of communication, so nearly all of it needed to be re-written and condensed.

In the end, the book had less than 58,000 words.

In the editing process, I had help from Alice Hindanov, and, especially, Natalie Sidner. As we shrank the book smaller and smaller, we cut many scenes that I thought were interesting though they distracted from the main story.

To show our editing process, here I post 2 scenes that were cut for 2 different reasons.

I had many, many anecdotes about bad management decisions that John made. At a certain point, these become excessive, so we had to cut most of them. What follows is not dramatic enough to justify inclusion in the book. Rather, it is one of a thousand such scenes that undermined my confidence in how the project was run.

Monday, June 22nd, 2015

I woke up at 10 AM and made breakfast and coffee. I posted on Slack that I’d be in late. John sent me a response.

John
Whatss yr status, we have a ton of stufff to go over a I am about to run out of the office for a litttle.

We had no scheduled meeting for the morning. I told him I’d be in by noon.

At 2 PM we had a meeting scheduled to go over all of the tasks in PivotalTracker. John had promised Milburn that we would execute our work according to a project-management philosophy that the tech industry called agile. Agile software development, among many other aspects, focuses on the delivery of small, incremental improvements to software. It encourages self-organizing teams, evolving and continuous progress, and rapid response to challenges faced. The Celolot team would work two-week sprints, checking in at the end of each period to see where everyone was at.

Unfortunately, vague definitions of “done” haunted our progress. John read through a long list of tasks that had been assigned to Sital.

“Find all possible variations of ‘Close Date,'” John read from the screen. “Is this done?”

“Yeah,” muttered Sital. “Sure.”

His assurance meant nothing to me. Sital would never lie, indeed I was often surprised by his childlike honesty, but he lacked an appreciation for the many ways that software could break.

“How many variations have been tested?” I asked.

“Two,” replied Sital.

“That’s not enough,” I said.

“That’s enough,” countered John. “‘Close Date’ and ‘Contract.’ That’s all we need.”

“What about ‘Close’?” I asked.

“Oh, yeah,” John thought aloud. “What about ‘Close’?”

“I’ll see,” Sital responded somewhat robotically.

John marked it as done.

“Wait,” I objected. “That is not done.”

John turned back to Sital. “Do you think you can finish today?”

“Absolutely,” Sital assured us.

“Then I’ll mark it as done,” said John, returning to his screen.

“But it’s not done till it’s done,” I argued.

John pondered this for a brief moment. “It’ll be done today,” he shrugged. He marked it as done.

In my view, John’s casual use of the word “done” to refer to items that were nowhere near done meant that this whole effort to track tasks was a useless ceremony. But John felt good about it. He could tell Milburn that we were following a two-week sprint, just like an authentic agile team.

It was true we had the accoutrements of an agile team. We used PivotalTracker. We broke down goals into fine-grained tasks. We reviewed the task list once a week, and we added more tasks every two weeks. But the whole thing was mockery of what the Agile Process was supposed to accomplish. If you have programmers who cannot finish assignments, then there is no point in pretending to be making progress.

I loved working at the NYU incubator. The whole experience was a treat. I got to meet many amazing people.

I originally included some of their personal startup trajectories in the book, but ultimately all such anecdotes had be cut, because they distracted from the main plot, which was about John and Milburn’s terrible decisions.

Here I include a conversation with one of the many interesting people that I had the pleasure of getting to know.

Thursday, July 23rd, 2015

Around 10 PM much of the office emptied out. There was a keg in the back of the office. I regard this as amusing: the incubator wanted to be understood as a hip place where creative people could invent the future, so it offered fairly good coffee, and fairly good beer, and it’s all free. However, no one thought to set up a budget to buy milk or cream for the coffee, so they put jar near the coffee, and they put up a sign saying we had to put in 50 cents any time we used the milk. The sign had a warning: “If we don’t get enough money to pay for the milk, then we will no longer be able to provide milk.” So this was a place where the beer was free but the milk was expensive. These kinds of minor inconsistencies tend to spring up in any large organization, and incubator was part of a university and subsidized by the government of New York, so perhaps for us to get free milk would require a vote by the Legislature. Thankfully, I was unaffected, since I do not usually put milk in my coffee or beer.

Svetlana came into the kitchen, drew a beer from the tap, and went back to her desk. When I went back to my own desk I asked what she was working on. She showed me the new signup page, which they were aggressively A/B testing. She’d come up with 8 variants on 3 completely different designs.

I said something polite about the A/B testing, remarking on the wisdom of trying multiple designs, each as different as possible. She surprised me by answering that she had put a lot of work into it, and she felt her company would benefit from it, but her best ideas were too often shot down by Daniel, the CTO. A real sense of disappointment now shaped her view of the company.

She was being paid very little, perhaps half of what she might make if she worked for a large corporation. A fancy title was the main benefit of her job: Head Of Design at SomeScenesSeen. But the title would only be meaningful if they were successful. If SomeScenesSeen failed, then her title was worthless. And even if they succeeded, it was worth something only because what it might bring her in the future.

Nearly all of us do this at some point, where we work for some low rate at a job that we hope will open doors for us. I did the same thing for several years.

Unlike many of the other founders at the incubator, Daniel had no real need for money. He was from a wealthy family, and they had set him up so he could get started. He was drawn to startups because of the autonomy they offered, and the chance to prove to the world exactly how much his vision of the future was true. More so, he estimated himself highly, and wanted to convince the world that his self image was justified. A guy like Daniel would find it disgusting to work at a large corporation, where his freedom to maneuver would be severely cramped.

But Daniel was 23 years old and he was still learning about software, even as he built his company. Like a lot of the best programmers, he had a strong sense of craftsmenship, but his sense of what constituted quality was evolving. When he started the company he wrote everything using the PHP language, then he became disgusted with PHP, and then he fell in love with what he felt was the elegance of Javascript, so he re-wrote all the company’s code in Javascript. This lead to delays.

When Svetlana had first joined the company, she was told that they would go public in three months, or they would have to close down. That was two years ago. Daniel had found the money to keep things going, but they had not yet gone public. They had shown the product to a few dozen journalists and writers, but they had not yet launched. Every time Daniel had delayed the project by changing technologies he had apologized. He felt very bad about missing deadlines. But Svetlana didn’t need him to feel bad, she needed him to figure out a process that would lead to success, or she needed him to call an end to the project. It was the endless trying but failing that put her in a bad spot.

Svetlana was now 26 years old. She was wondering, at what point did this company become something? At what point could she ask for a real salary? What if SomeScenesSeen failed? Was she simply wasting her life by working here? Should she work somewhere else? She felt some loyalty to the company. On a personal level, she liked Daniel very much. But on a professional level, she worried that these two years were going to amount to nothing but a giant hole on her resume that she would have an awkward time explaining.

Venting is healthy and I was happy to listen. She wasn’t looking for advice, and I had none to give. I was sympathetic to all concerned. Like Daniel, I could remember that sense of craftsmanship, which sometimes made me want to re-write all of my code. I had felt it keenly early in my career, when my sense of quality was evolving rapidly. Back in 2004, when I had my own startup, I often used the nights and weekends to refine my code, because I was deeply frustrated with the way I had done things in 2002 and 2003. And I certainly felt Svetlana’s concerns. Anyone in a leadership position takes on the ethical obligation to use people’s time wisely. That’s true even if the people are well paid: no one wants to feel like they are wasting their abilities, even in exchange for decent money. But the ethics of the situation are more urgent when someone has agreed to work for less than what they are worth, on the mere promise that your abilities as a leader will take them a place that is successful. And when those in leadership positions fail at their tasks, they are both ethical and professional failures.

A final note: I had many, many anecdotes about Sital’s unprofessional behavior. If I’d included them all, then it would have seemed as if the book was about Sital, rather than about John and Milburn’s bad decisions. Sital is at the beginning of his career, so there is no justification for writing a whole book about his mistakes. I’m sure he’ll get better over time. All the same, it was important to communicate that in 2015 he didn’t have the skills that we needed. I knew we needed to include some anecdotes about his inexperience, so the reader would understand my frustration with him. I don’t know that we hit the right balance, in terms of including enough to explain my frustration, without spending excessive time focused on him. Perhaps it is worth repeating, he is not guilty of being inexperienced, since he is at the beginning of his career. Rather, the leadership is guilty of hiring the wrong person for that particular task. We needed someone who could move fast, someone who understood both NLP and computer programming. Sital was not the right person in 2015. Perhaps in 2020 he will be the right person for a similar startup.

I hope you enjoyed the book. Please leave a comment below.