Software development teams perform a myriad of different tasks at work. From day-to-day tasks like attending meetings to more outstanding tasks like a complex migration, every task is different in nature and scope, and, as a result, so is its urgency.
Recognizing the type of task at hand is paramount for deciding if it warrants a hard deadline or not. The ability of a tech lead, manager, or individual contributor to choose which tasks to assign a deadline to plays a key role in team happiness and team creativity as a whole.
Table of contents
Recognizing When a Task Requires a Deadline
Not all tasks are created equally. Some lend themselves naturally to have a deadline, while others can be done without any pressure or, at least, not with a hard deadline set.
In my experience as an IC, I came to identify mainly three types of tasks that make up the bulk of my work. Each type of task can have different needs when it comes to deadlines, and I will outline such needs with each task type:
- Day-to-day work: The normal day-to-day work for a software developer usually consists of pulling in tickets from a backlog into a sprint and working through them for the sprint duration. These tickets can be for extending existing functionality, updating documentation, arranging for cross-team meetings, refining work into manageable chunks for an upcoming sprint, bug fixes, etc. Given this work's continuous nature, deadlines are usually rarely put in place or enforced. Since this work simply needs to happen, there's this "sliding window" aspect to it: if it's not done this sprint, we'll do it next. This approach to work makes it naturally deadline-free;
- Critical work: I view critical work as work requested by clients or work that is dependent on specific deadlines imposed by third-party vendors or tools. If your authorization provider is sunsetting their services by day X, then you have until day X to migrate all your customers and build a custom solution or switch vendors. The same goes for a critical client request, for example. In this type of work, there are usually hard deadlines that you can't afford to miss;
- Research work: Some of the tasks assigned to someone will be greenfield tasks that have never been done before within the team or the company. In these cases, the bulk of the work usually comes from researching existing approaches in the industry, what has been tried or not tried, if something can be adjusted, or if a completely custom-made solution needs to be built altogether. Due to their nature, these tasks are well suited to a timebox deadline. A timebox deadline is simply an agreed-upon amount of time that will be spent on the task, regardless of whether or not it gets completed. The idea is to simply report the findings once the timebox period ends;
Enforcing a Deadline or Letting It Slide
What is the purpose of setting a deadline for a goal?
Not all work is similar in nature; neither are deadlines. Sometimes a deadline can be seen as an expectation for when something is expected to be done, and, sometimes, it can be a true dealbreaker that can make or break a project or a contract. Recognizing the different situations and types of deadlines that apply to each is key in keeping deadlines meaningful and relevant for a team.
No team wants to be under pressure to meet a deadline for a specific deliverable just to have it pushed back further down the line because the deliverable was later deemed unimportant.
It's the responsibility of team leads and/or managers to ensure that these situations are rare and don't happen that frequently. They need to assert when a situation is volatile enough that maybe a sliding deadline is better than a hard one or when a deadline must be met. This can be a joint effort between leads and developers within a team:
- Look to the past to predict the future: Over time, a certain track record of proven deadlines that were either made or missed will start growing within the scope of a given team. Analyzing these situations and identifying which set of aspects led to their success or failure is a useful exercise in predicting future outcomes based on existing structures. If team composition feels similar, if stakeholders are shared, and if the nature of the task at hand can be mapped to previous efforts, an estimate can hit the target pretty well. This is also a great example of how an outstanding engineering culture is built within the team.
- Be transparent about the outcomes: Miscommunication can be a real obstacle to ensuring deadlines will be met or that their urgency is well-understood by the developers who will be the ones who need to do the real work. By being transparent about the expectations, i.e., if a deadline can be missed or if it needs to be strictly enforced, the chances that everything will work out as intended increase significantly. Without transparency, expectations can’t be well-defined and when that happens, any type of deadline will be missed, no matter how important it might be;
- Allocate people correctly: This is indirectly tied to the previous point. Depending on the nature of the deadline, there might be the need to assign more people to a given task because of its importance. When done wrongly, this allocation of team members to the wrong tasks can impact team’s morale and performance and its ability to meet deadlines and might even lead to tech burnout.
Knowing when to let a deadline slide or not is a key skill for managers to have. It will directly affect the team’s capability to respond to change, their morale, and their capacity to foster creativity to meet any possible deadline that gets thrown their way.
Deadlines as Means to Foster Creativity and Happiness
So far, we have looked at the different types of deadlines and work, and how they connect. We are now in an excellent position to see when exactly setting a deadline can be beneficial for a team and help it grow by enabling all its members to do their best work while being under pressure to meet a deadline.
Do deadlines destroy creativity?
Not all the tasks can simply be slapped on a deadline and be expected to be completed perfectly by the due date. Many factors can affect the way developers perceive deadlines and if there's any chance of them being met at all or if it's just something destined to fail.
In my experience, it usually falls under finding the right combination of the type of work and deadline that works best to empower developers to do their best work. In many cases, a timebox-style deadline combined with a well-defined research task offers the best results possible. Why?
Because developers know exactly what the expected intended outcome of the task will be. They have a reference time frame to work against, so they can also measure their progress while simultaneously knowing that no real harm will come if it ends up taking a bit longer than expected.
This type of work is the perfect way to boost team happiness. It comes with a certain degree of freedom that developers would not be possible to find in a bug fix or in fixing a critical production outage. When there is the freedom to explore different avenues to reach a solution, and when there is time to assess trade-offs and implement things carefully, a lot of developers can truly find joy in their work. They will have that nice feeling of accomplishment, which is a great nod to the optimal mental health in the working environment.
Conclusion
We looked at how deadlines intertwine with the different times of work they get associated with. We also saw how that association could shift the stance of managers and teams when it comes to deciding what is the most critical piece of work to focus on next.
Usually, finding the right type of work and combining it with the right type of deadline, all the while taking into account the organizational dynamics, the availability of colleagues, and the urgency of external stakeholders, is key to maximizing developer happiness and fostering creativity.
