We’ve all been there. A looming deadline, more work than you think you can get done on time. Handling tight deadlines is an important skill for any software engineer, and it becomes essential when you start growing into a senior engineer.
What not to do
Let’s get the “don’t”s out of the way first:
Do nothing and hope for the best: You’d be throwing your stakeholders under the bus by not delivering on what you promised.
Work overtime to meet the deadline: This might work a few times, but you will get burned out if you make this a habit. If you’re leading a team and expect them to work overtime, they will not be very happy with you.
Cut corners on quality: This might temporarily make your stakeholders happy, but eventually your changes will blow up in production, causing reputational damage to your team/company.
In all the above cases, you will lose trust with your team and/or stakeholders. This will affect your performance ratings and bonus, and you can kiss your chances of getting promoted goodbye.
Is it even my job?
It might be tempting to say it isn’t a software engineer's job to manage deadlines. Isn’t that why project and program managers exist? To an extent, even engineering managers own delivery and deadline management.
However, software engineers are closest to the work and are arguably best positioned to identify whether a project is on track. It also doesn’t show great ownership to say it “isn’t your job”. Delivering the end solution to the customer IS your job.
The Tools to Handle Deadlines
There is no one-size-fits-all solution when it comes to handling tight deadlines. Every project is unique and could require a combination of approaches described in this section. Treat the following as tools in your toolkit, rather than a prescriptive guide.
Tool 1 - Initial Analysis
When given the project requirements, you should take some time to analyze what it means to deliver it. Depending on the size and scope of the project, it could involve:
Designing the solution (if the solution is ambiguous or complicated)
Identifying dependencies (on other teams/third-parties)
Breaking the solution down into pieces of features/milestones
Understanding the priority order of these features (essential, then nice-to-have)
Understanding what parts of the project can be delivered in parallel vs what parts have dependencies on each other and have to be delivered sequentially
Estimating the pieces and working out the total time estimate
Ensuring you’re factoring in time for robust testing - you don’t want to deliver a low quality product to your customers
Report this fresh estimate back to your stakeholders to set their expectations, especially if they expected you to deliver the project sooner.
Tool 2 - Understanding the deadline
Like with the requirements, it is important to understand the rationale behind a deadline. This will help you suggest the most appropriate mitigation strategy if you think you can’t make it. Ask the following questions:
Is it tied to an external, non-negotiable deadline? (like a government regulatory deadline or a change in market conditions that require your business to rapidly adapt to avoid losing money)
What are the risks of missing it? (Monetary, reputational or client loss)
Are there any workarounds? (For example, is your project replacing an old system? Can users continue to use the old system if you need to extend the deadline?)
Tool 3 - Calling out risks
Software engineering is unpredictable. It is important to call out risks to your stakeholders, so they can make alternative arrangements in case you don’t make the deadline. It is also good practice (and a sign of showing growth to senior engineer) to plan for mitigating each risk.
Some examples include:
Risk: Dependency on a new third/party service that is not yet ready. Mitigation: Fallback to an existing legacy service with a plan to migrate later.
Risk: Lack of expertise in a technology needed to be used in the project. Mitigation: Identify and request time from subject matter experts outside your team.
Risk: Team members falling sick/requiring unplanned leave. Mitigation: Identify other team members who can step in if required.
Feel free to lean on your manager, project manger, TPM etc to identify mitigations. But taking the initiative to drive this effort shows leadership skills.
Tool 4 - Reporting on progress
Track the project’s progress regularly (once per sprint is a good cadence) and report this to your stakeholders. This way, if your project is at risk of going off-track, your stakeholders will be the first to know!
Tool 5 - Course-Correction
You could deploy all of the above tools and still realize mid-project that you won’t make the deadline. Per the last section, the first thing to do would be to inform stakeholders of this.
In order to course-correct your project, you have the following options:
Ask stakeholders for a deadline extension: Do this if your deadline is not tied to an external non-negotiable deadline.
Ask management for additional resources: Do this if in your initial analysis showed the presence of parallelizable tasks. More people could help you hit the deadline in this case.
Ask stakeholders if you can deliver some nice-to-have features after the deadline: The priority order of features created in this initial analysis will come in handy here to identify which ones you can trim down to hit the deadline.
Continuous improvement
Once you finish the project, make sure you run a retrospective to capture why you couldn’t hit the deadline as planned. This will help you learn from your own mistakes and you will get better at this as you go.
Can you think of any other ideas to manage tight deadlines? Let me know via your comments, I’d love to hear them!
I was eagerly waiting for it ! Thank you 😊