How to Destroy a Tech Startup in 3 Easy Steps

Author: Lawrence Krubner, Natalie Sidner
4.6
This Year Hacker News 4
This Month Hacker News 1

Comments

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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.)

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

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:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...