Balancing Speed and Stability in Delivery

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.