How to Destroy a Tech Startup in 3 Easy Steps

Category: Genre Fiction
Author: Lawrence Krubner, Natalie Sidner
This Year Hacker News 4
This Month Hacker News 2


by lkrubner   2019-07-12
From 2002 to 2008 I was the technical co-founder of a startup, and I had amazing fun. I worked 70 hours a week for 6 years, mostly because we were having so much fun.

In 2015 I was the lead engineer at a small startup that had a self-destructive and abusive top leadership. The technology was very exciting but the context was not.

What I learned from the two experiences is that startups can be intense fun if you are one of the owners, but if you are not an owner, startups can be absolutely miserable. More details are available in the book that I wrote:

by lkrubner   2019-06-24
This can lead to bias about whole categories of experience, for instance, starting a business. If you only hear the success stories then you start to think it is easy. You might intellectually be aware that 90% of all businesses fail, but that anecdote doesn’t carry as much emotional weight as hearing people’s joyful stories of success. That’s why I think it is important that we document some of the failures and we do it while the memories are still fresh and when we still have access to documents such as email and Slack messages that can offer the gritty details of what went wrong. That ideal if accuracy and specifics are very much what guided me when I wrote this:

by lkrubner   2019-06-07
What I learned is that these jobs are only really fun if you are the founder. Over 20 years, I was the technical co-founder at 3 different startups, and I had crazy fun at each of those jobs, even when we were working 70 hours a week. Because when you are a founder, you're really only under the pressure that you yourself set for yourself. Yes, I worked very hard, but I was working on my ideas, I was meeting cool people, I had absolute freedom to set my own hours. It was fun.

I then made the mistake of thinking that I would also have the same kind of fun as an employee. I became the tech lead at a startup, thinking I would have the kind of freedom that I previously had. This was a mistake. I was very excited about the technology that this startup was working on, but in the end I found, these jobs are much less fun, if you are not the founder, because there is a lot of pressure that comes from up above you, and when you come up with what you think is a great idea, you don't get to implement it. And there are additional frustrations: for instance, on this project I came to believe that it was crucial that we fire our initial data scientist, but the top leadership refused to fire him. This was a major roadblock that I would not have faced if I was the founder, as I would have had the authority to fire someone if I was the founder.

For anyone interested, I wrote in great detail about the experience here:

by lkrubner   2019-05-31
Far more startups die of suicide than homocide and that was true of the last startup that I worked at, which I’ve written about here:

by lkrubner   2019-05-24
I wrote of my experiences here, as a cautionary tale, and an antidote to the often over optimistic hype about startups:

by lkrubner   2018-12-24
About this:

"I mean, essentially it's a command line interface with a wonky input method, no?"

This is precisely the feedback we got from salespeople, when we were working on a Natural Language Programming interface for Salesforce. Initially, I got angry and denied the comparison. But after several people made the same comparison, I came to appreciate how true it was. Unless NLP is perfect, it is really just a Command Line Interface with an awkward input device. I talk about this a little towards the end of this story:

by lkrubner   2018-11-15
I've seen some young people who are very good managers, but I've also seen some absolute disasters. I've also seen some older folks who are absolute disasters. I shared a story about both kinds of manager in How To Destroy A Tech Startup In Three Easy Steps:

by lkrubner   2018-11-10
After many years trying a vast variety of project management software, I've come to the conclusion that what matters most is the project manager, rather than the software. Nowadays when I consult with clients I advise them: "First, find a really good project manager, and then use whatever software they want to use." If you have a great project manager, and they prefer to keep track of everything on crumpled up napkins, then the whole team should be given an ample supply of crumpled up napkins. Great project managers are rare, but if you have a great one, you should let them set the parameters of project management for your project.

When you have a bad project manager, good software will not save you. This is my personal story of how things can go wrong:


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.


related to here:

by lkrubner   2018-11-10
A huge problem with CRMs is the lack of staff engagement. A company will spend $30 million to customize their Salesforce workflow (or their SAP workflow, or any other workflow or CRM tool) but the staff will hate it and so the investment seems wasted. That’s why Natural Language Processing seems like it could be a win for this space. A salesperson should be able to write a quick text message on their phone, and that message should be parsed by an NLP script and then put into Salesforce. The promise of this idea, as well as the problems, I detailed here:

by lkrubner   2018-11-10
True, and someone who is a great salesperson probably has skills that are optimized for the context of sales. But another aspect of getting promoted is that a person is given oversight of new kinds of activities, where teams work with different cultures and different rules. I've seen some sales manager succeed by being bullies to their sales team. But I think it is a disaster when someone attempts to bully a tech team. So what works in one context fails in another context. I've tried to describe this previously:


Every industry has certain euphemisms for the least savory aspects of its business. In sales, there is the secretly ugly phrase, “goal-oriented.” That sounds pleasant, doesn’t it? If I point at a woman and I say, “That entrepreneur is goal-oriented,” then you probably think I am complimenting her. But if I point at her and say, “That entrepreneur is a lying, manipulative, soulless psychopath who brutally exploits labor from the eleven-year-olds she employs in her sweatshops in Indonesia,” then you probably think I am insulting her, unless you are a libertarian. And yet both statements mean about the same thing: that she is someone who is willing to do whatever is necessary to ensure the success of her business.

When I read about Milburn online, I’d seen testimonials from his colleagues in which he was often described as a goal-oriented salesperson. That probably meant that he was a master of manipulating other people’s emotions. He knew all the tricks: praise, shame, laughter, anger, promises, guilt, threats.

Whether his use of these tools was conscious or unconscious is, of course, unknowable. But it doesn’t matter much. A lifetime as a sales professional left him with an arsenal of psychological ploys that had become second nature to him.

...Milburn truly had a genius for the strategic use of anger. If he sensed the risk of losing control of the conversation, he would indulge in another outburst. If I were to ever switch over to the Dark Side, I would want to study with him. His techniques were fundamentally dishonest and manipulative, but that is probably what made him so good at sales. And his tactics were probably an effective way to drive a sales team, but I sincerely believed that such tactics were the wrong way to run a software development team. Especially when doing something cutting-edge original, like we were doing, I think open and honest communications were extremely important. (I have worked with many companies where the sales team was both friendly and successful. One does not need to use abusive tactics to have success in sales. Indeed, the sales manager who relies on abuse is typically more interested in aggrandizing their own success, rather than the success of the company they work for.)

by lkrubner   2018-11-10
For the most part, a person only gets invited to give a speech if they are one of the lucky few for whom things went well. If your situation is more ordinary, and you've failed, then you not invited to speak. Because of this, we (the public) end up with a distorted view of things. Success seems more common than it is, because we only hear from the successful. That is survivorship bias. It's also why I've argued we need more honest stories about projects that fail:

by lkrubner   2018-11-10
I strongly agree. I'd like to see more honest conversation about the problems people face when building a business. I'd like to see more honesty about failure. I'd also like to see more transparency about the amount of personal conflict that tends to come up when building a business. This sums up my views:


Recently, I exchanged some email with my friend Colin Steele, currently CTO of TypeZero and formerly CTO of We discussed another startup that had failed, and he wrote:

It’s sad and disheartening. I think few people understand how amazingly difficult it is to start a new business, and run it successfully. Drama, people, and personalities, seem to have an outsized role in how these things crash and burn. There needs to be some codification of best internal practices for creating startups, like Steve Blank’s book “4 Steps To The Epiphany,” but for the culture; a co-routine that runs alongside “customer development” — call it “culture development” or something.

I agree wholeheartedly, and would also add that more public discussion of the difficulties would help startup culture. I would make an analogy to the history of divorce in the United States. The divorce rate rose for much of the twentieth century, and it peaked in the 1970s and 1980s. Since then there has been more public discussion about what makes marriages strong. You can see the trend reflected on television shows: neither Leave It To Beaver nor the Brady Bunch mentioned the difficulties of marriage, and that was the era when the divorce rate was rising the most. Modern sitcoms talk endlessly about the difficulties of marriage. Couples still face drama and conflict and personality, but the public discussion seems to have granted people the vocabulary they need to address their problems, and the divorce rate has come down. Popular awareness helps. At the very least, books and movies can help explore the important reality that startups are not easy.

by lkrubner   2018-10-07
Some leaders are control freaks, and they resist anything that reduces their control of things. Some are so hungry for control that they behave in irrational and arbitrary ways, often undermining themselves and their companies. I wrote about this at length here:

by lkrubner   2018-08-17
I hope I won't bore people if I repeat a point that I've made before: far more startups die of suicide than homicide. The tendency to self-sabotage, among entrepreneurs, is surprisingly strong. And I’m hardly the only one who has noticed this odd fact. The great business guru Peter Drucker made the point repeatedly. In his 1985 book Innovation and Entrepreneurship, Drucker includes a long chapter on the tendency of entrepreneurs to destroy the innovation they’d created.

For those interested, I've written about this elsewhere:


We might hope that those in leadership positions possess strength and resilience, but vanity and fragile egos have sabotaged many of the businesses that I’ve worked with. Defeat is always a possibility, and not everyone finds healthy ways to deal with the stress.

Each person matters. Established firms will have a bureaucracy that can ensure some stability, even when an eccentric individual is in a leadership position, but when a company consists of just two or three people, and one of them reacts neurotically to challenges, the company is doomed.

From 2002 to 2008 I worked with an entrepreneur who had inherited a few million dollars when he was twenty-five. He admired musicians and considered the music industry glamorous, so he built a sound studio. It never made money. The bands that stopped by were broke. Those few who came up with a hit song mostly signed with a major label which, typically, had its own recording studio.

I met him in 2002 when his focus was shifting to the Web. I had developed some software that allowed people to create weblogs. Typepad, which fostered something similar to what I’d built, had just raised $23 million in funding. Surely we could do the same?

Our difficulties were self-imposed. We might go like maniacs on some project for four months, and when we were on the brink of unveiling it to the public, he would grow bored with it and move on to something else. The first time this happened, and I asked him his reasons, he improvised some arguments that sounded plausible; there were already too many startups doing the same thing. But this pattern, where he walked away from a project just when we were ready to introduce it to the public, repeated itself.

What led to this self-sabotage? As I met his whole family over the years I got to see the sad dynamics that ate at him. A modest business success would not be enough, in fact, it would leave him embarrassed. Only the creation of something as big as Google would suffice. But to grow that big, we would first need to be small, and that was the step he had no patience for.

As the years went by and he burned away all the money he’d inherited, the stress wrecked him. His self-image became increasingly grandiose. He told people that he was a visionary, someone who was able to tell what the future would look like. Late at night he would smoke weed and read articles on Slashdot and TechCrunch and then put together an amalgam of words that seemed full of the bright hopes of humanity, which he offered up as our marketing: “The Universe is fundamentally electromagnetic yet non-sentient, and we are sentient but only partly electromagnetic; the Internet is the ultimate harnessing of sentience to the fundamental forces of the Universe. Therefore our software will put you, our customer, in the driver’s seat of real-time conscious human evolution.” Later, when he wrote up our business plan, he put these two sentences in the executive summary. I’m not joking.

We had one modest success, in 2007. His girlfriend, a yoga instructor, suggested we build an online marketplace where yoga instructors could sell videos, as well as other health advice. This site was an immediate success. Within the first month it was profitable. We were written up in all of the major yoga magazines. It seemed obvious to me that we should use the same technology to build a series of similar sites. We could do a site devoted to cooking videos, another devoted to tennis, another devoted to golf. Indeed, just a few years later, the team behind did exactly what we could have done.

My business partner, however, was enraged by the success of the yoga site. He had burned through several million dollars chasing ideas that he felt were “visionary” and then his girlfriend came up with a simple idea that turned into our one true hit. To this day, it remains a popular yoga site. We could have built an empire around that site, but instead his girlfriend’s success left him bitter.

by lkrubner   2018-08-16
The more original the technology, the more insane it is to draw up sales schedules before the technology works. I've written about this before.


Tuesday, June 9th, 2015

John told me that the board of directors had drawn up monthly sales goals for him. Starting in August, he would be expected to hit his quota. I thought this was insane. Once a product exists and is stable, then a company can draw up a sales schedule. How can one reasonably do that when the product does not even exist yet? Especially if the product is a cutting-edge technology which carries a lot of unknowns? For a stable company with an existing product, deadlines need to be more than mere aspirational goals, but when building truly original technology, then the entire company is aspirational — until the technology is working, there is no proof that the technology can work.

Even if the glorious day arrived when we would finally have an app customers could install on their iPhones, that would only be the beginning of a long process. Customers are an endless surprise. I’ve worked with startups for sixteen years; I know this well. Whenever I have shown people new software, the features that seemed intuitive to me were counterintuitive to them. Real-life needs that seemed intuitive to them seemed strange to me. If John thought that we could create our apps and have them working by mid-August, and he could immediately go out and start making tons of money, then he was sadly mistaken. If the board of directors thought that, then they were being badly misled.

by lkrubner   2018-04-02
And also, what if they are lucky enough to get close to success? How should they handle it? When should they trust their own instincts, versus when should they defer to experience? I've written at length regarding what happened when a 22 year old was given $1.3 million dollars and the chance the run with a great startup idea. A very cutting edge idea that was full of potential. It should have become something great. But the mistakes made were of a type that might be expected from a lack of experience.

That is the flip side of it. Endlessly shouting "Express yourself and amazing things will happen!" is a bit of a trap. It doesn't prepare kids to handle the lucky breaks that some of them will undoubtedly get.

by lkrubner   2018-03-31
There is the risk of conflating two separate types of problem. There are problems that arise from the complexity of the code, and problems that arise from particular people.

If a programmer has a habit of sloppy code, or violates the team's standards in some ways, then a good leader will keep track of the fact that one person is responsible for a recurring pattern of mistakes.

I absolutely agree with Rachel By The Bay, that many bugs arise from the complexity of the situation, and it would be wrong to blame the person who just happens to trip over that bug. But a good leader should take action against anyone who repeatedly screws up, and who seems unwilling to improve.

I've written about this before. This is from "How To Destroy A Tech Startup In Three Easy Steps":


Wednesday, July 15th, 2015

I got to work at 11:00 a.m. John announced that our demo had stopped working. Sipping my coffee, I logged into the server to find out what the problem was. I looked at the error log for the API app, but it seemed okay. Then I checked the error log for the NLP app.

java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring( at

What the hell was this?


What kind of name is that for a function?

A computer programmer can name their functions anything, but there are some “best practices” regarding names, and this particular function name violated all of them.

I asked Sital why he had given this name to his function. He looked at me straight, shrugged, and stated that the name was from the 1995 song by The Notorious B.I.G., “Get Money.” I replied that rap lyrics were not part of our naming conventions. He promised that he would change it.

Coming from anyone else, I might have interpreted the function name as an act of angry rebellion, but Sital was too forthright for that. Apparently, he thought the name was funny and went with it because he wanted to add some humor to his code. Never did he stop to think it might be unprofessional.

I looked through his code and found several other functions that had inappropriate names. I sent him a list and asked him to change their names to something standard.

A week later the function was still there. FuckBitchesGetMoney. Yet I don’t think that any of this was a deliberate act of rebellion. He was just oddly forgetful and disorganized.

by lkrubner   2018-03-18
This was talked about on Hacker News yesterday:

by lkrubner   2018-02-25
I get that any kind of writing can provoke strong reactions, as some people have strong preferences. And they have a right to those preferences. But I hope we can agree that being vocal about one's preferences is a different kind of activity? Everyday on Hacker News there are dozens of articles that don't interest me, but can you imagine what people would think about me if, in every one of those articles, I posted a note saying that I didn't like the article?

Most of us simply skip over the stuff that doesn't interest us. That is clearly the default behavior. Therefore it is interesting why, on certain articles, people do feel the need to comment on the style.

Personally, I've been lucky, because the most vocal people have been the people who like my writing. But not always. I wrote a book about startups, and some people loved that it had a lot of humor, whereas others really hated it. At least so far, the one's who hate it write to me privately, whereas the ones who love it have written the reviews on Amazon:

I'm lucky, but I'm also curious why this is. As a purely sociological question, why is that sometimes people feel the need to be very vocal with their disapproval, whereas most of the time they keep such disapproval private?

by lkrubner   2018-02-17
Strongly agree. I would like to spend more time teaching junior developers what I know. But anything that slows down a small, agile startup can mean the death of the startup, so this tends to undercut my ability to do any kind of mentoring.

Excerpt from a real life situation I was in:


June of 2015:

Sital was a beginner. In general, there is nothing wrong with being a beginner. All of us are beginners at some point. And for the most part, I think corporations in the USA can do more facilitate apprenticeships to help people start their careers. However, we were a startup that needed to move fast. Could we succeed when we had a beginner in a critical role? I had doubts.

July of 2015:

I felt no sympathy for John. Hiring Sital had been his call, as was failing to hire Arthur. These last few weeks had offered plenty of evidence that Sital was a liability to the team. If John wanted to stick with Sital, he would have to live with the consequences.

I would feel very differently if Celolot had a formal commitment to an apprenticeship program, and if I had clearly been given the responsibility of running that program. And I do think corporations in the USA can do more to help people start their careers. But it was ridiculous to both want to run an aggressive schedule and also train a beginner. The one contradicts the other.