At a friend's suggestion, I recently read The Lean Startup, by Eric Ries. It was sometimes a bit fluffy, and I think it could have been a much tighter book if it were about 30% slimmer. But there are a couple of really interesting ideas in there, and I'd like to talk about two of them.
The main topic, especially in the first part of the book, is all about making informed decisions - a process Ries called "validated learning." He quips that the best way to achieve failure is to execute on your plan perfectly - and end up with a product nobody wants. By getting real feedback from customers as early as possible, you avoid the worst types of mistakes, and get to put the maximum amount of time and energy into improving something people want.
This concept seems pretty sound, but the process of implementation seems a bit... fuzzy to me. Yes, information is good. And I can certainly see how feedback very early can help, especially "real" feedback, based on customer behavior. But not all products scale into new markets in such a way that early tests become invisible later on. If you're testing a new soda, you can run trials in a couple cities. But if you're writing political jokes for the news, or making episodes of a nationally syndicated tv show - that sort of process doesn't really obtain.
Re-defining Waste
But it's part 3 where I found myself really finding some fascinating insights. Part 3 of the book is no longer discussing how to build your ideas - it is about eliminating waste and increasing efficiency. It draws heavily on Toyota's "Lean Manufacturing" strategy, so in that spirit I'll try to illustrate the central idea:
Imagine that you have a plant which makes cars. There are 20 divisions within this plant. One division makes wheels - they fabricate enough wheels for 100 cars each day. Another division makes seats - enough for 100 cars each day. Another build the engines - enough for 100 cars each day. Overall, the factory produces all necessary materials for 100 cars each day, across 19 divisions.
But that final division is the "assembly" division - and they can assemble only 50 cars a day. So your total output is 50 cars, not 100.
A very reasonable way to think about this situation is to say that the assembly division is working too slowly - you need to staff them up, or somehow get them to 100 cars a day. But the Lean Startup thinks differently - to the Lean Startup, 19 of the 20 divisions in this plant are wasting 50% of their effort every day. Fully half of everything being made is just waste. Fabricating 100 engines when only 50 are used is the height of inefficiency!
Instead of trying to fix the assembly division, all other divisions should cut their production in half, and then see if they can do something extra to improve the assembly process. Perhaps the undercarriage could be assembled by the leftover staff from two divisions? Maybe parts could be fed to the assembly staff in a better order, organized by some of the people who used to be fully occupied with fabrication?
This approach seems a bit odd - but there is a very important concept, which is that everyone is working towards a single goal - making cars. If you allow divisions to focus too much on their individual bits of that process, you can have 95% of your staff working at half efficiency, with all of them blaming the 5% who is actually working without any waste.
If you can, by re-organizing every division EXCEPT assembly, get to a point where you are building and assembling 70 cars a day, you then have a good basis upon which to expand your total output.
Don't Bother the Programmers
This concept really resonated with me, because of a phenomenon I've dealt with for more than a decade called "don't bother the programmers." The idea behind it runs like this - programmers have important work to do, and they are always behind. Therefore, you shouldn't bother them.
But this never works out very well - because invariably a lot of what the programmer do turns out to be only marginally useful. Sometimes a feature which takes 2 weeks to build ends up being something easy to cut, or turns out to not really add much to the product. Management can't find and eliminate these sort of issues ahead of time - it needs to be a living process. That means programmers need to be involved in the development, not just working off a static list of features.
I've seen every discipline be the bottleneck at one time or another - and in every case everyone who isn't part of that bottleneck feels really good about not being in the hot seat. But by the Lean Startup method, there is no such thing as being successful within your department but failing overall - the team lives and dies together. That means bottlenecks are more a result of everyone else working piecemeal, rather than one particular person / group not working fast enough.