One of the questions I often encounter as a delivery manager is how to balance speed and stability, especially when we’re under pressure from tight deadlines. However, I would argue that there’s a fundamental issue with the premise of this question: why are we under such tight deadlines in the first place? More often than not, these deadlines exist because stakeholders lack confidence in our ability to meet them. This is the absurdity of deadlines.
Let’s consider the nature of deadlines. Some deadlines are imposed by external factors, such as regulatory requirements. For instance, if a government introduces a new regulation that our software must comply with, we might face a deadline that seems absolute. However, even in these situations, we have options. We can choose to pay the fines for non-compliance rather than rush to deliver a feature that may not be ready.
Here are a few key points to consider:
Assess the Real Cost: What is the cost of building a feature quickly? What are the implications of pushing for speed? If we rush, we risk tripping over ourselves, leading to a product that could damage our brand and erode customer trust.
Quality Over Speed: It’s crucial to deliver features with the right capabilities and quality. Shipping a poor-quality product can have long-term repercussions that far outweigh any short-term gains from meeting a deadline.
The Fine Dilemma: While paying fines may seem undesirable, it’s often a more viable option than delivering a subpar product. The fines are typically much smaller than the potential costs associated with a failed product launch.
Reflecting on my experiences, I recall the case of Zoom during the pandemic. As their user base skyrocketed, they faced a critical decision: cap the number of users or scale up their infrastructure. They opted for the latter, prioritising user growth over quality. This led to significant compromises, including the disabling of encryption features, which had been a key selling point.
This decision had dire consequences. Many organisations still block Zoom due to concerns over security and trust. It’s a stark reminder that reducing quality to ship features faster can backfire spectacularly.
So, how do we strike a balance between speed and stability?
Prioritise Stability: Stability is paramount. It’s far more important than speed. If you find yourself in a situation where you must choose, always opt for stability and quality.
Make Ethical Choices: Avoid the temptation to cut corners. The easier, cheaper path may lead to ethical dilemmas that can tarnish your brand and reputation.
Communicate with Stakeholders: Educate your stakeholders about the implications of rushing projects. Help them understand that quality work takes time and that the long-term benefits of a stable product far outweigh the short-term gains of speed.
In conclusion, while the pressure to deliver quickly can be overwhelming, we must remember that the foundation of a successful product is built on stability and quality. If it means paying a fine or missing a deadline, so be it. Let’s commit to doing things well and properly, ensuring that we maintain the trust of our customers and the integrity of our brand.
So one of the questions I often get is how do we potentially, as delivery managers, balance the difference between speed and stability? Right, when you’re under pressure for tight deadlines. And I’d assert that there’s a fundamental problem with the question, and that’s that we’re under tight deadlines. Why are we under tight deadlines? We tend to be, because let’s be honest, most deadlines exist because people don’t believe you can meet them. That’s why a deadline—this is the ridiculous thing about deadlines.
So there are some deadlines which are not even real deadlines that are coming, the external deadlines. Right, so let’s say you’ve got a business, you’re something within the context of, let’s say, a regulated thing. Something’s regulated by the government. The government brings in a new rule, and your software does not currently comply with that rule. And the government says, “By this date, if you don’t have compliance, we’re going to start finding you x amount of money for every day that you’re not compliant.” Right? That, for many businesses, they would decide that that’s just an absolute deadline. But the reality is that’s not even an absolute deadline either. We can pay the fine, right? We can pay the fine. How much is it going to cost to build a feature? How long is it going to take? And what are the implications of trying to push for that feature to come out faster than we are able to deliver that feature? Right?
People are going to start tripping over their feet if we start pushing them too hard. They’re going to fall on their face, and if they fall on their face, the software is going to fall in its vase. What’s the impact of that on our brand and our business? And is it worth the fine? Normally, the fine’s a lot smaller than the cost implications of going too fast. So long-term, you’re probably not wanting to pay all those fines, right? But short-term, you need to build the feature in the right way, with the right capabilities, with the right level of quality. Otherwise, you’re going to start eroding your customers’ confidence in your product. You’re going to start eroding the brand awareness of your company. This is not okay, right? It’s not okay to ship poor quality, unstable product under almost any circumstances.
The only circumstance I can think of—even so, the circumstance I think about is our company will go out of business next week if we don’t have this feature. I think that’s totally arbitrary, but I’ve heard that one. But if we ship that feature and we have that feature, but it doesn’t work properly and it’s buggy, is that actually going to help us? Right? Is that actually going to help us stay in business? I would be dubious as to that. Maybe we can try and hide it. A good example of that being successful is Zoom during the pandemic, right? They succeeded. I actually don’t understand why they didn’t get more crap for it, but what they did was when the pandemic happened and everybody started working from home, their user base massively multiplied, right? Very, very quickly, massively multiplied. And what they found was that their systems could not support that number of users.
But if you start capping users, right, and saying to people, “No, we can’t have another user on the system,” they’re going to go somewhere else. They’re going to go to your competitors. They’re going to go to Teams. They’re going to go to WebEx. They’re going to go to somebody else. So you don’t want to do that, right? Good business practice is—sorry, what good? That’s one of those could be either way. Moral and ethical business practice would have you either cap the number of users until you can increase capacity and bring on more people, bring on more capability, right? But Zoom chose a different route. They decided that maintaining that user curve and supporting it was more important. So they started systematically building features more quickly at lower quality. They started ignoring security concerns because security is a lot of your cost, right, for building stuff, validating and checking. So let’s cut all of that, and then we can build more stuff.
And they deliberately turned off encryption. So one of Zoom’s selling points was end-to-end encryption. But end-to-end encryption adds about 40% load. I’m just ballparking that. I’m sure there’s all sorts of variations there, but 40% load. So they can immediately have 40% more users stable on the system by turning off encryption. But they didn’t want to turn off encryption and tell their users they were turning off encryption because that was a huge selling point for the product, having encryption. And what would existing users do if they were told that it was encrypted? So there was a little green light in the corner of Zoom, and it was the encryption light, and it would go green when the communication was encrypted. They turned off the encryption, but they changed the code so the light continued to be green. Right? That’s a reduction in quality. That’s a massive, massive business risk, and they were caught. And that had a massive impact on their brand awareness and a massive impact on their business.
There are still companies today that have Zoom blocked as a product within their organisational network that they will not allow it to be used, and it’s because of that moral and ethical decision that was made at senior levels of that organisation to reduce quality, reduce stability of features that users expected to work effectively. They did. They were even worse. They kind of lied. It’s kind of like the Volkswagen scandal a little bit, right? Except I don’t think anybody died. But don’t reduce quality in order to ship features quicker. It has an impact, and it has—because we’re building complex systems, it often has an impact you’re not expecting. It often pushes you into a corner, and you’re then left with those moral and ethical decisions, and you have to go a particular way. One’s going to suck, and one’s going to be nefarious. And quite often, we as humans pick the nefarious one because it’s easier, cheaper, more manageable in order to do that.
So how do you strike a balance between speed and stability? Stability is more important than speed—much, much, much more important than speed. Stability and quality is much more important than speed. Pay the fine if you have to pay the fine, but do things well and do things properly.
