This is partly inspired by Cairo traffic, which in itself probably the worst I’ve experienced in terms of safety, volume and complete lack of road sense. But it’s brilliant and whilst something normal for the 20 million or so Egyptians who live there, it’s something different to the occasional visitor like me.
Been an interesting week and one thing that been on my mind is the constant attraction to the day to day activity for people rather than the tackling of the bigger picture.
There are good reasons for this:
- It’s business as usual and you tend to know what you are doing. You are generally good at it
- You get immediate results. Bit of a rollercoaster as they can be good and they can be bad
- They need to be done and someone needs to do them.
- We tend to go for routine as it is well defined and usually easy.
However there are sometimes problems with this focus :
- The day to day activity may be inefficient and / or obsolete.
- No-one necessarily appreciates the activity you are doing.
- By doing the day to day you’ve not got time for strategy or development work.
One other area of concern (well to me this week) is where the way of working for day to day is also the approach for strategic work.
This way of working has a number of characteristics which centre around confirmation bias. You are going to do what you know best or what you’ve done as routine even if you are working on something new. What you therefore produce as new will be course elements of the old even if it’s seemingly been completely rebuilt.
There’s a great film from the 1950s which highlights the reluctance to change and inefficient working practices that persist. Okay it’s a comedy (and well worth watching) but it does give you a sense of the frustration and the mood towards change.
“I’m Alright Jack ” also highlights corrupt bosses and the power of the trade unions (Only one of those two thrives in the UK) but by watch the time and motion man you get a sense of what might need to be done to make things happen.
I’m writing this in the context of software development and IT architecture but of course they are many different areas where this is true.
The shifts and changes in IT are probably more rapid than in other areas so the need to change agreed practices and ways of working happen more frequently. What you might see is new applications written with new languages and but where the paradigm for development is still the same. You will see that way of working hasn’t changed.
Saying “we’ll develop this for a container platform” is all well and good but it’s not going to be that effective if:
- You don’t use the right languages that support the design
- You keep legacy functions and features in the application, even if they are provided by the new platform
- That the process of software development changes as well, with greater levels of automation
- It is actually proven to be more effective than the previous application platform.
People (and in this case software development teams) will always try to:
- Work the way they’ve always worked
- Use the same shortcuts, coding standards, testing procedures etc they’ve done before
- Use the minimum effort needed
- Minimise risk by as doing as little change as possible.
So what approaches can use to break the cycle and the reliance on the old way of working.
- The lab: using a safe environment where external coaches work with an initial group of people, who will in turn share new ways of working with others in the organisation
- The core team : internal team, as the lab, which is ring fenced to do the right thing and correct way or working
- The acquisition: acquire a business or organisation that has the new culture and way of working and use that to drive change.
Plenty of scope for discussion and some interesting but this propensity for change is key; it will impact if you can change and how quickly this can then happen.