Cultural Patterns: Routine Culture (2)
Routine – we follow our routines (except when we panic)
A Routine culture assumes that there is a optimal way of doing things and that we can determine this best way. This assumption can hold if the organizational context, the problem domain, and the technology are well-known and predictable enough.
A Routine culture might work if you mainly do small, simple, similar projects. I think a Variable culture fits this context better however, being more efficient and less risky – a group of skilled craftsmen who can oversee the work and who will do whatever they think is best to get results.
If your organization specializes e.g. in building accounting software and you have built over a dozen accounting systems with the same technology, the same DBMS, the same programming environment, a Routine culture could work. You should ask yourself however why you are doing the same thing over and over again – you’re better off making a product or service out of it and selling this product or service. Alternatively, you could make a framework or automate it (e.g. an accounting systems generator or a 4GL for accounting systems). This will give a much better return on investment.
So some IT projects are in a known, predictable context, but most of them aren’t. Usually the problem domain is not as predictable as you wish. The business context changes continuously. You have to discover requirements along the way. By deploying prototypes and early versions of software, you influence the users’ perception and understanding of problem and solution, making the whole system unpredictable.
Even if the problem domain and technology are well-known and predictable, you still have to cope with the complexity of people systems when you roll out a system. If you have one or two users, you might be able to oversee it…if you have to roll out your system to ten different offices and hundreds of users, you’re definitely in a complex space…
IT projects that deliver a strategic advantage for the business are by definition not in a known, predictable context – if it was known and predictable, there wouldn’t be any strategic advantage, only something you need to do to keep up with the competition.
And even if everything is currently known and predictable, it’s not going to stay that way:
- You tread into a new and unknown problem domain, thinking something like: nah, client relationship management is probably just like accounting.
- Someone else creates an accounting service that costs ¼ of what you charge, undermining your company’s reason for existence.
- Your programming language or 4GL isn’t supported any more and you have to migrate to .NET, a technology that is completely new to you.
This makes Routine processes break down. People start to panic. In practice, the software development system becomes more and more like a Variable culture, where most people just do whatever they think should be done in order to get over with it. This is not something that is discussed or admitted (don’t you dare mention it!). Officially, you’re still following your routines. In practice, you’re doing something completely different.
An example: in a regular waterfall project, a test phase is planned at the end of the project, followed by a few days of rework, followed by deployment to production. What happens in practice, is: the test phase uncovers a lot of defects all at once, developers work 70+ hour weeks to fix everything; they start cutting corners in code quality and unit testing as a response to the management pressure to finish before the release date; ultimately, even a few untested fixes slip into production.
How can you recognize a Routine culture going awry?
- Lack of trust; focus on role definitions, contracts, service level agreements instead of collaboration.
- People say “that is his/her responsibility, not mine!”
- Lots of blaming (and placating) – managers look for scapegoats and reprimand developers for not following the process – Who’s fault is this? Heads must roll!; developers blame managers, but not openly.
- Developers complain about all the routine meetings, but still attend them, silently nodding and yawning.
- People try to stick more and more to the routines, adding extra procedures and rules; but this makes things even worse.
So what can you do when this happens? You could let the routines fade away over time and proceed in the chaotic way things are already happening, i.e. transitioning to a Variable culture.
Alternatively, you can try transitioning to a Steering culture, but this is not for the faint of heart: you have to build trust and make the undiscussable difference between what is should happen and what actually happens discussable. One of the next installments will be about transitioning from a Variable or Routine culture to a Steering culture.
In the mean time, don’t forget to check out Nynke’s blog entry on scenario planning as an Anticipating culture practice.
Links
- Most IT Jobs Are Like Deodorant – about strategic, value adding IT work vs. essential but not strategic IT work.
- The new dynamics of strategy: Sense-making in a complex and complicated world – in depth article about the Cynefin model, about known, the knowable, complex, and chaotic spaces.
- Gerald M. Weinberg, Quality Software Management vol. I: Systems Thinking
October 16th, 2007 at 5:18 pm
[...] post, Nynke jumped ahead with scenario planning and Marc continues with his routine on routines – we follow our routines (except when we panic) on what happens when a routine culture breaks down because of a foreign element. I could have [...]
February 9th, 2009 at 10:01 pm
[...] customer requirements, complex problem domain, and/or unknown and rapidly evolving technology (I’ve written about this before in the context of Weinberg’s cultural [...]