Deadlines
What poor misfortune has led you to this page?
Last updated
What poor misfortune has led you to this page?
Last updated
Ah, the plague of every enterprise software company. The Killer of Morale. The Harbinger of Stress. The Bearer of Poor Client Expectations. Still, you will inevitably run into deadlines, as we all have, and you should at least have a few tools for tackling them.
To tackle at-risk deadlines, there are many tactics you can apply. Some of which I don't believe are good strategies, and I'll mention why. Others will require compromises in some form and it's up to you to determine where you can give. Because you're going to have to admit that something has to give.
Aka put in more hours. I think most people know well enough at this point that more hours lead to burnout and working overtime isn't actually productive for engineering tasks. Working harder sometimes means compromising quality in favor of getting content through. Don't do that unless you absolutely have to. The long-term costs will far outweigh the short-term benefits.
Aka, pulling additional engineers into a project. This is usually a bad idea [1] [2]. It takes about 6 months for an engineer, even a great engineer, to ramp up enough in a project to be helpful. Also, having more hands in the pot doesn't typically speed things up.
However, if you have an engineer that 1) has previously worked in that project and 2) has jumped to another team or is currently working on a different initiative, pulling them back into this particular initiative temporarily can be successful.
Lastly, you may consider temporarily contracting software engineers. Don't do this. Contractual staffing has particular uses, but saving you time or money is not one of them. The ramp-up issue for new hires still applies to contractual staffing; even more, the greater consequences of temporary work often lie beneath the surface long after that contractor has left. Contractors profit when they fulfill surface-level expectations, often compromising good architecture and long-term decision planning in favor.
Can the deadline be pushed back? "Absolutely not! The client will pull out of the deal!" Eh. I've found over the years that hard deadlines are usually a lot softer than they appear. Most clients will throw a fit (or at least your sales rep associated with the client will) about the extension, but I've rarely seen it be an absolute requirement.
If you absolutely cannot extend the deadline, then you'll need to start cutting content. This does not mean you should compromise on quality or rush feature sets. Instead, you should be very deliberate about which features do not need to ship on time. You'd be surprised at how many must-have items are actually nice-to-have items in disguise.
If you don't know what to cut, I'd recommend rank-ordering the unfinished tasks (a good time to use the Eisenhower matrix), updating the task's story point estimates, and using your velocity tracking to give a data-driven cut-off point.
This one has been my favorite solution as of late and one that I have applied more liberally to many situations where innovation is key. In a nutshell, think very hard about finding a solution to the problem that doesn't involve the most expensive and time-consuming aspect of the product pipeline: writing, deploying, testing, and maintaining code. Depending on the situation, you can usually swap out your automated/coded solution with a human one.
This does not scale, and should certainly be temporary, but it buys you one great benefit: data. Lots of it, and directly from the source. Whoever is tasked with the work will have a very good idea of what is working and what isn't, how much the "solution" is being utilized and in what ways, and how you can better design and develop this function once you have the resources to codify it.
I'll go over this in much more detail in my Non-code Scaling article.
Probably the last thing you want to hear at a time like this, but you're going to want to perform some critical analysis of how you got here to begin with. Use the 5 whys. Try to find the root cause of the poorly defined deadline. It likely has something to do with mismanagement, lack of cross-team/department coordination, overconfident estimates, insufficient scoping, or missed expectations.
It may also be a good time to investigate your product pipeline to see if there are any bottlenecks. Use lead time and cycle time analysis to see where you can improve in your process.
We don't want to be beholden to deadlines, especially artificial deadlines. Sure, if you have an SLA or client obligation around specific functionality, then that's part of the business. More often, however, engineers are held to the fire of what they think they can achieve within a given timeline. SLAs and client obligations can be overcommitted to finalize a sale. Quarterly planning, cross-team bottleneck dependencies, and external pressures can all push for products to ship on unhealthy and rushed schedules.
There are several strategies to combat this. One of which is learning how to appropriately estimate tasks and velocity to better gauge timelines. However, with all the caution I can muster, task estimation should never be used as a tool to justify setting deadlines. Just because you have the power to estimate when something will be done, does not mean you should publicize it, even internally.
The video game industry knows this far too well. No game ever ships on time. The studios that over-hype their games announce release dates, then renounce them (and re-announce another date), and so on, and so on, until all your customers are pissed and your developers are overworked, and your product is buggy. The smart studios simply say, "it will be done when it is done." I highly advise you adopt this mantra and drill it into your company culture.
