Development is inherently different from production. But managers of development and allied efforts often allow their thinking to be shaped by a management philosophy derived entirely from a production environment.

In production, you will want to:

• Reduce error
• Optimize for up-time
• Standardize procedure
• Eliminate experimentation

However, when you are trying to develop something, these tactics will take the wind out of your sails.

• Quota for errors
  • Not all designs are equally defective — some designs are better than others. It may not be worth it to continue working on improving a design; starting over with a new design that is less inherently defective would be better.
  • Not allowing for error makes people defensive and they won’t try multiple designs because some designs may turn out badly.
  • Many managers are susceptible to the sunk cost fallacy; they would rather salvage a defective version of a software even if it will cost more in the long run. This is not the right thing to do
  • Make it worse by imposing rigid methodologies so that employees are not allowed to make key strategic decisions.
  • Make it better by asking your coworkers on occasion what dead-ends they’ve been down and making sure that “none” is not an adequate answer.
  • This reminds me of the value of prototyping and the Weak/Strong Link Problem
• Management: The Bozo Definition
  • A mistake management makes is that managers do all the thinking and the employees do all the work.
  • In a development environment, everyone’s brain should be used.
  • You cannot force someone to be creative, inventive, and thoughtful. Even if you could, it would be disheartening to the worker since it tells them that their own motivation is inadequate.
  • You don’t need to keep people working; most people love their work. You might need to take steps to make them work less so they can do more meaningful work.
  • This reminds me of the four-day workweek, which has been shown in various repeated studies that it provides the same level of productivity as a five-day workweek at the same pay.
• The People Store
  • Many managers go to great lengths to make sure no one is irreplaceable.
  • Because managers fear that a key person will leave, they force themselves to believe that there is no such thing.
  • People are not replaceable; there is no store where you can buy the same person.
  • “The uniqueness of every worker is a continued annoyance to the manager who has blindly adopted a management style from the production world. The natural people manager, on the other hand, realizes that uniqueness is what makes project chemistry vital and effective. It’s something to be cultivated.”
• A Project in Steady State Is Dead
  • A project’s entire purpose in life is to put itself out of business.
  • Managers incorrectly assess people’s value to a new project based on steady-state statistics like how much code they can write or how much documentation they can produce.
  • The focus of project management should be the dynamics of the development effort — how do people fit into the effort as a whole?
  • Even a person who is just a catalyst for the team can be important — “Someone who can help a project to jell is worth two people who just do work.”
• We Haven’t Got Time to Think About This Job, Only to Do It
  • The time spent on finishing a task cannot be 100% dedicated to actually doing it — you need to research and explore possible solutions
  • Managers spend too much time trying to get things done and not asking whether or not the work should be done at all
  • The excuse for dedicating 100% of the time to doing the task is always “time pressure”, but work always has time pressure. What work doesn’t have time pressure?
  • The higher the stakes, the more important it is to do things that aren’t just the task — you need frequent brainstorms and social events to help individuals build rapport with each other and become an effective unit

Anecdote from the section “A Project in Steady State Is Dead”:

I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: “I don’t quite see what she adds to a project; she’s not a great developer or tester or much of anything.” With a little investigation, I turned up this intriguing fact: During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn’t recognize the role of catalyst as essential to a project.

Source: Peopleware: Productive Projects and Teams, 2nd Edition, Chapter 2