Download - 10 Things Not to Do in a Startup
10 Things not to do in a Startup
John Coggeshall
Hi, I’m John!
18 years in web development, PHP Former Sr. Architect, Zend
Technologies Core PHP Contributor Startup CTO Business Owner
What we’re talking about today This is going to be an entertaining talk
about failure
I’m pretty good at failure
I’ve watched a lot of people fail too
I’ve also learned a lot in the process
Names have been changed to protect me as necessary
Failure Scoreboard
????? ????? ????? ????? ????? ????? ????? ????? ????? ?????
This really happensAct I
My first gig
New minted consultant at Zend Technologies
First big project is working on Signature Network’s biggest client, the band U2
My first gig - FAIL
The project was doomed from the start
Technical Debt isn’t like a bank loan, it’s like the mob.
Bono publically apologized for the failure (awesome)
Failure Scoreboard
Do not neglect technical debt
????? ????? ????? ????? ????? ????? ????? ????? ?????
Some time later..
Hired by another development shop to work on the Amp’d Mobile backend
Severely over-architected CMS
Wouldn’t scale, all hope is lost.
“Amp'd Mobile takes the crown for money-burning with $360 million in losses.” – Quicken
Failure Scoreboard
Do not neglect technical debt.
Do not overcomplicate.
Do not ignore the advice you are paying for.
????? ????? ????? ????? ????? ????? ?????
Let’s talk about Joe
Joe is a construction guy and he had an idea for a great new web site that was going to make all sorts of money
Joe doesn’t know the first thing about programming web sites, but what problem could that be? He doesn’t need to know right?
Let’s talk a bit about Joe.
Joe is an idiot.
It’s okay if you want to start a tech company but don’t know how to write code
It is not okay to do so without having a quality partner who does
It is not an acceptable substitution to just hire a programmer employee and rely on them for business decisions
Failure Scoreboard
Do not neglect technical debt.
Do not overcomplicate.
Do not ignore the advice you are paying for.
You must have expert skills in your tech as partners not employees
You get what you pay for, don’t be cheap.
????? ????? ????? ????? ?????
Hey! I’m CTO!
Despite what you might think from this talk, I am actually pretty good at my job.
Hired on as CTO to a startup called Individual Digital
Like many fledgling startups, we had plans to take over the world.
…. And we failed.
Where’d we go wrong?
We were well funded.
We had good ideas.
We had good market opportunities.
We had good tech and the staff to run it.
We had it all, but one thing
We had it all but…
We displeased our masters (investors) by tying the success of our product to a single thing.
As executives / founders we allowed ourselves to be boxed in to what amounted to acceptance criteria
We were succeeding in building a business, just not the business our investors wanted.
Failure Scoreboard
Do not neglect technical debt.
Do not overcomplicate.
Do not ignore the advice you are paying for.
You must have expert skills in your tech as partners not employees
You get what you pay for, don’t be cheap.
You must manage expectations
You must be flexible
????? ????? ?????
Everyone messes this up
Act II
Everyone messes this up
What follows happens almost every time I walk into a project
Many of you have experienced this
We can all commiserate together!
Open a damn ticket.
Any project of any size needs a way of managing the tasks to get it done
Word docs are great for first cuts into a new project, but break that down into discrete tickets
Pick a philosophy for development, I really don’t care if it’s Agile or Waterfall – and stick to it.
Failure Scoreboard
Do not neglect technical debt.
Do not overcomplicate.
Do not ignore the advice you are paying for.
You must have expert skills in your tech as partners not employees
You get what you pay for, don’t be cheap.
You must manage expectations
You must be flexible
You must have a development process
????? ?????
Keep it simple, stupid.
In life, in development, in anything. Never forget KISS
Keep requirements clear but simple Keep features lean and useful Keep architecture clean and
expandable Keep process structured and habitual
Failure Scoreboard
Do not neglect technical debt.
Do not overcomplicate.
Do not ignore the advice you are paying for.
You must have expert skills in your tech as partners not employees
You get what you pay for, don’t be cheap.
You must manage expectations
You must be flexible
You must have a development process
You must keep things simple
?????
Last but not least….
Thank you!
Follow me on Twitter @coogle, Check out my code on Github (coogle)