Startup vs. big company culture

Since Larry Page became Google’s CEO again in April, his focus has been on “making a company of more than 24,000 employees act like a startup“. And because of my interest in mapping out organizational space and understanding the different ways in which people can organize themselves, I’ve been trying to figure out what, exactly, differentiates a startup culture from a big company culture.

My current theory is that the difference is in incentive alignment. At a startup, it is difficult to be individually successful while doing the wrong thing for the company, because if the company fails, everybody is out of a job. At a big company, though, fiefdoms can develop, where within a fief, people can get promoted for improving the position of that group despite being obstructionist to the rest of the company. This is often what people disdainfully refer to as corporate politics.

This reminds me of Mancur Olson’s book Power and Prosperity, where he describes how it makes economic sense for special interest groups to subvert democracy in harmful ways – if they represent 1% of the population and push for an action that will benefit them while hurting the overall democracy, they reap 100% of the benefit but only feel 1% of the pain. A similar dynamic is at work for groups within big companies, where they push for their own agenda even when it might hurt the overall company’s position.

This difference in incentives drives many of the differences in behaviors between startups and big companies. At a startup, nobody says “That’s not my job” when asked to do something that’s critical to the company’s success, because they won’t have a job if the company isn’t successful. At a startup, people have an understanding of what drives the company’s success and re-prioritize on the fly if necessary if market conditions are changing. Everybody is invested both economically and personally in the startup’s success, and that drives a unity of purpose that overrides individual agendas.

At a big company, people want to avoid risks and perpetuate the status quo, because creeping up the corporate ladder is the safer path. It’s easier to say no than yes, leading to the big-company phenomenon where every new project has to be signed off on by 10 different departments (legal, finance, security, PR, marketing, sales, engineering, etc), creating 10 opportunities for “No” without having a single person that can say “Yes” and have it stick. It’s possible to get promoted and get paid more without doing anything to benefit the company, if you are advancing your group’s agenda and hitting your individual targets even if the targets are no longer meaningful.

So what does it mean to have a big company with a startup culture? Part of it is figuring out how to get everybody at the company aligned on what the priorities of the company are (this is incredibly difficult at a sprawling company like Google), and rewarding them appropriately. Part of it is to encourage appropriate risk-taking – rewarding those who said “Yes” when it was the right thing to do even if the project failed. Part of it is creating a more risky environment in general – the people who are attracted to safe big companies with a well-defined ladder are not the people that will function well in a startup culture where things are changing fast. And I’m sure there is lots more that I haven’t figured out yet.

I’m fascinated to be part of Larry Page’s Google experiment on creating a big company with a startup culture. I’m not sure it’s possible without addressing the questions of incentive alignment and risk I raise here, but I want for it to be possible. The scale of projects that can be done at a big company are mind-boggling, but I also miss the free-wheeling all-for-one-and-one-for-all culture at the startups I’ve been at in the past. I will be watching closely and looking for opportunities to help with this culture shift as somebody who has startup experience and is interested in these sorts of culture questions.

8 thoughts on “Startup vs. big company culture

  1. my 2 cents

    size of an organization matter
    beyond a certain size, it becomes difficult to know everyone
    In start-up culture, you pretty much know everyone or you eventually get to know them.
    on en.wikipedia.org, a battalion is 300 to 800 people, a company is 80-250 people, a platoon 15 to 30, a squad 7 or 8 to 12 people. I think an organization larger than 300 people is no longer a start-up culture.
    (the exception to this would be a religion like the Catholic church, or some sort of a cult or a social movement)

    start-up culture
    plans to learn versus plan to execute

    start-up culture
    p.202
    … And the processes by which a company would experimentally and intuitively feel its way into emerging markets would constitute suicide if employed in a well-defined existing business. If a company needs to do both types of tasks simultaneously, then it needs two very different processes. And it is very difficult for a single organizational unit to employ fundamentally different, opposing processes. As shown below, this is why managers need to create different teams, within which different processes to address new problems can be defined and refined.
    (Innovator’s dilemma, by Clayton M. Christensen, copyright © 1997, 2000, 658.4 Christen, p.202)

    mature organization (established culture)
    p.183
    In his book Mobilizing Invisible Assets, Hiroyuki Itami 14 notes that there are three different kinds of customers, each contributing differently to a firm: (1) customers who generate profit, (2) customers who will generate sales growth, and (3) customers who allow the accumulation of invisible assets. Itami suggests that every company would wish to have a balanced mix of customers, so that the revenue-generating ones may tide the company over financially while other less profitable markets generate important knowledge for the future.
    (Wellsprings of Knowledge : building and sustaining the sources of innovation / Dorothy Leonard-Barton, 1. information technology——management, 2. information resources management, 3. management information systems, )

    mature organization (established culture)
    p.81
    managing “religious wars” about tools and methodologies

    Because preferences for certain tools and methods are interdependent with preferred cognitive styles and specialized skills built up over time, individuals can defend their particular methodologies with near-religious fevor. As illustrated below, flexibility in approach can sometimes be encouraged by introducing “alien” methods from totally different specialties. Other times, managers have to make hard, Solomon-like choices, and in such cases, the best tactic is often to shift the ground of the argument, to change the criteria on which the methodological is being made.
    Regarding Alien Methods as Herbs in the Dish. At Interval Research, manager David Liddle thinks of the infusion of alien methodologies into team projects as the herbs that make the dish.

    [O]ur ethnographers, our cognitive psychologists, our people that focus on
    product design and interaction design, the people who focus on or understand
    character and narrative, our research videographer, the people who do our
    mechanical and machine design and high-quality physical design, the people
    who do generic algorithms and complexity and so on——those are seven or
    eight different people who are overstressed around here because of the number
    of different people who want to at least consult with them and often to tug
    them into another project altogether. Most of those people are the herb, not
    the entrée, in the particular project that’s being baked, [but] the minor ingredients . . . are really very, very important. There is no chance of doing good,
    new work in these areas in a sterile environment where there are no herbs
    allowed.

    (Wellsprings of Knowledge : building and sustaining the sources of innovation / Dorothy Leonard-Barton, 1. information technology——management, 2. information resources management, 3. management information systems, )

    engineering culture and manufacturing culture
    p.255
    engineering’s bias in comparison to manufacturing’s bias
    In a book about product design and manufacture written by and for westerners, we find the following observation: “Engineering’s bias is to experiment with new technology because it is exciting and there are always fresh discoveries to be made . . . . Manufacturing operations thrive in a stable environment. For them bringing a new product into production means starting at the top of the learning curve. Manufacturing people are not rewarded for the headaches they incur by being involved in working the bugs out of a new product.” 48

    48. Smith and Reinertsen 1991, 85—86.
    Smith, Preston G., (and) Donald G. Reinertsen. 1991. Developing Products in Half the time. New York: Van Nostrand Reinhold.

    (Wellsprings of Knowledge : building and sustaining the sources of innovation / Dorothy Leonard-Barton, 1. information technology——management, 2. information resources management, 3. management information systems, )

  2. sorry for this, I hate long post … and I am breaking my own rule by doing this …

    another 2 cents

    start-up culture
    size is related to and is a factor in communication and organization.
    p.74
    A Management Audit of the Babel Project

    According to the Genesis account, the tower of Babel was man’s second major engineering undertaking, after Noah’s ark. Babel was the first engineering fiasco.
    The story is deep and instructive on several levels. Let us, however, examine it purely as an engineering project, and see what management lessons can be learned. How well was their project equipped with the prerequisites for success? Did they have:

    1. A clear mission? Yes, although naively impossible. The project failed long before it ran into this fundamental limitation.
    2. Manpower? Plenty of it.
    3. Materials? Clay and asphalt are abundant in Mesopotamia.
    4. Enough time? Yes, there is no hint of any time contraint.
    5. Adequate technology? Yes, the pyramidal or conical structure is inherently stable and spreads the compressive load well. Clearly masonry was well understood. The project failed before it hit technological limitations.

    Well, if they had all of these things, why did the project fail? Where did they lack? In two respects–COMMUNICATION, and its consequent, ORGANIZATION. They were unable to talk with each other; hence they could not coordinate. When coordination failed, work ground to a halt. Reading between the lines we gather that lack of communication led to disputes, bad feelings, and group jealousies. Shortly the clans began to move apart, preferring isolation to wrangling.

    (The mythical man-month : essays on software engineering, Frederick P. Brooks, Jr. — Anniversary ed., © 1985, Software engineering, p.74 )
    I think in a start-up culture because of size, it less hard to overcome the organizational and communication factors.

    the failure rate of start-up companies with so-called “start-up culture” is extremely high. I don’t know number. Most fail because they run out of money before they can discover their niche market. Less than 10% success rate I would guess (less than 2% over a period of 7 years?). Most don’t make it pass the first year, less pass the 2nd year, even less pass the 3rd year mark.

    According to Conway’s Law : “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”

    In a start-up, what does a communication structures of these organizations look like. Again, size comes into the picture. The communication structures usually grow organically. However, communication structures can be facilitated by have the key people in place who enable, encourage, and facilitate the situation for lateral communication. One formal way to do this is to establish information routing group.

    http://wikibin.org/articles/information-routing-group.html

    Information Routing Group

    An ‘Information Routing Group’ (or ‘IRG’) is a component of social networks consisting of a semi-infinite set of similar interlocking and overlapping groups. Each IRG contains a group of 3 to 200 individuals (IRGists), and each IRG loosely shares a particular common interest; IRGists exchange information, as a group, a sub group, or individually within that IRG, via lateral communication. Any IRGist might be in 2 or 3 IRGs peculiar to them but with different IRGists. The idea was proposed in 1984 in the book “The IRG Solution – hierarchical incompetence and how to overcome it” before the advent of the Internet although personal computers plus modems were conceived as mediating contact. Nowadays they are referred to as a social networking services and are intended to foster information and innovation exchange and to enhance group intelligence and Collective intelligence.

    p.34
    When Tom West, Data General’s project leader and a former long-time Digital employee removed the cover of the DEC minicomputer and examined its structure, he saw “Digial’s organization chart in the design of the product.” 2
    Because an organization’s structure and how its group work together may have been established to facilitate the design of its dominant product, the direction of causality may ultimately reverse itself: The organization’s structure and the way its group learn to work together can then affect the way it can and cannot design new product.
    p.63 n2
    2. Tracy Kidder, The Soul of a New Machine (New York: Avon Books, Inc., 1981).
    (Innovator’s dilemma, by Clayton M. Christensen, copyright © 1997, 2000, 658.4 Christen, p.34)

    p.111
    Who: organization chart. This becomes intertwined with the interface specification, as Conway’s Law predicts: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”1 Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost surely not the right one. If the system design is to be free to change, the organization must be prepared to change.

    1. Conway, M. E., “How do committee invent?” Datamation, 14, 4 (April, 1968), pp. 28—31.
    (The mythical man-month : essays on software engineering, Frederick P. Brooks, Jr. —— Anniversary ed., © 1985, Software engineering, p.111)

    • The IRG Solution
    • The IRG Solution is a book written by David Andrews and published in 1984
    • The Irg Solution : Hierarchical Incompetence and How to Overcome It
    http://www.amazon.com/I-R-Solution-Hierarchical-Incompetence/dp/0285626620
    http://wikibin.org/articles/the-irg-solution.html
    • unable to address tacit knowledge transfer
    • David Andrews, my hat is off to you. Not only did you see Facebook coming back in the days of ARPANET, you let me see how modern civilization has invaded my home and my head. An amazing display of polymath erudition. The only problem is that your IRG Solution shares the problems of all central media. It disallows tacit knowledge transfer and leaves people impersonally sitting at their home computers. That’s why, with IRGs a reality and then some, none of the problems of modern hierarchical civilization are solved. Aside from that, your book is one of the best I have ever read.

    Lastly, I would add, you have to look at the technological infrastructure of the landscape. The world wide web (hypertext) could not have happen until something like the Internet has been established (). The Internet (Inter-network) would not be possible without something like the TCP/IP protocol and the underlying network protocol stack. The software is depended on the hardware. How long was it before there was enough content on the World Wide Web to have the need for a directory (card catalog) and an indexing search engine. 7 to 10 years?

    according to https://en.wikipedia.org/wiki/History_of_the_World_Wide_Web
    1980–1991: Invention and Implementation of the Web
    1992–1995: Growth of the Web
    1996–1998: Commercialization of the Web
    1999–2001: “Dot-com” boom and bust
    2002–present: The Web becomes ubiquitous

    So using this data, it took about 17 for the web to be commercialize, and three more years after that for the Web to spread to general public into ubiquitous adoption. Someone born in 1980 would see the Web as part of everyday life, like paper, radio, and television, and the Web would not seem to them as a technology or a technical development.

    “Removing the faults in a stage-coach may produce a perfect stage-coach, but it is unlikely to produce the first motor car.”;–Edward de Bono.
    ( source: JoIM(Winter1996-1997).pdf )

  3. size is related to and is a factor in communication and organization.
    p.74
    A Management Audit of the Babel Project

    According to the Genesis account, the tower of Babel was man’s second major engineering undertaking, after Noah’s ark. Babel was the first engineering fiasco.
    The story is deep and instructive on several levels. Let us, however, examine it purely as an engineering project, and see what management lessons can be learned. How well was their project equipped with the prerequisites for success? Did they have:

    1. A clear mission? Yes, although naively impossible. The project failed long before it ran into this fundamental limitation.
    2. Manpower? Plenty of it.
    3. Materials? Clay and asphalt are abundant in Mesopotamia.
    4. Enough time? Yes, there is no hint of any time contraint.
    5. Adequate technology? Yes, the pyramidal or conical structure is inherently stable and spreads the compressive load well. Clearly masonry was well understood. The project failed before it hit technological limitations.

    Well, if they had all of these things, why did the project fail? Where did they lack? In two respects–COMMUNICATION, and its consequent, ORGANIZATION. They were unable to talk with each other; hence they could not coordinate. When coordination failed, work ground to a halt. Reading between the lines we gather that lack of communication led to disputes, bad feelings, and group jealousies. Shortly the clans began to move apart, preferring isolation to wrangling.

    (The mythical man-month : essays on software engineering, Frederick P. Brooks, Jr. — Anniversary ed., © 1985, Software engineering, p.74 )

    I think in a start-up culture because of size, it less hard to overcome the organizational and communication factors.

    According to Conway’s Law : “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”

    In a start-up, what does a communication structures of these organizations look like. Again, size comes into the picture. The communication structures usually grow organically. However, communication structures can be facilitated by have the key people in place who enable, encourage, and facilitate the situation for lateral communication. One formal way to do this is to establish information routing group.

    http://wikibin.org/articles/information-routing-group.html

    Information Routing Group

    An ‘Information Routing Group’ (or ‘IRG’) is a component of social networks consisting of a semi-infinite set of similar interlocking and overlapping groups. Each IRG contains a group of 3 to 200 individuals (IRGists), and each IRG loosely shares a particular common interest; IRGists exchange information, as a group, a sub group, or individually within that IRG, via lateral communication. Any IRGist might be in 2 or 3 IRGs peculiar to them but with different IRGists. The idea was proposed in 1984 in the book “The IRG Solution – hierarchical incompetence and how to overcome it” before the advent of the Internet although personal computers plus modems were conceived as mediating contact. Nowadays they are referred to as a social networking services and are intended to foster information and innovation exchange and to enhance group intelligence and Collective intelligence.

    p.34
    When Tom West, Data General’s project leader and a former long-time Digital employee removed the cover of the DEC minicomputer and examined its structure, he saw “Digial’s organization chart in the design of the product.” 2
    Because an organization’s structure and how its group work together may have been established to facilitate the design of its dominant product, the direction of causality may ultimately reverse itself: The organization’s structure and the way its group learn to work together can then affect the way it can and cannot design new product.
    p.63 n2
    2. Tracy Kidder, The Soul of a New Machine (New York: Avon Books, Inc., 1981).
    (Innovator’s dilemma, by Clayton M. Christensen, copyright © 1997, 2000, 658.4 Christen, p.34)

    p.111
    Who: organization chart. This becomes intertwined with the interface specification, as Conway’s Law predicts: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”1 Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost surely not the right one. If the system design is to be free to change, the organization must be prepared to change.

    1. Conway, M. E., “How do committee invent?” Datamation, 14, 4 (April, 1968), pp. 28—31.
    (The mythical man-month : essays on software engineering, Frederick P. Brooks, Jr. —— Anniversary ed., © 1985, Software engineering, p.111)

    • The IRG Solution
    • The IRG Solution is a book written by David Andrews and published in 1984
    • The Irg Solution : Hierarchical Incompetence and How to Overcome It
    • unable to address tacit knowledge transfer

  4. Lastly, I would add, you have to look at the technological infrastructure of the landscape. The world wide web (hypertext) could not have happen until something like the Internet has been established (). The Internet (Inter-network) would not be possible without something like the TCP/IP protocol and the underlying network protocol stack. The software is depended on the hardware. How long was it before there was enough content on the World Wide Web to have the need for a directory (card catalog) and an indexing search engine. 7 to 10 years?

    according to https://en.wikipedia.org/wiki/History_of_the_World_Wide_Web
    1980–1991: Invention and Implementation of the Web
    1992–1995: Growth of the Web
    1996–1998: Commercialization of the Web
    1999–2001: “Dot-com” boom and bust
    2002–present: The Web becomes ubiquitous

    So using this data, it took about 17 for the web to be commercialize, and three more years after that for the Web to spread to general public into ubiquitous adoption. Someone born in 1980 would see the Web as part of everyday life, like paper, radio, and television, and the Web would not seem to them as a technology or a technical development.

  5. ‘Information Routing Group’ (or ‘IRG’)
    • The Irg Solution : Hierarchical Incompetence and How to Overcome It
    Some what related to IRG Solution are the following:
    (1) Ed Catmull talks about communication network in a creative organization.
    (2) fast-cycle organization using communication network to overlap communication hierarchy, and establishing the right channels of information in a closed-loop architecture to enable faster-decision making process.
    (3) assemble a breakthrough teams : These teams are one-time solution-finding teams, not permanent working teams.
    Of course, neither of the three methods can be a complete replacement for creating Information Routing Group (or creating lateral communication channel). They are presented as different approaches to address the need for communication network to overlap communication hierarchy.

    see Ed Catmull talks ‘Neuroscience 2013 Dialogues between neuroscience and society-The Creative Culture’ on youtube.com, in a nutshell for creative culture: adopt, champion, foster, support communication network (no barrier to communication), avoid communication hierarchy (control of access, control of information, negative feedback(punishment) for breaking the communication rule.

    pp.182-183
    OODA (observation, orientation, decision, and action) loop
    Companies that work like OODA Loops describe themselves differently. One senior manager who left a more traditionally managed organization to join a time-based management company says he could tell the difference as soon as he asked his new colleagues to describe the company over lunch. His former company used conventional organization charts with hierarchies of boxes and levels to describe itself to new employees or outsiders. The company listed its departments and buildings——its structures. In contrast, his new colleagues talked mainly about how the company works and who works with whom. They sketched out on a piece of paper a picture of the company that was basically a set of loops. The loops were small boxes representing functions connected by arrows. Some loops overlapped. Process and interaction were the main points he remembers from the discussion. And, as it turned out, the new company is faster than the old one.
    It is one thing to develop a fast-cycle organization when your people know exactly what the product will be because customers keep asking the same thing from you. Henry Ford got a huge organization at River Rouge to take in iron ore and coal at one end and other end in less than four days but limited his customers to one product. The real difficulty in designing fast-cycle organizations comes when complexity grows——different customers start to want different things, and the product line needs changing continuously. Now, fixed information channels and established lock-step routines don’t work so well. Some functions in the company, especially those located farthest from the customer——such as a design engineer or a data system specialist——do not see what is happening. They stop creating useful information, and they no longer understand the signals they are getting from others.
    A company that works well is something like a communications network, with each station performing a particular role and each sending and receiving messages continuously. A room of inter-connected foreign currency traders is an example. They will usually outperform a group of independent, isolated traders even on a quiet day. But on a fast-moving days full of complex events, they will ALWAYS perform better because they learn quickly from each other. As the world changes, the networked traders see more patterns and are then able to get into and out of position faster. Variety and complexity compounds the amount of information flying around and the combination of actions that can be taken. A closely connected room of traders will sort through it and make more of the right moves than the isolated trader can.
    Many companies, however, instead of allowing the network to speed information flow, take the opposite approach in trying to cope with variety and complexity. They rely less on network learning and more on additional structure, and they end up short-circuiting the network. If, for example, new technologies are emerging, they specialize their engineers by technology. If a product is getting more complex and more and more employees have to work on it as it moves through the company, they will increase the number of formal control points. And, when greater variations in the mix of orders show up as they try to increase product variety to the market, these companies will typically build more inventory and put slack capacity into the system to handle the overload.
    All of this is costly and will slow the company down. The marketplace demands for variety are real and growing. But additional structure and buffers are not the answer to meeting them. The buffers break up and slow down the OODA Loop. In contrast, time-based organizations cope with variety directly, by building up their flexibility and greater capacity for creating and sharing information. One way they accomplish this is through closed-loop teams.
    p.191
    Another measure that often produces unexpected results is time lost waiting for decisions——any kind of decision, from those made by major executives to those involved in simple inventory replenishment. Most decisions could be made sooner and better, closer to the time all the information needed to make them is known. But the right channels of information haven’t been created. Furthermore, the gap between when a customer discovers the need for replenishment and when you learn, this is not only direct time wasted but will probably amplify forecasting errors else-where in the system. A critical pipeline is missing between customer and supplier. The same thing is true for regular go/no-go decisions on new product features. The right information is slow to get to the right place. This is why closed-loop architecture is important to time-based companies
    (Stalk, George, HD69.T54S73 1990, 658.5’6——dc20, copyright © 2009)
    ( Competing against time : how time-based competition is reshaping gloabl markets / George Stalk, Jr. (and) Thomas M. Hout., 1. time management., 2. delivery of goods., 3. competition, international., 4. comparative advantage (international trade)., pp.182-183, p.191)

    p.219, pp.221-222
    breakthrough teams
    p.219
    These teams are one-time solution-finding teams, not permanent working teams. Their members are the most capable middle managers from the parts of the organization involved in the cycle, so they know the problems and the difference between paper and real solutions. Part of the breakthrough team experience is to get them talking without day-to-day problems grinding at them, to get them to see the whole system. Their charter is to drop assumptions about how the company works and to come up with a better way. The aim is not a highly polished, no-loose-ends presentation, but rather the core working of a way to do things that is dramatically better and faster.
    … […] …
    ([ this ‘root-cause analysis’ or ‘root-cause diagrams’ or ‘root-cause analysis path mapping’ is not Kepner-Tregoe Analytical Methods root-cause analysis. See book, The Rational Manager : A Systematic Approach to Problem Solving and Decision Making, Charles H. KEPNER, Benjamin B. TREGOE, © 1965 for Kepner-Tregoe Analytical Methods root-cause analysis or en.wikipedia.org for a short brief. ])
    … The teams use a variety of techniques——root-cause analysis (pp.226-228), system mapping (pp.200-205), scenario building, pursuing conflict between two people until the real problem crystalizes, and old-fashioned imagination. ([ see JoIM(Winter1996-1997).pdf, An Introduction to the Seven Creativity Tool Boxes, Author: Janice Marconi, pp.25-32. ]) Between regular meetings, research into technical or other problems is done. There are no formal reports to the team members’ superiors. The teams report to a senior steering group that is responsible for all the breakthrough teams operating. This steering group is responsible for managing change under the time-based vision that the management team has decided to pursue.
    pp.221-222
    … The steering group that charters and integrates the breakthroughs becomes the principal orchestrator of the change. The number of teams is important. Setting up too many teams will fragment the problem and fail to confront the real issues of organizational complexity and distance. Too few teams will overwhelm each team with an impossible charter. Breakthrough teams should be set up to succeed.
    Breakthrough teams, or something comparable, are especially useful for making organizationally complex changes, where analysis should precede action. Analysis is needed because the solution isn’t obvious and different parts of the company have to be involved. These teams are the backbone of a company’s move toward time compression and can be mobilized quickly. Teams can shape recommendations early and draw reaction. Once a solution takes shape, it can be refined during implementation. Breakthrough teams lose effectiveness if they stand too long.
    (Stalk, George, HD69.T54S73 1990, 658.5’6——dc20, copyright © 2009)
    ( Competing against time : how time-based competition is reshaping gloabl markets / George Stalk, Jr. (and) Thomas M. Hout., 1. time management., 2. delivery of goods., 3. competition, international., 4. comparative advantage (international trade)., p.219, pp.221-222)

  6. Smith, Preston G., (and) Donald G. Reinertsen. 1991. Developing Products in Half the time. New York: Van Nostrand Reinhold.

    http://www.strategy2market.com/Preston-Smith/Developing-Products-In-Half-The-Time/about-dpht.html

    Chapter 1: Faster and Still Faster
    Chapter 2: Putting a Price Tag on Time
    Chapter 3: The Fuzzy Front End
    Chapter 4: The Power and Pitfalls of Incremental Innovation
    Chapter 5: Capturing Customer Needs
    Chapter 6: Using System Design to Compress Schedules
    Chapter 7: Forming and Energizing the Team
    Chapter 8: Organizing for Communication
    Chapter 9: Designing Fast Development Processes
    Chapter 10: Controlling the Process
    Chapter 11: Preventing Overloads
    Chapter 12: Managing Risk Proactively*
    Chapter 13: Bridging the R&D – Manufacturing Gap
    Chapter 14: The Role of Top Management
    Chapter 15: Making Changes Faster

    http://www.amazon.com/Developing-Products-Half-Industrial-Engineering/dp/0442020643

    › Visit Amazon’s Preston G. Smith Page

    Biography
    I have been a management consultant and trainer specializing in rapid and flexible product development since 1984. Prior to that, I earned a PhD in engineering from Stanford University and held several engineering and management positions in a broad variety of companies.

    Here are short descriptions of my three books:

    Developing Products in Half the Time has become a classic in the time-to-market literature–90,000 English copies in circulation plus six translations. It was published originally in 1991, with a paperback update in 1995 and a second edition in 1998.

    Proactive Risk Management was written because I found that–even though Chapter 12 of Developing Products in Half the Time covers project risk management–companies were doing poorly at it. Specifically, companies with a phased-development process would typically identify and document project risks in an early phase. But then they would do nothing about these risks, and when the risks blossomed later in the project, it was embarrassing that to see that they had been predicted. This book won the David Cleland Project Literature Award from the Project Management Institute in 2003 as the best project management publication in 2002.

    Flexible Product Development recognizes that, as the world has become more chaotic, it is unrealistic to presume, as we usually do in our plans, that the project will proceed to completion without changes. In fact, it is the nature of innovation that the project should change as we learn more about the customer and the product. So, instead of denying change, this book embraces change by reducing the cost of change and keeping options open. It aims to do for non-software products what agile software development has done for that field.

    Smith, Preston G., (and) Donald G. Reinertsen. 1991. Developing Products in Half the time. New York: Van Nostrand Reinhold.

    Developing Products in Half the Time: New Rules, New Tools,
    by Preston G. Smith and Donald G. Reinertsen, John Wiley & Sons, 1997, 298 pages.

    Foreword

    (By Neil Hagglund, Corporate VP and Director of Corporate Technology Planning, Motorola, Inc.)

    Most of the readers of this book probably associate Motorola with quality. We have worked hard to achieve leadership in this area and are very proud of our accomplishments. However, customer expectations have increased and have never been higher. Our customers expect us to demonstrate flawless quality and provide leadership products with value-added features, at lower prices, in shorter and shorter cycle times. The companies that can respond to quickly changing needs will flourish and those that can’t, will be left behind. Time to market is a crucial element in being successful in the global marketplace.

    For readers who are about to embark on the journey to faster development, let me offer a few observations. First, in my more than 30 years of product development experience, working with some of the best product developers in the world, I have yet to find a single magic tool for transforming a development process. Other companies may jump from fad to fad hoping there is a fast, easy way to accelerate product development. At Motorola we achieve rapid development the same way we achieved breakthroughs in quality-with old-fashioned hard work and constant management attention.

    Second, many readers may wonder if pursuing development speed requires a company to compromise quality. At Motorola we have firmly rejected this option. There are abundant opportunities to improve the development process without taking the sloppy and dangerous approach of sacrificing quality. If you find yourself considering such options, you have not thought deeply enough about your choices. In fast-moving markets we often find that faster development actually provides higher quality to our customers, resulting in products delivered before customer needs begin to change.

    Third, I would encourage you to question many of the deeply entrenched methods that you use for product development. Some of our greatest successes at Motorola have been a result of our engineers questioning the fundamental design of the entire process. This willingness to question the status quo proved vital to transforming quality and appears equally vital in transforming development speed.

    Finally, I would encourage you to stay the course on this effort. The benefits of faster development can be substantial but they cannot be achieved instantly. Fundamental changes in your development process require careful analysis, broad involvement, and extensive effort. Not everything that is worth changing can be changed quickly. If you approach this as a short, quick journey you will not get very far.

    On your journey I think you will find that Developing Products in Half the Time is an excellent companion. I am excited to see this new edition because at Motorola we found the original edition to be far and away the most useful book of its kind. The state-of-the-art in product development has continued to progress in the last six years and this new edition is very welcome. This book remains a vital resource for those of us interested in rapid development. I have read it more than once and I think you will too.

Leave a Reply to Elliot Cancel reply

Your email address will not be published. Required fields are marked *