I have just written a couple of articles on bad decisions and I seem to be getting a little carried away with the idea (the articles are here and here).

But I have been focusing on how to avoid or learn from mistakes. This is a little one sided, so I thought I would balance things out by exploring how evil agile coaches and dodgy leaders actually encourage greater mistake making and greater carnage generally, without expending too much effort.

Regular readers of my blog are probably aware of my occasional work with evil coaches.

Even if you are not familiar with that, though, you will have observed that there are some coaches and leaders out there doing some fine work, creating cultures that maximize error making, minimize learning and amplify the damage of mistakes, almost systematically.

But how can you really excel at this if you are an evil coach, already hard pressed to keep up with your quota of carnage and already struggling to stay under the radar.

Understanding the risk of regret

There are many approaches to creating systemic stupidity, from the use of aggressive language to burning people out and letting their stress lead to consistent error making and friction.

But one of the most straight forward approaches is to understand and leverage the “Risk of Regret.”

The risk of regret is the likelihood that you will either regret making a decision, or regret not making a decision. While it is not possible to predict this with certainty, it is often possible to anticipate it.

The risk of regret is really a combination of two opposing risks:

• The risk that you will regret making a mistake because you were impatient and did not stop to think things through, for example buying a “nut surprise cake” for someone without checking if they have a nut allergy. This is usually caused by impatience, panic or pressure from others; and
• The risk that you will regret your inaction when you should have made a decision, for example if you hear a fire alarm and are not sure which exit to take, so you sit back and hope that someone comes to tell you what to do – only to realise that fires can be dangerous as the fire appears at every exit on your floor. This is usually caused by inertia, fear or panic.

Of course, not all decisions carry the same risk of regret, so let’s create a matrix to compare decisions where the likelihood and impact of regret is low or high.

OK – so people might regret things, but surely an evil coach can do more than just turn up and gloat when people are feeling down.

That is the beauty of understanding the risk of regret rather than the actual regret, since it is the fear of regret that usually leads to suffering with decisions. And what is even better for the eager evil doer is that each quadrant in the matrix contains simple strategies for causing systemic organisational damage and human suffering, including but certainly not limited to simple fear and regret.

Let’s look at each quadrant in turn and examine some simple, easy to implement yet powerful “hacks for evil.” I will also add some simple suggestions for being nice when you are taking well earned day off your campaign of evil.

Here is the same diagram as before, but with some suggestions for mischief making added in.

It may be tempting to move to the top right quadrant to try to cause distress or dampen hope among your crew, but all four quadrants are rich with opportunity.

High risk of regret caused by inertia

Let’s start with decisions that appear to have a high risk of regret if we delay the decision and little or no risk of regret if someone is able to make and act on their decision.

Here the goal is to delay decisions while appearing helpful. The most common way of doing this is to add unnecessary bureaucracy. Try to implement sign off steps, reviews or even ask for sign-off from someone in another office.

A more devious approach though, is to add people. This represents a great opportunity to appear eager to help while actually slowing things down.

Each person you add will need someone to bring them up to speed and will also try to contribute suggestions before they know what is going on. Ideally, seek to add people who have little knowledge in the subject but a history of friction with the team.

Perhaps you can even bring in some people who have a pet project or solution they are pursuing that appears to be related but is not linked to the problem at hand in any real way. They can almost always be relied on to subvert discussions to try to move to their pet project, creating delays and diverting energy simultaneously.

But don’t discount the frustration and delay that simple questions can create here either. If you lack obstinate fools to deploy then simply ask the team to respond to a complex, yet ambiguous question before proceeding. Even if they put it in the parking lot or “phase 2” then you can tell people that the question is critical to success. When people come back with some kind of answer, then simply reword your question or add some jargon. This can cause ample suffering with surprising delays.

Speaking of delays, though, I worked with a guru of impeding movement, who introduced me to the “surprise second guess” move.

This is best deployed when you have already used some other approaches and the team are fighting back. Appear to give them your full support and even agree to everything – particularly where you lack any real authority anyway.

Then, just as they are moving from decision to implementation, second guess what they are doing. Either announce they are doing something different, creating confusion all round, or better yet, re-introduce a previous risk that they thought they had fully explored already, with an apology that you had a bad feeling about it and had been worrying secretly. Ask for a full explanation of their plan to fully explore and mitigate this new crisis.

OK, enough evil for the moment, what can you do when you are in a good mood and feel like being helpful. Here again there are some simple solutions, which I have added to our matrix.

Still in the “high risk of regret caused by inertia” quadrant, the goal is to reduce inertia and help to lower fear of failure to an appropriate level.

The most common approach is to run interference for the team.

Constantly remind people of the goal and why it is urgent. Constantly say things like “If we don’t get this done … ” OR “this is costing the poor front-line guys an hour a day …”. This is called the broken record technique. Constantly keep the cost of delay top of mind by repeating the same thing at every opportunity until people are so sick of you they support any decision,

Related to this though, people will often highlight problems that might arise, sometimes blowing them out of proportion but often actually raising reasonable impediments or problems.

Rather than steam rolling them, ask for clarity and then immediately ask people how they can mitigate the issue, rather than how we can better discuss it in detail. Use your broken record message and then add, “yes, this is still something we should tackle – how can we deal with this without delaying our implementation?”, or “how do you suggest we help people deal with this, given it may happen and we are not stopping?”

There is also a subtle trick that I employ sometimes. People often ask for permission and then find that stakeholders are considering the risk of approving quick action, which can cause a delay.

Instead I remind people of what is at stake and get them to sign off that they accept the risk of delaying action and will be accountable for the cost. I call this “flipping the problem.” When your organisation is risk averse, fear of inertia can create momentum where fear of failure used to cause the inertia. The key is to make the cost or risk clear.

High stakes – a high risk of regret from both making mistakes or delaying

Let’s talk about decisions with a high risk of regret from both delay or mistakes.

This seems like a great place to be evil, but it is harder to stay under the covers here because of the focus people have on the issue.

You can employ any of the delaying tactics that we have discussed, but you might also extend these with some simple recipes for regret.

Adding noise, with either superfluous information or perceived risks that are actually unrelated is a good start. With people already stressed, noise is easy to create and can have become a real distraction. Add superfluous meetings, rabbit holes and unrelated “quick things we need today” wherever possible.

But consider this one too – state that we really need to get this right and we do not want to really mess up. Remind people how unpopular they will be if this goes cactus. Then (seemingly helpfully) state that we need to clarify everyone’s role so that we make sure we have everything covered.

But don’t actually talk about shared goals and accountability, nor supporting each other.

Drag people into needless detail around RACI matrices and specific responsibilities. This will almost always cause people to suggest bringing in others and will create an opportunity for early ass-covering conversations that can create considerable delay and mistrust.

Even better, you will find that you cannot possibly cover all the bases, so by definition you are able create gaps in understanding and areas where things will fall through the cracks, especially with everyone discussing roles and processes so they are distracted from discussing the real root cause of the problem.

Finally, and most dastardly of all, you can “deploy moths.” This is probably not a term you are familiar with, but you may have seen it in action.

When I grew up in Perth, Western Australia, we had a lot of barbecues. These were a huge part of our culture and we often ate outside as the sun was going down.

When the sun when down, we would naturally turn on a light and when we did – moths would miraculously appear from nowhere. They weren’t there when the sun was up and nobody knew where they appeared from, but the moment a light went on they appeared in large numbers and flocked around the light.

You don’t need real moths in your corporate castle of chaos though – corporate “moth people” will do just as well. As soon as there is a big problem, invite a horde of concerned citizens who want the attention of senior management or who love to stick their nose into problems. You will know the people you need – rich on opinion but poor on time to help or lacking the accountability and energy to help in anyway. They will flock to the problem like moths to a flame, expressing opinions and demanding answers to important sounding questions, even requiring frequent updates. In essence they will distract the team far more than any one evil coach could ever do on their own.

But back in Perth, we noticed something else strange – as soon as you turned off the light, the moths seemed to teleport away. There was no delay, they just vanished.

Then if you flicked the light on they all rushed back, only to disappear the second you turned it off. You might think that they were just camouflaged in the dark, but even in the twilight you could see them vanish.

Anyway, this will happen with your corporate moth people too. As soon as it gets tough, they will vanish. They will offer no budget, no cups of tea, and certainly no follow through as soon as the crisis is over. They will neither change their behavior nor support the implementation of the boring bits of the solution. They are rushing off to the next shining light already. This leaves the team disheartened and overstretched. A marvelous medley of mayhem.

Again though – you may want a break from being evil, there are some simple strategies to employ.

The first is to spend a little time breaking the problem down. Where things are so dire that mistakes and delays really matter, there are normally multiple entangled problems. Some need urgent attention and others need some greater focus. By breaking things down you will find many more options to reduce the risk of regret as the team iterate through problems and solutions.

But breaking down the problem is hard if you cannot dedicate the right people. So drop everything else – and I mean everything. Allow a focus on this one issue.

Then as you start to clarify the real problem, free up the right people from everything else for the duration, even though there will be a cost. No holding the fort, no “update someone on what else your were doing so they can run with it.” Just drop everything and let people know this takes precedence.

As soon as you know more though, cut back on the people so ONLY the critical people are involved. Then let them draw on others when needed.

There is one more step though, related to the “moth effect.” Protecting the team from moth people sounds like a start, but actually the bigger issue will be having the time to follow through to close the issue off properly. I hate to admit it, but I have been a corporate moth in the past, pulling people off just before they finish and rushing to the next light, leaving the problem “nearly fixed” and the people exhausted but harried.

Once the crisis seems to be under control, the team are likely to be dragged back to other work while half baked workarounds are still in place. Instead, reconvene when things are coming together.

Say thanks and maybe do a retro, but most also plan into the next wave of action, including some time for the team to recover and some additional time for people to finish the job that they started, or to get others carrying it forward in a sustainable way. Tactical solutions are great for the ego, but professionals close the loop.

Low risk of regretting a delay but a big risk of regretting impatience

This seems like an anticlimax after the last two topics. But there is some fun to be had with situations that require proper analysis.

Rushing people is mean, but lacks flair. So here are some nicer tools for your wicked toolkit.

Demanding complete solutions allows you to keep growing the boundaries of the problem so that analysis turns out to be useless. It also allows you to keep things ambiguous. This is literally the opposite of allowing people to break problems down into bite sized chunks and roll out multiple steps towards the complete solution.

Great fun and delays can also be added by bringing in teams of evil consultants to second guess the team. Make sure that you do not share their results and just keep referring to some murky master strategy that they consultants allegedly supplied. If you find good consultants by mistake and they start getting to the bottom of things though, don’t despair, just bring in more consultants to second guess them and add more murky “master strategies” that are not communicated – the more the merrier really.

However there is another option. One of the most effective approaches I have ever seen is to “prepare a detailed briefing for the minister.” Note that the minister could be a senior politician or a company executive or anyone more senior than your crew really.

It doesn’t really matter who they are though because the briefing will never be shown to whomever the “minister” is.

Start by wasting considerable time asking the team for a full, detailed report, while asking them to dumb everything down so someone with no idea what is going on can read it and learn nuclear physics overnight. Ask hypothetical questions and request the team add responses to the briefing. You can even cut and paste “suggestions” based on random images and articles you find on the web – just email them across with the command that they be included.

Then discard the report at the last minute and meet with “the minister” without the team. Present a different problem to the minister, with similar symptoms but a completely different root cause. Highlight that it is urgent, especially because you fear the team will waste time and money and make the minister look bad.

When you do this you should be able to gain some irrelevant, yet urgent, directive from the minister and hit the team with it. They will now need to implement the wrong solution rapidly, virtually guaranteeing regret.

Of course, again you might be nice, in which case do not do those things. Instead have the team pause for a cup of tea to clarify what they think they should do. Seek broad feedback and analyse effectively. It will take longer than people want but regret lasts longer than analysis in almost any project I have dropped the ball on.

Low regret all round but still a chance for mischief

It may not look like it, but I have left the best till last. In almost every corporate failure I have read about, people were distracted by needless minor things while core issues went unchecked. Even in history, Nero played the fiddle while Rome burned and people shuffled chairs on the deck as the Titanic sunk.

So there is a great deal of harm that can be done in frustrating people and delaying action on minor things.

Start by asking for a briefing on every minor decision that is made by the team, or give briefings all over the place when your make minor decisions.

For fun though, try these tricky mind games.

Testers have often been both annoying and surprisingly sensible on many of my projects. So call them together and ask for their advice on everything, ask them detailed questions and show appreciation for their answers. Then when they are finished, simply discard all their advice and announce the opposite of what they recommended. If you can thank them publicly for their input then all the better. You will laugh and laugh when you see the quiet rage in their faces and with luck they will inflict that rage on hapless developers, doubling the disappointment across the team.

If that doesn’t tickle your fancy then ask people to hold off acting on simple things while you ponder it. Tell them you will “get back to them soon” so they can’t move forward but don’t give up waiting. A variation on this is to say you will have to run it past “randoms” or random people the team can’t check with. That way you can waste more time talking about every issue than acting on them.

Being nice here though is a real blow against systemic stupidity, so be careful here if your intent is evil.

A simple approach is to just delegate without strings. Don’t ask questions or even state your own opinion. Just tell people you trust them and you are happy with their proposal.

The alternative is to make a decision yourself, in which case make the decision emphatic and clear and make it immediately.

These approaches have surprising power but I suggest backing them up with demonstrated trust. When things go wrong, which they will, take the hit for the team or state that you have the team’s back and that we will learn from minor hiccups. State this often and never get into gossip or blame, just keep moving and focusing on the next thing rather than the last.

Also, when thing go right, which they will, say thank you or talk behind people’s backs. It may surprise you, but commenting on how people are taking action and making their own decisions always seems to bring both them and you karma.

So there you go. A very long article, but I enjoyed writing it even if I didn’t really think it through at the start.

I guess a far shorter version would be this – if you understand the risk of regret, then you can use this to unleash great evil or even good with relatively little effort. The decision is yours.

I was talking about mistakes in my last post and I said I might look at bad decisions.

Thinking about thinking

I have made bad decisions because I did not wait to find out more information, but I also gone off to find more information, only to regret not making the decision early.

Oh dear, it sounds like deciding whether to make a decision is in itself is a decision, so even avoiding a decision involves making a decision to avoid the decision. The only way to avoid that is to avoid deciding to avoid the decision, but that means …. I guess you get the idea.

But there are actually 3 choices when we come to a “decision opportunity:”

• Make the decision now, based on what we know
• Seek more information
• Ignore the decision for now and defer thinking about it

Each option has a cost (or risk) and each has a benefit. So I am sometimes surprised that someone will say:

We are risk adverse here, so we always want to gather more information before we make a decision.

Unknown client

Error 1 – not deciding because you fear a mistake

But what if the risk of delaying is greater than the risk of making the wrong decision? What if the cost of analysing the decision is greater than the cost of guessing wrong? What if the benefit of deciding now is nothing and the benefit of some analysis is great?

Based on these questions:

• Decide now if the cost of making a dumb decision is less than the cost of analysing or relaxing. This includes when you want to avoid a decision but know you will keep stressing about it
• Just relax and decide later if there is time to spare and better information will come along, or record a trigger point if you think there is a logical time when you need to decide. Neither make a decision, nor do any analysis.
• Stop to analyse if there are things you can learn without delaying the decision too much, or if there is real value in improving your confidence. But “analyse” does not mean collate meaningless data and then delay thinking. Instead generate questions that would help you form a better decision and seek answers to those. The cost of analysis is often a lot less than people think it will be, if it is done deliberately and with curiosity rather than fear.

Error 2 – mistaking a good outcome for a good decision

I was telling someone recently that I am lucky. In almost every project I take on, things come together really well because the stars seem to align.

This is great and I recommend being lucky wherever possible, but I have also been on some projects where things went to custard (a term meaning that the outcome was sub-optimal and that my reaction was one of sorrow).

But the outcome has not always correlated with the quality of the decisions I made along the way.

I have made excellent decisions, based on the available information and then found things out later that led to our demise. I also realise that there has been more than one opportunity when the decision I made was actually a poor one, but that we succeeded in spite of my foolishness.

A good decision and a good outcome are different things. You will learn the wrong lesson if you assume otherwise.

James King

I do retrospectives on my projects and on my ongoing work. I often start with the outcome and then say “was that good or bad.” This is useful if I want to identify factors and patterns that I can notice next time – but can be destructive if I then assume that the outcome dictated whether the decisions I made along the way were good or bad.

There are many instances where people have ignored risks and been lucky or spent a lot of money when they could afford to. They then assume that they did the right things and take the same approach next time – only to inevitable be unlucky once, or run short of money when they can least afford to.

Instead, if you want to create better decisions then try asking these questions:

• Knowing what I know now I might have done something different – but in a similar in the future, if I had the same information, would I make the same decision?
• Let’s say something went wrong – did I foresee the possibility?
  • If not, should I have?
  • If I did, then was my preparation proportionate to the risk – Ie if it was unlikely, was it reasonable to keep going? If it was likely and bad, should i have done something different?
  • Once I learned about the mistake, what happened? Could I learn from that and take both positive lessons (do ts again) and negative ones (don’t do that again)
• Let’s say things were tough but they turned out well. Do a pretend retrospective on different outcomes – what would we have done if Bill didn’t come along at the right time? Then ask what lessons you might have learned from that.

Techniques that might help

So, where does that leave us. One idea that comes to mind is to do retrospectives for decisions on the basis of what you new then – what would you do in a similar situation if you had similar information. Similarly, review what happened when new information came to hand – did you respond well, or did you try to negotiate with reality so that the original decision is right, when you know in hindsight that it is no longer correct.

Looking forward, try using pre-mortems (pro-spectives) where you guess different scenarios and then assess what you might do.

I am an agile guy now so I believe in things like psychological safety, “safe to fail” and trusting people.

Just like all agile coaches, I am a nice guy and I believe everyone else is too. So I let people try new things, they make mistakes and we are pretty happy about it all, since we know mistakes are a great source of learning.

Of course there is a small blast radius where the mistakes led to some human suffering but that is cool because we all learned from the experience.

But in the old days I did a lot of work looking at processes and work practices and what where I was not so enthusiastic about making mistakes. In fact I spent a lot of my time predicting and identifying mistakes so I could design them out of what I was building.

Not only that – when building processes, I would try to design them to stop naughty people causing harm to nice people. Essentially, if a naughty person wants to steal money and they work in a bank, I thought that we should try to stop them.

So what happened when I became agile, did I become more naive, or did I suddenly discover that people are nice and amend my behaviour to account for this new discovery?

We no, I have always been a pretty trusting person.

My father taught me that the cost of not trusting people is usually higher than the cost of trusting them

James King – Son of Barry

My father had a saying – “whether you trust people or not, you will generally prove yourself right.” What he meant by that is that the way you treat people changes the way they behave.

Now that I am older I can think of several times where trusting someone led to me being hurt or let down. But for the most part, I think my father was right. Treating other people the way I want them to treat me has almost always worked out for me.

This seemed true in process design too – if you put in too many checks and balances then they distract people, who then stop thinking and miss things. At the same time, naughty people spend time gaming the system – learning how to circumvent all the controls and barriers to being naughty.

So a complex system or approach generally leads to more errors than a simple one that relies on people’s accountability.

Telling someone that you trust them and letting them know you are relying on them is usually more effective than trying to control their actions to prevent them being dumb or naughty

Agile researcher – 2016
Written on a post-it note, since lost to the world because he failed to document his thinking properly

So where does that leave us – should we trust our customers and our teams and just assume the benefit of learning will always outweigh the cost of failure?

My wife has a saying in project management – I trust but I will check. She will trust people to deliver, but there will be agreed points in where that trust will be validated by reality. There will be milestones, walk-throughs and audits.

In an agile team we build this in too. Every sprint has a plan at the start, trust in between but a check point at the end of the sprint. Every day has trust and collaboration supported by a stand-up where we check in on things. Every story has has a definition of done and an agreed acceptance test. It all sounds like a lot more validation than trusting.

In fact these approaches are designed to minimise the “blast radius” of mistakes. We can create a culture of safety because people know that when they make a mistake, it will be found and corrected quickly without them being yelled at and without great suffering for others.

This is especially true where we have retrospectives, peer reviews and constant collaboration which increase the speed and depth of learning.

Agile approaches aim to decrease the cost of mistakes and increase the speed of learning so the value of learning exceeds the cost of learning from mistakes.

James King and possibly many agile coaches before him

That is lovely and empowering. But, mistakes still have a cost and some of them just suck, with no learning to be gained.

So we should still try to analyse our mistakes, so we are making “learning mistakes” and not stupid ones. Interestingly, there is a long history of designing mistakes for learning and in designing processes and even collaboration to avoid them.

I have previously written about designing systems to protect users from making predictable, yet annoying mistakes in an ancient article called “International standards for being stupid.”

What I would like to do in my next article is to explore one specific type of error – bad decisions. These might be decisions where naughty people intend to be lazy or where good people may be prone to make a mistake or exercise poor judgement.

I hope that by looking at these areas, good teams can adopt some simple practices to build good decisions without slowing the team down or harassing people to make them justify everything they do.