To be a good manager is to be honest with yourself and others. To be a great manager is to have the data to back it up.
Building a company requires grit, execution, honest belief in your team, and real heart. But no great company was ever built without careful and deliberate thought. The process of planning, or laying out the plan for growth, requires examination of a companies purpose, investment capabilities, and personal and company priorities.
Most of the exercises I've been in have been either a fairly fluffy form of theater designed to impress bosses and co-workers, or a whole lot of numbers. Neither of these approaches are easily translated into action. It's hard to go through and exercise as big as "where do we take the company?", and end up with something you can wake up every day and execute.
I used to believe this was because the same people that are good at running a company aren't the same people as the ones who are good at building them. But after a decade as an entrepreneur, that's not it. Lots of talented people have planning document folders on shelves and archived emails. There is something a lot deeper going on, that I think is fundamental to some of the changes we're seeing in software engineering.
It's coming up on October, and time for my management team to start talking about how we're going to move into 2014 and continue our success as a company. As I've been going into this process, I've been reflecting a lot about the process changes I have seen come about in engineering this year: The Reactive Manifesto, Lean Methodology, etc. I've been thinking a lot about how these approaches can be combined, and what it would look like if we did. I've also been inspired quite a bit by this API talk by Kevin Lacker at Parse. In it (and this is definitely a spoiler), he assigns good API design process down to one fundamentally important emotional point: laziness. Good laziness mind you, as in programmer laziness, as in "things should just make sense," or the so called, "don't make me think about things that don't matter" style of programmer logic.
If you take the Lean methodology and apply it to company planning, what happens? I think the first thing, and the primary thing that happens, is that you start looking for shorter feedback cycles. Mini-tests that you can use to provide feedback are the foundation of modern startups and good marketing programs, but they're just common sense for strategic planners. Yet almost nobody I've talked to designs their business plan to make use of testing.
Building a test-driven annual plan is the best way to figure out how to run a company. A plan is supposed to work for an entire year. However, the consequence of only planning once a year is that mistakes persist at least 12 months. I mean it jokingly, but it’s true.
It's time for companies to start applying lean principles to business planning. There is a virtuous cycle that happens when you break down a business plan into things that can be accomplished and assign them to individuals — people actually follow through. But there is probably a virtuous cycle even deeper in enabling people to learn from what they're implementing — the same benefit software engineers receive from iterative feedback in Lean.
Understanding that your people just want things to inherently work, and then helping build systems that make measure how well things are working, and whether they are a fit for the business you are running sound like common sense. We're experimenting with ways to create feedback systems in the company, and so far, it's been fantastic. The same benefits of shorter cycles, faster learning, and higher job satisfaction that you can find in Lean software shops work in business planning, and I encourage others to experiment with how a Lean, test-driven approach to annual planning can work for them.