As a software engineer, I acknowledge that are a controversial topic. They have a considerable emotional impact on an organization and significantly affect team dynamics. deadlines Nevertheless, there are 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. genuine deadlines In this post, I want to explore a few aspects of , why they exist, and a few personal ideas on how to embrace them as software engineers. genuine deadlines 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, 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. deadlines As per the Cambridge Dictionary, a is deadline a or by which something must be done time day Cambridge Dictionary - https://dictionary.cambridge.org/dictionary/english/ 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 : 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. seize an opportunity 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 the customer. When this happens, the commitment could have a attached. win deadline 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 is communicated to the engineering team, there's most likely existing work in progress. A is therefore an to deal with. As with every context-switching opportunity, there is always a natural resistance toward it. deadline deadline interruption 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, : it's already too late when you get to know about it. handling a deadline can't wait 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 . It is likely that critical work is already in progress. Such work might even have a deadline attached to it already. reach a shared understanding of what this means for the organization interruption 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 . It's easy for this aspect to be underestimated, completely ignored, or left untold but it must be surfaced. deliberate about the impact that the deadline is going to have on existing work in progress 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 that everything is going to work out by the end date. hoping The Scope Accidental 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 is vaguely specified, scattered across different email threads, phone calls, online docs, and presentations. something I call this scope. This is to me the first inherent risk that engineering teams have to address. accidental 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 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. with 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. The accidental In this case, the scope easily results in overwork and additional stress for the people involved. accidental 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 scope is always going to be smaller than what the scope is going to be in the end. perceived actual 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 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. accidental scope 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 should not be perceived as something established the engineers that are going to be responsible for delivering. Rather, its purpose is to maximize opportunities for the company to succeed. deadline against 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 are needed. all hands on deck The team responsible for the successful delivery of the project needs to be involved and understand why the organization is allowing to disrupt existing work in progress. this interruption 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 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. interrupting 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 will lie beneath. accidental scope 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 that translates into the so-called . commitment bias sunk cost fallacy As the team progresses into the work, it might become apparent that . the it committed to far exceeds the gains expected from meeting the deadline accidental scope 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 . One of the most famous examples of this is the so-called . stop the bleeding Concorde fallacy Practice Deadlines Another option to prepare in the event of an 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. unexpected deadline 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 had we committed to this time? Was it better than the last time? accidental scope 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 in Agile contexts? . fit 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 states: Parkinson's law Work expands so as to fill the time available for its completion https://en.wikipedia.org/wiki/Parkinson's_law 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 and the actual scope of the project follows. definition of done 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 deadline can have on the team. new 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 @alediaferia@fosstodon.org , Twitter . Linkedin

This story contains new, firsthand information uncovered by the writer.

The Best Teams I've Worked With

How I got into programming and my thoughts on its future 

Embracing Genuine Deadlines as Software Engineers

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Adopt a DevOps Culture Before Looking for DevOps Engineers

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Adopt a DevOps Culture Before Looking for DevOps Engineers

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps