(via scaryideas.)

• Platform selection and technical design
• Seeing the big picture (in graphic detail)
• Provide options
• Find the 80/20 (understand the objective and then give it for 20% of the cost)
• Grow technical leaders (and technical skills of the organization)
• Own the development methodology (it decides what we can do and what we need to do)

1. Not getting involved in “the business”
2. Keeping the technology vision in your head
3. Adopting bleeding-edge technology
4. Giving up control of the development process
5. Staying too hands-on and not getting hands-on enough

I actually found it interesting how these were still applicable to my current non-startup role. Hard won lessons, all so thanks Carl !

The bleeding edge technology one is one I’ve managed to avoid (though my team would argue any open source and anything but java is bleeding edge), but I think more poignant is the one about giving up control of development since it makes it impossible to execute on a technology vision. And yeah, could probably be accused of keeping too much of the tech vision in my head (or not communicating it well enough). Sometimes what seems obvious and transparent when you’ve thought it up is pretty murky to other people (so add communicating it better as well).

Interestingly, I’ve got the opposite problem on the “Getting Involved with the Business” side. I try to get involved with the business outside of pure tech and get rebuffed, at least in my current non-startup role. Yes, this is more political gatekeeping and small-minded empire building/protecting and not at all good for the org. It’s maddening, especially when you’ve got actual expertise in a particular area (like for example, business intelligence or KPIs but can’t get traction because “you’re the technology guy”). The other flip side of this is too many wish list demands rather than things that may actually be needed.

I was thinking about the mistakes I’ve made in the past as well reading this.

• Going with What’s in Place

  Quite often, you’ll find that coming into someplace there is already a “solution” in place. Sometimes it’s clear that this solution is not going to scale, meets the needs a few months down the road and generally will be painful. Examine the assumption underlying the selection and if they’re no longer valid or have big holes, well… Kill it. Smother it with a pillow if necessary while it sleeps but get rid of it if you have a better solution that is clear and unambiguous (or even less problematic). If it cost money and the current thing is “free” build up a case to show that it isn’t or how the new thing will solve problems/drive benefits. If you don’t need to do these things, just do it quickly. Out behind the shed. With a shotgun.

• Just Good Enough is Good Enough

  Perfect is the enemy of better. I’ve gotten a lot better at this one, but the fact is users and the business always want a pony. Follow the idea of 37 Signals’ : Be ruthless about adding new features in if you can avoid it at all. For example, on one of my apps at this very moment I’m ripping out massive stuff we put in since it never gets used and clutters UX and functionality (and we sacrificed actual useful features to build). See next point though.

• Not Paying Technical Debt Back Quickly Enough

  Technical debt accumulates rapidly. You might think the interest on your credit cards is bad, but the fact is not refactoring and not redesigning when you have to leads to a while lot of problems for later iterations. It goes on long enough and you require a big bang re-write which is always problematic. Trying to re-implment all those features and knowledge of the system all over again is rarely done with perfect fidelity. Work it into your plans. Do it often. Do it early. Even if you’re being lean.

Disclosure: Carl had the terrible misfortune to hire me and be my boss for the first year I was at my last company. I still think working with Carl and Core was some of the most fun I’d had had in a long, long time when I took the job. I still miss our desks back at the old office on Pacific (and the experience is a stark contrast to my current experiences with AI). I fully intend to make the new gig in Aus at least as fun as Van was.).

The two failures he mentions, which are great, really honest and open stories are deeply ingrained parts of his character. And I love the way he looks at them… He had to screw up those jobs. He has this great analogy about kids always trying to push boundaries and break rules by discovering the shape of the world and banging into them to figure out the shape of the world. Kind of professional failures are just like that as an adult. They govern the shape of his intuition and plan past the worst case scenarios.

Avoid the carney, the sea-monkeys and the trolls. Write content to be identifiable, engender trust and provide clarity on calls to action.

(via Seth’s Blog.)

OK, so this article a bit of a classic around the Net, but I think it’s important to remember that if you’re not Google or YouTube or insert mega corp here that you need a customer and audience strategy (note to people who are not thinking this way : If you think everyone is your audience strategy, you don’t have one and should do some audience and/or market research).

And this is where community and direct contact is essential. As KK says, keeping in touch with your true fans is the key way to keep them happy. Understand their needs, feed their enthusiasm, riff off their ideas and creativity and take care of them.

Even if you are a bigger company this isn’t necessarily a bad strategy to follow. Look at Apple, for instance, who I’d argue have followed this strategy into being a widely loved and respected innovating consumer products company via the iPod and iPhone while still keeping their core macaddict fans.

I can imagine a few other things you need here, like a complete sandbox for for each dev, as well as the continuous integration server to keep testing every commit, and the cultural change is enormous but not onerous.

I think the other important thing is that this is scary. Even me at my most crazy would be a bit concerned about this. People will be worried, especially if this is something you haven’t done from the very start. You also need a culture that doesn’t punish honest mistakes. Otherwise, people will fear to deploy something in short cycles from idea to production in nothing time.

I’m also very curious about how they role out distinct changes to only certain users in order to make sure that they have metrics and testing on features they should keep or discard before rolling things out to the broader base.

Kinda curious as I’d like to apply this to some of the Rails work we’re doing. What sort of continuous integration servers are people using ? Technically I’d want the thing to run at a minimum, cucumber and rspec stories and be triggerable off a git repository (or even better, github).

For the real nitty-gritty on the CI stuff, look at this other article of Eric’s.

One of the major things we’ve learned about user stories, even if we’ve never articulated it, is about “popping the why stack.” In essence, you ask “Why ?” a number of times and, if at the end of those five whys, the answer isn’t increasing revenue, protecting revenue, or reducing costs, that feature you’re writing probably isn’t worth the time.

I never realized the idea came from Toyota where it’s practically a gospel part of their keizen process in improving quality and reducing defects.

Obviously, your first priority is to get it back up. But as soon as the crisis is past, you have the discipline to have a post-mortem in which you start asking why.

The next step is this: you have to commit to make a proportional investment in corrective action at every level of the analysis.

I’m totally lurving this idea and going to bounce it off my team, because we’re great at hustling to fix things but slow(er) to take corrective strategic actions which will prevent things happening again. Wondering how they’ll go for this idea. Actually thinking going to try it on a project retrospective we’ve got coming up as well with a cross departmental team.

20th-Century Business, you’re fired. The global economy has decided to let you go. Why? Because you turned out to be, well, a less-than-productive hire. You failed to live up to your end of an implicit but very real social contract: do stuff that makes people better off. Instead, you did stuff that trivializes, belittles, and enfeebles people.

Great read. Down with the zombieconomy ! Please put this guy in your rss feeds.

Excellent slideshow presentation from Eric Ries on the lean startup. Lurved this and totally trying to bake this into our organizational DNA. Code fast, test often to validate hypotheses, learn faster, repeat.

Loved the lessons learned from a failure he examined : the fact that the future is hugely uncertain, you know what customers want, you can predict the future with any accuracy and mistaking advancing your strategic plan with real progress.

Nice slides I am soooo going to steal for when I need to present on these same idea. Interesting to see that the successful startup Eric mentioned is tracking on some of the same things we’ve been doing back on our ranch (or trying) in terms of metrics, monitoring and feedback.

(via Tweet from Barsoom Core.)

1. Find quick money first.
2. Content businesses suck (or: do it for love and expect to lose money).
3. Know when to value speed vs. stability.
4. Set a dollar value on your time.
5. Marketing requires constant expertise.
6. Control and calculate your user acquisition costs.
7. Form partner relationships early, even if informal.
8. Plan costs conservatively and err on the side of raising too much.
9. The key to negotiating is having options.
10. Knowing isn’t enough.

Along with this, check out the excellent post from Guy Kawasaki’s blog on the first year financial estimates for Redfin.

(via Signal vs. Noise.)