5 Whys is a blog about technical leadership in the software world.

Dangers of Survival Mode

I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them (lots of factors that create chaos).

The goal of that exercise, where I play the customer, is to win by delivering to the customer what they expect to be delivered.

This does not mean that what was initially discussed as the requested building is what will be delivered. Team leaders are expected to negotiate and try to change their surrounding "reality" by discussing and explaining to the customer what they can and cannot deliver, and negotiate on time, feature scope, or amount of people they can work with to achieve the task.

It's always a very interesting experiment to see how people handle the stress associated with Survival mode.

Survival mode is that awful place where you are over committed and have no time to learn, so you are left only "reacting"; fixing fires, cutting corners, and never really proud of your work.

Many times it is a spiral, since lack of time to do things "right" leads to much more messy fixes, and slower release cycles, since everyone has very little confidence in whatever it is they are building.

So, how do people, even leaders with experience, react under this situation? In a very human way. The most common reactions are:

  • Give up almost immediately. As a customer, I tell them they have x minutes to finish, and not even a hint of trying to negotiate, or saying that this time frame doesn't fit the work. Many accept this time limit as a given even without asking simple things about the scope such as "how big is this LEGO bridge supposed to be" or "which color does it need to be?"
  • Forget to show demos along the way so they can see if they are doing the right thing. Then failure ensues as what I requested and envisioned in my head is very different that what they envisioned.
  • During the work, fail to notice any team bottlenecks. For example people with disruptive behavior.
  • If helping out as part of the team, forget to look at the big picture, such as how much time is left, showing demos, or are there any inherent problems in the way of work.

As a result, many teams fails to give what the customer expected in the time negotiated. And many teams fail to even negotiate a reasonable amount of time, or even notice they are building the wrong thing in time, or at all.

You might say "It's just LEGO." But lots of the same symptoms arise in real life software development (and other types of teams).How many projects have you been to where, on the first day of the project, you knew it was going go fail?

There is a certain release in knowing something like this. It helps you shed any responsibility to the well being of a project, and you feel less accountable.

Here's the problem with that approach, though. Many team leaders are "thrown" into a dire situation, thinking that the whole situation is "a given". A fact of life that cannot be changed. Doomed project? Guess we're screwed then. Nothing left to do but twiddle your thumbs.

No. You are paid to change the situation you're in, and do good professional work. If that's not what you are paid to do, I think you should leave your job. Most software team leaders have options if they started looking, and there are plenty of companies out there looking for people who want to be proactive bout making things right.

So, what are those things that people think are "given" that aren't really most of the time?

  • The time you have to finish the project is not really a given. It is a direct factor of the estimates that you give at the beginning, and as time progresses you can and should ask for more time/ change of scope or adding team members (although that might make the project even later in some cases)
  • The low quality is not a given. You can change the low quality (at least for new work) by demanding it from your team. Don't have time? make time. Re-estimate. Is that scary to do? Guess what, part of being a leader is doing things that are uncomfortable.
  • People's behavior in your team is not a given. You can influence and help change unproductive behavior. Sometimes leaders avoid directly talking to people in their team about unproductive (problematic) behavior. Part of the work. You don't have to be an asshole about it, but you can be direct without being hurtful. People need to know that there are consequences for problematic behavior. You can even ask people to stop contributing, or ask for people to be replaced. Though usually you should try and work on the problem instead of getting rid of people. It will do good for you as well to try and jump into such a challenge, and you will learn a lot from it.

When I Want to Give Up

Ask Royo #1 - Team Leadership and Influence Edition