It’s only fitting (I actually find it a bit comical) that I should begin writing here with such a topic. Being in a state of crisis can sometimes be hard to identify, but once seen, it cannot be unseen. Its nagging signs and confirmations immediately begin to get in the way of productivity and even sanity. Feelings of hopelessness, indifference and carelessness begin to show and the hopes for a brighter future can sometimes fade. This article is taking more of a methodical approach to finding leadership in crisis situations, as well as providing tips and ideas on how to better prepare for such unpredictable future circumstances.

---

Note: The topic of crisis situations is very broad and though it may be helpful elsewhere, the information provided here is primarily focused on software engineering. This article was originally published on Medium.

Times of crisis

One of the definitions for crisis in the Merriam-Webster Dictionary that I find particularly applicable is:

an unstable or crucial time or state of affairs in which a decisive change is impending

But being in a state of crisis is really quite a subjective matter. It is up to the individual, team or organization to identify it (even if this means getting external help). So how do you come to the conclusion that you or your organization are in fact in a state of crisis?

Identifying a crisis situation

Several factors should be considered when assessing a situation. In my experience, the below listed groups are the most fundamental ones to consider when analyzing a situation. Bear in mind that the individuals or team performing the assessment, do not necessarily need to be those who remedy the situation.

Urgency and time constraints

There are usually two overarching types of crisis situations.

One that cannot be predicted or warranted — e.g. computer failure, dependency system being hacked or taken down for an unexpected reason, etc. To put it into perspective, some of these events or situations usually end up causing the 1% out of a typical 99% uptime SLA (Service Level Agreement) 1.

The signs are there all along, but due to one reason or another, they’re either not taken into consideration, or no action to prevent the crisis is performed — e.g. there is an expected hike in application usage during a particular upcoming shopping season, but the organization responsible for said application does not take the necessary steps to prepare for it.

The main difference between these two types is time before “a decisive change is impending”. Time to both make a decision whether the event is in fact a crisis, and time to decide how to act (this includes the decision to ignore).

Impact and escalation potential

I think the name says it all, but I’ll list some common questions to help determine the severity:

• Is the crisis life threatening or business threatening?
• How many clients are affected?
• What is it going to cost us and what are the running costs until the situation is mitigated?
• How visible is the crisis? Will it hurt our brand and in what way?

Uncertainty and lack of direction

This type of crisis is usually hard to identify mostly because it is predominantly related to leadership in the organization itself or current state of business or industry. It is not unusual to see here signs of the Stockholm Syndrome in team members, which makes it extra hard to stop and clearly assess the situation. What I’ve found works here is to always focus on data and perform a data driven crisis identification and decision making.

Finding leadership

We’ve already looked at a few different aspects and signs when identifying a crisis situation, but wouldn’t it be nice if every time during a crisis, a leader steps up (sometimes unknown), while the rest of the team rally behind, and it all just works out? While this situation may sound utopian, it is very much real. Once you scratch the surface, you may find a very fluid team or organization, who has spent significant effort to get there.

The importance of taking action

None of the identifying factors would matter unless they’re actually involved in weighing or remedying a situation. Such involvement is all part of taking an action. And this is really a crucial aspect of what I believe to be the prime quality of leadership.

Taking a decisive action, while instilling trust.

But what makes up such a quality in a leader? There are two aspects here which are very much interdependent — taking a decisive action is related to what is within the leader, while instilling trust is projected outside from the leader towards the group or team. Both of these are tied together and they usually even help each other — e.g. if personal confidence in a leader is low, the team can boost it by supporting and trusting the decision, while on the other hand, if team morale is low, the leader can boost it from within by taking a confident and decisive action.

Experience, confidence and trust

These three qualities are not the only ones which come up when we talk about leadership, but they аre especially important in the context of mitigating crisis situations. But how do you find such qualities in people, so you can get to a crisis resolution with the least amount of damage? You build them.

Positive experiences build confidence and trust

Each situation is unique, but I’ve found that regardless of whether a leader is someone well known to the team or organization and emerges from within, or the leader is unknown and just brought in from outside, positive experiences play a key role in establishing leadership qualities.

A crucial point I’d like to make here is that the individual or organization must establish means to facilitate experiences. In other words, giving people opportunities to both try and even find out where their leadership qualities are most valued. Regardless of whether an experience is considered positive or negative, at the end of the day all experiences give individuals and teams more information on where their strengths and weaknesses lie so they can focus on what makes most sense. This is where ownership and focus area come into play.

Assigning ownership

In multi-crew aircrafts usually more than one pilot capable of operating the machinery is needed. This creates a conundrum as flight controls are operated by only one aircraft pilot. This also called “two pilot problem” has resulted in the development of the pilot flying (PF) and pilot not flying (PNF) concept, which aims to clearly define the ownership of who flies the aircraft at any given time. So what happens during a long haul flight, where the PF wants to take a break? Following the ALC-36: Positive Aircraft Control — FAASafety.gov training course the “Positive Exchange of Controls” procedure is performed:

When a flight instructor wishes the student to take control of the aircraft, he/she should say to the student, “You have the flight controls.” The student should acknowledge immediately by saying, “I have the flight controls.” The flight instructor confirms by again saying, “You have the flight controls.” Part of the procedure should be a visual check to ensure that the other person actually has the flight controls.

While the pilot Positive Exchange of Controls procedure may be considered excessive in a software engineering setting, it is imperative for clear roles assignment and ownership to be performed for each individual. Sometimes these are already established, but crisis situations are often unprecedented. In such cases, roles and ownership may be revisited for the duration of the crisis. Failure to do so usually results in confusion, inaction or even worse — role duplication which usually ends up pulling the team in conflicting directions, causing even more confusion and uncertainty.

In general, all crisis situations are perfect opportunities to facilitate experiences, however, it is important to take into account the severity of the crisis situation and how much risk the team or organization are willing to take.

Lead by example

Here is a plot twist (maybe not for all of you). Leadership is so much more than just leading people or even management. In fact, you don’t need to be leading a team in order to be a leader. More often than not leadership is actually about inspiration and drive. Let’s take for example a crisis situation in which a particular team has been assigned to handle. The team leader can very well help with inspiration, coordination and facilitation in such a crucial time, however, if we select any team member at random, that team member is showing leadership as part of the crisis resolution, whether they like it or not. In particular, the way the selected team member handles their area and communicates with the rest of the team is in fact leadership, which will inevitably contribute to their experiences and leadership qualities.

Recovery

When we discus leadership in crisis situations it is imperative to talk about recovery. The more energy an individual or team spends in times of crisis, the more said individual or team needs time to recover and replenish the energy spent.

What goes up must come down

Spending time and focusing on recovery is arguably the most frequently disregarded aspect of leadership, but I believe also the most crucial one. Take physical training for example, the time spent during recovery is actually what shapes and strengthens the structures, muscles and other tissues, so they are ready to perform again more prepared than ever. In engineering, times of recovery usually help boost morale and trust not only in leadership, but also in the team itself.

Retrospective

A retrospective (also called a post-mortem in some cases) represents a review of the incident, from its occurrence to its resolution. It is paramount that such a review is performed in a safe space with a blameless attitude. Participants in a retrospective usually resolve to everyone involved in the incident, and sometimes stakeholders as well. An effective retrospective primarily aims to improve the readiness and preparedness towards averting potential future crisis situations, but more importantly it can help team dynamics and improve inter-team communication.

Celebration

Celebrating after averting a crisis is vital for several reasons. It primarily acknowledges the hard work, resilience, and teamwork that went into overcoming the challenge, as well as boosting morale and reinforcing a sense of community. This moment of recognition helps to foster a positive culture, encouraging individuals to remain engaged and motivated in the face of future difficulties. It also instills a sense of accomplishment, reminding everyone involved of their capabilities and the importance of collaboration. Ultimately, taking the time to celebrate reinforces a proactive mindset and strengthens the bonds within a team, paving the way to continued success and growth.

The next crisis

Part of the recovery is related to preparing for the next crisis. Depending on how likely it is, and how resilient the systems need to be, Chaos Engineering and other techniques can be introduced. However, a few things need to be kept in mind when preparing or even experiencing the next crisis.

The dangers of the savior complex

I relate this to the Savior Complex syndrome in psychology, though more often than not in a software engineering setting rather than volunteering, individuals or teams are being “voluntold”, mostly because it is easier and “it worked last time”. But repeatedly putting such pressure on one person or team creates a single point of failure. What if the next time a crisis happens that person is on vacation, or on a sick leave? Furthermore, the notion of the Savior Complex has the danger of decreasing the “safe space”, i.e. others are afraid to step up because of failure, or in addition they become disconnected and passive because “we already have a savior”. Future crisis situations are also perfect opportunities to facilitate experiences for other individuals or teams, while of course the severity and how much risk the team or organization are willing to take should be taken into consideration.

Prolonged times of crisis

If we look at physical activity and sports for example, the way the body functions when performing an endurance event (e.g. a full marathon), compared to the way the body functions during a sprint event (e.g. 100m) is quite distinct. The actual biochemistry and energy utilization within the body is very different.

You can either have high output for a short period of time, or low output for a long period of time. But not both.

It is very similar with crisis situations. But what happens if the crisis situation is very long i.e. turning a sprint into a marathon, or it happens way too often and you’re asked to run a sprint again, when you haven’t recovered from your last soreness and you can’t even feel your legs? Injuries happen. In the perspective of software engineering, injuries usually conform to silent quitting, burnout and high turnover rate. So how do you prevent injuries? I’ve found two effective ways:

1. Introduce frequent recoveries. Split the overarching grand crisis into short milestones, each of which is followed by short recovery and recognition periods. But what if your business can’t afford this? Then
2. Introduce individual or team swapping to take on the lead in crisis situations. This is akin to a relay event, where the baton is passed onto the next individual (or team) who handle the next (or still ongoing) crisis. For example, introducing an on-call rota in a team setting to deal with urgent requests or crisis situations can go very far in keeping the team prepared, focused and motivated.

Each organization and team is different and ultimately what will help assess and address a crisis situation is predominantly honest communication.