So as I mentioned a few months ago, I’d made a concerted effort to regularly author blog posts. But, all excuses aside, I was impacted by the hurricane last week and didn’t get a blog post written.
Now, to be honest, I’m always a couple of blog posts ahead and I’ve authored a couple of “spare” blog posts, so I was tempted to just use one of those. But I also saw this as an opportunity to discuss a topic that is actually pretty important.
What do you do when you miss a deadline or delivery?
This is subtly different than making a mistake. A mistake is when you discover a defect in production, or even in dev or staging. Yes, that can have an impact on both cost and schedule because there has to be effort expended to address the mistake. But I’m talking about when a customer or stakeholder is expecting you to deliver something by a specific date, either an artifact or completion of a milestone, and that date passes and you didn’t deliver it. What then?
This is tough for a couple of reasons. The obvious one is, of course, the schedule impact, but a more nuanced one is the loss in customer trust. Every time you miss a due date there’s that little bit of trust that is eroded between you and your customer. They start to wonder whether you will miss other due dates, and what impact this will have on them and their business goals.
So I’ll be honest. I’ve made a mistake or two in my career, and I’ve missed one or two due dates. Well…maybe more than one or two. And in my experience, here are some key things you should do when this happens.
Own It, Fix It, and Learn From It
Looking back in my career, there are two different ways I’ve talked to customers about missing deliveries. The first was, as I called it back then, was “take control of the narrative”. I would say something like, “Yeah, we had some unexpected setbacks, but we are bouncing back, in fact, we’ve learned some things so the eventual solution will, in fact, be better than ever!” and so forth.
But one time, I was leading a software team, and we missed a delivery date. Instead of trying to talk my way around it, I just sat down with the customer and just “owned it”. I told them we missed the deliverables, that I took responsibility, and that we would work to make it right. There was no positive spin, but the customer (in that particular scenario) appreciated my honesty and was willing to work with us to move forward.
When it comes down to it, I’m a believer in transparency and ethics, even when the truth is ugly. I would rather be honest and upfront with my customer. It has taken a long time, but experience has shown me, in the long run, this really is the better way to earn trust with your customer, even if it is painful in the short term.
The next step is to quickly and decisively come up with a plan to deliver. This might mean reshuffling your entire backlog and sprints, but the best option to regain that customer trust is to figure out how to meet your delivery commitments as quickly as possible.
I realize you might have contractual or business constraints that limit what you can do, but I would urge you to find creative and innovative ways to flex in your customer’s favor as much as you can. Earn their trust back by showing them that you care about them, and are willing to go to bat for them.
This might, again, mean some pain in the short term, especially if it means adjusting your sprint plans and task prioritizations. But responding to a missed due date by rising to the occasion to meet your customer’s needs can actually earn back some of that customer trust in the long run.
Learn From It
A very common interview question is, “Tell me about a mistake you’ve made.” But a key follow-up question to that is, “And what did you learn from that mistake?” What do you want your answer to that to be? Do you want to say something vapid like, “Yes, I learned I should be more careful when running the ‘rm -rf’ command.” Or do you want to have an awesome answer like,
“I went and did a quick refresher training video on privileged user best practices, and started incorporating things like using a different shell prompt when I’m root, and also testing my rm -rf command first with ls. And one time, when running ls first I realized I was in the wrong directory and it saved me making a big mistake!”
Have a real, no-kidding review of what caused the missed delivery, and take real, no-kidding actions to prevent those things from happening again. Whether this means adding checklists, changing behaviors, or adjusting the ways you do things in sprint planning or with issue management, think about how to actually make your team and organization better and not just play it off as a one-time mistake.
Everyone makes mistakes, and I like to joke that experience just means you’ve made more mistakes. But you have to grow and learn from your mistakes for that experience to mean anything.