In the recent past, I have found myself where no project manager wants to be. A deadline is fast coming and despite commitments from the developers, unless Jeff Dean joins the team you are screwed.
I will admit, on the way here I made a lot of mistakes, the most important being I failed to bound my uncertainty. You see when we started missing key milestones, I knew for sure we would not make the release date. The problem is I didn’t know how much we were to miss it, would it be a day? a month? a year?
In such situations, panic is practically inevitable. It’s only the most sophisticated companies that don’t jump into the code and fix model at the expense of a solid development practice.
In this entry, I will be sharing some of what I learnt and what we did to get to where we were.
Add more staff
If takes 5 painters 8 days to paint a house, how long would it take 10 painters to paint the same house?
You must have come across such a question in your high school math. How well do you think it plays out in the real world?
Suppose the contractor painting the house is in a tight market, after the first 5 expert painters, it became much harder to recruit new painters so the remaining 5 are either novice or intermediate, how does the math work out then?
What if the house must be painted sequentially?
What am alluding to is the ideal situation never plays out in the real world. These models gloss over a reality known to all managers, people are fundamentally unequal, diversely endowed in mental capacity, agreeableness and stick-to-it-ive-ness.
Further, new members are generally not as productive, no matter their technical knowledge, they are lacking in domain knowledge which is arguably more important.
In short, when its crunch time, you are better off sticking with your existing team.
Cancel continued education
Let us think for a second about the painters from the last section. If you are the owner of the house and you know there is a tornado coming your way, would now be the best time to be painting?
When faced with a crisis, the immediate reaction is to shut down all optimistic activities. What is the point of learning if you will never get to use the knowledge?
In this case, continued education will act as our proxy for all long-term capacity building activities which have no immediate tangible benefits.
The problem with this approach is you never really fix the fundamental problem. For example, when we noted a certain technology was not working out, the solution was to double down on what we already knew, this solved the problem then but later the same problem manifested but now in a different form, new features suddenly had an exponentially longer delivery time.
Even in the most dreary of times, you can not afford to ignore the education of your developers. It’s one of the key factors which when there encourage motivation and when not there drain it.
Extend the work day
There is something visceral about seeing people in the office doing the work. Just like the number of painters problem, the number of hours per painter is a variation of the same kind of thinking.
Here is what David Allen has to say on the topic:
How much does it take to have a good idea? Zero. You don’t need time. You need room in your head
I don’t believe any developer can code continuously for more than 6 hours. Add in breaks and you have a hard limit on a 9 hour work day. Anything more and you literally have zombies in the office, let them go home.
Software development is a creative exercise time does not matter as much as clarity of direction and mental space to think through ideas. This arises naturally when the developers have had a chance to rejuvenate themselves and spent time with their families.
Further, an insidious outcome of this move is people find a way to compensate. Suddenly people are sick more often or even just spend more time goofing around.
In conclusion, when things go wrong, don’t panic, orient yourself to the new reality come up with a revised plan and stick to the process.






