Requirements for effective steering

To establish an effective Steering culture, you need:

  • a mental model of how the software development system works
  • process visibility
  • process stability

Mental models

You need an implicit or explicit mental model of how your actions affect the system and its outputs. Routine managers tend to use simple, linear models, relying on prediction by extrapolation. This leaves little room for variation and unforeseen changes. Managing in a Steering environment means you apply more sophisticated mental models, taking into account nonlinearity and cause-effect relations separated in space and time (systems thinking).

A typical Routine manager for instance assumes the amount of work done is directly proportional to the number of hours put in. So when the project is getting behind, he mandates lots of overtime. His mental model is illustrated by the causal loop diagram below.

overtime, Routine mental model

The diagram shows three variables that you can measure or observe: the number of hours per week, the amount of finished work, and the amount of work left to do. If the number of hours per week increases, the amount of work that gets finished increases as well (indicated by the causality arrow and the +); if the amount of finished work increases, the amount of work left to do decreases (the inverse relationship is indicated by the -). This is a balancing loop (indicated by the scale symbol), because at a given moment the work left to do decreases rapidly enough to be finished before the deadline.

What happens in reality is that things speed up at first, but after a few 80 hour weeks, the exhausted developers create more and more defects and the project completely runs out of control. The diagram below shows the dynamics. After a delay (indicated by ||), fatigue will take its toll, resulting in more defects and more work for the developers.

overtime, Steering mental model

This creates a self-reinforcing loop (indicating by the snowball), pushing the system towards collapse – resulting in things like burn out, people getting sick, people leaving.

A Steering manager knows that overtime can work for a short time only. After that, people will become stressed and tired and will make more and more mistakes that add up to the work left to do. She also knows that the effect of work to do on the hours per week is a management decision: she can decide not to increase hours, but instead make sure the team gets enough rest.

Note that a Steering manager will usually not get into this situation; she will detect early on that the project risks getting late, when there is ample time to change the plan, get new people up to speed, or renegotiate with the customer.


If you can’t observe or measure what’s happening, you’re not able to know if things deviate from the plan and you have nothing to base your actions on. As an example, you can observe how a culture handles failures and defects.

In a Variable culture, where customers and developers work closely together, the customer reports a defect directly to the developer, who fixes it right away. This makes it hard to get insight in things like the amount of defects reported and solved or the amount of new defects introduced after fixing a defect.

A Routine culture doesn’t regard a defect as information, but as something to assign blame for. As a result, defects are moved around like hot potatoes, ignored, blamed on the user, classified as ‘minor’ (i.e. it won’t get fixed – learn to live with it), or relabeled as a change request. Managers buy fancy bug tracking tools, but these are not used effectively. Because of the blaming associated with defects, making defect handling more visible will run into a lot of resistance.

Scrum and Extreme Programming provide simple and effective ways of increasing project visibility, e.g. through velocity, burndown charts, story walls, or kanban boards. So these process models can help you transition from a Variable or Routine culture to a Steering culture.

Stability – If the software development processes are not stable, you don’t know what the effects of your actions are. If e.g. your project velocity varies wildly over many iterations, your burndown chart becomes meaningless, and you can’t promise your customer anything.

Introducing automated testing at different levels (unit, integration, functional, acceptance) helps to stabilize your projects.


Would you like to explore systems thinking and mental models as a tool for better understanding and better decision making? Would you like to get a grip on your projects? We can help you – feel free to contact us.