Delivering to an Impossible Deadline

Problem

A few years ago, I was managing a team tasked with building a feature that enhanced the performance and reliability of a core part of our real-time data plane. Although the plan was to eventually release it to all customers, the initial version was scoped around the requirements of a particular customer. Meeting this customer's immediate needs was critical to achieving our short-term, tactical objectives and also strengthened the long-term strategic relationship.

Unfortunately, we had already contractually agreed to a go-live date and MVP scope with the customer. Additionally, the team who would work on this was fixed due to geographical and system knowledge constraints. The fundamental problem we faced here should be readily apparent to anyone with basic project management experience: we grossly violated the "iron triangle" by fixing all three: the scope, schedule, and cost on a project.

Unfortunately, due to accidental complexity introduced during the evolution of the system, the architecture did not readily support the changes that needed to be made. When we explained this situation to the team, they became "less than happy." To make matters worse, before sharing the news with the team, they were hoping to spend some refactoring time to make the code more manageable.

Due to all the constraints, the team was feeling pushed into a corner, and they had no desire to work with that high level of pressure.

I admitted to the team that I knew I was placing them in a bad situation and acknowledged that I was asking them to pull a rabbit out of a hat. The question then became: How do you make the teams happy while delivering on the projects as it relates to timeline and deliverables?

Actions taken

One of the first things I did was ask the team what they wanted in return for delivering on this project. They asked for two things: 1) time and space to clean up the technical debt they'll accrue during the execution of the project and 2) the ability to move to another team that is better managed at the conclusion of the project.

Given the first request, I went to the business and told them that we can deliver the contracted scope on time, but will have to give the team six weeks afterward to clean things up. That means that immediately after launch, we can't go and add a bunch of features or build new other stuff, and the team should not feel like they are needed elsewhere.

To address the second request, I told the team that I would sponsor everyone that wishes to move to another team after the project was successfully concluded.

I also realized that I had made a classic mistake by underestimated the amount of context I have that was not shared by the team. Although the importance of the project was very clear to me, it wasn’t to them. This caused them to be demotivated as they did not understand the

“why” behind the pressure on this project. To solve this, I enrolled the help of the product manager to provide context and explain the importance of this project, for both the short- and long-term benefit of the organization.

After successfully delivering the customer requirements on time, we gave the team the six weeks they needed to get the code in the shape where engineers would be happy to work with it again. During this time, I shielded them from other distractions and gave them a break from my weekly project check-ins. After they cleaned up the code, we started the conversations about me sponsoring their move to other teams. 

Lessons learned

In the end, everyone was pleased with the outcome. Surprisingly, not a single member took me up on the offer to move teams. After they completed their work, I think they realized the value of what they delivered despite the imposed challenges. They felt supported in their venture to do their jobs and properly execute their project.

As they continued on the team, they become more ambitious and shipped more challenging changes. Eventually, they shipped additional features that were made available to all the customers, which counts in the millions. It can be substantial to see the impact of your work on that scale.

Every manager will be faced with this situation at least once in their career. For me, it is critical to be honest and admit that the situation is unfair. Show empathy and acknowledge this to the team. Do not try to sugarcoat it for them, don't try to hide it from the team, and don't try to sell them on it. Be honest and tell them you are asking them to go above and beyond. Find out what they want in return and negotiate a reasonable compromise.

Then, and this is the biggest takeaway: you must absolutely make good on the compromise. It is very, very easy to offer a team six weeks to go and clean up any issues or mistakes. However, it is tough to shield them for six weeks. The business is going to ask for something else from them the moment that they finish the project. The company will want this, and the customer wants that. But you must shield them. Tell the business that, after now pulling a rabbit out of the hat, it is now time to go clean the hat.

If you do not do fulfill your promise, you will burn the team. You will also burn your credibility and support an exploitative culture. But if you do keep your word, we will likely end up with a happy team. They will trust and respect you.

It’s important to reemphasize this as it’s very easy to make promises while under pressure without thinking through how to make good on them one day and then conveniently forgetting about them later.

By delivering on your promises, protecting your team, and considering everyone and their needs, you can be sure not to get burnt as a manager.