

"I Did a Bad Job" - AshMokhberi
http://blog.ashmokhberi.com/post/2940181809/i-did-a-bad-job

======
bluethunder
This is a really insightful writeup. Thanks.

I just wanted to mention that a lot of things that you did bad, look so only
in hindsight. Not that they are not bad, in the sense that you could have done
better, but the very same things that now look bad could be construed to be
actually 'good' had your startup gone right. Even the startups which do end up
successfull do not become so by doing everything right.

For example:

1\. Your co-founder was not committed due to mortgage or family, however he
was a great tech guy. And there is a chance that hte startup might have done
better, without him spending as much time, in which case you would have duly
thanked his technical chops which contributed to startup success.

2\. If you would have been stricter with the goals your co-founder might have
bailed early. Had the startup done better, being less strict could have been
construed as a good management decision which helped accomodate your co-
founders competing personal commitments.

3\. Similarly for setting a deadline - sometimes things just take longer, and
your startup might have turned over a good leaf by just trying hard enough.
There is really no easy way to know when you have to stop.

Essentially, the point that I am trying to make is that it is extremely hard
to figure out what is the real reason for failure, and most such analysis
misses the woods for the trees.

However, being able to distinguish correlation from causation is extremely
critical as it is the basis on which startups should pivot (or shut down).

~~~
AshMokhberi
You have some very good points, which I'm in agreement with. It's impossible
to analyse the defining points of failure and come out with the correct
answers. But trying to understand what was not working well cumulatively, is a
better way of understanding how one problem can stem into many more. Should I
have broken the idea down soon enough and got something visible out there,
potentially non of the other issues would have arisen or not been so relevant.
The same goes for any of the other points I mention.

------
toadi
Lots of people work on startups having a families and a mortage.

That's why I disagree that the choice of co-founder was bad because of these
reasons. I think this is a overgeneralization.

Then you state you should manage development better and set better
expectations. Well I think this is the main reason in the failure.

Did your co-founder knew exactly what you espected?

~~~
AshMokhberi
I agree it is over generalisation, but I feel in my case it was a main
causation. He did under stand what my expectations where. However it was more
that most of the time he had to work to support his family. He was not in a
9-5 job, he was doing freelance. So its not like he had a defined amount of
time he could work. Clients work always came first and consumed most of the
time.

~~~
toadi
Well I can fill 14 hours a day with client work too. But when working for your
startup you calculate the minimal income you need and only spend the amount of
hours on a client to earn it.

The rest of the time is spent on working for your startup. When I was co-owner
of a isv our main income in the beginning was consultancy for clients. In
addition we developed our product and used the spare money to hire additional
developers. The consultancy work made sure we had a minimal paycheck at the
end of the month which would pay our mortage and the bills.

Maybe this model is not sustainable anymore with being quick to the market and
bead competitors on speed. But it worked in that period of time.

~~~
studiofellow
This is exactly what I'm doing for my startup and have found it works really
well. Although I have to say it helps to have even a small network of contacts
who can direct work your way. It's easy to burn through a lot of time just
looking for freelance work.

------
jacquesm
The hardest part for me in analyzing past (partial or complete) failures is to
make sure that none of those will bite me again. if there was a way to
guarantee that you only make every mistake once then that would be progress.

Kudos for being able to look at your own project this ruthless and to try to
distill the lessons. If you succeed in never repeating any of the mistakes
please tell me how.

As for the write-up: you did a good job.

~~~
AshMokhberi
Thanks I'm glad you appreciated it. It is likely that I will make the
same/similar mistakes again, no one can prevent it. I think understanding what
mistakes you are likely to make, allows you to watch out for them. While you
will still make them, you will be quicker to try and remedy the situation.

------
biot
One thing not mentioned is: "I did a bad job... selecting the idea". For
myself, I've had some stunningly lousy ideas that, at the time, I thought
would change the world but looking back I'm glad I never executed on them as
they wouldn't have been viable no matter how flawlessly they were executed.
I've also had my fair share of ones that I should have executed on but didn't
so it goes both ways.

~~~
Locke1689
I agree. I read the DistinctID idea and immediately had a pit in my stomach:
"I hope the technical lead has a really good security background."

Many software projects are, as I like to refer to them, "generalist projects."
A good developer can make significant progress and success with these kinds of
projects. However, there are some projects that I feel very hesitant about
when someone without domain experience is brought on the project. These kinds
of projects include, as a brain dump: machine learning, OS/low level systems
development, cryptography, distributed systems in challenging environments,
and reliability engineering.

I'm not saying a non-expert can't succeed in these areas, just that it makes
me antsy.

------
snippyhollow
I'm a terrible programmer [http://blog.kickin-the-
darkness.com/2007/09/confessions-of-t...](http://blog.kickin-the-
darkness.com/2007/09/confessions-of-terrible-programmer.html) !

~~~
Tycho
One thing that seems terribly broken in most IDEs/code-editors is that tiny
spelling mistakes can ruin your program. Visual Studio helps out with
AutoComplete, in that you can deliberately never fully type a
variable/function yourself, always use intellisense to complete things and use
the right letter case. Although it's still not completely immune.

When you run a script in Coda, say, first instinct is to look for functional
problems, and usually there will be some, so you'll change stuff. But
_additionally_ there will be these tiny spelling errors, and failing to fix
them right away leads to all sorts of trouble.

How do most folk deal with this? Just get 'better' at not making small
mistakes?

~~~
Vivtek
You get better at not making them - but much more importantly, you get better
at realizing what mistakes you're likely to make, so when you make them and
something doesn't work as expected, you find and fix the small mistakes very
quickly.

You also generally get better at testing and at diagnosis.

It _does_ get better.

~~~
ams6110
Yeah you get better. It's like learning to ice skate, maybe... you fall a lot
and get a lot of bruises at first but eventually it gets to the point where
you don't think about it.

I learned to program before IDEs and I still use Emacs as my primary editor
for almost everything. I find the Visual Studio "IntelliSense" type behaviors
in most IDEs annoying in the extreme. But I can see how if that's what you
started with, you'd come to find it useful.

~~~
Tycho
With VS it's almost like testing each individual line though, at least for
syntax and spelling. What I did was deliberately type things with as little
attention to case/formatting as possible, and then watch to see VS transform
it into neatness. Which meant it understood the line as expected.

Can't expect every editor to have the same features, but some sort of 'smart'
plugin would that monitored your words and picked up things that were
'probably a mistake' would be useful. Then you could run the plugin every so
often. A spelling mistake can be practically invisible because of the way your
brain processes things.

------
BrandonM
"I did a bad job" Proofreading this blog post. I'm not usually a pedant, but
this post repeatedly made basic grammar errors. It detracted and distracted
from what was otherwise a great article.

~~~
AshMokhberi
Sorry if it spoilt the experience. I will try to pay more attention next time.

Thanks for pointing it out. :)

~~~
BrandonM
The main thing was the frequent use of "where" in place of "were." Another
thing that jumped out at me was the omitted words in the introduction. If
you'd like me to go back and proofread, I'd be happy to.

Thanks for an insightful article.

~~~
AshMokhberi
Thank you very much for offering. I would really appreciate it, if it will not
consume too much of your time.

You can mail me at, me[at] ashmokhberi [dot] com

Thanks very much in advance.

~~~
BrandonM
Sent.

------
gohat
This is very helpful and appreciate it.

I think one of the most important skills to have in business and
entrepreneurial pursuits is realizing when things aren't going great. You
develop the tendency in life to whitewash things, to always think in the
positive.

But this isn't always necessarily good. I read a fascinating piece which said
that depressed, pessimistic people were actually more accurate in their
analysis of some things than happy optimists.

Being able to think/accept that you have room to improve is a good thing. It's
when the real improvement/learning takes place.

------
RyanMcGreal
Indeed:

"Our servers are over capacity and certain pages may be temporarily
unavailable. We're incredibly sorry for the inconvenience."

~~~
AshMokhberi
haha, tumblr is always doing that :)

~~~
RyanMcGreal
It's back up now - and definitely an insightful read. Thanks for sharing.

------
bourbaki
You did a bad job? In that post, you analyze perfectly the causes of your
failure. If you learn something from that experience, your job wasn't bad, was
good. Have success is important, everybody wanna get money and fame, but fail
and learn from it is important too.

~~~
isleyaardvark
If you don't look back and think you did a bad job, it obviously means you're
not improving.

------
infocaptor
The important fact is "You did a job". Some people never get to do the "job"
or "work for themselves". Can you believe that for the first year of my
product (infocaptor) I had zero sales. At that I kept feeling, "I did a bad
job" doing the following -selecting the market -selecting the coding language
-marketing and so on..

But eventually I prevailed. The product is now successful and all the
learnings is only going to shorten the path to success for my new product
(mockuptiger)

I like to enjoy the journey more than the destination and think financial gain
is just a side effect. ofcourse you need mile posts to know that your are
going somewhere and these financial gains are excellent mile posts.

So enjoy,live and learn - repeat :)

