What Everyone Is Thinking

Can we please stop doing this? I don't see the benefit. It's not working. In fact, it's harming the business. We need to go back to the old way!

I've said it before and I'll keep saying it. The Middle is long. This long amount of time allows for so many opportunities for people to question the strategy and the tactics, and to pick apart pretty much anything you are trying to change. The new stuff is hard, and may in some ways be unpleasant. People's favorite projects might have been canceled or delayed. New skills are required. The payoff is not obvious yet. People want to go back to the old way, because the old way is familiar. It's comfortable. It's easier: “This new thing…well…it just isn't working.”

“Burn the Ships at the Beach”

First, a brief historical reference: 1519 AD, during the Spanish conquest of Mexico, Hernán Cortés, the Spanish commander, scuttled his ships so that his men would have to conquer or die, no matter how hard the mission became and how much they might have wanted to turn back. There was no turning back because the ships were gone. Forward was the only choice.

This was a phrase I learned from my boss in one of my roles, when I was asked to step in to run a software development organization of about 200 people. In this situation my boss taught me a lot about Valor. He had it. He required me to step up and have it too.

When I got there the team was on a two-year product development cycle— and we were running late! The quality of our product was very low, and the morale of the organization was even lower. The sales force and customers had abandoned us. It was a mess.

Our strategy for the business became to fix the quality problems and get on a predictable software development and release schedule. The bulk of executing this landed on me. We adopted, at the direction of my boss, a process framework called the SEI process, which is a predefined software development process with rules and checkpoints that occur at each step in a software development program. SEI process improvement became our “ruthless priority” for the year. (See Chapter 18: Too Busy to Scale, for more on ruthless priorities.)

This was not an easy ask of the organization.

Software developers are enormously talented and creative people who can work miracles. But as a group what they do not love is a process improvement initiative! My boss's mantra for our organization was “process, schedule, features.” Process was the priority, because that was what was going to improve our quality and predictability and allow us to turn the business around and get the sales force and customers back. The priorities that software developers prefer are features, features, features. We were putting the only thing they cared about last. This was not an easy sell.

Now I'm not a lover of process for process' sake, but I am for just enough process to make things better. To give you a sense of what we were doing, we were going from SEI Level 1, which was defined as “chaos,” to SEI Level 2, which is defined as “managed.” There are five levels. All I needed was to get us to Level 2. Level 2 basically says that you are no longer in chaos. Level 2 requires that you must commit to what you are going to do and write it down. If you want to change what you committed, you have to go through a change review process, document the change, and write it down. For each phase in the process there is a checklist that you go through to make sure you completed all the work, communication, and review necessary to move from one phase to the next. This was not an overwrought or detailed process. This was simply going from “chaos” to “managed.”

The way that this played out was, after rolling out the process framework and checkpoint lists and committing to the feature set for our next release, on any given day, when a sales person or a customer said, “I must have this feature now,” an engineer would come to me and say, “I need to add this feature.” I would say, “Process, schedule, features: Does adding this feature at this time go against our defined process? Does adding this feature impact our committed schedule?”

The engineers absolutely hated this. The other thing they would try to do to get around the annoying process work would be to try to blackmail me and say something like, “I can finish this on time, but not if I have to fill out these process documents. If I have to do all this extra process work, then I am going to be late.” I would say: “Process, schedule, features: I want this to be on time, so do your best, but you can't skip the process work. It's a must, and it's a higher priority than schedule, so please complete it.”

I would go to my boss and say, “This is really hard, everybody hates this, and they argue with me every day.” And he would say to me, “Patty, you have to burn the ships at the beach.” He taught me that you have to make it very clear at the beginning of a difficult journey that there is no turning back. The only way through is forward. If you go back, there is nothing there for you. You can't get back.

And he taught me that the way you “burn the ships at the beach” is to be completely consistent in your message and your decisions.

People would tell me, “You are being stupid, you are killing our business, we're going to lose our top people over this,” and I'd say, “I understand your frustration, but this is what we are doing, and I am committed to it. I promise you in the long run it will be good for the business.”

Then they would get very upset and go to my boss and say, “Patty is killing the business, this process stuff is wasting time, and we are not going to be competitive if we don't put this feature in.”

He would reply: “Process, schedule, features.”

To jump to the end, as soon as we got on this process, we reduced our cycle time from two years to six months. We did our first release nine months after we launched the process and did the next two releases like clockwork six and twelve months after that. The quality improved dramatically. We lost two top engineers who were just too angry that they couldn't do exactly as they pleased, but the morale of the rest of the team skyrocketed. (People love to finish things.) We were able to re-recruit a sales force and win the customers back. The engineers realized that shorter, predictable cycles allowed them to be even more creative and that they could make better choices because we were getting real market feedback on finished products that were out in the market. They never loved the process part, but they ultimately admitted that it helped, and they became personally committed to it.

I was so proud of this accomplishment and this team because we began to operate like a well-oiled, predictable machine. You could give us any task, and we'd run it through this process and get it done. But it was so hard to get to that point. It required standing up to criticism, doubt, and attacks every single day for months. I doubted myself many times when a new feature seemed really urgent and important. But I stuck to the process, and it had a huge payoff. I learned so many lessons about Valor from this experience:

1. Say what you mean and defend it.
2. Don't change your mind.
3. Guard the people who are doing the right thing with your life.
4. Pick one thing at a time.
5. Don't lose your nerve.
6. Don't get bored or tired.

Let me say more about each of these things.