Skip to main

How to react to the crisis as a software team lead?

by Krzysztof Wasilewski

How to react to the crisis as a software team lead?

In March 2020, thousands of IT professionals all over the world moved out of their hipster offices into cramped apartments shared with frustrated spouses, naughty children, and mean pets. They are all holding their breath, uncertain of what the future holds. Most of us keep asking ourselves: when is this going to be over? When will things be back to normal? 

Others are beginning to realize that things aren’t ever going to return to the pre-pandemic state. The CoVid-induced feeling of uncertainty and doubt grows like cancer, consuming the healthy tissue of self-confidence we once possessed. With every sleepless night, we are closer to the realization that we should ask a different question instead: will we survive? 

Lacking any prophetic abilities, I may not be equipped to answer this question directly for myself, let alone on behalf of others. What I can offer here as a substitute is an analysis of what breed of engineers has the highest probability of survival. By answering this alternative question, we can at least be sure that even if we lose, we die trying. Or we can realize that we’re out of luck, we were only born to become an extinct species, and stop wasting our time trying to achieve what is unreachable for us.

Copy link
Rediscover the wisdom of 1859

In 1859, Charles Darwin laid out the foundation of the modern theory of evolution in his famous work, On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life. Among the several facts and inferences of which this theory consists, two of them stand out in particular as potentially hinting the right answer to our original question.

“Individuals more suited to the environment are more likely to survive and more likely to reproduce and leave their heritable traits to future generations, which produces the process of natural selection.” And “a struggle for survival ensues.” Let’s see how we can extrapolate these evolutionary phenomena from their biological domain into the realm of our IT business.

We are often tempted to apply the simplistic interpretation of the process of natural selection as the survival of the smartest, fittest, and healthiest. This is not what Darwin had in mind. We can clearly read that he was referring to the suitability of individuals to the environment. Obviously, dinosaurs were fit and powerful, and yet they were birds, insects, and tiny mammals that survived the great extinction of species.

What is the environment that we should suit to like in the epidemic era? The only thing we can state with certainty is that it is uncertain, dynamic, and unpredictable. Therefore the trait that we are looking for to ensure our survival is adaptability. We need to adapt to the ever-changing business requirements. We need to inspect and adapt our processes. We need to inspect and adapt our product increment after every sprint. Oh, wait… There is already a name for this. It’s called Agile! So, if we follow SCRUM, we should be safe, right? Unfortunately, this is not good enough, and let me show why.

Copy link
Is SCRUM the synonym of ultimate adaptability?

I have seen a team practicing agile make a very stupid, and almost fatal mistake recently. The whole SCRUM team was working on a product increment (which was scheduled to go to production at the end of the sprint, and not only potentially). An incredibly unlikely chain of communication mishaps between the stakeholders, the product owner, and the development team resulted in a series of misunderstandings that followed. The end result was the wrong premise of one of the user stories, namely that they should launch a new landing page with the default WordPress favicon. 

The team was not new to SCRUM. Conversely, they have been working SCRUM for years. The team didn’t neglect any of the ceremonies. The Product Owner had a conversation with the development team about each and every user story. He worked daily with the business and maintained a perfectly groomed backlog. The Definition of Done was in place, and the acceptance criteria were defined. The only mistake they made was not related to methodology at all. They used terminology, which unfortunately resulted in semantic confusion between various roles on the team.

What would have happened under normal circumstances (even two months ago)? There are plenty of safety mechanisms built into SCRUM. The mistake would have been spotted by stakeholders in the sprint review and corrected at the next opportunity, if not earlier. Later, the team would have discussed in their sprint retrospective how to avoid similar misunderstandings in the future and would have committed to take some corrective actions.

In times of crisis, the end result could have been dramatically different. If the mistake went unnoticed, for a customer frustrated beyond limits by the economic situation already, such a silly mistake could mean disappointment, embarrassment, and contract cancellation. This is not the right recipe for survival.

Copy link
Evolutionary response to the crisis

Where did the team go wrong, then? Darwin provides the answer: “a struggle for survival ensues.” In this case, the team has clearly lost their survival instinct. Feeling confident in the process and its safety mechanisms, they followed it straight into a trap. Did they not have any second thoughts? In hindsight, launching a new brand with the default WordPress favicon is plain dumb. I’m sure they did. They were all very experienced engineers. But relying on the system alone made them come close to the verge of disaster. They must have felt that something was fishy, but no-one dared to speak up, and they ignored the elephant in the room.

The survival in the difficult times we are living today requires a new level of adaptability. We can’t merely follow a process that ensures flexibility for changing business requirements. It won’t cut it anymore. We need to readjust our already agile ways of working continually too. Let’s call it meta-agility. This, in turn, requires not only agile frameworks but agile people first and foremost.

These are the people driven by their strong survival instinct, people who challenge the status quo, and who are not afraid to question the system. It is an essential realization in Darwin’s theory of the struggle for existence that mutual aid and cooperation are consequences of an individual’s fight for survival and not its alternative. Note that Darwin speaks of the suitability of an individual, not a group, in the context of survival. This implies that an organization needs many highly adaptable people to survive.

The pessimistic conclusion from this analysis is that if you’re not an organization whose people ask difficult questions, you will not survive. If your people rely more on the process that protects them than on the primordial instinct to survive, you are doomed. If you have people on board who can smell an odor but do not stand up and check if there is anyone in the driver’s seat, I only have bad news for you. If your guys respond, “I did everything correctly,” when your reactor core is melting, you have good reasons to suspect that this is not your surviving team. A bunch of outspoken troublemakers is who you need.

What can you do if not all your people seem to fit Darwin’s ideal model? Your only hope is that the survival instinct in your team members is not entirely non-existent, but at least dormant. It’s time to awaken. Commence by having them read this blog post. It’s only a 5-minute perusal that can still change your fate.

Copy link
Manager’s survival guide

As a manager of a team that may potentially not survive the great extinction of software shops, the most powerful instrument you can use to separate the wheat from the chaff is your own time spent with your team. If you have been invited to sprint reviews, demos, and planning meetings so plentiful that you had to decline all of them, now is the time to participate.

Keep your eyes and ears open. If you can’t absolutely join in person, send a trusted envoy, or have the team record the session for you. If your organization is using ZOOM for remote work, this is a trivial request. These sessions are often eye-opening. Someone forgot that the demo was today. Another team told the customer that there is nothing to show today, but they will have a better demo next time. Or a team member didn’t show up for the demo session with a client, citing unspecified important reasons.

All of these are objectionable even in times of peace with a tendency to happen from time to time. During a crisis, such behaviors should ring the alarm bell instantly. Taking immediate disciplinary action against individuals demonstrating such conduct may be premature and should call for a closer examination first. Still, it is a telltale indication of your team not performing in the survival mode.

Losing credibility in front of a client, or offending them with a no-show at the very moment when the client is counting every penny they could save, is extremely dangerous. The cost of acquiring a new client to replace a lost one is skyrocketing, and the chances of succeeding in this pursuit are getting more narrow every day. Even the spontaneous demonstration of a product increment or an ad-hoc sprint review is like asking for trouble these days.

I highly recommend having a script, with a clearly defined role for every team member who would be demonstrating. I very much advise against any sort of manager presenting on behalf of his team. In essence, this doesn’t ever communicate the same level of engagement and togetherness as a proper demonstration by the development team. Rehearse by conducting an internal dry-run before presenting this to the client. 

If in any of the reviews, you discern the aforementioned undesired behaviors, your next step should be to determine why they are occurring. You are acting as if you were fighting for your life, and are flabbergasted when many other people behave as if life is going on as usual. I can offer a few possible explanations. 

1) You didn’t communicate the gravity of the situation to the team clearly. Surely, you may be under the impression that it is a well-known fact that the economy is in turmoil. And that we should all adjust our ways of working. But you will be surprised how many people focus on the medical side of the pandemic news and try to avoid the psychological discomfort of thinking about how the virus affects the IT business. The restaurants, airlines, shopping malls are in trouble, but how can the IT industry be?

Aren’t we the ones who are supposed to save mankind by providing an online substitute for the physical world? It is astonishing how many people still fail to recognize the invisible connections between industries. Many don’t realize how easily a hiccup in the retail sector can trigger a chain reaction that will make a few software consultancies go belly up. It is your job as the manager to make sure this fact is clearly grasped by everyone.

2) People are still living in a dream world where the business people take care of the business, and technical people do take care of the technology. In other words, “I’ll keep doing things as before and keep my fingers crossed for the business folks to ensure we keep getting enough deals.”

Our search for adaptability will definitely not be appeased with this mindset. Our business is my business is the belief that you, as the leader, should instill into your team. Call for a meeting and explain that. Set the brains of your organization into the struggle for existence mode. Don’t settle for a single session. Keep enquiring and monitoring until you are absolutely sure they’ve got it. 

3) There is always a particular population of people who just don’t give a damn. They will not get it no matter what. Regardless if their minds are unable to comprehend the message you are conveying, or they are not willing to put their hearts into work, these are the people whom you don’t want on your team. Perhaps if times were better, their presence would be tolerated because they were somehow bringing profit for the company.

Under the current circumstances, they will do more harm than good. Not only can they bring down their own project, but they can also influence others by spreading undesired behavior patterns. Even worse, people watching their conduct may infer a false sense of security. “If others are acting as always, then perhaps things aren’t as bad as people say?”

You must make sure that your team understands very clearly that things are not at all healthy. This apprehension is the prerequisite for the survival response to kick in. Don’t waste any opportunity to demonstrate that sloppiness or indifference has no place in your organization.

Copy link
Summary

The recommendations I presented in the preceding paragraphs may be challenging to implement in practice in an organization that hasn’t mastered the art of scaling its culture yet. In a tiny company, you may be able to take care of this all by yourself. Still, in a larger one, you will need the whole chain of command to give everyone’s best in terms of soft skills to really apply this knowledge throughout all departments. It’s going to be as strenuous, if not more, than executing the technical part of projects flawlessly.

The time is not on our side, and we need to prepare for the worst on very brief notice. The financial cushion that companies had will run out within 3 months on average if they start losing their accounts. Changing the culture of your organization takes years. Can your team beat the clock?


IntroductionArticle

Related Articles