A couple of years ago I was working on a very challenging and interesting project, which had many features competing to go live. We had a line of internal customers ready to use our product as soon as we added the features they needed, and everything was working fine as we had a clear roadmap to implement them.

One of these internal customers approached us, asking when we’d deliver the feature they needed to integrate with our service. The Product Manager replied that sadly it was not in our roadmap for the quarter, just as we had explained to them before.

This was aligned with the way in which our team worked, where the Product Manager decided the roadmap, in consultation and collaboration with the rest of the team and other stakeholders. So, everyone was caught off guard when another team member jumped in and publicly reassured our customer we could deliver in just a couple of days.

According to this person, who I’ll call John, there was no reason for us not to deliver that feature, because the code was ready, and we just needed to spend a couple of days to wrap everything up and ship it.

The person who wrote that code was on leave, and the only other person who knew about it was John. Without any additional information, and after John’s public promise, management decided to trust John and go ahead and deliver the feature for this insistent customer.

Once the project started, however, the house of cards started to fall apart. It didn’t take long to see that this project would require two people for at least two weeks. The code was just a working prototype, but it was not production ready, and we still needed to do testing, observability, interoperability, analytics, i18n, documentation, etc.

Some time later, John admitted that he made his claim based on what he had heard about the state of the code, not even having seen it or executed it. This is a reminder that making decisions based on assumptions, without taking the minimum time to validate them, is usually not a good idea.

Another big mistake that John made was to forget that code complete does not mean it can be shipped. This was not a side project that you could just run in your terminal and run again if it crashed. This was supposed to handle a significant number of requests per minute, be fault tolerant, and meet all our high standards for customer features and operations.

Those were important issues. But, in my opinion, the real problem was bypassing the Product Manager and making a commitment alone.

John really wanted to unblock the other team, but he should have tried to persuade the Product Manager, in private, rather than committing the whole team in a public forum. The key was to collaborate with the rest of the team, rather than put everyone in a position in which the only exit was to do as he himself thought better, bypassing all the internal procedures to prioritise and plan work.

Had John approached the team privately and shared what he thought, we could have allocated those three days to work on the feature, but without committing to the other team yet. That would have given us enough time to validate his assumption and deliver if he was right, or stop if we found any issues, as we did.

In the end, we completed the project after four weeks of unplanned work, and the other team was happy. This may not seem like a lot of time, but other teams that were waiting for their features had to wait longer for them, impacting their expectations and having to adapt to this unnecessary delay.

To me, playing as a team means taking care of each other, and that was missing in this situation. Everyone in a team is responsible for protecting the team from outside pressure, and aiming for the best outcomes for everyone. Validate, then commit, as a team.

Cheers,
José Miguel

Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.