Managing Contradictions

To pursue the impossible is madness Marcus Aurelius

So I read through what I wrote yesterday about contradictions. And I realised that it's quite a depressing read.

The depressing nature of contradictions might be why they're so hard to pin down, why it feels rude talking about them and why thinking about them somehow feels a bit like staring at the sun.

But I think there's a bright side to talking about contradictions. One of the reasons that you picked up this book might be that you have taken on the job of delivering a project and you have started to suspect (or you have been slapped across the face with the idea, or you have woken up in the middle of the night screaming, thinking) that the project that you're suppose to deliver is impossible. And when you've fully admitted to yourself that the project can't be delivered, the temptation might be to start looking for people to blame. It's the clients fault for asking for such an insane thing, in such an impossibly short space of time. It's the teams fault for not being better qualified and not working harder. It's the users fault for being so stupid and not wanting what we're trying to sell them.

But of course? What is all this blame really about? Who, in your heart of hearts, do you really suspect is to blame? Of course, it's fucking Boris Johnson. I'm joking. He may be to blame for many things, but the state of your project (unless the name of your project rhymes with "Sack" and "Chase") probably isn't his fault.

No, seriously now. At heart, who do you think is to blame for the problems that your project is facing?

You. That's what you really think isn't it? It's you.

Deep down, beyond the "blamestorming" and finger pointing, that's what you really think. You think that you're to blame.

This is the positive, uplifting thing that can come from identifying the contradictions in a project.

Think about it for a moment. If what you're being asked to do is impossible. Your inability to do it, can't be your fault.

The contradiction that I called "The Chicken Soup Paradox" yesterday, is a good example of a paradox that is in some ways comforting and relieving.

Why do I call it "The Chicken Soup Paradox" because it came to me after a lunch of chicken soup.

I was reading Robert Dilt's book on hypnosis "Sleight of Mouth." In it he was pointing out that it's very important to understand the difference between thoughts, and reality. As an exercise he asks the reader to think about something that could have happened in the recent past but didn't, an ordinary thing, not a fantastical thing, and then think about thing that did actually happen.

I had just had chicken soup for lunch - so that was the real thing that I thought about. What I would have liked for lunch (although just about every dietary authority on the planet would try to dissuade me) was a bacon sandwich.

So there, sitting in my study, I tried to think, how I knew that I had had chicken soup for lunch (something that had really happened) versus a bacon sandwich (something that I would have like to happen, but didn't).

Here's what I came up with as a good way of knowing the difference between ideas and reality:

I'd spilt chicken soup on my shirt.

And the realisation that came with that is this:

one way of knowing that stuff is being done, is that stuff is going wrong.

OK, OK, there are also some things that go wrong because of acts of omission, but it's important to understand that a lot of the problems that you face as a project manager are because you and your team are doing things. In the trendy language of cryptocurrencies, a lot of the problems that you know about when you start doing a project are "proof work." The project is about implementing something in a new technology. Only by starting to try to implement something in this technology, will you realise that it's vapourware - it makes a lot of claims, very few of them stand up. Your project is about delighting a certain group of users. Only when you start to talk to those users can you discover that they hate the idea of the project.

In my experience, having discussed this "chicken soup paradox" with a lot people on training courses, there's a great relief that comes from realising the connection between stuff going wrong and stuff getting done. If only for a moment the weight of responsibility for all the things that are going wrong on their projects is lifted off their shoulders.

But there are couple of obvious consequences of understanding the chicken soup paradox.

If you're a team, one way to stop things going wrong is to stop doing stuff.

This is another paradox that we've talked about - agreed activity. This means that how leaders - project managers and customers - react to stuff going wrong is absolutely vital. Something things go wrong due to laziness and incompetence, some things, as I mentioned, go wrong due to omission. It's important to understand that when you're trying to do a lot of things, things will go wrong for these reasons. When team members are trying to do new things on a new project, many things go wrong simply because nobody really knows what they're doing.

If you're a project manager or a leader or a client. It's important to understand the utterly corrosive power of responding to "things going wrong" in the "wrong" way.

If you're a client and all you're hearing about your project is good news, there are two possibilities.

The project team in concealing things from you.
Nothing is happening.

We'll come back to contradictions tomorrow, but finally, for today, a really important thing to understand about contradictions is this:

if you don't have awareness and control over the contradictions in your project, they will have control of you.