Tasks

A programmer / software engineer has tasks that require different resources. If we consider a few stereotypical tasks on the dimensions of thought and interaction:

• Coding can require intense concentration for new and novel tasks, but well understood tasks can be almost semi-automatic. Coding tends not to be an intensely collaborative activity; even pair programming has stretches where one of the pair is writing almost independently before the other half of the pair comments.
• Debugging definitely requires concentration and is typically an independent activity. There may be times discussion helps the process, but the ground work to get to that point typically far exceeds the time required in the discussion.
• Systems administration in spite of clever DevOps tools (Puppet, Kubernetes etc) these tasks typically involve a level of routine and repetition this means that after the original learning curve they tend to be a bit less cognitively demanding. As these tasks are often done for or with other people they tend to be collaborative.

In addition to the positive demands of a task, there are environmental factors that can be detrimental:

• interruption is an anathema to concentration particularly to flow state
• unavailability of information / resources can prevent a task from being completed

Working conditions

During the working day:

• the availability of colleagues ranges from absent (some people start early, some late) to too present (the discussion over your shoulder in the open plan office about a completely unrelated project)
• mental capability varies for different types of thinking through the day
• problem solving / creativity
• concentration
• sociability

Efficiency

Only when the demands of a task and working conditions are matched can the task be performed most effectivly. In fact, attempting a mentally demanding task without the required mindset and environment can actually result in rework being required later.

Managing in this environment

One of the problems in managing in this environment is that invisible factors - mental capability - are so significant in determining efficiency. Directing activity under these circumstances can be highly disruptive to both overall and task productivity.

For example: A worker may have decided that they are mentally not able to achieve the levels of concentration required for a high priority task, rather than engaging in the priority task they choose to do a lower importance task that can be completed unblocking others in the business.

This example leads to 2 questions:

• Is it wise to intervene and force a change of task under this circumstance?
• Bearing in mind that the invisible factors are so important in this situation, can you intervene at all?

A statement of priority might be called for, but direction would clearly be less effective in this example.

Intervening in this example is managing for activity rather than productivity.

Conclusion

This article was going to be focused on managing creative activities and the difference between managing for visible activity rather than productivity, but one of the stereotypical examples that is trotted out for this lesson shows it affects all workers:

The secretary who saves their filing for Friday afternoons

They are being:

• efficient as they fit their capacity rather than using a time where they are more capable for a lesser task
• diligent as they are working rather than avoiding it
• productive as they are doing a task that needs doing eventually

Tags: Activity, Productivity