How injecting randomness into your project can help it succeed

Success and failure differ, very often, by very little. Take nature as an example. A small change in our DNA (a few mutated genes) can have catastrophic consequences. On the other hand, without these mutations humans would never have come into existence.

Humans and other species in the planet evolved because of chance (although not totally chaotic) changes in their DNA. As small change after small change happened, the surviving individuals were able to spread the viable, and ultimately the most adequate changes to the next generation - and the process repeats still in our own bodies today. If Nature has taught us something about improvement and evolution is that you must have a little bit of luck involved!

The DNA of a project

In software projects - my domain - I see some similarities to this natural model that are worth exploring. Projects also have a DNA which includes the structure and the communication connections between individuals. Communication being one of the most quoted causes for failure in software projects, and therefore one of its critical success factors.

The More I Practice the Luckier I Get

Once a project gets started, a particular structure is put in place (governance, management, teams, etc.). Very often that structure remains in place, and static until the end of the project. But is this a smart choice?

Another aspect of the project that rarely changes is the network of connections between the individuals. This network is what carries information from individual to individual and eventually "selects" the information that is acted upon by the project team. If a piece of information reaches an individual in the project, and that individual does not consider it relevant, that information will not spread further. In contrast, when a piece of information is perceived as important by an individual, that information will be actively spread by that individual.

The Illusion of Control

The structure that is set for a project strongly influences the communication links that can emerge between individuals. Who talks to whom? What meetings exist where people interact regularly? etc. But the reverse is also true. The existing communication network within an organization is a strong influence on what governance structure is put in place, how teams are formed, etc. These co-dependent processes create a positive (or negative) spiral of events for the project, but because neither (structure, or communication network) is often changed, that spiral is unstoppable. If it is positive, it will help the project succeed. If this co-dependent processes create, instead a negative spiral, that will relentlessly remove the chances of success for that project.

This co-dependent relation between two key processes (structure and communication network) is why we can increase the chances of success in our projects by simply causing random perturbations in the project. Randomness helps us explore different patterns for structure and communication networks.

As we carefully design and inject small - safe-to-fail - changes into the project, we can observe how it reacts and adjusts. Later, we can retrospectively amplify or remove/dampen the changes based on the outcome we see. If something works, keep it and ask how can you make it grow. If something creates a net negative outcome, dampen or remove it completely.

The cycle goes like this:

• Define and implement small, safe-to-fail changes in the structure or communication network for the project
• These changes lead to emergent behavior as the individuals and teams adapt to the changes
• A new project configuration emerges which drives new project results
• Finally, we evaluate the results of these changes and decide which components we will try to amplify or dampen

What Do You Mean Random?

There are many ways in which we can, randomly, explore better configurations for our projects. Below I list only a few to illustrate the concept:

• At the start of a project, let the teams chose their own composition. This establishes new connections between individuals in the project as some will choose to work with new team members. However, these new connections will not eliminate the previous connections between individuals. The net effect should be that your project now has a more connected communication network (more individuals with strong connections to each other). In practice this works just like when we form new neural connections in our brain: more connections leads to different thinking and acting patterns
• Organize common project events where people interact with each other outside the day-to-day routine. Planning events can be organized following a structured approach, but including also some unstructured time (à lá unconference, using e.g. Open Space) where people can interact based on their interests. This will also help form new connections between individuals in the project and spread information that would otherwise be locked down and not accessible
• Have regular project "coffee breaks" that happen at the same time and same place. In these events people can connect with other individuals and ask questions from the project management team or the most connected individuals in the project. This unstructured communication increases the chance that some piece of information will "jump the hierarchical borders" and reach people in decision-making positions, or people with influence that can later act on that information.

Conclusion

These practices are designed to inject randomness (unplanned situations or connections) into the project. The goal is not to create Chaos (a scary word for many project teams), but to generate new pathways for the information to flow within the project team, as well as novel project structures that are more adapted to the current challenges the teams face.

Using these (or other) practices will increase your project's chances for success. They don't eliminate the need for the project to be managed, or to have structure. They do increase the chance of success for the project by exploring new organizations and structures through a process of small (safe-to-fail) changes that can lead to unplanned, but ultimately superior performance.

These were just a few examples. How would you inject randomness into your project? Have you done that in the past? Please share your experiences in the comments for the benefit of others.

Photo credit: John Hammink, follow him on twitter

On rewarding and performance systems...

The ideas of "pay-for-performance", and it's twin sister "management by objectives" exist to try and increase the performance of a group and ultimately the whole company. The basic idea is: promise them a carrot and they'll work more / better. But is that true? Can a company really perform better by promising people they will get more money if they individually perform better?

It is an appealing though. Instead of working with the people, managers are advised to put the right rewards in place and let people loose. Things will magically work out, or so the theory goes.

Although there is some truth to that, the fact is that this simplistic view of reality hides, or ignores, the deeper impacts of the individual performance reward culture:

• First, by placing rewards at the centre of the performance system, the companies shift the conversation to rewards and away from work
  
• Most people feel they perform above average, but reward systems tend to grade people on "the curve". This leads the lower performers to get a higher grade than they deserve (but still lower than they think it should be) and the top performers a lower grade than they deserve because of the need to "follow the curve". This has the notorious effect of leaving everybody unhappy.
  
• Most importantly, the reward mechanisms that focus on individual performance completely miss the fact that a company exists in a complex environment. Especially non-trivial work (like software), is impossible to reduce to a set of repetitive steps. The immediate consequence of this is that, even if all the people perform at their best and get the top evaluation, the company could still totally fail to meet the level of their competitors. The performance of the system (the company) depends on the complex interactions between the different people in the company. If all try to optimize their personal performance, the system as a whole can perform a lot worse.http://www.blogger.com/img/blank.gif
  

What amazes me is that there are still people who advocate "pay-for-performance" in complex environments like software development.
The fact that we work in a complex environment all but ensures that "pay-for-performance" is at best indifferent to the overall company's performance and at worse an active value detractor for the company.

An additional bonus

Deming and Shewhart proved that in a stable system, trying to change it's performance from the outside can actually reduce the performance of the whole system. Deming called this "tampering": messing about with a system you don't understand (link to Deming and tampering).
"Pay-for-performance" and "management by objectives" are an instance of "tampering". Instead of messing about with a system we don't understand we, as managers, should focus our energy on understanding that system and changing the system through the use of small and controlled experiments.

This is not as easy as it sounds, but is the only way in which managers add value to their companies.

If you still want to have variable salary costs in your company, then use a profit sharing scheme: where everybody shares in on the success and pain, rather than individuals independently. Besides, can you really evaluate a single individual's contribution to the success of the whole company? (Especially when the company is not succeeding and that individual still claims their bonus?)

One question that is raised against the view I tried to explain is: "Fine, but how do I keep top performers? They certainly want to be rewarded by their good work, right?" My answer to this question is that people value many different things. While some people are influenced by short term gains, most people do not act consistently with that hypothesis. There's evidence that people react more consistently with (see this video):

• "meaning", i.e., they are more motivated and committed when they feel that their work has meaning; or
  
• "peer-recognition", i.e., people tend to feel more committed and motivated in an environment where their work is appreciated by their peers.
  

A better way to keep your best people is to work on creating an environment where people's work is recognized by their peers, and the meaning or nexus of that work is clear to everyone.

You, as a manager, have to focus on those things!

Photo credit: L2F1 @ flickr

Punished by the Annual Performance Review

Many of us in the Agile community have voice our opposition to the individual performance reviews and target setting.
Now, a professor from the University of California, Los Angeles (UCLA) has come out with a similar position and not less than in the serious Wall Street Journal (copy of the article), yes, the same that your CEO religiously reads every morning in the 5 star hotels where he "lives" -- there's hope he read this article.

Professor Culbert goes on to say that annual performance reviews are not only counter-productive, they are immoral. He says it best:

I believe it's immoral to maintain the facade that annual pay and performance reviews lead to corporate improvement, when it's clear they lead to more bogus activities than valid ones. Instead of energizing individuals, they are dispiriting and create cynicism. Instead of stimulating corporate effectiveness, they lead to just-in-case and cover-your-behind activities that reduce the amount of time that could be put to productive use. Instead of promoting directness, honesty and candor, they stimulate inauthentic conversations in which people cast self-interested pursuits as essential company activities.

He goes on to say that the manager's job and responsibility is to enable and promote the employee's performance, not to "punish" it:

The boss's assignment is to guide, coach, tutor, provide oversight and generally do whatever is required to assist a subordinate to perform successfully. That's why I claim that the boss-direct report team should be held jointly accountable for the quality of work the subordinate performs. I'm sick and tired of hearing about subordinates who fail and get fired, while bosses, whose job it was to ensure subordinate effectiveness, get promoted and receive raises in pay.

Here are some of the dysfunctions that the annual performance review cause:

• They harm teamwork
• The "objective" nature is completely fake objectivity
• They create adversarial relationships between employee and manager
• Pay for "performance" is really market-driven pay (or raises) in disguise
• They impede personal development

How about you? What have been your experiences with the annual performance review? Write it up on the comments.