Optimization versus Learning
I’m reading The Lean Startup, by Eric Ries, and I can’t believe I haven’t read it until now. It’s the best business book I’ve read in a long time. I promise a full review once I’m done, but I couldn’t wait to point out one really important point that connects to something I feel very passionate about: systems thinking and organizational learning.
Part of the lean startup model is a rigorous focus on what Ries calls “validated learning.” If you’re creating some new awesome app, it’s not enough to just optimize the features and make the app better and better as a software product–you actually have to learn whether the product’s whole business model is going to succeed while you’re creating it. That’s different work than optimizing, but in the software world (and outside of it, I would argue), putting in the hard work of optimizing is valued, even if it’s not getting you the results you need. So what do we do? We blame the workers for not working hard enough. From the book:
I’ve been called in many times to help a startup that feels its engineering team “isn’t working hard enough.” When I meet with those teams, there are always improvements to be made and I recommend them, but invariably the real problem is not a lack of development talent, energy, or effort. Cycle ofter cycle, the team is working hard, but the business is not seeing results. Managers trained in the traditional model draw the logical conclusion: our team is not working hard, not working effectively, or not working efficiently.
In truth, they are simply executing a plan that does not make sense. And unless you’ve built in a clear process for learning why that plan does or does not make sense, you run the risk of this hamster-wheel dynamic. This is one reason why I hate the way most organizations use strategic planning. It separates the thinking from the action and usually distracts you from valuable learning.