How many conversations have you had about deadlines where at least one person scoffed at the concept? Pfft!
I have heard this a number of times — including from myself — and I want to fix this.
The world of software is very different from the world of print media, where our current concept of deadlines is derived. However, just because there can be no universal definition of deadlines across all software projects doesn’t mean we shouldn’t use them or that they aren’t valuable.
Deadlines are extremely important for planning and parallelizing work. Without expectations about when dependent work will be completed, all teams would have to work in serial. This would drastically slow down delivery times.
At the same time, deadlines can be frustrating and counter-productive if people disagree about what they actually mean.
Problems and solutions
In my experience, these are the most pertinent problems with deadlines in engineering organizations, and the most promising ideas for how to solve them.
1) They are interpreted differently from person to person.
Person A: “The deadline is next week so I’m pulling a ton of extra hours.”
Person B: “Why? It’s a fake deadline and doesn’t matter.”
Person A: “But I don’t want to get fired!”
This shows that a deadline means vastly different things to Person A and Person B. This can lead to confusion and frustration on the team working towards that deadline.
Instead, deadlines need to be a rallying point. Everyone needs to understand why this deadline is important. They need to know what impact missing the deadline has on their world (that can be other teams, customers, or the business as a whole).
More importantly, deadlines that are met need to be celebrated. Wildly. This is often overlooked. Building a culture around celebration for meeting deadlines is a much better practice than berating people for missing them.
2) They are used too early in a project life cycle.
Person A: “Hey we need to accomplish [insert_really_hard_unknown_thing]. When can we have that done by?”
Person B: [quickly wikipedia’ing what that thing even is] “uhhhhh, I don’t know.”
Person A: “I need a timeline!”
Person B: “Thre–FOUR! mmmmo-wee-months. Four. Months.”
Person A: “Great, see you in four months.”
Asking for a deadline when EVERY aspect of a project is unknown is a recipe for disaster. It’s stressful for everyone involved and sets the project up for failure. So let’s take a deep breath. Wait a few days for some exploration to be done. We will be spending time to buy information, but then we can come up with a meaningful estimation of the work. This information will help us set deadlines that have a better chance of being accurate.
3) They aren’t updated often enough.
Person A: “Hey, deadline is in 5 days. Are we still on track?”
Person B: “We’re a little behind but yeah, we can make it.”
Person A: “Great!”
[ 4 days, 23 hours later ]
Person A: “Just checking back on that project. We good to go?”
Person B: “Uhm, no we’re not gonna make it. Something came up. It looks like another week of work.”
Person A: “$%@!*”
In this case, the deadline wasn’t moved or re-evaluated when new issues became known. Instead of raising that flag immediately, Person B waited until the deadline itself to inform others. Now Person A is affected as well AND the team gets to feel the stress of coming up on yet another deadline in the future.
Deadlines shouldn’t be set to force humans to do inhuman amounts of work. They should be used to set expectations externally and enable a sense of predictability for planning. They need to reflect reality as accurately as possible or trust is lost and they can no longer deliver that predictability. Now, I’m not advocating for changing deadlines hourly or daily. But perhaps weekly, or at the very least within a standard planning cadence.
Updating a deadline isn’t limited to extending the date. Scope reduction is also an option. Choosing which action to take (or a combination) is a conversation the engineering and product teams need to have.
4) All the “knowns” aren’t taken into account… just the fun ones.
Person A: “How long to ship this feature?”
Person B: “Two weeks.”
[ two weeks later ]
Person A: “Why isn’t this done?”
Person B: “Well, it technically IS done. Now we’re working on testing it, building a new deployment mechanism for it, and we’re gonna roll out a beta first. Also, I was on vacation last week.”
This deadline was made without a complete understanding of the work to be done, and the time to dedicate to it. (not to mention Person B also threw problem #3 into the mix.)
We need to make sure we take all known challenges into consideration when determining a deadline. Will we be losing person-hours to a known cause? Vacation? Company offsite? Birthday party which will cause missed mornings due to hangovers?
Also, what un-sexy tasks are we potentially forgetting about? How many tests are we gonna write for this? How do we get this sucker into a production environment? Slow down and think thoughtfully about your process and the availability of resources. It’ll make your deadlines much easier to deliver against AND it will make deadlines easier to defend against scrutiny.
On estimation: uncomfortable but necessary
Deadlines that are set by engineering teams will largely be informed by estimating work. That means that everyone on the team is going to have to get comfortable with being wrong. A lot. Saying anything that you know to be wrong and have little confidence in can be a very difficult thing to do.
We need to have a collective understanding that it’s our best guess and that we’ll get better at it over time. Estimation is a skill that gets better with repeated use. In the early stages, it’s going to feel uncomfortable, but we need to do it.
Estimating tasks
Before we can define the delivery date of a large project, we should break the project down into tasks, where tasks are defined as things we believe we can accomplish in roughly 5 workdays or less.
Some helpful questions to ask when estimating a task:
- Is the project green field or in a pre-existing area?
- What is the quality of code in that area?
- How well do I know the area of code?
- How familiar am I with the programming languages involved?
- What touchpoints or integration points with other pieces of code are there?
- How good is existing test coverage?
- Does this work touch any business-critical areas? (write path, billing, load balancers, signups)
- Has anyone done this work before? What are their thoughts?
- What are the tradeoffs I am making?
- What is the objective of this task?
- Does this task need to be done at all?
Estimating projects
Projects are typically defined as a larger body of work that multiple people can work on in parallel.
Some helpful questions to ask when estimating a project:
- How much time will we actually be dedicating to working on it?
- What is the objective of the project?
- Do we have any known days off?
- What are ALL the tasks required to be done?
- Do we have any blocking dependencies on other teams?
- Are any tasks blocking other tasks in the project?
- Is any new infrastructure/hardware required for this project?
- What are the Doneness Criteria for this project?
Doneness criteria
Even knowing when something is done is difficult. Different roles within the team can have different perspectives on “done” so we need to have specific criteria that can determine what that means for the project.
Some examples of typical Doneness Criteria:
- Deployed in production
- Tests fully automated
- Communicated internally or externally
- Spent a certain amount of time in an internal or external pilot
- Documentation in production
- Education of sales or marketing team complete
- Landing page launched
- Analytics and tracking
- Operational runbook and observability
Conclusion
Deliverability is essential to any company as it grows and matures. Deadlines are a major tool in the toolbelt. When used properly, they are incredibly useful. But it takes time and practice to get better at using deadlines. So, I suggest that engineering organizations treat them as alive and breathing, continue to learn about them, and document shared experiences internally and with the engineering community.
If you have any tips or suggestions on using deadlines effectively, we’d love to hear them. You can drop me a line at ryan@keen.io or ping us on Slack
Subscribe to stay up to date on future software engineering posts (no spam, ever):
