Chapter 4. Dealing with survival mode

This chapter covers

• What survival mode means
• How to get out of survival mode
• How to utilize command leadership

Survival mode (I sometimes also call it the survival phase), where I think most teams are located these days, is what I define as “not having enough time to learn.”

Are you in survival mode?

If your team is constantly chasing its own tail and putting out fires, instead of having time to sit down and experiment, learn new things, and apply them in a manner that makes them stick, then you don’t have enough time to learn.

Can you send your team to a unit-testing course for a few days? Maybe. But when they come back, how much extra time do you provide for your team to apply what they’ve learned at a slower pace of development (also known as deliberate practice)? Twenty percent more? Not nearly enough. As I’ll discuss in this chapter, 20% won’t begin to address the need. In fact, 200% to 300% more time is the minimum you should allow.

By not creating this extra slack time, you put your team back into survival mode. They will spiral back into old habits because of the constraints put on them.

The survival comfort zone

As chaotic as survival mode may sound, I’ve observed and sometimes experienced that it’s quite easy to stay in this mode. In fact, as annoying as it may feel to always chase and put out fires, many people seem right at home with this stressful state of mind and are comfortable with such a role—staying up late, fixing that build, fixing that late-night bug—being a hero of sorts.

For some, being in a constant state of survival mode and fixing things that should have already been fixed is within their comfort zone. Within that zone, they know how to operate and what others expect of them, and, most importantly, they know how to succeed in this cruel world. In fact, they excel at working where others feel terror or want to quit. They excel at putting out fires. It’s what they do.

Survival mode is a warm and fuzzy place where only those who have painfully learned how to handle things properly can tread without fear and walk between the pitfalls. Always within a hair of failure, they magically come, tired and fuzzy-eyed, out of the fog of war, saying, “It was tough, but I got it working.” That warm and fuzzy feeling of knowing what should be done when the crap hits the fan serves to perpetuate survival mode.

Even more worrying: survival mode perpetuates itself. When we’re in survival mode, we tend to stay there and not even attempt to get out. It’s a sort of addiction cycle.

The survival mode addiction

We convince ourselves that the current course of action (putting out the fire) is the only one that can make us feel better and help us through the current situation.

For example, we’re faced with a dilemma: fix a fire or refactor the code (improve the quality and maintainability of the code without changing its functionality) to prevent the fire from flaring up again. What do we do?

We convince ourselves that putting out the fire now will let us rest a bit in the near future, and we fix what aches the most. The next time this dilemma occurs, though, we remember that the last time we had this dilemma we made a choice that made us feel better immediately. We turn to that choice again.

This addiction cycle of repeating something that only drives us further into the abyss can only be broken by

• Realizing that we are in such a cycle and that we are over-committed
• Finding the courage to break the cycle by taking a risk and removing some commitments

Next, you’ll see what steps you can take to get out of survival mode.

Getting out of survival mode

To get out of survival mode, you have to worry about one thing: creating slack time as a standard in your work process. To do that, you’ll need to remove some commitments, and that’s unfortunately a risk that many team leaders are afraid to take. If you also are afraid, here’s something I read in Jerry Weinberg’s book Managing Teams Congruently:

If done well, management is a tough job, which is why the pay is premium. However, there will always be those managers who want to get paid for the hard parts of management work without doing them.

That’s an important lesson to those of us who choose the path of leadership.

But what if you do create slack time? By creating slack time, you can start using it to practice new techniques, and, by definition, you’re no longer in survival mode, but in learning mode, which is what the next chapter deals with.

How much slack time do you need?

The book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, by Tom DeMarco (Broadway, 2001), talks about learning-time productivity being up to 10 times less than normal productivity.

If you’re learning test-driven development (TDD), for example, that could mean that for a month or two, your developers might be up to 10 times slower implementing the same number of features because they need to experience writing them in an unfamiliar test-driven way. It might not be that bad for other types of learning, but you must be prepared for the many hours you will need to allocate away from other work.

If you can’t accommodate for learning, perhaps you’re in survival mode.

Making slack time—required actions

How do you drag your team by the hair out of survival mode to begin learning? You can start by understanding the mess you’re currently in.

Find out your current commitments

Making slack time is about getting rid of some of the commitments you already have; you can fill up that time with valuable learning experiences. To know which commitments you want to let go of, you have to start by finding out what you’re already committed to. One of the simplest ways to do this is by hanging up a task (dry erase) board on a wall. Put on that board three simple columns:

• A to-do column, which will contain sticky notes of tasks that await action over the next month
• An in-progress column, which will contain sticky notes with tasks currently in progress
• A done column, where sticky notes that list completed tasks will live

Also, make a special area on the board for sticky notes that you will be removing from the to-do and in-progress columns in favor of learning time.

Round up the team, and ask each person what they’re currently working on, even if it’s not written anywhere. Make sure to put a sticky note for that in the in-progress column. Go through the tasks for the next month with the team and make sure you didn’t miss anything. When you’re finished, you should have a clear (and often gloomy) picture of what’s happening.

Find out your current risks

Now it’s time to see what hidden things might be holding you back. One technique I recommend is called future memory. Assemble the team, and ask a simple question: “Imagine it’s six months from now, and our project has failed completely. Why did it fail?”

If your team feels comfortable enough with you, be prepared to hear some things that might surprise you. If you don’t hear anything surprising, this would be a good time to have private one-on-ones with each person on the team to see if there are things they would be more comfortable saying in private.

Make a personal list of any risks discovered and, if you uncover any in-progress tasks that people are doing that haven’t yet been documented (private pet projects for the CEO, marketing requests that aren’t listed anywhere, and so on), add them to the in-progress part of your wall.

Plan a red line

Now that you know your current commitments as a team, it’s time to plan a red line. That’s the point in time when you plan to schedule learning time as part of work. After the red line, you commit to make time for your team to learn.

The red line can be a month from now or at the end of the next iteration. Anything more than a month into the future increases the risk of losing focus on the current task, and interest in learning time may decline into apathy. Once you have a red line, you have a deadline. Your job is to clear enough fires before the red line, allowing you to feel comfortable scheduling learning time.

The only way you’ll feel comfortable after the red line is if you remove some of your current commitments—the ones you have on the wall now. Before reaching the line, you make a dash to put out fires. Estimate how many fires you’ll be able to put out before the red line arrives. For whatever fires you can’t put out before then, you will have to delay your commitment to achieve them on their current schedule.

Past the line, your schedule will include tasks, but fewer than usual. How many fewer? It depends. Learning time, the time when your team experiences new skills and applies them to its current work, can slow productivity by a factor of 10. Although in theory you should allot up to 10 times more time for each task for a few months, you should realistically plan for at least 2 or 3 times more than normal.

Based on how things go, you should add more learning time by removing commitments or by adding more buffer time to the current commitments. In this case, the word buffer is not meant to denote the “time we might need but currently don’t have.” It signifies “time we need to practice new skills.”

Initially, removing half of the tasks you have or allotting tasks double time might seem crazy. But imagine a team learning TDD. In fact, maybe your team tried to learn that. Written in a test-first manner, the same code can easily take three to five times longer to write than when not using TDD (this is only from my personal experience).

How do you remove commitments?

You remove commitments by informing whoever needs to know. Your boss. Your stakeholders. Everyone who should care. Here’s what you do:

• Show them the list of current tasks in progress.
• Explain to them that many of the current tasks could have been avoided if the team had had enough time to learn and become more professional (give some concrete examples).
• Explain your outlook for the next few months, in terms of commitments.
• Explain the gains from this move: reinventing the team as a professional team that makes fewer mistakes and learns from the ones it makes.

Before you decide that this step isn’t for you, for various reasons, here are some reasons why you should do it anyway.

Why slack?

It’s easy to let this whole thing go in an effort to keep up with the daily stuff. Why would you want to tackle even more hardship than you’re already tackling on a daily basis? But adding the slack will make or break your efforts. If you don’t succeed in securing more slack time, you won’t get more time to learn, and you won’t be able to grow your team away from future survival modes and teach them the necessary skills to deal with the world.

Remember why you’re doing this

You’re going to go through this whole ordeal to become the team leader you wish you always were—someone who fights for the team’s right to learn and to always improve. This isn’t an easy task. In fact, it’s quite hard because it involves a bit of risk. Not as much risk as you think, but still, it is a risk.

The risk of losing face with upper management

You could lose face by admitting that things aren’t going well. This might be a win according to some, because you’ll get more respect. You can’t be the only one who noticed things aren’t going that great, right?

Nevertheless, it’s going to feel a bit scary and risky. But remember, that’s what you get paid to do: make things better, in the most professional, clear, and transparent way. Losing face is part of the game, and any would-be leader should be prepared to face such tough situations.

The risk of failing

Yes, it’s possible things won’t go as smoothly as you wish. It’s possible you may not put out all the fires you promised by the red-line date. But you will learn from this experience and become better and fix things as you go (change the red line or remove more commitments).

This is what you’re being paid to do

What is the job of the supervisor at a car repair shop? If you ask me, when I come to the shop, I expect the supervisor to see to it that my car is fixed relatively quickly and that it won’t hurt my budget too much. But from their point of view?

The lousy ones believe they get paid to decide on the shift schedule. The good ones feel they get paid to have a great workforce that’s always ready and able to service the cars in a way that makes the customers happy. They’re paid to make sure everyone in the shop knows what they’re doing and how to handle any car that comes in the door.

Your manager might say that you get paid to ship software—or induce your team to ship software. That means you need to do everything in your power to make your team the best at delivering that software, dealing with any needs that come up and solving problems quickly, without experiencing any bottlenecks.

Translated: You’re being paid to make tough calls and judgments to the best of your knowledge and ability to achieve this. You’re being paid to get your team to a level where they do things professionally. You’re being paid to keep taking the team to the next level of performance and professionalism, because that’s what will allow them to write and deliver the software.

From some perspectives, all this may seem to be undervalued, but it’s what’s needed to get what’s requested—working software that can deliver real value over time.

But suppose management tells you, “Thanks, but no thanks. No need to grow our teams. Just write the damn thing.” My initial reaction to that position is to flee that workplace and find another place where management wants people to make the best of themselves.

You don’t have to leave, because this might be a good story you can keep to yourself, as you continue to work quietly at getting more slack time. A year from now, if all hope is still lost, perhaps it’s time to pack up and go, but try to show results first. Create slack time with guerrilla maneuvers, and show success patterns to management when you have some numbers in your hands.

Realize that you’re going to break your own patterns

Yes, I’m going to repeat myself now, only because this will happen many times. It’s going to be scary and annoyingly unfamiliar. You won’t be sure what to do at each specific point, and you’ll sometimes have to rely on your instincts and a bit on my advice.

Getting out of your comfort zone is, by definition, uncomfortable, but that’s how you learn new skills. In his book Becoming a Technical Leader (Dorset, 1986), Jerry Weinberg tells the story of how he plotted his scores in the game of pinball. The score seemed to be consistently going up over time, meaning that he was becoming better, but before every large quick rise in points, there was a down slope in points. These happened when he discovered new, interesting facts about the game he was playing.

For example, he discovered that when you have more than a single ball at the same time in the game, you earn double the points for every hit. When he discovered this, he started aiming to have more than a single ball in the game.

When he first began doing this, he was bad at it. In fact, he was a worse player and scored fewer points than before using this technique. But as he got better at the approach, his total score went up higher than his usual average score.

In short, he learned how to look at and play the game differently, and to do that, he had to let go of his “sure footing” and unlearn things he had learned. To get to the next stage and to become much better than you are, you have to let go of the things you already know. You have to let go of the safety of the current position you’re in, to allow you climb to the next level. The same applies to what you’re about to do as a team leader. You’re about to take a risk, do something you’ve never done before, and change circumstances that seem almost unchangeable. In the process, you’ll learn many new things that nobody said aren’t scary.

Nobody said you won’t fall down a few times while you learn a new skill. Eventually, you realize that in life you always have to get uncomfortable before you learn new skills, and this is a phase of learning—you’ll learn to even like it a bit. When this happens to me—when I feel uncomfortable, annoyed, or scared—there’s also another voice in the back of my mind that makes me smile, telling me, “Ah, I must be learning something. Cool!” You’re about to learn a lot. Hold on, and don’t let go of the end goal: to always get better.

Don’t fear confrontation

As you break your patterns and your team’s patterns, you might get into some arguments with folks who don’t like change or don’t trust you. Be prepared for this to happen. Many people don’t like change. It’s okay to disagree, and it’s more than okay to say, “Let’s agree to disagree,” unless it’s your manager. In that case, don’t be afraid to say what you believe in and what you think. It’s okay if they don’t accept your position, but you need to try. If you don’t try, you’ll never know if they might agree with you.

Don’t run scenarios in your head about how a conversation with someone might go. It’s usually an excuse not to have a face-to-face with that someone. Realize this, and meet with that someone in person. Be calm and rational. Make sure you can live with the decision. If you can’t, you should say so.

You should strive to achieve a real change, not the illusion of change. If you need 100% more time and you get 20%t more time, that’s something you cannot live with. You have to speak up. You have to bet the farm on this. You have to be able to say, “This is the best way I know how to run this team. Let me do my job.” You should be able to say, “This is how I work. If you know someone who can do this job better and get this team to be better, you should hire them.”

Eventually, know that if these things aren’t accepted and you don’t get anything you can live with, you should try to find a place that will respect these ideas. I believe it’s okay, and even expected, to change jobs based on your work values. Don’t stay where you’re not appreciated and where you can’t change things. Don’t stay in a place that makes you feel miserable.

Commit to a place where you can live with how things are going or can change things enough that you can live with them. If you accept survival mode as a fact of life, it’s your fault as much as it is everyone else’s—maybe yours even more because it’s your job to stop midway and raise the flag if something is wrong. It’s your ethical responsibility. It’s your ethical responsibility not to tell yourself, “Well, I told them. Now it’s on them,” and then stay and do the same old thing. That’s a cop-out. It’s up to you to make something out of this role you’ve chosen to fulfill. Being a leader can, at the beginning, feel quite lonely, but it can also feel amazingly fulfilling to drive for a real change you believe in.

Don’t despair in the face of nitpickers

You might come across some “good souls” who will, with a smile, let you know about all the different ways you could have done this and all the things you should consider before doing this. It’s okay to listen, and it’s okay not to accept advice. It’s important that you stay focused. Your focus is to get the team out of survival mode, to make time for your team to learn new things, and to improve the team. You might need to be a bit more command and control in your actions.

Command-and-control leadership

When the ship is sinking, the captain doesn’t call a meeting. The captain gives orders. To get out of survival mode, you need to save precious time—time you will need to put out the fires on your way to learning. During survival, your goal is also to prevent mistakes made by the team, if you can detect them, and save time by making decisions on topics that, if you have meetings about them, will take a long time to decide in a team manner.

Yes, this feels like it goes against most of the ideas of trusting your team and letting them self-organize, but it’s likely that the team itself isn’t ready for self-organization. Team members may lack the skill to solve their own problems when faced with issues outside their comfort zone.

One of the common symptoms betraying a lack of skills to self-organize is that the team keeps expecting the team leader to solve all of their problems. They might have learned to do that from you or from their previous team leader, but, much like an animal that has been kept in a zoo, letting them go alone into the jungle will likely get them frustrated and stuck trying to negotiate a maze of issues they’re not used to dealing with. It’s likely that letting them self-organize without learning the proper skills is partly the reason you’re in survival mode.

Correct bad decisions

If your team decides for some reason not to use source control or use a zip file mechanism as source control, you step in and make a choice for the benefit of the team—to use proper source control tooling (for me this translates to “avoid ClearCase!”).

There’s no time to start debating such a decision. Now is the time to get out of survival mode. There will be plenty of time to decide and learn different configuration management options later, in the learning phase.

Play to the team’s strengths

Now also is the time to get every team member to do what they do best, not to challenge them to do something they will do slowly or hate to do. If someone is a DB expert, let them handle the DB until you get out of survival mode. You don’t have the precious time to let them do anything they aren’t 100% productive in (unless you don’t have anyone else).

Get rid of disturbances

If someone is a bad influence on the team, for example, always pessimistic, your responsibility to the team is to remove that problem.

A beta reviewer for this book asked, “It’s not clear how I’d know if someone was being a ‘bad’ influence by resisting changes, especially if they feel they have a valid point of view. How do I decide?” If someone resists changes quietly, sitting with you, during a one-on-one conversation, they’re not a bad influence. They’re not influencing anyone, because you are the only two people in the room.

If someone resists changes in a room full of developers, they might still not be a bad influence because discussion and developers who speak up about things that bother them should be welcome in team meetings.

But having someone question decisions in the middle of survival mode in front of the whole team can be a show stopper, or at least slow down the start of the transition to learning mode. Now is not the time for too many questions. Too much doubt, particularly in difficult times, can bring down an entire team.

One way to handle dissent is to have a one-on-one talk and explain that for now, until you’re out of survival mode, negative talk is unacceptable and that there will be time to talk about improving things when you have learning time available.

Another way is to move that person into a separate room for the duration of that survival phase or have them work on a different project or team for the duration of the survival phase. It may seem harsh, but harsh times sometimes call for harsh measures.

I’ll add a warning here: I’d try the one-on-one first, but I wouldn’t waste too much time having many such talks with the same person. The amount of time and energy you put into making this person play well on the team will be a burden—precious time and energy you’ll need to get the team out of survival mode. You’ll have plenty of time to work with that person on their team skills when you’re in learning mode.

On a related note, there’s always the noted “no downers” rule, in which you don’t allow immature behavior within the team. Phrases like, “I knew it would never work,” count as downers in this book.

During transformation you’ll likely need to...

Once you have a green light from management to add slack time and to begin growing out of survival mode, you might need to make several changes to the way you manage yourself and your team. I’m saying “might” because you may already be doing some of those things, not because I think these changes are optional.

Start spending more time with the team

How much time? At least 50% of your time should be spent either in the team room or talking or working with one of the developers. Move your computer to the team room. Make that your base of operations. This will allow you to become a “bottleneck ninja”—you will be able to detect when someone is stuck or the team is stuck and help steer them away into more productive waters.

In survival mode, you need to make navigation corrections all the time, to make sure your vision of a learning team is realized. A stuck team cannot put out the fires and cannot move on to learning mode because they haven’t made enough time for it. To clear 50% of your time, you’ll need to remove yourself from meetings.

Find all the meetings where you feel you are contributing little or nothing at all and the ones where you are benefitting the least. Some regularly held meetings might only require your presence every other time, and some you can let go of completely. Cancel them as part of your overall effort to be more with your team. Use the same lines of reasoning that you used when getting rid of commitments. Your team can’t function and get out of survival mode without you at the helm.

To work through the “needy” problem, you’ll need to be there in case your team gets stuck; later on, when you have time to learn and teach, you can teach them to solve their own problems, and they won’t need you as much. There has to be a time investment first, and it has to be you; you are the one who leads the team.

What if you’re not a technical team leader? It’s still vastly important that you be there, to see any team problems that come up and how your technical leader is solving them. You should be there to see if there are any people problems you can solve in some way. You should also be there for the technical lead to prevent them from getting stuck answering a question that has to do with the vision or direction the team is taking.

Be there for your team. Show that your words are not empty. Show that you are there for them as much as you expect them to be there for the company. If you ask your team to work long hours, you should be the last to leave during survival mode. If you leave before they do, you will create, at some point, a silent mutiny where people don’t work but appear to. Resentment is a powerful enemy. You should be there feeling their pain while getting out of survival mode. You should be there to set a personal example. If you want to get out early, tell them they can get out early too, but don’t ask them for unreasonable tasks in that time. Be there for what needs to be done and for however long it takes, until you get out of survival mode. If longer hours for are needed for a month, you should be there.

Personally, I’m against longer hours because I feel they generate tired employees who will break at crunch time or will create more fires. But I’m okay with a couple of days that are longer than usual to solve something that has gone horribly wrong, as long as it’s not the norm.

Take ownership of your team

Your team may be taking tasks from multiple stakeholders. That’s not a bad thing per se, but if your team is in survival mode, it might be that the team’s lack of skill or technique in handling multiple stakeholder requests at the same time is one of the causes of survival mode. If a team member says “yes” to a task because they don’t want to let down the requesting party, without regard for the current schedule and commitments, that’s a cause for action.

One possible action could be to make the decision for the duration of the survival phase, and until otherwise stated, that you will be the only funnel through which the team will be taking tasks, and stakeholder conversations should take place through you. This can help make sure the team stays focused on fixing the current fires and also gives you the opportunity to take control when conflicting requests come in and act accordingly.

For example, you could talk to the stakeholder and explain the current priority of the tasks. You could replace a current task with a stakeholder task. As long as you’re in control of what the team does, you’re able to direct the team out of survival phase. If you don’t control your team, someone else will and probably already is.

Learn how to say no by saying yes

One way to refuse stakeholder requests is by letting the requesting party realize for themselves that there are better ways to spend the team’s time. One of the best ways I know to accomplish this is by using the task board with sticky notes of what’s currently in progress and what’s coming up, sorted by priority (high-priority tasks are closer to the top).

If your stakeholder wants feature X, bring them up to the wall and say, “Okay, which feature do you want to move down in order to build this?” Ask them to take down a feature from the in-progress column or the to-do column. This usually leads to an interesting conversation with the stakeholder about what each task means and how much time was estimated for it. By the end of the conversation, either the stakeholder will realize where the task fits, or you will. Either way, what wins is the value generated for the company.

Start doing daily stand-up meetings

This technique is critical to get the team in the right mindset on a daily basis. Each day, you have a team meeting lasting no longer than 10 to 15 minutes. In the meeting, each person goes through three basic questions:

• What did you do yesterday?
• What are you going to do today?
• Is there anything stopping you?

These questions are as much for the rest of the team as they are for you. Through the answers, you get to find out about team members who may be stuck working on the same task alone for more than a day or two and pair them up with someone.

You can also discover if people are working on the wrong thing or focusing their energy down a path that’s not productive during the survival phase. The team gains important insight as to what’s going on and what the main focus is. They don’t work in their own bubble, but instead they feel more like they’re part of a larger effort. Having a daily stand-up meeting (yes, you stand up during the meeting; it takes less time) helps you get rid of unnecessary, boring team meetings.

Before I get into the subject of code reviews in the next section, I want to discuss the notion of a broken window, because lack of code quality and broken windows go together hand in hand.

Understand the notion of broken windows

A broken window is a line that can be crossed. It relates to the broken windows theory, which states that if people see an opening to do something, they will take advantage of it to eventually do whatever they want. You can read more about this concept at http://en.wikipedia.org/wiki/Broken_windows_theory.

To summarize, the broken windows theory was first introduced by social scientists James Q. Wilson and George L. Kelling, in an article titled “Broken Windows” that appeared in the March 1982 edition of The Atlantic Monthly. The title comes from the following example:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside. Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or even break into cars.

How do code reviews relate to broken windows? Turns out sloppy code reviews are an entryway for broken windows. Read on.

Start doing serious code reviews

Code reviews are a great tool for teaching and learning, but during survival mode they can be used to mitigate a code-quality problem. As a team leader, if you realize there’s a problem with the quality of the code that generates more fires than you’re able to fix, it’s time to do some serious code reviews. By serious, I mean full commitment to the task.

Here’s what worked for me: no piece of code gets checked in to source control without a code review. Yes, even if it’s one line of code. Even if it’s an XML file, I still review it.

At the beginning, as a team leader, I did the code reviews. It slowed down the team, but the code quality improved. Effective code reviews are not done via a tool or remotely—they’re done when you’re sitting side by side with the person or pair who wrote the code. This personal approach allows you to share and teach much more information than you can pass with a text-based tool. Don’t skimp on this! If you’re going to do code reviews because your code sucks, do them right. Otherwise, if you compromise on the quality of the code review, you create a “broken window.”

If you decide that “some code” doesn’t need to get reviewed, that’s a broken window. Eventually people will move the bar of what constitutes review-worthy code higher and higher until there’s no line. By setting an “everything, no exceptions” policy, you ensure that there’s no bar to move. Everything is included. During survival mode, that’s important.

What if your team is larger or distributed?

What if your team is large?

If you have more than, say, seven people on your team (Google “Pizza Sized Teams”), things become less manageable. It also makes code reviews much harder. In that case, try first to break the team into smaller teams, and then teach one person on every team how to review and, more importantly, how to teach the other people on their team how to review code.

If you can’t break up the team, assemble a group of people (about one per five people) and ask them to be the code review gate watchers, and then continuously sit with a different person of that team while they review other people’s code. That could help you see where they can be better reviewers, coach them on missing techniques, and scale up the code review process, without sacrificing communication and shared knowledge.

What if you’re part of a “wide team”—a team that’s distributed?

You might not have the option of having your leader sit with you, and that’s too bad. You have to use other means, like screen-sharing tools, voice software, and the like. I’ll recommend a couple of tools for those situations, but know this is never going to be as good as the real thing, and you should make it your goal to have at least some scheduled times where people come in and sit down with one another.

About tooling—at the risk of dating myself as soon as the book publishes—I use a combination of TeamViewer for screen sharing and Skype for audio in the background. TeamViewer is free, and you can give the remote viewer the controls that allow them to code and change text in your local machine. This can be a bit laggy, unless your internet connection is amazing.

On Mac and Unix, and for Vim lovers (the text editor you will love to hate and hate to love), use a combination of tmux and iTerm2 with Vim over ssh, and be amazed at the world of wonder before you. For those who lived then, it feels like BBS all over again, but it works.

If you’re not a technical manager, Google these terms, and get a better understanding of what you want people to use to communicate more effectively.

Next up

If you keep at it and live up to the principles outlined here, I’m sure you’ll begin making time to learn. In the next chapter, I’ll discuss what to do with this time and how to grow people to become self-reliant and self-organizing as a team.

Summary

• Survival mode can be defined as having no time to learn, or not using your slack time to deliberately practice new skills. Creating slack time is one of the core tactics for getting out of survival mode, but it requires taking a possible risk of losing face, or telling unhappy news to your management. But this is part of the territory and part of what real leadership means.
• Getting out of survival mode also means sometimes changing your leadership tactic to a command-and-control style. When the ship is sinking, the captain doesn’t call a meeting. The captain gives orders. This is sometimes crucial because the point is to make time for learning so you won’t have to use command and control anymore. You want the team to move into learning mode to self-organize, but they can’t do that without practicing the skills they’re missing.