These are my slides/notes from a presentation I gave at Boom Startup in Utah in July 2011. I found this while cleaning up some old stuff in Dropbox and I figured I would make it public because why not?
Hello, my name is Jay, and I work at Plancast.
Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it (1973). This paradox implies, essentially, that you have to "solve" the problem once in order to clearly define it and then solve it again to create a solution that works. This process has been motherhood and apple pie in software development for decades (Peters and Tripp 1976)...
One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked. Programming assignments in school are devised to move you in a beeline from beginning to end. You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. But that very process is an everyday reality in professional programming.
The only way to know if a startup will work is to try it and find out.
Markets that do not exists cannot be analyzed: Suppliers and customers must discover them together. Not only are the market applications for disruptive technologies unknown at the time of their development, they are unknowable. The strategies and plans that managers formulate for confronting disruptive technological change, therefore, should be plans for learning and discovery rather than plans for execution. This is an important point to understand, because managers who believe they know a market's future will plan and invest very differently from those who recognize the uncertainties of a developing market."
I think it was Steve Blank who said a startup is a company formed to find a business model.
No One Size fits all...not for building your company or, on the technical side, solving scaling issues.
This is the first Plancast Techcrunch traffic spike.
Plancast's database Munin CPU graph, trying to figure out a rogue query right before SXSW.
Funny story, the rogue query was a
SELECT * FROM users that was buried in a certain page load and had existed from Plancast's inception. The query wasn't a resource drain in the beginning (small user base) and so it sat there...waiting. I never noticed it because it blended in with the normal server load increases that come from a growing user base, but when we hit a critical mass of users it all of a sudden appeared, literally like flicking a switch, and became an exponential resource hog that kept taking the site down.
I said there is no one size fits all, but now I'm going to retract that a bit and say there are certain things that are pretty much universally needed across all companies.
- To activate, people need to visit your site at least three times.
- On your site, they need to find at least three things that interest them each time.
- To lose them, they don't find interesting things on your site three times in a row.
It's hard to get people you've lost back, so try not to lose them in the first place.
Accept what type of site you are.
At Plancast we finally realized we're an event site and looking at the numbers, we were never going to be more than a 1x/week frequency visit for most users, much to our chagrin.
No one cares what happened in the past. We lose half our content every. Single. Day. So there is no evergreen content benefit like other sites might have.
Normal people don't like to do things4, this has caused us to Pivot to support more "professional" events.
Spend where you should, be very careful about who you hire and how you spend your money.
Developers should have nice chairs and nicer computers and monitors.
We comically over-provisioned our app and db servers, everything else we cut corners on.
How Larry Ellison got efficiencies from teams5:
He told me a story of how Larry Ellison actually got efficiencies from teams. If a team wasn't productive, he'd come every couple of weeks and say "let me help you out." What did he do? He took away another person until the team started shipping and stopped having unproductive meetings. (via)
We suck at hiring, so I've got nothing to say about that6.
Never too early to start defining your company culture.
Ours is helicopters. And I'm not a morning person.
Choose wisely! All of our downtime for the last three months has been because of MongoDB7.
I have absolutely no problems annoying the one or two pedantic people who care about this for the benefit of thousands who don't.
Time for an old-school analogy question: Silicon Valley is to entreprenuers as blank is to actors?
Hoooooray for Silicon Valleywood!
I can't say where a startup should be located, I can say it is cool to be at a party and look over and see the Twitter founders. Or to hang out after some dinner event and listen to Prominent Venture Capitalist talk about raising money for his fund. There is just no other place in the world where stuff like that happens every. Single. Night8.
Any questions at all?
Code Complete, section 5.1, Design Is a Wicked Problem. ↩
Innovator's Dilemma, p165 ↩
Fun fact, I think this is the first place I ever talked about this law outside of Plancast's office. ↩
Many people just don't fully appreciate how little the average person likes to plan and do things. ↩
Plancast was never larger than about four people, but the people we did hire were amazing, so maybe suck was too strong a word, it might be better phrased as we were incredibly slow to hire. ↩
Here's a fun game: guess what database Path had the most problems with? ↩
I still think this is true and still chose to leave Silicon Valley because there are many other factors that go into choosing where to live, like how good the schools are, or if you want to own your own home, or you like seasons. Also, Israel is pretty great also if you want a tech capital on the other side of the world. ↩