How to create an engineering team that hits their deadlines

Does this sound familiar?:

Your customers are frustrated that engineering is not hitting their deadlines
Your customers are frustrated with you because you had to delay a feature launch again

If that’s the case for you, I’m going to go over a simple strategy that can help you and your team plan your work in a different way.

I’ve seen many times that teams struggle to hit their deadlines because they are overconfident in their skills and they don’t give themselves leeway to address unexpected surprises. The story often goes like this:

You say that something will take 4 weeks
By week three, it looks like you can still make it if everyone works hard.
It’s already week 6 and you are still fixing bugs before being able to ship.
Customers are angry that you haven’t shipped the feature you promised, they had announced it on their end that the feature would be ready. They are thinking about churning because they have business problems that have not been addressed.

It’s far too common to try to predict how long a project will take. There is plenty at stake as well when not hitting a deadline. What I’ve found is that it is not possible to predict exactly how long something will take in software engineering. You will often be off by anywhere from 1-4 weeks for every 4 weeks of scope.

What should I do instead then?

The solution that me and the teams that I work with have adopted is quite simple.

We agree on 2 dates:

An internal date: This is the one that engineering has as a goal, this is the date that your engineering teams aspires to hit when taking on a project.
An external date: This is the date that your team will communicate to customers.

I want to highlight the external date and go in-depth into what that one means. The external date is the one that if it changes, you have to communicate with the customers that were promised the feature if it’s going to have to change. It’s not the best feeling to have to move this date, but it’s usually the best long-term decision to still own the fact that you will delay launching that new feature.

Customers have plans around what you are building so it’s important to let them know. This is an invisible cost that is not so obvious to anyone in the engineering and product orgs but it’s something that is usually obvious to Customer Success teams.

And more in general, whenever you say you are going to do to something to anyone, you always stick to that and if you change your mind and decide to go with something different in something non-trivial, always communicate your decisions to whoever represents the customer, and that would usually be either Product or Customer Success.

If your team needs help hitting their deadlines consistently, checkout my Consulting page!