Embracing Genuine Deadlines as Software Engineers

As a software engineer, I acknowledge that deadlines are a controversial topic. They have a considerable emotional impact on an organization and significantly affect team dynamics.

Nevertheless, there are genuine deadlines in business. I consider a deadline genuine when it’s there to help the organization seize an opportunity. This is the case when the chosen point in time constitutes an advantage for the customer and/or your organization.

In this post, I want to explore a few aspects of genuine deadlines, why they exist, and a few personal ideas on how to embrace them as software engineers.

---

Before starting to work on this blog post, I found an old draft of an article I wanted to write a long time ago. It was decisively against the concept of deadlines and argued how quality is hard to deliver when working towards a deadline.

I was coming from the perspective of an individual contributor passionate about the art of crafting software and completely disregarding the business aspect of building products that deliver value.

My thinking has definitely evolved: As I take on more management-focused roles, and over the last years of my career as a senior individual contributor, I've come to the conclusion that deadlines are a great opportunity to facilitate team effectiveness and bring the whole organization together towards a common goal.

At the same time, I am conscious of the stress and mental health implications they might have if abused.

What Are Deadlines and Why Do They Exist?

In most contexts, deadlines are just part of the job. When software is the revenue generation engine for an organization, it must abide by the rules of time and business.

As per the Cambridge Dictionary, a deadline is

a or by which something must be done

Cambridge Dictionary -

When deadlines are genuine, the point in time is considered an advantage for the customer and/or your organization.

By setting a deadline, the organization wants to seize an opportunity: be it to win a new customer, retain an existing one, or more strategically generate interest in the company, for example, by presenting new functionality at an industry event.

More commonly, in B2B industries, you might have worked to implement specific functionality to win your next customer.

There might be a contract coming to an end, and the potential customer highlights how interested they are in your product, though it lacks a single feature that would fit their use case.

In this scenario, your organization might decide to commit to delivering the requested functionality so as to win the customer. When this happens, the commitment could have a deadline attached.

In this case, the commitment is strictly linked to a revenue opportunity that your organization wants to seize. Regardless of why, a deadline is often a fixed point in time by which the organization is supposed to deliver functionality.

So, There’s a New Deadline. Now What?

When a new project with a deadline is communicated to the engineering team, there's most likely existing work in progress. A deadline is therefore an interruption to deal with. As with every context-switching opportunity, there is always a natural resistance toward it.

Depending on the maturity of the team, some might even tend to ignore it until they are done with what they're working on.

Unfortunately, handling a deadline can't wait: it's already too late when you get to know about it.

I'm not talking about dropping all your current work and starting coding straight away without even knowing anything. But, as I'll explore further in the upcoming paragraphs, it's important to start assessing the scope and risks of the project.

In my experience, the crucial first step is to reach a shared understanding of what this interruption means for the organization. It is likely that critical work is already in progress. Such work might even have a deadline attached to it already.

Therefore, it's paramount that everyone understands how this is going to impact existing commitments.

Disrupting existing work in progress is sometimes a necessity. Other times, there might be enough capacity to handle the new deadline without considerably impacting the current commitments.

Nevertheless, it's important that everyone is deliberate about the impact that the deadline is going to have on existing work in progress. It's easy for this aspect to be underestimated, completely ignored, or left untold but it must be surfaced.

In this, the engineering team has a huge responsibility: being transparent and raising concerns early is the best way to facilitate deliberate actions as opposed to hoping that everything is going to work out by the end date.

The Accidental Scope

Committing to a deadline might happen without engineering being involved. This is usually the case when departments other than engineering deal more directly with customers and better understand the opportunities arising out there.

This is arguably quite a common scenario across industries. The teams working on opportunities for growth are separated from the ones building the product.

Once a deadline is established, an implicit scope comes naturally with it. The organization has now committed to delivering something, and this something is vaguely specified, scattered across different email threads, phone calls, online docs, and presentations.

I call this accidental scope. This is to me the first inherent risk that engineering teams have to address.

The accidental scope leads to the disconnect between what the customer expects and what the organization is ultimately going to deliver. Depending on the complexity of the problem you are solving with your product, the disconnect might be wider or narrower.

For example, a new customer might need your product to account for very peculiar cases that only apply to their context.

The Deadline Is Your Last Chance

This type of disconnect hardly surfaces until the product is in the hands of the customers unless your organization is able to iterate on the solution with the customer. When this doesn't happen, the deadline will be the first time you are going to get feedback on what you have built.

The accidental scope also means that, as the deadline approaches, further interactions with the customer might surface additional unforeseen requirements, putting the project at risk of not delivering on time.

In this case, the accidental scope easily results in overwork and additional stress for the people involved.

My recommendation to the decision makers for a deadline is to not underestimate the scope and strive to keep it as concise and defined as possible. The perceived scope is always going to be smaller than what the actual scope is going to be in the end.

This, of course, is a complex balancing exercise that has to keep the customer's needs into account.

Engineers, Act Now!

As we've explored what the accidental scope is, I focused my analysis on what usually happens outside of the engineering organization's control. Let's spend a few words, now, on what engineers can do when dealing with deadlines.

While the decision of taking on a project by a certain date might have been outside of the engineers' control, the success of the initiative is heavily dependent on the act of building what's been promised, and therefore on the engineering organization.

Working Toward the Same Goal

At times, the act of handing over responsibility from the people committing to the deadline to the people that have to build the software might lead to frustration and antagonism. This could be the case for a multitude of reasons.

Some of them might be: an (accidental or deliberate) lack of transparency about what the company is trying to achieve, a history of unreasonable expectations around existing commitments and new deadlines, or general political issues across departments.

I won't go into the details of these organizational issues as part of this post but I just want to stress how important it is that all the departments involved work together for the success of the project.

The deadline should not be perceived as something established against the engineers that are going to be responsible for delivering. Rather, its purpose is to maximize opportunities for the company to succeed.

For this reason, working to surface such expectations and consolidate a shared understanding of the scope of the project is the first step toward the success of any deadline-driven initiative.

And yes, difficult conversations are to be had, likely about realigning hopes and dreams of what the final product will be like by the committed date.

Since a time commitment has already been made externally, it naturally follows that a sense of urgency is needed when being made aware of a deadline.

The sense of urgency needs to drive the next steps of your team when it comes to understanding the scope and gaining confidence about what you think can be delivered by the given date. Such confidence is going to be needed when renegotiating scope and, sometimes, the deadline itself.

The earlier you start this risk mitigation exercise the better all the involved parties will be able to handle any potential project miss.

Empower the Team

Most likely, the team is already engaged in a workstream, so it might have a natural tendency toward resisting the change of context and pretty much ignoring the deadline until it's too late.

While shielding the team from unneeded interrupts is definitely important to facilitate quality work, there comes a time when all hands on deck are needed.

The team responsible for the successful delivery of the project needs to be involved and understand why the organization is allowing this interruption to disrupt existing work in progress.

As a member of the team, don't be shy about asking questions. Understand why your organization is doing this, what the company is trying to get out of the initiative, and what the impact is on existing initiatives. Take ownership of your part, and feel free to talk with the stakeholders.

If you're unsure or blocked on something, be proactive: chase somebody who might help you as opposed to waiting until the next day's stand-up to raise your issues.

If you are a leader, make sure the team has access to all the information they need. This is key to promoting the sense of ownership that is needed to drive the initiative to succeed.

A sense of ownership empowers people to find solutions and be autonomous when making decisions that have the success of the initiative as their north star.

As a Leader, Shield Your Team

Engineering leaders should help teams accept the interrupting nature of deadlines and adopt practices that minimize the disruption they cause. At the same time, it's important to work to minimize the negative impact that deadlines have.

Balance

If, as a leader, you are heavily engaged in day-to-day software development activities or tasks on the critical path for your team, you might have a harder time preparing the ground for your team when it's time to address a deadline.

I don’t have a recipe for guaranteed success here, but in my experience, team leaders should be deliberate about the time they spend on critical software development activities, especially in highly interrupt-driven environments like startups might be.

As a leader, taking on big chunks of work on the critical path for the team’s success jeopardizes your effectiveness at guiding the team through all those activities that require significant expectation management efforts and negotiations.

Since deadlines are going to disrupt work in progress, you might want to create opportunities that help surface them early.

Additionally, try to use recurring meetings with your team as the place to communicate with them: This helps keep the number of interrupts down so that the people on the team can enjoy as much time of uninterrupted stretches of work as possible.

Recurring meetings with other departments outside of engineering can also be a great opportunity to help surface deadlines early. You might become aware of initiatives that have the potential of resulting in a committed deadline.

At the same time, you can use it as an opportunity to communicate what the team is currently focused on and what consequences interrupting that work might have.

Make the Hard Decisions Early

Protect your team from overwork and burnout.

While on the one hand, having a fixed point in time to work toward helps better define the scope of the initiative, it might also add significant stress to the people on the team: This is even more so if considerable work is still left to do while the date is approaching soon.

Early and frequent check-ins and visibility of the work in progress are some of the tools an organization has to help keep honest and identify risks of missing the deadline in advance: When this happens, it's time to try and renegotiate the date (if possible) or pull out of the commitment.

Renegotiating a date, though, usually requires a new time commitment. This time you want to be confident that you can deliver by the new point in time.

Careful: The bigger the scope you had committed to, the higher the accidental scope will lie beneath.

If you are going to renegotiate the date, the engineering organization should take the time to pause and assess how much work has been done and how much is left before being able to recommend a new date.

Stop the Bleeding

Pulling out of a commitment is also an option, and it is often an overlooked one. This is frequently because of a commitment bias that translates into the so-called .

As the team progresses into the work, it might become apparent that the accidental scope it committed to far exceeds the gains expected from meeting the deadline.

Maybe it was deliberately decided to implement functionality only for the purpose of the demo, but as the date approaches, it's become apparent that the investment in building it far exceeds the expected gains.

The time (and money) spent so far might mislead the organization to keep pursuing the endeavor even if stopping the work would help stop the bleeding. One of the most famous examples of this is the so-called .

Practice Deadlines

Another option to prepare in the event of an unexpected deadline dropping on your team is to master the art of committing to a fixed point in time. As part of the day-to-day work, make sure your team strives to split the work into chunks of comparable size.

Once that's done, try to always commit to an internal date. Then, as part of your retrospective meetings, review how you did. Compare the size of the items you completed and evaluate how far or close they were to the initially committed date.

Continuous iterations of this type of exercise will help your team's confidence when it comes to assessing the scope of a deadline-driven initiative.

A Learning Opportunity

Handling deadlines, like it or not, is part of your job as a software engineer. Fighting or ignoring them is hardly going to make them go away. Rather, think of them as a learning opportunity.

If you've been deliberate about working towards a deadline, you will have spent time on activities like requirements gathering, estimations, expectation management, and, hopefully, development.

Once the project is delivered (or if it is at all), take the chance to learn from it: Retrospectives are a great tool to look back on and understand any improvement opportunity you can take home for next time.

Additionally, consider cross-departmental retrospectives where you have a chance to reflect as an organization on what went well and what went wrong. Consider the following questions:

• Did we deliver?

• How close was the deliverable to what had originally been envisaged?

• How much accidental scope had we committed to this time? Was it better than the last time?

• Were we all clear about how disruptive this was going to be on existing deliverables?

• As an engineering team, were we clear about what was actually going to be delivered?

These types of questions recap what we have discussed so far and help your organization align on the success of the initiative; as well as on what to change to have better chances of success next time.

Deadlines & Agile

I've heard the argument that deadlines do not fit with an Agile way of working.

Do I think deadlines fit in Agile contexts? YES.

I have no doubt that Agile methodologies are the best way to handle deadlines. A deadline gives you a fixed point in time to work towards. There is no better way than a constraint to help turn an idea into a concrete output. A time constraint even more so.

I think this is because by fixing the time quantity, you're left with an understanding of how much scope fits the constraint and can focus all your energies on that.

As the humorous Parkinson's law states:

Work expands so as to fill the time available for its completion

While this might be true due to dysfunctions, that is a bold statement. In highly effective Agile contexts, a solid definition of done protects you from never releasing software, even if you don't have a deadline.

As we have seen in the scenario described at the beginning of this post, in some circumstances, the desire of seizing an opportunity becomes part of the definition of done. Meeting the specific point in time is believed to be a significant advantage for the company.

When this happens, meeting the deadline becomes part of the definition of done and the actual scope of the project follows.

Deadlines are a reality in business. When they happen, an Agile approach can help you handle the work effectively.

In particular, visibility of the work in progress can help form a shared understanding of the disruptive effect that a new deadline can have on the team.

The fixed point in time will help your team prioritize the aspects of the functionality that have the biggest impact on a given estimated effort.

Continuous iterations ahead of the deadline help you validate that you're building the right thing and avoid unexpected surprises at the *big bang * deadline event.

---

If you've enjoyed this post, please share it within your circles. If you want to follow me on other social networks, check me out at , , or .