IMO this a product/leadership horror story, not necessarily a technology horror story. The issue is that the right feature wasn't built – or it was built in a way that required new processes from the customer. When that happens, the methodology and timeline of its release isn't the cause of the failure – it would have always been poorly received. There is a missing 'product' role here – a person or team that is in constant conversation with the customer and ultimately responsible for features make it into the product.
You're right on about compliance. So a CD "culture" or structure isn't a drop-in solution for every business. Some industries simply should not be releasing new ui changes or features all the time.
CD isn't always about features, though. Sometimes it's about performance, security or technical debt. In fact, a trusted CD process is a potential solution to this type of "bad feature" issue, allowing for fast backpedaling.
When talking about features, it is totally true that customers don't want change. They don't even want the "product", what they want is what your product enables them to achieve. They're hiring your product to get their job done. Compassion includes being on that journey with them when scenarios change.
An example: your customer's industry has a new legal regulation that requires them to change how they work (or let's say, a global pandemic occurs and changes everything 😉 ). In this scenario, compassion for the customer means anticipating their needs, and releasing changes as quickly and confidently as possible – as the situation evolves. This responsiveness is what CD enables.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
IMO this a product/leadership horror story, not necessarily a technology horror story. The issue is that the right feature wasn't built – or it was built in a way that required new processes from the customer. When that happens, the methodology and timeline of its release isn't the cause of the failure – it would have always been poorly received. There is a missing 'product' role here – a person or team that is in constant conversation with the customer and ultimately responsible for features make it into the product.
You're right on about compliance. So a CD "culture" or structure isn't a drop-in solution for every business. Some industries simply should not be releasing new ui changes or features all the time.
CD isn't always about features, though. Sometimes it's about performance, security or technical debt. In fact, a trusted CD process is a potential solution to this type of "bad feature" issue, allowing for fast backpedaling.
When talking about features, it is totally true that customers don't want change. They don't even want the "product", what they want is what your product enables them to achieve. They're hiring your product to get their job done. Compassion includes being on that journey with them when scenarios change.
An example: your customer's industry has a new legal regulation that requires them to change how they work (or let's say, a global pandemic occurs and changes everything 😉 ). In this scenario, compassion for the customer means anticipating their needs, and releasing changes as quickly and confidently as possible – as the situation evolves. This responsiveness is what CD enables.