I found myself amiss. On a deserted island, stranded. Wondering what to do and where I would go. I glared. I scowled. The computer would not come back to life.

After much fussing about, I narrowed it down to something that I would call unrepairable. By this I simply mean that the cost of repairing is more than what it would take to buy something new. It’s an opportunity to upgrade. In this case, it was a substantial and enjoyable upgrade. I rewarded myself.

This is one way to lose (or gain) momentum. I used the computer upstairs while my kids are getting ready to go to bed. I hacked away or write while they are getting bathed and enjoying quiet time. I didn’t use it for any important work, though. Only things I could get interrupted from and not mind. I still got a lot done, though. All the little things. The yaks, needing to be shaved.

Momentum is easy to understand. Here is what it means to me:

Five minutes of work today should always be worth less than five minutes tomorrow.

It was amazing how much I wasn’t getting done after this system died. It was frustrating and that frustration turned into lost momentum. I found myself needing to work on mundane details at inopportune times. Those times where I was secluded, free from interruptions. This caused me to push back things that were important and difficult.

At the core of my being things were out of sync. I lost momentum. Momentum is very hard to get back. In an effort to rekindle I rewarded myself with a new system. It is extravagant but now I am happy. Working on a system that is very, very nice has the expected result; I want to work. That desire builds momentum.

Having a computer fail is just one way to lose momentum, but it’s the easiest to solve. In this case I think it may have helped me gain some momentum (ignoring the time in between where I did nothing.)

What if there is a disruption that isn’t hardware? Something vague in a group that seems innocuous to outsiders. Staff changes, leadership changes. Language or platform choices. These changes are difficult to track. Sometimes they are successful and build momentum. Sometimes they are not, but hidden and very hard to isolate.

There was an article from 1995 (they had computers then?) by Orson Scott Card (author of Ender’s Game). It was titled, How Software Companies Die. A brazen title, but worth the read. So go read it. Now. It’s ok if you don’t come back, it’s better writing.

At the center a lot of the article I believe it is really about momentum.

Developers have variable amounts of energy. What separates a brilliant developer from the mediocre is that amount of energy. It’s almost like hit points in a video game. When a high energy developers loses momentum, the energy goes somewhere. In the article, it talks about developers becoming uncooperative and disobedient. This is true and it is a result of lost momentum. The energy must be applied somewhere.

I don’t care about lost momentum, though. I think it’s the result of inept leaders. The best way out? Quit. Don’t look back. Don’t work for a bad leader. If the company is good demand to be transferred. If it isn’t, quit. I know of at least a dozen really good companies that are hiring.

The more important question is how do you build momentum? My thoughts lately have given me some suggestions, but I haven’t put these in practice. I’m mostly judging the ideas by what I think would work for me.

If momentum stalls or is low because of a leadership change the second in command needs to step up quick. Fill the void internally or hire someone famous. Someone every person feels they’re just plain lucky to work with. It’s expensive, but an idle team is more expensive.

Outside of organizational changes there are tool changes. Sometimes people have to use a new tool or programming language and don’t like it. The momentum gained (or lost) from learning a new tool or programming language is rarely transferable. The product of the group will suffer. People will make the same mistakes they made with the old tools again. Then they’re likely to overcompensate (something like the Second-system effect. More lost momentum.

Again, I think the solution is to hire someone well respected and well versed using the new tools (or language). This will be a beacon of light on a stormy sea of uncertainty. Employees will be thankful instead of fearful. Being thankful builds momentum. Being fearful hurts it.

The worst, and I believe irreparable, situation is losing faith. Not believing the direction of the product or company. Even if the tools, language or platform is agreed to be a good choice, developers and employees can still flounder.

The hard, cold answer is to let them go. You’re with us or against us. Why worry about these employees anyway? If they don’t believe in the new company and you know better, cool. If you don’t know better you should have listened to them. You won’t know until everything is done and over. Nobody can see the future. If the company direction changes and fails, all the departed employees will be dancing. That has to be very hard to cope with.

In these situations the leaders must either stay the course and ride out the storm of all the talent quitting (or worse, being outwardly subversive and difficult but not quitting) and try to replace it or cancel and regroup.

There is no shame in retreating if it builds momentum to cross the finish line in a different direction. There is shame in blindly pushing forward against all odds. Fortunately, employees who feel wronged are never shy to point out they were right and the leaders were wrong. Sometimes this works better for them in the long run.

This is the first essay written on the new system. It’s delightful and I’m greatly enjoying it. It feels good to be writing again. That was a painful week.