Skunk Works and Startups
I had an argument.
Not the logical kind, mind you. No, no, no... Those take thought and require that I actually care about the outcome. Rather, this was the irrational kind where you know you're not going to change the other person's mind. You see, those are fun from a cheap thrills point of view.
Topic de jour? The GPL, one of my favorites.
Now you have to understand something about baiting a good GPL argument. The key is citing industry norms, experiences, and trends. This works well because the "industry" premise is simply invalid in the eyes of a GPL fellow and the flailing that is the result is amusing.
(For the record, I happen to be on level terms with the GPLv2, disagree with the GPLv3, and believe that a developer is welcome to license his software as he pleases. If the license a developer chooses happens to be GPL, so be it. For users and extenders of the software, the rule is simple: if you use GPL software, it stays open. If you need something closed, don't use GPL software. Now quit posting to comp.os.linux.advocacy and do something productive with your life.)
Does this make me a bad person? Probably. But in all fairness, it takes a GPL diehard on a warpath to initiate the argument with me before my evil side is provoked.
One of the benefits of these arguments is that they are an opportunity to revisit memory lane and cite examples of things that worked while making a conscious effort to avoid the things that didn't. During this particular argument, we took a tour of development teams, their size, and their impact...
Accepted belief: Small teams are significantly faster and more effective at building new products than large teams. Corollary: Large teams are slow and ineffective at building new products.
There are a few well known proof points to this argument:
The Skunk Works was (is?) a highly autonomous team created in the late 1930s and led by Kelly Johnson. Under Kelly's leadership, the group created some of the best known military aircraft in the 20th century. His well known Kelly's Rules included the rule that teams are to be kept small "in an almost vicious manner." The F117 Stealth Fighter was a disappointment for Kelly in many ways because he felt that the team had grown too large which led to troublesome development and a late project. By contrast, all of his earlier projects were small, on time, and under budget. (Recommended read: Skunk Works: A Personal Memoir of My Years at Lockheed by Kelly Johnson)
Apple's best known products were created in a similar way. The original Apple II was almost completely the design of Steve Wozniak, all the way down to the board layout and ROM software. The original Macintosh Team had only a small handful of people. The Macintosh products of the mid-90s were created by much larger teams and lacked the "ooph" that gave the original 1984 Mac the edge it had. The number of models also reflected a "design by committee" approach in their product marketing ranks.
The best example of the corollary is the IBM 360 project from the 60s. The project spanned well over 1000 software developers and generated multi-inch binders of documentation on a daily basis. Fred Brooks, the 360's project manager, went on to write The Mythical Man Month which is a must read for any project/program/product marketing/manager, regardless of industry. The project had gone so awry that Brooks created the now famous "Brooks Law": Adding people to a late software project makes it later.
The conclusions drawn out of these examples is that large teams in large companies are ineffective. This is often, but not always true. What ends up getting tagged along for the ride is the belief that large teams cannot innovate because bureaucracy gets in the way. Given enough layers of indirection within a single chain of management and innovation dies.
But is it really bureaucracy that kills innovation? Are there not examples of innovation with large teams large companies?
Actually, there are. A lot of them really. The IBM 360 project is an excellent example of this. A large team in a large company that defined what multi-user operating systems should be capable of. MULTICS, Unix, VMS, and their kids all came later. For as challenging and expensive as the 360 project was, it set a high bar for others to follow and was a key reason so many industries stuck with big iron all the way through to the 90s.
What really kills innovation is a company's culture. A company need not be large for this culture to form. I've seen it in mid-sized companies and even some small companies. The defining aspect of these cultures is PIT'M: Prove It to Me. In PIT'M, innovation is pitted against proof points. Someone proposing an idea must do so with proof points based on established market data: analyst reports, past growth, customer interviews, etc. In other words, the market has to be on its path to being a billion dollar business. While it is still possible to innovate in billion dollar markets, typically most of the innovation has already happened. If a drastic change to technology happens, it typically happens outside of an established market (e.g., Application Firewalls vs. Classic Firewalls) or a "megatrend" emerges that gives new technology a chance (e.g., hybrid electric cars vs. traditional cars).
PIT'M based businesses aren't necessarily bad businesses. Cisco is a PIT'M business and they make no bones about it. Until a market has clearly shown its path to $1B, they don't bother making a play. When it's time to make a play, they don't hesitate to acquire the innovator. Smaller plays are either ignored or viewed for their potential to enable sales of their bigger brothers. E.g., NAC enabling sales of newer 802.1x capable switches.
The other end of the culture spectrum is one that supports Gut based decision making. Innovation thrives in these environments because individuals are allowed (if not outright encouraged) to read between the lines and seek new business opportunities. In these circumstances, there is often little in the way of proof points or market analysis available. The decision is based on a certain degree of market inputs, customer comments, and intuition. In other words, your gut. There is more risk here, but it's the only way to be on the front end of innovative ideas that gain traction.
Large companies use of small teams, like The Skunk Works, for localizing Gut based innovation not because small teams are inherently more innovative. They do so to foster a low overhead environment that in turn costs less to run. Translation: flesh out the idea with a lower risk profile. Smaller companies are often forced into this role because they don't have the resources to wait for $1B markets, the corresponding research, and someone else to cook up the idea before they can jump into the game. By their very nature, they need to be on the leading end of innovation in order for them to stand out and gain attention.
Bottom line: Are small teams more effective at building products? Yes. Are they necessarily more innovative? No. Innovation isn't a question of team size, it's a question of team culture.
Not the logical kind, mind you. No, no, no... Those take thought and require that I actually care about the outcome. Rather, this was the irrational kind where you know you're not going to change the other person's mind. You see, those are fun from a cheap thrills point of view.
Topic de jour? The GPL, one of my favorites.
Now you have to understand something about baiting a good GPL argument. The key is citing industry norms, experiences, and trends. This works well because the "industry" premise is simply invalid in the eyes of a GPL fellow and the flailing that is the result is amusing.
(For the record, I happen to be on level terms with the GPLv2, disagree with the GPLv3, and believe that a developer is welcome to license his software as he pleases. If the license a developer chooses happens to be GPL, so be it. For users and extenders of the software, the rule is simple: if you use GPL software, it stays open. If you need something closed, don't use GPL software. Now quit posting to comp.os.linux.advocacy and do something productive with your life.)
Does this make me a bad person? Probably. But in all fairness, it takes a GPL diehard on a warpath to initiate the argument with me before my evil side is provoked.
One of the benefits of these arguments is that they are an opportunity to revisit memory lane and cite examples of things that worked while making a conscious effort to avoid the things that didn't. During this particular argument, we took a tour of development teams, their size, and their impact...
Accepted belief: Small teams are significantly faster and more effective at building new products than large teams. Corollary: Large teams are slow and ineffective at building new products.
There are a few well known proof points to this argument:
The Skunk Works was (is?) a highly autonomous team created in the late 1930s and led by Kelly Johnson. Under Kelly's leadership, the group created some of the best known military aircraft in the 20th century. His well known Kelly's Rules included the rule that teams are to be kept small "in an almost vicious manner." The F117 Stealth Fighter was a disappointment for Kelly in many ways because he felt that the team had grown too large which led to troublesome development and a late project. By contrast, all of his earlier projects were small, on time, and under budget. (Recommended read: Skunk Works: A Personal Memoir of My Years at Lockheed by Kelly Johnson)
Apple's best known products were created in a similar way. The original Apple II was almost completely the design of Steve Wozniak, all the way down to the board layout and ROM software. The original Macintosh Team had only a small handful of people. The Macintosh products of the mid-90s were created by much larger teams and lacked the "ooph" that gave the original 1984 Mac the edge it had. The number of models also reflected a "design by committee" approach in their product marketing ranks.
The best example of the corollary is the IBM 360 project from the 60s. The project spanned well over 1000 software developers and generated multi-inch binders of documentation on a daily basis. Fred Brooks, the 360's project manager, went on to write The Mythical Man Month which is a must read for any project/program/product marketing/manager, regardless of industry. The project had gone so awry that Brooks created the now famous "Brooks Law": Adding people to a late software project makes it later.
The conclusions drawn out of these examples is that large teams in large companies are ineffective. This is often, but not always true. What ends up getting tagged along for the ride is the belief that large teams cannot innovate because bureaucracy gets in the way. Given enough layers of indirection within a single chain of management and innovation dies.
But is it really bureaucracy that kills innovation? Are there not examples of innovation with large teams large companies?
Actually, there are. A lot of them really. The IBM 360 project is an excellent example of this. A large team in a large company that defined what multi-user operating systems should be capable of. MULTICS, Unix, VMS, and their kids all came later. For as challenging and expensive as the 360 project was, it set a high bar for others to follow and was a key reason so many industries stuck with big iron all the way through to the 90s.
What really kills innovation is a company's culture. A company need not be large for this culture to form. I've seen it in mid-sized companies and even some small companies. The defining aspect of these cultures is PIT'M: Prove It to Me. In PIT'M, innovation is pitted against proof points. Someone proposing an idea must do so with proof points based on established market data: analyst reports, past growth, customer interviews, etc. In other words, the market has to be on its path to being a billion dollar business. While it is still possible to innovate in billion dollar markets, typically most of the innovation has already happened. If a drastic change to technology happens, it typically happens outside of an established market (e.g., Application Firewalls vs. Classic Firewalls) or a "megatrend" emerges that gives new technology a chance (e.g., hybrid electric cars vs. traditional cars).
PIT'M based businesses aren't necessarily bad businesses. Cisco is a PIT'M business and they make no bones about it. Until a market has clearly shown its path to $1B, they don't bother making a play. When it's time to make a play, they don't hesitate to acquire the innovator. Smaller plays are either ignored or viewed for their potential to enable sales of their bigger brothers. E.g., NAC enabling sales of newer 802.1x capable switches.
The other end of the culture spectrum is one that supports Gut based decision making. Innovation thrives in these environments because individuals are allowed (if not outright encouraged) to read between the lines and seek new business opportunities. In these circumstances, there is often little in the way of proof points or market analysis available. The decision is based on a certain degree of market inputs, customer comments, and intuition. In other words, your gut. There is more risk here, but it's the only way to be on the front end of innovative ideas that gain traction.
Large companies use of small teams, like The Skunk Works, for localizing Gut based innovation not because small teams are inherently more innovative. They do so to foster a low overhead environment that in turn costs less to run. Translation: flesh out the idea with a lower risk profile. Smaller companies are often forced into this role because they don't have the resources to wait for $1B markets, the corresponding research, and someone else to cook up the idea before they can jump into the game. By their very nature, they need to be on the leading end of innovation in order for them to stand out and gain attention.
Bottom line: Are small teams more effective at building products? Yes. Are they necessarily more innovative? No. Innovation isn't a question of team size, it's a question of team culture.
posted by Steve Shah at 8:30 AM
0 Comments:
Post a Comment
<< Home