Do meeting cancellations make you grumpy? A not so scientific study.

I work in a role where it’s possible that a meeting can happen anywhere in the 24 hour of a day. In general people work together to respect people’s working day, but there are times when a meeting at an anti-social time is unavoidable, that’s accepted. What makes me grumpy, though, is when these meetings are cancelled or postponed, particularly at short notice.

Yesterday evening I finished my normal working day with the expectation of joining a teleconference at 8:00pm. When I had started my break at 6:00pm I had already attended a preparation meeting with the full expectation that the later meeting would go ahead. Still expecting that the meeting would go ahead I retreated into my small study at 7:55pm ready to connect, but in the 1 hour 55 minutes I had been offline the meeting had been reschedule to a later date. I was a bit grumpy, I wasn’t a lot grumpy, because I had some expectation that this would happen. Why was I grumpy?

This experience got me thinking; if the notice of this postponement had come to 6:00pm I would have been delighted. The timing of the cancellation/reschedule made all the difference to my response.

I wondered whether I could create a model, or an equation, to understand this phenomenon, something that would help us to empathise with others in different time zones attending a meeting.

First step, create a chart of grumpiness/delight for a typical meeting cancellation based on time of the meeting and notice period given:


How grumpy/delighted am I if a meeting is cancelled, based on how much notice I was given?

The first observation is that most of the points on this chart are actually ranges that depend upon the type of meeting and the importance of the meeting that is being cancelled or postponed. If a meeting is at an anti-social time, but I don’t think it’s important, I’m not likely to attend anyway. If the meeting at an anti-social time is critically important to progress another activity and is postponed I’m likely to still be a bit grumpy even if I get good notice of the move. Imagine that this charge represents a moderately important meeting that doesn’t represent anything that is time critical.

There are some interesting aspects to this chart:

Good notice can bring delight

If you give me good notice of a cancellation for a meeting at an anti-social time I will be delighted that it’s been cancelled. The reverse is also true, give me poor notice and I’ll be especially glum. If I know before the end of my normal working day that I don’t need to interrupt my evening with a work commitment I’ll be very happy, thank you. If I interrupt my evening, or even my sleep, to attend something that I then find out that I didn’t need to attend will make me sad.

The later it gets the more notice you need to give

There are degrees of anti-socialness, evenings are different to very early mornings but for each of them you need to consider how much notice you might need to give. The danger here is that the more anti-social it is the more notice you need to give; giving 2 hours of notice for a 2:00am meeting isn’t helping anyone.

12-hours notice may not even be enough

Even with a 12 hour notice there is still a window for grumpiness. Assuming that I finish my working day at 6:00pm and don’t check in the evening, the postponement of a meeting scheduled for 7:00am the next day will still make me a but grumpy. I’m normally awake about that time, but attending a meeting at this time will be outside my normal routine, which I’m happy to do as long as there is some value in doing it. Interrupting the normal routine and having nothing to show for it it frustrating.

Zero notice is nearly always going to make me grumpy.

While it’s not always possible to give people notice of a cancellation giving zero notice is always likely to lead to a level of umbrage. If you have some notice you have a chance of re-planning your day, zero notice takes away that possibility.

Lunch is a special condition

Cancellations for meetings that happen around lunchtime are a special condition in the model. Meetings at mealtimes are themselves anti-social, there’s a less marked impact, for me anyway, for breakfast and dinner, but messing about with lunchtime makes me grumpy. Treat that meeting at 12:00pm to 12:30pm with special care.

The end of the normal day boost.

The end of the normal working day is another special case. This is the one time I’m likely to a little peak of delight that a meeting is cancelled with zero notice. Strangely I feel more delighted about a meeting cancelled at the end of the working day than one postponed in the evening.

Having looked at the chart I concluded that there probably wasn’t a formula for this. I also concluded that there were several other factors that influence my response to a meeting postponement or cancellation:

  • Day of the week – a Monday looks different to a Friday.
  • Time sensitivity – how do I feel if the results of a meeting are needed for a time critical activity.
  • Social impact – what I am doing outside of the normal working day makes a huge difference, especially if I have chosen to forego a personal commitment in favour of a work commitment that then doesn’t happen.
  • Reasons for meeting timing – there are very good reasons for some meetings happening at anti-social times, the reasons are not as clear for other meetings.
  • Expectation of postponement – there are some meetings that give me, for various reasons, I have a high expectation of change. My response to these meetings differs.
  • Overall meeting-load – there are regularly situations where I need to choose one meeting over another. Getting short notice of cancellation of the chosen meeting can lead to high levels of frustration.
  • Family and cultural routines – some people’s chart for the anti-social hours would be very different to mine and that signifies their family and cultural routines. I tend to regard early evenings as easier than late evenings, people with younger children probably see this the other way around.

In short, there isn’t a simple formula to work out what my, or someone else’s, response to a reschedule will be, but giving people as much notice as possible is an excellent working practice. Avoiding zero-notice cancellations should be very high on meeting organisers objectives, especially at anti-social times.

More Features = Lower Utility: Watching the TV

Not all change, is change for the better. We may get more features, but do we get more utility.

Then:

Once upon a time an evening at home was a simple activity.

Having completed the necessary activities it would become time to watch the TV. There was a simple choice available from a few over-the-air channels, the choice was tiny, but I don’t remember ever being lost for something to watch.

Deciding on which of the four-way choices to watch meant opening one of a number of magazines to see the now and next options. The lack of choice made this easy.

The transition to the main event – watching a programme – took a few seconds.

There was only one screen to watch and we all watched the same thing.

Now:

(Last night to be precise)

Having completed the evening’s activities we sat down and decided to turn on the TV. In our current configuration we also need to turn on a companion box from the local cable company. The list of available programmes is staggering and we scroll through the list for a few minutes before settling on a particular channel.

Once that programme had finished we again scrolled through the list of available channels. Not seeing anything we particularly wanted to watch we scrolled through the list of available programmes that the companion box had decided to record for us. I used to know why this box recorded what it recorded, but it’s evolved to have a level of free will while it’s been with us and now chooses which programmes to record for itself. I considered moving over to one of the streaming services, in order to gain further choice, but these run so slowly on this box that the wait is excruciating for a brain that has been conditioned to expect immediate gratification.

Returning to the list of available programmes we settled on something that would get us through to bed time.

We were tired though, and decided to move our watching to the screen in the bedroom after a few minutes. The channel we were watching was one that was also available over-the-air from that screen. Unfortunately there was a problem with the over-the-air signal and all we got were a set of occasionally moving blocks and an intermittent soundbite. This is a recent problem which I had forgotten about, other channels are fine, but this one is unusable in its current state. A false start, but I wasn’t going to be defeated.

That’s OK, I thought, we can do this a different way, this screen has one of the popular streaming devices available to it and there’s an app for the channel that we were watching.

Switching over to the streaming device isn’t as easy as it may sound because I need to get out of bed to plug it into the back of the screen. We remove it occasionally because it interferes with the over-the-air signal. The streaming box always needs restarting in this situation, which takes a few minutes.

Thankfully the streaming box didn’t do the optimisation thing that it decides to do at the least convenient times. It clearly took pity on me because it knew what was about to come.

Once the streaming box had started I navigated to the appropriate app for the programme we wanted to watch. Like many of these apps this one has recently started asking me to authenticate myself. Authentication was to be done via a URL and a supplied PIN code. One of my evening rules is to leave my smartphone downstairs, so out of bed I get and retrieve the required touchscreen interface. Before I could enter the PIN I needed to authenticate to the web site via the URL. Having tried to log in with the email address that I use for such things I eventually conclude that I haven’t previously registered for this particular app – so I registered. Registering also meant validating my email address via an email notice. Having jumped all of the hurdles I entering the PIN and gained access to the app. The end was starting to felt like it was within reach.

Once I was within the app I used the search interface to find the particular programme. I don’t know how these apps decide what goes on the front page, but it never reflects the programmes I watch. Search on these apps is never that good, particularly as you need to enter the characters via a remote control interface a letter at a time – left-left-left-up-click-right-right-down-down-click-right-right-right-right-right-right-up-up-up-up-click.

Eventually the programme I was looking for showed up in the search recently, all I needed to do now was to decide which episode we had been watching. Thankfully, I picked the right one straightaway, but how far through were we? Time to fast forward, which highlighted another challenge, this particular app didn’t show a preview of where you were, so I just had to keep guessing. Another few minutes lost.

More than twenty minutes later we were back to were we had been before me made the journey up the stairs.

This isn’t the only app like this though, there are at least six different ones on my streaming box and each of them requires a different authentication. One of them loves to forget my credentials and it’s almost become routine to enter my details every time I use it.

I haven’t worked it out but between 15% and 20% of my viewing time last night was taken up with navigating the technology. Yes, I have access to unbelievable amounts of content but why does it have to be so difficult to watch a programme? Was the programme I fought to watch worth the 15% to 20% tax – no.

Running in Dark Mode all Day

It’s likely that most of the apps that you use have a white (or light) background with black (or dark) text. It’s also likely that the operating system capabilities that you use also has this configuration.

This is the default after all and why would you change it?

You may have gone to the effort of changing the colour scheme a little, but it’s probably still got a light background and dark text.

I’ve recently taken the step of reversing this on many apps and some operating systems as a bit of an experiment. My screen world is now predominantly dark – dark background with light text.

Why? There are a few reasons, but mostly it’s about personal taste and visual preferences:

  • Eye Fatigue – When you are looking into a screen you are looking into a light. It may only be a low intensity light, but it’s still a light. Using dark mode reduces the amount of light and hence, hopefully, the levels of eye fatigue. Some people claim a scientific justification for this, but the research I could find was quite limited. I find it easier on the eye and that’s good enough for me.
  • Reduced Blue Light – Of the light that your screen is emitting the blue light is probably the most destructive. It’s thought that this type of light impacts our ability to sleep, and that we should reduce the amount of blue light before we go to bed. My logic goes like this, if I don’t need it in the evening, why would I need more of it than my surroundings are providing it in the daytime?
  • Readability – This is a subjective one, I find light text on a dark background easier to read.
  • Reduced Distraction – Using dark mode reduces the intensity of many of the interface elements. Things like window borders and app icons are not as highlighted and hence grab less attention. At the same time, the elements that I am working on – the words and diagrams – stand out more and draw my attention.
  • Reduced Power Consumption – This is a tenuous one, dark mode uses slightly less power to light the screen and hence it improves battery life on a device. I suspect that the difference here is marginal, but what it has allowed me to do is to lower the light levels on my iPhone extending the battery life by a little.

There are some drawbacks though:

  • It’s not the Default – Because Dark Mode isn’t the default for operating systems or for applications, you have to choose it. My experience has been that some applications will take the preference from the operating system, but not all of them will. Some apps provide an option which you then have to find.
  • Web Sites – The real challenge is web sites, it takes far too much effort to switch over to dark mode in each of these. I’ve tried a few plug-ins for browsers, but have concluded that the glitches are worse than just letting the web sites display in light mode.
  • Mixed Mode – Because it’s not the default it’s not always possible to work in dark mode in every application, and certainly not on every web site. The challenge with this is that you then get the rather jarring experience of switching between an app that is in dark mode and another that it in light mode. On balance, though, I think I prefer this experience to the default one. I’d call myself a lightweight dark mode user.
  • iOS Dark Mode – My primary smartphone is an iPhone. The iOS interface doesn’t really have a dark mode. You can use the accessibility features to invert the colours which is supposed to be smart enough to only invert the colours of the text, but it also has an annoying habit of inverting the colours of all of the images. Having said that, once you switch apps to dark mode it’s surprising to realise how little of the actual iOS interface you see day to day. Yesterday, Apple announced that iOS 13 will have a dark mode.

All I need, now, is for each of the apps that I use to give me the option to change, or better still, to take the default settings from the operating system. I suspect that web sites are always going to be, by default, in light mode, but perhaps a time is coming when they will pick up the correct mode from the browser that is being used.

As part of this experiment I’ve switched this web site over to a dark colour scheme and even there I’ve had some glitches to deal with, some of which still aren’t resolved.

Many people see dark mode as a way of making the nighttime visual experience better, but I’ve been using dark mode all day every day. I started this as an experiment a few weeks ago, I wasn’t expecting it to make much difference, but it has made a far greater difference than I was expecting.

I’m not advocating that everyone moves because I think that it’s primarily an issue of personal preference, but you might like to give it a try.

Header Image: This is Traigh a Bhaigh, Vatersay in the Outer Hebrides. Apparently this is how you park a boat around here.

“That doesn’t sound very agile?”

I’ve heard this phrase a number of times recently. The normal context is this:

  • Manager: “I must have the important widget for ABC Corporation by the end of the week.”
  • Product Owner: “Why?”
  • Manager: “Because we promised it to them last night?”
  • Product Owner: “I’ll have a look at the current work in progress and discuss what we can do with the team in the morning stand-up meeting. Because this is a new item, not in the plan for the current sprint I’m not sure that we can do anything by the end of the week.”
  • Manager: “That doesn’t sound very agile?”

There’s a miscommunication here. What the Manager has said to the Product Owner makes no sense to the Product Owner because what they have heard is “Well, that doesn’t sound very Agile?” with a great big capital “A”. What the Product Owner has defined IS Agile, it may not meet the Manager’s expectation of agile, but they are different things.

See: Office Speak: “Agile with a capital ‘A’” and “agile with a small ‘a'”

Somewhere along the road Manager Types have picked up the impression that they can ask Agile Teams to do whatever they want and it will be done at the drop of a hat. In their understanding Agile equates to “no planning” when the reality is that Agile means “planning differently”.

I suspect that this impression of Agile as ultimate flexibility is derived solely from the name and not from any study of the practices of Agile. In many situations I suspect that the Manager Types haven’t done any training on Agile and are simply fab-surfing with the hope that the latest fad will, at last, be the answer to all of their problems. What they haven’t realised is that Agile will only be an answer to some/many of their problems if they engage and embrace it, and to do that they need to understand it.

Document Driven v Data Driven

I’ve recently been thinking a lot about forms. Why forms? Forms give us fascinating insights into that way that organisations work.

A Life of Forms

We are surrounded, some would say inundated, by forms:

  • Banking runs on forms.
  • Insurance wouldn’t survive without forms.
  • Most organisations have thousands of ad hoc forms for various diverse purposes.
  • One of the worst things to happen in some organisations is that a situation arises for which there is no form.
  • Visit a medical professional and somewhere within the dialogue a form will become necessary.
  • Subscribe to any service and forms will be used as part of the contracting process.
  • Start a new employment and you are likely to spend much of your first day completing forms.
  • Our birth and our death are accompanied by forms.
  • How many times a day do you complete a two-field form in order to gain access to some technology.
  • Interact with a government organisation and a form will be required.

Sometimes these forms are online, web page, or even forms on mobile devices. There are still, however, many situations where forms are completed with a pen. How many hours have you spent trying to complete a pseudo form that was sent to you as a Word or PDF document.

Document Driven Business

There are many PowerPoint decks, Excel spreadsheets and Word documents that are in essence forms. They are created from a template that sets the titles and contents of each slide/worksheet/section. The person completing them is expected to say certain things in certain ways, just like a form.

  • This first slide has the title on including the reference number, person presenting and target date.
  • The next slide has the required content on and only this content.
  • The following slide will explain what it is you are going to do.
  • The penultimate slide will outline the business case in the supplied table.
  • The final slide will contain the risk register, using the supplied table headings.
  • No other slides may be added.

It’s a form, isn’t it?

A Form to Transact

Each of these form-types exist to support a transaction:

“Once you have completed sections 1 to 5 and 8 of the loan application form we will proceed to the next phase of you application.”

“You are required to complete a tax return of which sections a to e are mandatory.”

“We’ll proceed with your project once you have provided the project initiation template document.”

The boundary of the transaction is defined by the form, without the form nothing moves forward, or backward.

This way of working produces a number of effects:

  • Over preparation – in order to make sure that a transaction can complete documents tend to be over-worked. Many hours are spent making sure that every detail in a form/document are correct to a level of detail that is not required to move onto the next phase, but everyone strives for perfection to avoid rework at all costs. A small amount of over-work is compounded as a process is worked end-to-end. Imagine how much work goes into producing a set of 40 document? Add a little bit of over-preparation to each of them and the amount of effort being expended is huge.
  • Over-stating – The over-preparation of documents often includes over-stating, where things that aren’t required in the document are stated in the document “just-in-case”. The problem with this superfluous information is that it becomes part of the record and is then used by people who make decisions despite its heritage and trustworthiness.
  • Point-in-time perspectives – The information in the form/document was mostly correct at a particular time on a particular day, but that’s all that can be said about it. Any perspective that is taken on that document is locked into the context at that time. The information in the document isn’t being refreshed, it was completed, a transaction took place and now everything within the document is, at best, history. Yet, people will continue to refer back to it as information way beyond the valid life of the data contained within it. The reality is, even before the document is concluded the data within it will be out of date.
  • Action blocking – A form/document represents the end of one activity and the start of another – a phase-shift. The next phase can’t start until it has received the information from the previous phase. Even if an element of the next phases has all that it needs to proceed it can’t until the transaction has been agreed. Consider how many actions are expected to be undertaken following the transaction of a 100 page document? How many of those actions could have safely been undertaken way before the transacting of the document?
  • Phases based on documents – The definition of a document as the point of transaction means that production of the document often becomes the definition of the phases/stages of an activity. This way of planning has little to do with the amount of effort involved, or the value being produced, it just represents a transaction. An activity that only exists to produce a document is a bad activity.

Data Drive Business

Let’s turn our attention to data-driven activities.

The document has been with us for thousands of years, but we no longer need to work at such a coarse level. The information that is placed into a form was not generated by the form. A form is just a place to consolidate information that already exists elsewhere. When you are asked about your date-of-birth in a form you are simply recording information that has existed, for some of us, for many years. So why not link the data directly with the intent for which it is needed. Why bother placing a date of birth on a piece of paper when one system could ask another system whether I’m older than 18 and get the correct answer back.

There are situations where data isn’t enough and a set of information may need to be brought together to tell a particular story. Imagine a design for a network topology, the design may be the first time that it’s been outlined. This isn’t to say that in this situation a document is required, it’s just to highlight that an intermediate step from current state to future state may be required to fill gaps in the data. Even in this network topology example a diagram with meta-data is probably sufficient to communicate the change being proposed and for people to agree to transact. Once the change has been implemented the diagram is no longer required because the current state information becomes the record.

Taking the network topology example even further, the need for a human-readable design demonstrates a gap in policy and understanding. If the change could be codified in a way that a policy mechanism could understand and assess, then the change could have taken place without the need for a diagram. If, as an example, an application needs to add more resources to the network, the network would respond on the basis of the data provided and the policy defined. Likewise, once those resources are no longer required the policy engine would turn the resources off. All of this would happen before someone has filled in half of the “necessary” paperwork.

Our job, as humans, should be to assess and define the required actions for the exception, for those situations where data and policy is not sufficient for a decision to be made.

Time for Transformation

For much of the life of IT may applications have been little more than form replacements and that has given us some productivity gains. In many ways we are only just at the beginning of a transformation from a world driven by documents to one driven by data  This will require a profound change in the way that we think and act.

Organisations that continue to rely upon forms (including apps that are replacing forms) will be overtaken by the machines.

Header Image: This is one from a recent morning walk along the lanes near my house. I’ve always loved the shapes of tree skeletons in the winter.

Navigating in the Mountains, Using the Right Technique for the Conditions – Testing an Agile Analogy

One of the joys and challenges of being human is that we communicate and understand differently. Some people prefer numbers and facts, others need a picture or a story. Art exists in many forms because it helps us to break through and communicate.

I’ve been trying out a new analogy recently and wanted to expose it to a broader community to see if it resonated. I’d love to hear your views.

One of the joys of my life is a day walking in the hills. There are various skills that that you need when you are out in the hills, perhaps the most important being navigation. I call navigation a skill because it isn’t a method, it’s a collection of tools and techniques that you need to apply in the right situation to get the right result. The tools and techniques that you use on one particular day, or even during a specific hour, are influenced by several factors, including:

  • Visibility – How far can you see?
  • Local knowledge – Do you know where you are going? Perhaps you’ve been there before?
  • Terrain – Is there a defined path? What are the hazards ahead, or to the left or right?

If visibility is good; if there’s a defined path and you are walking a route you’ve walked many times before you join the chosen path, look ahead and walk. Navigation is straightforward and doesn’t require you to spend all of your time looking down at a map. When things are really good you can even see places where the journey could be improved by taking a slightly different route or by taking a shortcut.

This approach is fine until the factors above change. Clouds roll in causing visibility to drop to a few metres and you arrive at a point where the defined path becomes less distinct and the terrain becomes indistinct. At this point the navigation techniques need to change, it’s time to get the map and the compass out.

For anyone who hasn’t used a map and compass in this situation what you need to do is to take a bearing. This video shows you how to do that:

Further details here.

The important point is right at the end of the video:

  • Take a bearing,
  • Pick a landmark that you can see,
  • Head to that landmark,
  • Take another bearing at the landmark,
  • Repeat until you get to the point where you are wanting to go.

Unless you are a very skilled navigator and there are lots of visible landmarks it’s not likely that this approach will get you directly from A-to-B, but it will get you there. Even if you could navigate on the direct route it’s likely that there will be obstacles in the way that will cause you to stop and adjust. Navigating this way is slower than when conditions are good, taking a bearing takes time and diversions cause extra work.

The key skill in this approach is to take bearings often enough to keep you focused on the end goal, but not so often that you are spending all of your time taking bearings. The length between bearings depends upon the amount of visibility and the available landmarks. If you can only see for 5 metres, then that’s as far as you can navigate. The last thing you want to do is to pick a landmark that is itself out of sight, that’s a recipe for disaster because you are likely to miss the landmark in the mist and plunge yourself into a situation where you don’t know where you are on the map. Relocating yourself on a map is another skill, slowing progress further.

Some days you start out on a walk where visibility is good and you have great local knowledge but that situation can change rapidly. That’s when the approach needs to change to match the conditions.

Projects, particularly IT projects, are journeys from one place to another. The methods that we use should be dependent upon the conditions, that’s where this analogy comes in. Agile is fabulous for those situations where it’s a bit foggy and the path isn’t clear. Take a bearing, pick a landmark and then sprint to it, then take another bearing. Lean isn’t great in the fog, but is the fastest way of making progress when conditions are good. Even in a Lean situation you may still want to define some interim goals to maintain motivation but you’re not changing the path or the destination just because you’ve reached an interim goal. Even if you think that the road ahead is clear and you can follow tried and tested routes doesn’t prevent the conditions changing and a different type of navigation being required.

Like all analogy this isn’t a perfect picture of the different approaches, but it’s helped most of the people I’ve described it to. Does it work for you?

The 5 Phases of a Reply-to-All Storm

Reply-to-all Storm: The set of events that occur when a group of people decide that the appropriate response to an email is to reply-to-all. In nearly all of these situations the replies add no value other than to fill-up the email account of everyone on the distribution list.

I’ve observed many a reply-to-all storm and it occurs to me that they have a set of phases to them, have a missed any?

Phase 1: Initial Contact

I’m not sure quite what the anatomy of an email needs to be to start a reply-to-all storm but there are some characteristics that will increase the likelihood of a storm starting. Emails with a pointless subject and equally pointless content are my favourites, they create a response in certain people that is completely disproportionate to the initial contact. It’s rare that a reply-to-all storm is generated from a meaningful email.

I’m pretty sure that the likelihood of a reply-to-all storm increases exponentially with the number of recipients on the initial distribution. Emails to 500 people aren’t likely to result in a storm, emails to 5,000 people have a much higher probability, correctly crafted emails to 50,000 people are almost certain to result in a storm.

Phase 2: Initial Reply

Someone has to be the person to start the storm. Much like a firework requires an ignition a reply-to-all storm requires someone to get everyone started. It helps if the initial reply is as benign as the initial contact.

The purpose of the initial reply email is to create a release valve that gives everyone else permission to participate in the storm. A single drip doesn’t create a flood, but it does make a pathway for what is to follow.

Phase 3: Engage the Pack

Two emails do not constitute a storm, but that’s all that the pack requires for those who are going to participate to become engaged. The pack, in general, only have one response which may use different words to these, but they are basically all saying the same things:

  • “Why was I sent this email?”
  • “Stop sending me these emails.”
  • “Remove me from this distribution list.”

None of the individuals involved in the pack realise the irony of their actions.

By this point most people have disengaged by clicking “Ignore” or “Mute” in their email app but this is where volumes come in, all that the storm needs to continue is one more person in the cohort to keep it going.

Phase 4: The Anti-Pack Becomes Engaged

The anti-pack’s role is to keep the reply-to-all storm going by telling people to stop replying-to-all. We are now in double irony territory.

These emails come in various grades depending upon the frustration of the recipient. This appears to be one of the few occasions where it has become acceptable to use capital lettering in an email subject. The use of the words “IMPORTANT”, “URGENT” or “STOP” become prevalent as does the use of bold, coloured and enlarged content all saying the equivalent of “please stop”.

Phase 5: The Die Down

Thankfully reply-to-all storms rarely last longer than a day, in my experience. You can sometimes get someone who tries to restart it the following day, not realising that everyone has already left the party, but that rarely does a restart result in a full storm emerging.

As quickly as they come, they leave.

Avoiding the Reply-to-all Storm

People have talked about getting rid of this problem for decades and yet it still persists, you may be wondering how we stop it. The simple answer is that you can’t because the instigator of the action is that weakest link in most processes – the human. You can do many things to avoid it, but stopping it altogether requires humans to behave in a logical way and that’s not going to happen.