Really great article and its great see a different perspective on “move fast and break things”.
For us, our primary constraint is we don’t have an experimental customer. Our customers expect deliveries to work, they don’t want to be part of the engineering team practices but they do want to be kept informed and have a say. I admit I do have envy with those teams where the customer plays an active role in the engineering process. Our customer, does not want us to break things regardless of the benefit we’re trying to find.
Over the last couple of years as we’ve got smaller, we’ve got better. So the teams are finding it easier to collaborate and communicate now, than when we were double the size and that I think has been the main source of improvement. We develop less more frequently and focus on doing each feature well and have reduced how much we’re impacted. We still have the odd incident but they’re either environmental or a misunderstanding (i.e. we didn’t ask the right questions earlier).
So now we have the right dynamic and culture in the team to manage deployments better, we need to be careful that when we start to grow again (which of course is the business ambition) we need to learn from the past and build out teams carefully so we keep the same people dynamics and just keep improving the quality engineering practices.