Back to Home

Obviously this is urgent

"The business is on fire!"
--Head of Engineering

The deployment problem

The deployment pipeline has been down for a week. This was for the main project for the main client of a software consultancy. No new features could be deployed and the client was getting increasingly frustrated. The Head of Engineering has been chasing the DevOps Lead to have the problem fixed. There was of course always other work to be done, including some projects with set deadlines looming. The Head of Engineering understood that the DevOps Lead had a lot going on, both at work and in their personal life, which is what they suspect is causing the delay in getting the problem fixed. However, the stress and pressure from the main client was mounting and the Head of Engineering feared they were losing the confidence of their most important customer.

The Head of Engineering has tried saying many things to get the DevOps Lead to fix the problem:

-The business is suffering.
-It'd be really great if you could prioritise this.
-Can you let me know when you'd be able to get it done?
-People are unable to do their work.
-Business is losing productivity.

The DevOps Lead would respond saying they would "get to it soon" but nothing would be fixed. Time is passing and the client is getting increasingly agitated at the lack of visible progress because new features are not being released on schedule.

The DevOps Lead would respond saying they would "get to it soon" but nothing would be fixed. Time is passing and the client is getting increasingly agitated at the lack of visible progress because new features are not being released on schedule.

The Communication Gap

The Head of Engineering thought that inability to deploy new features was obviously an urgent problem. "Deployment is down, isn't that obviously urgent?", he had told us. However, this was an assumption, there was nothing in the initial attempts to get the DevOps Lead to fix the pipeline that explained why deployment was an urgent issue. Saying things like "People were unable to do their work" and "Business is losing productivity" may not land because they are vague, and likely the DevOps saw people were doing other work.

Solution

We coached the Head of Engineering to have the following conversation:

I'd like the fixing of this deployment pipeline to be given the highest priority. I'm worried we are losing the trust and goodwill of our main client because regular feature releases are the indicator they rely on to maintain confidence in our team.

Outcome

After this conversation, the DevOps Lead immediately fixed the deployment pipeline within a few hours. In a later discussion it was revealed that the DevOps Lead had not understood why the ability to make feature releases on this project was important relative to the other projects with fixed deadlines. Unlike the other projects, there was no impending fixed deadline for this project. The DevOps Lead was tracking progress on the non-deployed features and they were going as planned, even though they weren't being deployed to production. The DevOps Lead had not realised how much their main client needed to see regular feature releases to maintain faith in the team.

Take-Home lessons

Don't assume others understand why something is important.The Head of Engineering needed to explain that the ability to release new features was crucial to maintaining the client's confidence. It was only when the Head of Engineering explicitly stated the concern of losing the trust of the client that the DevOps Lead understood the urgency of the request.



*Due to the sensitive nature of our case studies, names and details have been changed to be anonymous.

Want help for your organization?

Contact Us
or email us at: info@diplomacydojo.com