An IT Leader’s Journey

I’m going to start this article with my telling of a Taoist tale. A tale about a farmer in ancient, rural China, who runs his farm with the help of his son and a single horse – used for the heavy work like ploughing and carrying.

One morning, the farmer awakes to find that his horse has run away. When his neighbours in the village find out, they’re quick to tell the farmer about just how unlucky he is to have this happen. “What misfortune!” they cry.

The farmer simply replies, “Maybe.”

The next morning, the farmer awakes to find that his runaway horse has returned, but more – it’s come back with four other wild horses. When his neighbours find out, they’re quick to visit him and tell him about his great fortune for having these new horses. “What wonderful luck!” they exclaim.

And the farmer simply replies, “Maybe.”

The following day, the farmer’s son, while trying to tame one of the wild horses is thrown off and breaks his leg badly. The neighbours come by once more and tell the farmer just how awful it is that his main help on the farm is incapacitated. “What terrible luck!” they say.

And the farmer simply replies, “Maybe.”

The next day, the army come through the village looking for conscripts to the infantry. They arrive at the farm and, seeing the old farmer and the son with the broken leg, they pass through and leave them be. Finding out, the neighbours rush around to tell the farmer how lucky it was that his son was injured and so didn’t get picked. “What fortune you have!” they declare.

And the farmer once again replies, “Maybe.”

There are different interpretations of the tale. Core is that you can’t have good without bad, and that an individual event may not be what it appears when considered against other events; a seemingly good event can lead to a poor one and vice versa.  We might also note that the farmer understands this principle and chooses not to spend time considering it; he focuses on doing what he can, and what he can influence.

So why tell this tale? For me, there’s a parallel to my own leadership in IT.

Events that happen, when considered in isolation, could be either great or not. Take an example I’ve seen a few times of bonuses. Imagine a performance-related bonus, paid at the end of each quarter. Paying out 100% of that bonus to a team because they’ve achieved well is a great feeling: there’s pride in the team, pleasure in being able to reward and so on. You leave work on a high, coming in the following day to a key resignation. Why? In that situation, the engineer had been head hunted and had another job. By waiting until their bonus was secure, they didn’t forfeit the cash by resigning. Logical.

Regardless of the specifics (which could be another article), we’re all going to experience these ups and downs – and the ups may not always relate to the downs. When you’re a leader with your head above the parapet trying to make a difference, all the more and we have a choice about how we respond. Here are some options:

Reach for Process and Compliance

Implement tight process and procedure that seeks to control outcomes as much as possible. Detail everything in a project plan so that we know exactly who’s doing what, when. Plan for the worst! Get people following scripts for the tasks that they do. Decisions go ‘up’ the tree. Do that because, well… best practice.

This was where my own management career began. I held a belief that this was how managers were supposed to act and teams were supposed to run. There’s no doubt an attraction to strict process and compliance, especially when it offers a solution to a current pain or a shortcut to a result. If we give people rails to guide their actions, take the steps that give a known result, we can avoid adverse consequences. Take the origin of ISO9000 as a great example. According to John Seddon*, the process that we know today came out of munitions factories during the second world war. People working in these factories had – unsurprisingly - a high risk of mortality, and processes that limited that result were adopted. Do this, be safe.  There are loads of examples; pre-flight checks in aviation (are we fit to fly), medical equipment checklists in operating theatres (in other words, did we leave any in the patient?) and in IT, a simple example might just be to double check that a service is working after an upgrade or a password policy.

Strict process often comes at a price however, and especially when zealously applied. I’ve seen plenty of teams where the focus on avoiding adverse consequences and following the script is so high that they inevitably restrict their successes. We could have done X for the Customer, but we weren’t allowed to. We can do this more effectively, but we’ve got a process. I could have prevented that, but it’s not my job. I had a great idea, but it’s just too hard to get anything changed around here. We didn’t see that coming! We delivered something that no one wants. Great ideas might not be shared, creativity could be stifled and time wasted.

This situation normally originates from the implementation of a formal best-practice process/framework or an organic dam of minor changes. Briefly, imagine a river flowing as a metaphor for the work we need to get done, getting done.  We can impact its flow by implementing a full process (say strict Prince 2 for all projects imposing a series of lock gates to all the work) or by building up areas to prevent the river breaching (say we add checks/balances as things go wrong as it’s rarely after something goes well). 

In either case, the question should be one of value – is the process that we’ve just added, is the step we’ve just added, adding the value we want? Or, have we diverted the river to a route that is actually going to cause harm or waste. Sadly, that question isn’t asked nearly enough.

* If you’ve not read “The case against ISO 9000” by John Seddon, I recommend you do. Whether or not you agree with all the detail, Seddon outlines the origin and intention behind ISO 9000 – something that almost everyone I’ve met takes for granted. From there, you can make your own mind up about its value.

Go laissez-faire

The active opposite of process and compliance, freeing people to do what they will. Laissez-faire as a term (in French meaning “let do”) was first used in the late 17th century in relation to trade, and continues its use to today. The concept is that a freedom from government and legislation allows a natural order system to evolve; one where individual interests contribute to the greater good. It presumes that without intervention, systems are harmonious and self-regulating.

When used in management, laissez-faire is likewise ‘hands-off’. Given that we’ve hired talented and capable people into our teams, making sure that they have freedom to act sounds sensible. Without the risk of stifling process or leadership, we give our individuals the ability to be creative, to find their own solutions, to develop and explore. It can be deeply satisfying for people to work in these environments, and we open the door to remarkable innovation.

At the same time, there’s a danger with this approach. With a complete ‘let do’ attitude, individuals take their own paths and silos can pop up, leading to a drop in team cohesiveness and loss of group learning. Individuals could well make change without any thought for others (intentional or not). Some individuals might abuse the freedom, being over competitive or get away with doing little work at all. Work prioritisation itself could conflict with the wider organisational goals and the leader themselves might be even seen as ‘weak’.

I’d recommend a thought experiment for you, and to do that will introduce Jean-Jacques Rousseau, a Genevan philosopher in the 18th century. Rousseau, when talking about freedom posed the question of whether, if you lived on an island, with no government, no rules, no work and no ties, you would be free. Would you?

At first, this might seem attractive, but perhaps not. To Rousseau, instead of the restrictions and binds of government, you now have the needs of shelter, food and safety binding you. You aren’t really free at all – and what’s more, this new freedom is more oppressive as you have no time for more creative thoughts. Are you going to be finding time to write a book, compose an opera or paint a masterpiece? His assertion therefore being that government, by doing things for the people (by providing a fixed level of control), actually makes them more free.

Herbert Spencer, also in the 18th century, summed up Laissez-Faire as a movement which ‘calmly looks on while men ruin themselves’. Left unchecked a team given a full ‘let do’ can do just that.

Somewhere in between?

So, if ups and downs are going to happen, and adopting either end of the scale – compliance that stifles creativity or laissez-faire risking that we never get anything of value done – what do we do? What is the optimum level of compliance that meets legislative requirements and frees up the potential of the team?

Sadly, there’s not one answer as it’s situational and the situation will change.  Here are some questions that might help you get closer as you travel your own IT leadership journey.

-         Take a look at yourself. What have you learned personally from each of the up and down events? Make some notes. When did you underreact? When did you overreact? How do you know?

-         As things happen, good or bad, how are your processes allowing for or capitalising on that? Map out a process. What is the intention of the process? What value does each step of that process add? Would it work without that step? If it doesn’t, how do you know that’s the case?

-         Take a look at your teams. Does your team truly understand what, for you, are good and bad events? Would they recognise these without you needing to call them out? How are the team then setup to capitalise or act to learn from these events?

-         What do you your team think about your approach to the ups and downs? Do they think that process is too restrictive and holding them back? Would they prefer to have more specific guidance available in certain circumstances. How can you test different options?

If you enjoyed this article, please like and share – thank you!

You might be interested in some of my other recent articles:

It’s all about visualisation (and pitching isn’t just for sales) https://www.dhirubhai.net/pulse/its-all-visualisation-pitching-isnt-just-sales-stephen-morris/

7 reasons why individuals struggle with change in business https://www.dhirubhai.net/pulse/7-reasons-why-individuals-struggle-change-business-stephen-morris/

7 leadership habits to make IT teams rock https://www.dhirubhai.net/pulse/7-leadership-habits-make-teams-rock-stephen-morris/

About the author

Hi, I’m Stephen.  I teach IT leaders in complex IT how to make their teams ★ROCK★

I’ve spent the last 12 years in senior leadership and consulting positions for cloud computing providers and other organisations with similar high-scale and complex IT.  I’ve proudly led and worked with some amazing teams and have received awards for influential business leadership and agile team development.

I now teach and coach IT leaders to develop adaptable, high performance teams, available as short workshops and a unique leadership development programme, The Open Leader Method?, created specifically for leaders working in complex and uncertain environments like cloud computing. 

I also speak on leadership, motivation and change. If you’d like to find out more, book me as a speaker or apply for one of our programmes, drop me an message.