Today, a client of mine cancelled their meeting with me five minutes before we were about to start. Having meetings cancelled on you is a fact of life when you’re selling software. But I always find the reasons why they have cancelled the meetings interesting.
The reason today was “Sorry, we are having development and production issues,” in a nice, apologetic tone. Reading between the lines what she really wanted to say was “we did a migration last night to production and it subsequently set fire to the village,” or something perhaps more explicative than that.
I felt for them, cancelling so abruptly. They’re probably buried under loads of extra, unplanned work now, trying to get things back to where they were yesterday. The real kicker is that this is the third time they have had to reschedule.
What is more interesting is that the other reasons I get are all in the same ballpark; “we had a P1 this morning and we’re still trying to resolve it,” or “we had a failed migration last night and we’re picking up the pieces.”
It is the perennial problem in IT and DevOps, caused mainly by a lack of insight and action between development and production systems. And in the contact center industry, for example, even the tiniest of changes in production could cause havoc when migrating something upstream into it. It causes project slippage, missed deadlines, erosion of client trust and CX as well as tons of unplanned work, which is particularly toxic.
Unplanned work is expensive, time-consuming, and sends shockwaves across all other projects you may be working on. It also saps your highest skilled resources, which, incidentally, are likely to be the resources you have the least amount of. Which is why it hurts all the more.
Two methods of mitigating this are:
- Increase communication flow between dev and prod to relevant changes
- Widen the bottleneck to migrate configuration up and down stream faster without tying up your constrained skill base
When you increase communication flow, your developers will be alerted to production changes that directly impact their development activities. They should also be able to run instant comparisons against critical systems to see if they need to consider specific changes during their development sprints. This fundamentally, avoids the failed deployments. Or at least, reduces the likelihood of it happening.
And by widening the bottleneck, I refer to automating the activity of migration of configuration, including creating a build of config and other jobs, scheduling it, and rolling it back if it isn’t right. This turns hours of work into mere minutes, and if something does go wrong, the abiltiy to rollback mitigates the impact of unplanned work.
For those attending the Xchange roadshow events, you will be able to see how our software does this in real time.
I suppose the good news here is that when we do, eventually, get on a call with my client, we will be able to really help them.
Feel free to visit our website at https://www.theblackchair.com.
