It’s all about the people.
A service exists to serve people. It is built and delivered by people.
Even in the most technical domains like IT, the service is about managing information for people to use, and managing the way they use it.
When we change IT, a lot of the time we are ultimately changing the way people behave, the way they do things.
There is an old mantra “People, Process, Technology” to which I always add “…in that order”. By which I mean prioritise in that order, and start in that order.
People, Practices, Things.
Actually I don’t like that mantra; I prefer “People, Practices, Things” as a broader, more inclusive set. Either way, it all starts with people.
We’ve been using railways (railroads) as examples for this series of articles. Ask a railway how important the people are. Railways are complex and very dynamic: they need to adapt to constantly changing conditions, on a daily basis and across the decades. We are slowly getting to the point where we can automate the running of railways, but only because the trains run in a tightly designed, constructed and operated environment that relies on people to make it work and keep it safe. Much like IT.
I’ve never bought into this feel-good stuff about successful companies being dependent on a caring people culture. Some of the most successful railroads in the ultra-competitive US environment have pretty rough people cultures – they treat their staff like cattle. And other railroads are good to their people – though most of them are off to what we would consider the tough end of the spectrum. I don’t think it correlates. I could say the same about software companies I have worked for: from second family to sweatshop.
However it is probably true that all successful companies have a strong culture. Staff know how it works. They may or may not like the culture but if it is strong they identify with it and align to it, to some extent. So culture is important.
And cultural change is hard – in fact it is a black art. The bad news is that changing the way people behave – remember our first paragraph? – is cultural change. Behaviours only change permanently if the underlying attitudes change. And people’s attitudes only change if their beliefs move at least a little bit. Culture change. Fifty years ago railroads were places where men – all men – died regularly, learned on the job, and fought as hard as they worked. Now the people are trained professionals and the first priority of most railroads is safety. Twenty years ago the New Zealand Railways had 56,000 employees, couldn’t move anything without losing it, lost millions, and wouldn’t know what to do with a container. Now 11,000 move record volumes of freight and do it profitably.
“Just because you can change software in seconds doesn’t mean organisational change happens like that”
You can’t make those transformations in short timeframes. Just because you can change software in seconds doesn’t mean organisational change happens like that. You would think railroads take longer to change hardware technology than we do in IT because it is all big chunky stuff, but really our hardware and software platforms change at about the same pace; years and even decades. Plenty of Windows XP still around.
Technology is the fast changer compared to people and process. Just because you rolled a flash new technology out doesn’t mean people are going to start using it any differently unless you ensure they change and their processes change. That human rate of change is slow. People will change quickly in response to external pressures like war or threatening managers, but that change won’t stick until their attitudes and beliefs shift. I bet the safety culture on US railroads took at least one generational cycle to really embed.
In response to a few high-profile crashes, governments in the US, UK and other places have mandated the introduction of higher levels of automation in train control over recent decades (despite the much higher carnage on the roads but that’s another discussion). Much of this push for automation stems from frustration over driving change in behaviours. Does any of this remind you of IT initiatives like DevOps?
Culture can change, and sometimes it can change quite quickly, by human standards. It takes strong and motivational leadership, a concerted programme, and some good cultural change science. The leading set of ideas are those of John Kotter and his Eight Steps to change, but there are many ideas and models now in this area. In IT, everyone should read Balanced Diversity by Karen Ferris. And you will find a multitude of suggestions on my free site He Tangata.
Whatever methods you use for change, pay attention to three aspects: motivation, communication and development.
Motivate them in these ways:
- by getting them involved and consulted;
- by showing how they benefit from the change;
- by making them accountable and measuring that accountability;
- and by incenting them.
Communicate early, communicate often, and be as transparent about decision-making as you can. Tough decisions are more palatable if people understand why. Communication is two-way: consult, solicit feedback (including anonymous), run workshops and town-halls.
Development is not just one training course. Training should be followed up, refreshed, and repeated for new entrants. Training is not enough: practical workshops, on-the-job monitoring, coaching support, local super-users and many other mechanisms all help people learn what they need to make change successful.
One final thought: examine your current and planned IT projects, and work out how much effort and money is being spent on the people aspects of the changes the project wants to achieve. I’d love to see some comparative research on the proportions of money spent on people aspects of projects in different industries like railroading, because we in IT still seem to suffer the delusion that we work with information and technology.