Ways Founders Sabotage Themselves | Hacker News Reader

Ways Founders Sabotage Themselves

techcrunch.com

76 pointssunilkumarc15 comments

These 10 things are never going to change. Why? Because pedantic, well-paced software engineering isn't sexy. You know what's sexy and exciting to a startup exec (especially one with an ego)? Tight deadlines, going viral, going head-to-head with the biggest companies on earth, and dreaming big. The worst part is, all of these things actually work in Sales.

I've read this same advice in one form or another many times. This is all well-known stuff and "clients" still aren't learning as far as I can tell. I don't think they'll ever learn because proper software engineering practice is counterintuitive and the attitude of management will not lend itself to these practices.

Instead of talking about the problems, I think we need to arm engineers with techniques for defending proper software engineering practices. Lean and Agile methodologies have helped considerably, but I think more work is needed to truly ease many of these frustrations. I'll let you know once I've figured it out...

This post contains so many true statements. As beeing a freelance consultant for the past 9 years, I can comprehend every single point of the posting.

Especially the premature scaling combined with technical debts is a very common pattern. Companies tend to use the latest technology but also ignoring every common pattern of sustainable software engineering (e.g. tests, code style). Usually the involved developers are quite new to the technology and will make a lot of mistakes. Some will learn from their own mistakes over time and fix it, some will never learn and continue providing a negative value to a team.

I've seen this anti-pattern in various web-related companies and startups. The technology never was the primary reason of the failure but people problems (lack of skills, lack of proper management, lack of social skills — both of the developers and the business owners) was the #1 reason.

I've seen this with Perl, PHP, Java, Ruby, JavaScript/Node and all different types of NoSQL DBs when people use them "for the wrong thing" or didn't understand what's the trade-off.

Looks like even today everyone is believing in new and true silver bullets for each technical venture instead of combining the best practices with as little trade-offs as possible.

Wow, a lot of this rings true. I've witnessed #5 directly, and it's maddeningly frustrating. Once the execs get this idea that viral is this magical path to user growth, the idea can't be killed. This is the plan:

1. Start with our product that has nothing to do with social networking

2. Spoon in some "social" and "sharing", and mix.

3. ROCKETSHIP VIRAL GROWTH OMFG!

...and when you don't get to step three, just keep adding MORE SOCIAL!

Force people to log in using Facebook! Put share buttons everywhere! Harvest the user's address book and spam it! Harvest their Facebook friends! Add Twitter! Add Google+!

What's worse is when you're resource constrained and you stop working on the core features of your product: the features that actually bring real users to your product to.

Shameless (relevant) hijack: I want HN's advice on a book I'm considering doing.

Backstory: somebody on Quora asked about common startup misconceptions: http://www.quora.com/Startups/What-are-common-misconceptions...

Off the top of my head I named a bunch and it turned out to be a popular post. Somebody said, "Hey, that's a good outline for a book!" I thought, "Hm, let's give that a try."

So I could get feedback, I put together three sample chapters and a landing page:

http://williampietri.com/book/

Now I'm trying to decide: If I do the (substantial) work of writing it, will enough people read it to make it worthwhile? (Worthwhile is defined here in terms of impact. I'm sure it won't be as profitable as doing something technical, but there's an audience of first-time entrepreneurs I'd like to help.)

In particular, I'm wondering:

* Will new entrepreneurs bother to buy and read a book about problems?

* Will people who deal with entrepreneurs find a book like this handy enough that they'll make new entrepreneurs buy and read it?

Had a similar idea while reading this article: I was thinking of a website "How to do things", crowdsourced like Wikipedia where anyone could contribute. So examples could be: How to launch a ecommerce marketplace, or How to launch a Saas, etc. And you could read the manuals, edited by people that learned the hard way. And useful for some that didn't go through incubators. Plus we can extend out of startups/businesses. I like this idea of your book, but if you get a particular point wrong you can't change it, whereas by doing a crowdsourced website anyone can improve. Just my midnight 2cents :-)

I think both would be useful.

If I do the book, I'll do it through some medium like Leanpub so I can put out drafts to many people and get feedback. And after 18 months or so, I'll put the posts up on a blog so people can comment forever. But the nice thing about a book is that it's done; I don't want to be forever updating the material.

The how-to website would be cool. There's a lot of info out there that isn't well captured.

If you're excited to jump in on a related effort, there's the Lean Startup Circle wiki: http://leanstartup.pbworks.com/w/page/15765221/FrontPage

Sean Murphy in particular has done a ton of great work on that.

"The 4 Hour Workweek" had a great launch strategy that I suggest you steal. Tim Ferris basically did what we call Lean these days to figure out what he should title his book so that it would sell well.

>Yes, your app/site/service needs to be built within a technical architecture that can scale…

This is where many teams drop the ball. They start building their app/service with persistence technology that really can't make it to web scale. Their plan is to "build a team to solve the big-data challenge when we hit that level of scale".

Many of these shops that decide to worry about big-data challenges later on do end up solving the problem in time so from the outside they look like a success. What you're not seeing is how the founder's equity gets eroded as he is forced to borrow money in order to build out the team to rearchitect the app in order to deal with the scale. Many VCs want for us to accept this as a normal part of building apps because it ensures that they get a major piece of the pie. It doesn't have to be this way though, we can start thinking about data access patterns in the large from the very beginning.

Much of this advice is already well-known to these founders, but they do it anyway. And why? A big part is motivation. To do a startup, you have to motivate yourself and often part of this is falling in love with your product or your technology and dreaming big. So as an example some technical founders love figuring the scaling out and this motivates them to create a proper, clever product, even if it never reaches 10 users in the end. Without such motivation, no product.

Personally, I try to keep the dream and the motivation, but be choosier about action. That is, even if I want to build a giant system, I start small. Because avoiding the premature scaling is part of how I raise my odds that I'll have enough users to justify scaling.

This is just so true... been working with startups for about 4 years now. A lot of my time goes into educating them about not making this sort of mistakes.

I like viral the old-fashioned way, by word of mouth. Simple short memorable; problem you solve; positioned among alternatives; intriguing/funny/elegant.

People pass it on for its own sake... and if that problem comes up in conversation, "oh I heard about this thing for that".

Most of these are things that some successful founders get right, particularly scaling. Scaling needn't be a huge timesink. A couple of products I just started using are Slack and Circle CI, and I think each of them built for scale early on.

Yeah, to design for some initial growth is good, but you don't need to go for "Google scale" and "how are we going to do if we have 100Mi users tomorrow"

So basically don't worry about how to shard your DB to hundreds of instances and split loads across EC2s on different continents on day 1

When they do that, they are usually putting the cart before the horse in how they're scaling it. They have some things that would theoretically work on a massive scale but not a solid setup for a hundred thousand users.

Reply on news.ycombinator.com