Surviving Crunch Time
For the first 4 months this year I was in a constant crunch mode. At FlightCar we usually tried to avoid this, but we had to ship a redesign of the website, a redesign of the iOS app and finally release a customer app on Android. As for most other seasoned developers this is not the first time I experienced such a time and it will likely not be the last. Over the years I developed quite a few strategies to handle crunch time (and stay sane and productive at the same time) I want to share with you today.
The best case, of course, is to avoid crunch time. Some companies, especially Start Ups claim that this is not possible and that you have to be in a constant crunch. Here is the secret they do not notice most of the time: Playing table soccer does not count as work, no matter how often you try to tell yourself you are working for 25 hours a day while you are actually only shifting the location of your free time. Browsing HackerNews and reddit mostly also does not count as work, sorry.
If you still find yourself in a constant crunch one of those two things most likely happened:
- You have no idea how to create a proper roadmap
- You have unrealistic expectations
It usually boils down to one of those two options. One thing you have to realise is that you’re either making sure your developers burn out and you have to hire new ones every three to six months – or you are not actually in a crunch but decided that your free time should be spent in the office doing everything but work.
As I already admitted crunch time can happen and there are various, legit reason why it happens. And most of the time it is something that will decide the future of the company. Now if it happens the trick is to make sure you, the team and the companies actually survive crunch time without going crazy, burning out or setting tables on fire.
Daily Routine - Stay Healthy
Even if most of your day is spent working, there are a few things I would strongly suggest doing on a regular basis, first to stay healthy, second to refresh your body and mind.
- Exercise - even if it is only a 10-15 minutes walk, do something that forces your body to move and try to not think about work.
- Sleep - no, not with your nose leaning against your screen. In a bed. For more than 5 hours.
- Eat - a proper diet, not pizza and Jolt Cola mixed with energy drinks and ibuprofen.
The exercise part can be a bit controversial for some people. I will not try to look up all the studies that actually explain how important this is since I am not in a position to actually verify them, simply take it as a suggestion. It helps me a lot to stick to my daily exercise routine, give it a shot!
A project which decides the future of the company also means that during crunch time a lot of people will have an eye on the product and regularly check if the team is on track to get it done. After some time in the industry you will get used to C-level executives looking over your shoulder when you work on something important - and they will remind you how important it is. In itself this is not a bad thing, it only shows that they care, which is actually awesome! Far better than the opposite when they simply stopped caring about the product.
There will sometimes be people on your team who are not used to management having such a close eye on what they do, the expectations to get twice the work done in half the time or working on something that could kill the company if something goes wrong. Keep an eye out for those people and try to help them as much as possible with advice and guidance. This should actually be always the case, but someone being a bit stressed during a regular 9 to 5 day is far less likely to go insane and it is way easier to counter than someone not sleeping for 5 days straight because the only thing they got in their head is “if it fails, everything is over”.
While you usually cannot downplay the importance of a project, you can set the expectations straight that not getting everything 100% right in time is most likely not as bad as it is suggested. The fine line between motivating a team and putting so much pressure on them that they break is hard to hit. When in doubt try to not get too close to it.
You will usually have one big goal at the end of crunch time. Maybe it is a redesign, maybe it is a new feature, maybe it is a new application. But the goal will be defined fairly broad and a lot of smaller components are needed to make it happen. Not all of them are necessary to deliver a great product or a stripped down MVP and not all of them provide the same value to the customer.
It is important to start managing expectations early on. Make sure you have all components on a list ordered by priority. Does your admin interface have to be redesigned as well and launched at the same time as the marketing site? Most likely not. Would it be great if your iOS and Android app have feature parity? Sure, but if the app is only supporting your business and is not the core value, it could be sufficient to focus on the core features which are most important for the customer.
While product, management and all the people involved can tell you what they ultimately want, only you can tell them if this is realistic, which tradeoffs could help to make it happen and how fast after the expected deadline you can deliver the missing pieces. Start this conversation early, best before the actual crunch time starts and make sure everyone knows and agrees.
Shortcuts And Cleaning Up
“We are going to write the most beautiful, well tested, stable code the world has ever seen” - no one ever during crunch time.
You will be taking shortcuts. No matter how good your intentions are. And the shortcuts will be shorter and more ugly than the ones you are usually willing to accept. This is okay, crunch time is not about writing the best code in existence. But, no matter what shortcuts you take, it is important that the product is working as expected. Shipping something broken never helped anyone, and shipping something broken in time is in my opinion worse than not shipping at all.
What I strongly suggest is planning time after crunch time to clean up, refactor and make sure your working code is stable and maintainable. Leave some comments in there to identify the parts where you willingly took shortcuts. While most people have the intention to do this, it does not always happen. Making sure this actually does happen is part of the management responsibility for crunch time, the same as setting expectations properly. If you miss this, you will end up with a system that is holding together for now but blows up in a few weeks or months. That this will be required should be communicated to all relevant people before crunch time starts and you should make sure they agree to give you the time. While this is no guarantee, it increases the likelihood to happen.
This surely sounds pretty easy and straight forward. Sadly it will not be that way. People will be stressed and as you probably know it is not always easy to work with stressed people. If you got a partner you should make sure they understand why this is so important and if you are lucky they are understanding. When it is over make sure to compensate for the lost time of your life. Always remember that your health is the most valuable thing you possess. Crunch time sucks, but you cannot always avoid it, try to survive the best possible way.
>> posted on July 22, 2016, midnight in life, software-engineering