
Ways Founders Sabotage Themselves - sunilkumarc
http://techcrunch.com/2014/06/07/dear-clients-please-stop-ten-ways-founders-sabotage-themselves/
======
claudiusd
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...

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

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

------
wpietri
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...](http://www.quora.com/Startups/What-are-common-
misconceptions-about-startups?share=1)

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/](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?

~~~
idrisser
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 :-)

~~~
wpietri
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](http://leanstartup.pbworks.com/w/page/15765221/FrontPage)

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

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

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

~~~
wpietri
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.

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

------
hyp0
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".

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

~~~
raverbashing
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

~~~
benatkin
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.

