Flow and Software Development Performance

Before we get deeply into the compensation discussion, however, let's look at how this idea of flow relates to productivity/performance in the software development environment. One of the most intriguing and confounding phenomena for development managers is the wide variability in productivity among team members. How do we account for these variations?

In my experience with a large number of projects and an even larger number of team members, I've seen that the productivity of architects, designers, programmers, and testers who find their flow channel vastly outstrips that of their peers who have not.[6]

[6] In assessing productivity, I look at both quantity and quality of the software artifacts produced.

Lower-productivity individuals typically exhibit one of the two characteristics Csikszentmihalyi identified: anxiety from being in over their heads (task difficulty >> skill level) or boredom because of insufficient challenge (skill level >> task difficulty). The results? Poor codeeither because of inexperience and wheel reinvention in the first instance, or from procrastination and arrogance ("I can whip this thing together at the last minute if I have to") in the second.

Of course, another major factor in productivity is whether the company culture "pays" for performance rather than on the basis of how a job or a person looks on paper. There is some confusion about what this means. In my simple view, job skills represent the potential to perform. Through training and experience, we attain skill levels that should enable high performance but do not ensure it.

In a like manner, job difficulty represents the opportunity to perform. That is, a particularly challenging job provides an arena in which a combination of effort and skills can produce a great result. For a highly motivated and skilled individual, the lack of a sufficient outlet is frustrating, as there is no opportunity to shine. But just as with skills, simply having the challenge by no means guarantees high performance.

So ideally, we want to pay for performance, meaning results, or total contribution to the organization. And that means we need to understand all the factors that affect performance. These include more than simply the balances and imbalances in skill and job difficulty. For example, motivation is a powerful factor. Also, people perform much better when they are engaged in activities they just enjoy doing. Yet another factor is confidence in one's abilities; good performance can generate a positive feedback loop that leads to even greater confidence and higher performance.

When one is in the flow channel, motivation and enjoyment of the job are at their highest, and confidence soars. So the concept of flow is consistent with these other factors that affect productivity/performance.

However, we should be careful not to neglect motivational factors that are independent of flow. In particular, we should not underestimate the motivational effects that come from commitment to a mission and feeling part of a great team. And, of course, individuals go through cycles of increased or decreased motivation because of other things that are occurring in their lives.

Finally, perceived compensation can be either a motivator or a demotivator. People who feel they are being unfairly compensated, either absolutely or relative to others, can become demotivated to the point that their performance suffers. (The problem here, of course, is that these may be to some extent perceived inequities; employees may overestimate their contribution and/or peer compensation.) So there is yet another feedback loop that needs to be considered.

Although all these factors affect performance, and hence compensation, in the rest of this chapter I will stick to Csikszentmihalyi's flow model, with the understanding that this oversimplifies a very complex affair. I choose to do this because I believe we can directly affect three factorsskill levels, job difficulty, and compensationwhereas some of the other factors I have mentioned are much more difficult for us to influence.

The Software Development Edge(c) Essays on Managing Successful Projects
The Software Development Edge(c) Essays on Managing Successful Projects
Year: 2006
Pages: 269

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net