Learning lessons in startups

I had the chance to attend the Startup Lessons Learned conference last week, a day of talks (videos) by entrepreneurs who have been using the Lean Startup approach to help navigate a path amidst uncertainty. The model, elaborated by Eric Ries over several hundred posts on his excellent blog, has been gaining traction recently in my part of town (and today in the NYTimes). Startup face the unusual challenge, he argues, of having to find a solution to a problem when neither the solution nor the problem is entirely known at the outset. The structure and behavior of the startup should be optimized for learning, and for learning fast: One part of the company focuses on understanding the problem, while the other part focuses on learning how to build a solution to the moving-target of a problem. The two parts coordinate through a unified feedback loop (build, measure, learn), which should be repeated as rapidly as possible. The goal of the Lean Startup approach is to maximize the likelihood of figuring things out before exhausting the available resources.

Our own startup has taken this model to heart, and it very much characterizes my day-to-day experiences there. As my research has been focused on how to construct productive social learning environments, the lean startup has been a fitting (and fascinating!) context in which to engage in this work. In some ways, I see the pair-programming process adopted by our engineering team as a model for the type of learning environment that we’re building in order to support collaborative learning online. The knowledge sharing that happens through interactions among peer learners also happens among our developers while pair programming. I wonder about the extent to which this is a useful parallel to draw, and am curious if the strengths and limitations inherent in the one suggest corresponding strengths and limitations in the other. Are purely-Agile teams averse to taking on technical challenges that cannot be solved through verbal discussion? Does this in any way affect or characterize the software that results? For as much as I believe in the power of learning as a social process, I think there is always a need and a place for slowly grappling with thorny problems, both for students and for software developers.