Skip to content

Managing to deadlines

Most software engineers have worked in a world where the deadlines are made up, inflated, messed with and decidedly fiction most of the time.

I’ve worked with sales folks who would give clients deadlines that were three weeks past the estimates they got from engineering, thinking they were being prudent and doing folks a favor – only to find angry engineers when they discover they worked through the weekend to hit the estimated deadline instead.

Worse, I’ve worked with folks who have mandated deadlines well before the _actual_ deadline, baking in time in the hopes it would accelerate development, only to trigger the same backlash.

Sometimes, despite best efforts, you reach a point where a deadline you’ve been working toward isn’t feasible, only to find out that it wasn’t tied to anything other than a quarter boundary or the original estimate, and it could have taken longer all along.

Any software engineer of any experience has run into this and been conditioned over their career that deadlines aren’t real, likely don’t matter, and might even be a bit malicious.

I had all that in my mind when I was chatting with an engineering leader recently who mentioned that they had to chip in extra to help their team hit a Monday deadline when their team faded as the weekend began.

My first question was “Did they know why the deadline mattered?”

Followed by: “Do you know why the deadline mattered?”

If you’ve built a team that cares and align them with a valuable why, they can run through walls for you. When you don’t provide that why, all this prior history pops up and even the most generally enthusiastic engineer can balk at working through the weekend to hit what might sniff like an arbitrary deadline.

In this case, the engineering leader had a deadline philosophy a bit like mine I believe – they inherently wanted to hit the deadline – but they hadn’t communicated why the Monday deadline was important to their team, instead jumping to “We need to work this weekend to accomplish this goal.”

Add in an already stressed developer at a typical software startup (hint: they all are!) and that’s enough to push them past the red and into shut down.

Ways I’ve helped with this in the past:

1. As soon as there is a deadline agreed to, communicate it

If you’re in a planning meeting, and a deadline comes up, note it and communicate both to your team and the larger organization that’s also going to end up aligning to that deadline.

Deadlines are agreements on how different organizations and departments work with one another. You agree to hit deadlines, and they agree not to bother you about it until the deadline becomes questionable.

Deadlines are agreements on how different organizations and departments work with one another.

2. Explain the full timeline that the deadline is part of

When you communicate this to your team, you often can explain why even an early deadline is important by outlining what happens after the code is pushed.

In many organizations, code completion is when departments like product marketing, sales enablement and customer support kick in gear to actually get your team’s code ready for a product launch.

If your team knows that there are other folks waiting on that deadline to begin their own work, it helps put the effort required to hit the deadline into the proper context – your work alone is not the finish line, but the starting line in many cases.

Aside: this is also why launch dates should not be engineering deadlines. It’s not fair to other departments when engineering is working until the last minute.

3. As the deadline approaches, confirm its concreteness

I alluded earlier to the squishiness of many deadlines. Engineering estimates often run long – governed as all things by Hofstadter’s Law – and many organizations are predisposed to mentally planning for this.

As the deadline approaches and things start looking dicey on getting the work done by the agreed upon time, it’s useful to check what the downside of missing the deadline is.

Can the launch get pushed out by a week? Two? More?

I learned over the course of my career to start checking on this earlier and earlier. I’ve been particularly bad at this at various times because I’m an optimist and a problem solver at heart, and can always see a way to the best possible outcome.

I had to get bitten by this enough to learn a simple fact:

Nobody likes surprises at deadlines.

4. If people have to work the weekend, you’re working as well

My coffee conversant did this part right. As an engineering leader, if you’re asking your team to work extra hours to hit a deadline, you’re working, too.

If you can’t code, you’re cheering from the sideline and unblocking when questions come up.

If you’re still in-person, you’re buying the literal or metaphorical pizza for the heroes who are cranking widgets through their free time.

Make an effort, make sure their efforts are appreciated and be present.

5. Make sure your retrospective asks how the weekend work could be avoided

In the aftermath of this sort of situation – either a herculean effort to meet a deadline, or a missed deadline entirely – your next team retrospective should cover the topic extensively.

As an engineering leader, part of your job is to ensure your team doesn’t need to work the weekend in order for their work to be done.

Similarly, as a group, if you agree to a deadline, and then you don’t hold up that agreement, you lose a bit of trust with the larger organization and you need to work on repairing that trust and ensuring you don’t dig the hole deeper the next time a deadline comes along.

If you agree to a deadline, and then you don’t hold up that agreement, you lose a bit of trust with the larger organization

Oh, and if you’re not running team retrospectives, I shared some of my upcoming book on retros on my newsletter.

Leave a Reply

Your email address will not be published. Required fields are marked *