No Mythical Man or Unicorn

If you don’t want to get work done, add more people.

How many meetings have you been involved where decisions are made by committee and the outcome leads to a Franken-disaster that pleases no one?

Case and point: Getting 8 women to help a pregnant woman does not make her have a baby in a month.

You don’t fix problems by adding more people to them. You fix problems by having the right people involved at the outset. Just a few like-minded souls are all you need to conduct the orchestra of large, complex projects.

In software design and project management we suffer from what Frederick Brooks coined as Mythical Man Month. Mythical Man Month is not a hairy humanoid creature that lives in the Himalayas, camouflaging in the snow of the mountains. It is our managerial hard hat tricking us into thinking we can cut time (one man month of work) in half by adding more people to projects that are running past deadline.

Traditional business thinking would lead us to assert that we can cover up a problem with the Band-Aid of headcount. Adam Smith, godfather of modern capitalism, theorized that for divisible projects like auto manufacturing, the more you strip a process into its components and widgets, the more you reduce the average cost per unit in terms of time and money. However in software projects which have a high degree of complexity, indivisibility and communication, that is not the case. No mythical man or unicorn can save the project.

If you have X number of people working on a project, you have X squared communication channels, and the proportion of time you spend playing phone tag with your team instead of getting productive work done rises. You are depending on more things and are left idle, spending more time waiting for things to get finished. More so, if a new person tries to join a large project the probability of failure is non-zero because they have to get an abundance of information from many sources, and ramp up increases. For example, if there are too many radios and TVs on in the house you will not hear that “Dinner is ready.” Even although there is one kitchen, and one appetite, the signal to eat will get lost.

So therein lay the paradoxical chicken/egg syndrome. As a manager you want small sharp teams, but you can’t build a very large system this way. Scaling becomes very clumsy. Therefore I suggest the following: First one must build a team of complementary skills and diverse roles. Second, it is important to wisely add more people in the right place to speed things up. Unless the task ahead is no more complicated than building a brick wall, having the right people to ask the right questions will pre-empt over stack and a communication pile up down the road. Too many times teams get bogged down by getting people to row together rather than row in the right direction. Finally, one has to change their thinking from fixed schedules and capital resources into a more agile methodology, whereby you work to fail fast and learn. Even although you do not have all of the inputs at the outset of a task, you try to get through the first cycle of completion and then meet with the development group to make adjustments to requirements. You prototype and build up in increments based on a concrete outputs not abstract ideas.

Software design is like a tar pit: The more you fight it, the deeper you sink! However, if you just relax, your team will float in it, because the way you have chosen to think is less dense than the tar pit.